Differences

This shows you the differences between two versions of the page.

--- ris_operation_tutorial [2026/09/04 14:40] – cmorin
+++ ris_operation_tutorial [2026/09/04 14:42] (current) – cmorin
@@ Line 1: / Line 1: @@
 # RIS Operation Tutorial
-To Fill In
 **This Tutorial assumes that you have followed the basic CorteXlab operation tutorials (at least [[running_your_first_experiment|GNU Radio benchmark example]], and [[bokehgui_for_cortexlab|Eyes and ears inside CorteXlab]], but [[running_your_task_interactively|GNU Radio benchmark, interactive command execution]] and [[gnu_radio_docker_benchmark_example|GNU Radio benchmark example with docker]] are recommended)**
@@ Line 170: / Line 168: @@
 On top of that, we have quite a few elements to interact with the RIS.
-The main one sits inside the HTTP Helper block. It's a custom Python block to make the HTTP requests to the RIS server. Its code is inside ''power_reader_epy_block_0.py'' and looks like this:
+The main one sits inside the HTTP Helper block. It's a custom Python block to make the HTTP requests to the RIS server. Its code is inside ''power\_reader\_epy\_block\_0.py'' and looks like this:
 <code>
@@ Line 247: / Line 245: @@
         self.my_log.warn(f"Angle Tx = {TX_elevation} RX = {RX_elevation}")
 </code>
-All its functions send HTTP requests through the ''requests'' module to the relevant API endpoints on the RIS server, except for the ''ref_optim'' function where a ''curl'' subprocess is used to avoid freezing the display while the request runs.
+All its functions send HTTP requests through the ''requests'' module to the relevant API endpoints on the RIS server, except for the ''ref\_optim'' function where a ''curl'' subprocess is used to avoid freezing the display while the request runs.
 As you can see with their parameters, all the Bokeh GUI Button blocks are there to call functions of this HTTP Helper block.
-All this is sufficient for all RIS commands, except for, again, the ''/ref_optimization'' endpoint.
+All this is sufficient for all RIS commands, except for, again, the ''/ref\_optimization'' endpoint.
-This one requires feedback to evaluate the configuration it tries, in the form of another HTTP server, replying with a float value, whenever queried on the ''/power_feedback'' endpoint.
+This one requires feedback to evaluate the configuration it tries, in the form of another HTTP server, replying with a float value, whenever queried on the ''/power\_feedback'' endpoint.
 In our case, it's implemented inside of the same RX flowgraph, as a python snippet this time, that contains the following:
@@ Line 278: / Line 276: @@
 </code>
-We setup a Flask server inside of a separate thread, that implements only the ''/power_feedback'' endpoint.
+We setup a Flask server inside of a separate thread, that implements only the ''/power\_feedback'' endpoint.
 And that endpoint queries the Probe Signal block at the end of the flowgraph to respond with the latest computed average received power.