CorteXlab's Wiki

User Tools

Site Tools

Trace:
from_gnuradio_to_cortxlab_pico

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
from_gnuradio_to_cortxlab_pico [2016/07/29 17:20] – [tx_ofdm.grc] lbesemefrom_gnuradio_to_cortxlab_pico [2017/11/15 16:19] (current) – [Create the scenario] onicolas
Line 1: Line 1:
-# From GNU Radio to CorteXlab (Using PicoSDRs)+# From A to Z: GNU Radio with CorteXlab using PicoSDRs
  
-This tutorial goes through the process of executing an experiment on CorteXlab starting from an empty project on your computer. (and is quite similar with [[from_gnuradio_to_cortxlab|this tutorial]], but this time we are using PicoSDRs) +This tutorial goes through the process of executing an experiment on CorteXlab starting from an empty project on your computer (and is quite similar to [[from_gnuradio_to_cortxlab|this tutorial]], but this time we are using PicoSDRs).
  
-For practical purposes, we will use some GnuRadio examples instead of starting from a clean sheet, but it's exactly the same as if you had your own project you wanted to run on CorteXlab.+For practical purposes, we will use some GNU Radio examples instead of starting from a clean sheet, but it's exactly the same as if you had your own project you wanted to run on CorteXlab.
  
 ##Setup ##Setup
  
-The purpose of this tutorial is to execute an OFDM transmission between two PicoSDR nodes. One node will be the transmitter and the other one will be the receiver. Instead of starting from an empty project, we are going to use 2 GNU Radio Companion examples. Copy the files ''tx\_ofdm.grc'' and ''rx\_ofdm.grc'' located in ''$path/To/toolchain/share/gnuradio/examples/digital/ofdm'' to a new folder.+The purpose of this tutorial is to execute an OFDM transmission between two PicoSDR nodes. One node will be the transmitter and the other one will be the receiver. Instead of starting from an empty project, we are going to use a GNU Radio example. Copy the files ''tx\_ofdm.grc'' and ''rx\_ofdm.grc'' located in ''$path\_to\_gnuradio/examples/digital/ofdm'' to a new folder.
  
 As you can guess ''tx\_ofdm.grc'' will be used for the ofdm transmitter and ''rx\_ofdm.grc'' for the ofdm receiver. As you can guess ''tx\_ofdm.grc'' will be used for the ofdm transmitter and ''rx\_ofdm.grc'' for the ofdm receiver.
Line 27: Line 27:
 ### tx_ofdm.grc ### tx_ofdm.grc
  
-Open ''tx\_ofdm.grc'' with GRC. As you can see we have all the process from OFDM encoding to OFDM decoding, but transmission and decoding parts are just a modelisation. +Open ''tx\_ofdm.grc'' with GRC. As you can see we have all the process from OFDM encoding to OFDM decoding, but the transmission and decoding parts are just a modelisation. 
  
-The first thing to do is to change the generate options in order to have a 'No GUI' project (the results will be stored in a file). Open the Options block (in the top left corner) and switch the Generate Options from ''QT GUI'' to ''No GUI''. By doing this the blocks ''QT GUI Time Sink'' and ''QT GUI Frequency Sink'' can't be generated anymore (their name turn red with a an error message if you open them) so we have to remove them from the graph.+The first thing to do is to change the generate options in order to have a 'No GUI' project (the results will be stored in a file). Open the Options block (in the top left corner) and switch the Generate Options from ''QT GUI'' to ''No GUI''. By doing this the blocks ''QT GUI Time Sink'' and ''QT GUI Frequency Sink'' can't be generated anymore (their names turn red with an error message if you open them) so we have to remove them from the graph.
  
  
-Set the samp\_rate variable to 5000000 (5 MHz) using the corresponding variable block located in top of the flow graph.+Set the samp\_rate variable to 5000000 (5 MHz) using the corresponding variable block located at the top of the flow graph.
  
-Then we need to add mandatory blocks needed in order to use a PicoSDR :  +Then we need to add some mandatory blocks in order to use a PicoSDR :  
  
  
Line 105: Line 105:
  
  
-The input of the last custom register must be connected with a Constant Source block set to 1. The constant source need to output an int and to be connected with the custom register.+The input of the last custom register must be connected with a Constant Source block set to 1. The constant source needs to output an int and to be connected with the custom register.
  
  
  
  
-The next thing to do is to replace transmission and decoding parts to put instead a ''RTDEX Sink'' block. The parameters of this block are :  +The next thing to do is to replace the transmission and decoding parts to put a ''RTDEX Sink'' block instead. The parameters of this block are :  
 -> **Target ID** : nutaq\_carrier\_perseus\_0   -> **Target ID** : nutaq\_carrier\_perseus\_0  
 -> **Block priority** : 3   -> **Block priority** : 3  
Line 131: Line 131:
 ### rx_ofdm.grc ### rx_ofdm.grc
  
-Open ''rx\_ofdm.grc'' with GRC. As you can see it's quite similar with tx_ofdm, except this time the encoder part is a modelisation and the decoder part faithfully describe the decoding process.+Open ''rx\_ofdm.grc'' with GRC. As you can see it's quite similar to tx_ofdm, except this time the encoder part is a modelisation and the decoder part faithfully describes the decoding process.
  
 The first thing to do is to change the generate options in order to have a 'No GUI' project (the results will be stored in a file). Open the Options block (in the top left corner) and switch the Generate Options from ''QT GUI'' to ''No GUI''. The first thing to do is to change the generate options in order to have a 'No GUI' project (the results will be stored in a file). Open the Options block (in the top left corner) and switch the Generate Options from ''QT GUI'' to ''No GUI''.
  
-Set the samp\_rate variable to 5000000 (5 MHz) using the corresponding variable block located in top of the flow graph.+Set the samp\_rate variable to 5000000 (5 MHz) using the corresponding variable block located at the top of the flow graph.
  
-Then we need the same mandatory blocks than with tx\_ofdm, which are ''Carrier Perseus Board'', ''Radio420 RX'', ''Radio420 TX'' and three ''Custom Register''. We also use the same parameters as in [[#tx_ofdmgrc|tx_ofmd]]. (Pro tips : you can copy past a block from one graph to an other) +Then we need the same mandatory blocks as with tx\_ofdm, which are ''Carrier Perseus Board'', ''Radio420 RX'', ''Radio420 TX'' and three ''Custom Register''. We also use the same parameters as in [[#tx_ofdmgrc|tx_ofmd]]. (Pro tips : you can copy/paste a block from one graph to another). 
-  + 
-The next thing to do is to replace encoding and transmission parts to put instead a ''RTDEX Source'' block. The parameters of this block are :+We need to modify the frequency on the Tx block so as not to interfere with the transmitting node: 
 + 
 +* Radio420 RX (to set up RX radio front end)   
 +-> **TX frequency** : 2590000000   
 + 
 + 
 +The next thing to do is to replace the encoding and transmission parts to put a ''RTDEX Source'' block instead. The parameters of this block are :
 -> **Target ID** : nutaq\_carrier\_perseus\_0   -> **Target ID** : nutaq\_carrier\_perseus\_0  
 -> **Block priority** : 3   -> **Block priority** : 3  
Line 163: Line 169:
 ## Create the scenario ## Create the scenario
  
-The experiment description file called `scenario.desc` will be looked for and read by the experiment scheduler to get which nodes and what software will be used during the experiment. It also gives the necessary startup scripts and parameters that the user provides for his experiment.+The experiment description file called `scenario.yaml` will be looked for and read by the experiment scheduler to get which nodes and what software will be used during the experiment. It also gives the necessary startup scripts and parameters that the user provides for his experiment.
  
-Here is a simple example of a `scenario.desc` file:+Here is a simple example of a `scenario.yaml` file:
 <code> <code>
 # Example scenario description file # Example scenario description file
 # #
-#   All lines starting with "#" and empy lines are ignored+#   All lines starting with "#" and empty lines are ignored
  
  
 # Scenario textual description # Scenario textual description
 #   simple string (a one liner) #   simple string (a one liner)
-desc OFDM tx-rx example scenario for CorteXlab+description: OFDM tx-rx example scenario for CorteXlab
  
 # Experiment maximum duration # Experiment maximum duration
 #   Time after which the experiment is forced to stop #   Time after which the experiment is forced to stop
-#   integer (minutes) +#   integer (seconds) 
-durat 2+duration: 120
  
 # Node list # Node list
Line 185: Line 191:
 #   format: #   format:
 # #
-#   (machine): +#   nodes: 
-#   entry (entry point script relative to the task root) +#     (machine): 
-#   exit (exit point script relative to the task root. Use "none" for none) +#       command: (entry point script relative to the task root)
- +
-node29: +
-   entry rx_ofdm.py+
  
-node31: +nodes: 
-   entry tx_ofdm.py+  node29: 
 +    command: ./rx_ofdm.py 
 +  node31: 
 +    command: ./tx_ofdm.py
 </code> </code>
  
-This file uses its own syntax and is self-documented. Here the params line is mandatory even if it is not used (This will be changed in a future version). Adapt this example to suit your needs.+This file uses the yaml syntax and is self-documented. Adapt this example to suit your needs.
  
  
Line 207: Line 213:
 │   ├── tx_ofdm.py │   ├── tx_ofdm.py
 │   ├── rx_ofdm.py │   ├── rx_ofdm.py
-│   ├── scenario.desc+│   ├── scenario.yaml
 │   ├── tx_ofdm.grc │   ├── tx_ofdm.grc
 │   └── rx_ofdm.grc │   └── rx_ofdm.grc
Line 213: Line 219:
 </code> </code>
  
-The .grc will not be used by CorteXlab but you can let them in the same directory.+The .grc will not be used by CorteXlab but you can leave them in the same directory.
  
 ### Upload the files on airlock ### Upload the files on airlock
  
-Upload the tuto\_ofdm directory on Airlock as it is explained [[exp_upload|here]]. For example for Linux it will look like this : +Upload the tuto\_ofdm directory on Airlock. For example, for Linux, it will look like this : 
 <code> <code>
 you@your-pc:~$ scp -P 2269 -r path/to/tuto_ofdm username@gw.cortexlab.fr:~  you@your-pc:~$ scp -P 2269 -r path/to/tuto_ofdm username@gw.cortexlab.fr:~ 
Line 226: Line 232:
 ### Create the task ### Create the task
  
-Connect to Airlock through ssh as it is describe [[access|here]]. For example for Linux it will look like this : +Connect to Airlock through ssh. For example, for Linux, it will look like this : 
 <code> <code>
 you@yourpc:~$ ssh -p 2269 username@gw.cortexlab.fr you@yourpc:~$ ssh -p 2269 username@gw.cortexlab.fr
 </code> </code>
  
-You can find in your home directory the tuto\_ofdm directory that we have uploaded previously.+You will find in your home directory the tuto\_ofdm directory that we previously uploaded.
  
 Now, use the Minus CLI to create the task file: Now, use the Minus CLI to create the task file:
Line 238: Line 244:
 </code> </code>
  
-The success (or failure) of the creation will be printed on screen. The task file will be created at the same level and name than the targeted experiment folder but with a `.task` suffix, in our case ''tuto\_ofdm.task''.+The success (or failure) of the creation will be printed on screen. The task file will be created at the same level and with the same name as the targeted experiment folder but with a `.task` suffix, in our case ''tuto\_ofdm.task''.
  
 **Note:** You can get help on the Minus CLI at anytime with `minus -h` **Note:** You can get help on the Minus CLI at anytime with `minus -h`
Line 245: Line 251:
 ### Book the testbed with OAR ### Book the testbed with OAR
  
-As it is explain [[reserve|here]], we need to book the testbed with OAR in order to run our experiment. Once you have booked the platform, you will be the exclusive user of the testbed, avoiding experimentation interference.+As explained [[reserve|here]], we need to book the testbed with OAR in order to run our experiment. Once you have booked the platform, you will be the exclusive user of the testbed, avoiding experimentation interference.
  
 A basic example to submit an OAR interactive job requesting all available nodes, for 30 minutes: A basic example to submit an OAR interactive job requesting all available nodes, for 30 minutes:
Line 255: Line 261:
 Now, we have booked the testbed and we have a `.task` file containing our experiment. In order to run it, we need to submit it to the testbed scheduler. Now, we have booked the testbed and we have a `.task` file containing our experiment. In order to run it, we need to submit it to the testbed scheduler.
  
-For now, the scheduler is a simple FIFO queue, but a more advanced scheduling mechanism will be implemented in next versions of CorteXlab.+For now, the scheduler is a simple FIFO queue, but a more advanced scheduling mechanism will be implemented in upcoming versions of CorteXlab.
  
 To submit a task to the scheduler, use the Minus CLI: To submit a task to the scheduler, use the Minus CLI:
Line 270: Line 276:
 <code> <code>
 you@srvairlock:~$ minus testbed status you@srvairlock:~$ minus testbed status
-Testbed status: +num total tasks:   2540 
-ID count so far: 6 +num tasks waiting: 0 
-Number of awaiting jobs: 0 +num tasks running: 0 
-ID of the running job: None (None means server is idle)+tasks currently running: 
 +  (none)
 </code> </code>
  
Line 301: Line 308:
 you@srvairlock:~/results/task_15$ cd node29 you@srvairlock:~/results/task_15$ cd node29
 you@srvairlock:~/results/task_15/node29$ ls you@srvairlock:~/results/task_15/node29$ ls
-rx_ofdm.grc  scenario.desc  stdout.txt   tx_ofdm.py+rx_ofdm.grc  scenario.yaml  stdout.txt   tx_ofdm.py
 rx_ofdm.py   stderr.txt     tx_ofdm.grc rx_ofdm.py   stderr.txt     tx_ofdm.grc
 </code> </code>
from_gnuradio_to_cortxlab_pico.1469805601.txt.gz · Last modified: 2016/07/29 17:20 by lbeseme
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki