Guided Tutorial GNU Radio in C++

= Tutorial: Working with GNU Radio in C++ = NOTE: This tutorial applies only to GR Release 3.7

Objectives

 * Extend our knowledge to program GNU Radio using C++.
 * An introduction to GNU Radio's C++ API, in particular:
 * types
 * generic functions
 * GNU Radio blocks
 * Learn to manage and write our own OOT modules in C++.
 * We follow our discussions based on a working example by continuing to work on our OOT module.
 * Within the tutorial module, we will build our QPSK demodulator called as My QPSK Demodulator in C++.
 * Understand the nuances of developing an OOT module.
 * The tutorial considers some advance topics that are also part of GNU Radio framework.
 * These topics find their usage for some specific implementations of the OOT module.

Prerequisites

 * Knowledge of C++
 * Previous tutorials recommended:
 * A brief introduction to GNU Radio, SDR, and DSP
 * Intro to GR usage: GRC and flowgraphs

= Creating our OOT module =

We will now use gr_modtool to create an OOT module and write our block in C++.

Objective
When this tutorial is complete, we will be able to build this flow graph:



The flowgraph demonstrates a QPSK transceiver chain with the block My QPSK Demodulator block module under the OOT tutorial. We will be building this block using C++. All other blocks are standard GNU Radio blocks.

My QPSK Demodulator consumes QPSK symbols which are complex values at the input and produces the alphabets as bytes at output. The output screen looks like this:



Step 1: Create an OOT module
xyz@comp:mydir$ gr_modtool newmod tutorial Creating out-of-tree module in ./gr-tutorial... Done. Use 'gr_modtool add' to add a new block to this currently empty module.

Take a look at the directory structure of our

xyz@comp:mydir$ cd ~/gr-tutorial xyz@comp:mydir/gr-tutorial$ ls apps cmake  CMakeLists.txt  docs  examples  grc  include  lib  MANIFEST.md  python  swig

Note: The file MANIFEST.md was not added prior to GR 3.8.

Step 2: Insert My QPSK Demodulator block into the OOT module
Again using, inside  , we create our   block:

xyz@comp:mydir/gr-tutorial$ gr_modtool add my_qpsk_demod_cb GNU Radio module name identified: tutorial ('sink', 'source', 'sync', 'decimator', 'interpolator', 'general', 'tagged_stream', 'hier', 'noblock') Enter block type: general Language (python/cpp): cpp Language: C++ Block/code identifier: my_qpsk_demod_cb Please specify the copyright holder: gnuradio.org Enter valid argument list, including default arguments: bool gray_code Add Python QA code? [Y/n] Y Add C++ QA code? [y/N] N Adding file 'lib/my_qpsk_demod_cb_impl.h'... Adding file 'lib/my_qpsk_demod_cb_impl.cc'... Adding file 'include/tutorial/my_qpsk_demod_cb.h'... Editing swig/tutorial_swig.i... Adding file 'python/qa_my_qpsk_demod_cb.py'... Editing python/CMakeLists.txt... Adding file 'grc/tutorial_my_qpsk_demod_cb.block.yml'... Editing grc/CMakeLists.txt...

Unlike creating an OOT module, creating a block using  demands inputs from the user. To follow the command line user interaction, let's decompose the information above.

xyz@comp:mydir/gr-tutorial$ gr_modtool add my_qpsk_demod_cb

represents the class name of the block, where the suffix, 'cb' is added to the block name, which conforms to the GNU Radio nomenclature. 'cb' states the block takes complex data as input and produces bytes as output.

Enter code type: general

In GNU Radio, there exist different kinds of blocks with the different possibilities listed above (since 3.8). Depending on the choice of our block,  adds the corresponding code and functions. As illustrated, for  block, we opt for a general block.

Please specify the copyright holder:

Since version 3.8, the tool asks for a copyright holder for the code you are about to write. The implications of what you write in that line are legal and not computational.

For, gray_code is selected to be "default arguments".

Enter valid argument list, including default arguments: bool gray_code

GNU Radio provides an option of writing test cases. This provides quality assurance to the code written. If selected, the  adds the quality assurance files corresponding to python and C++.

Add Python QA code? [Y/n] Add C++ QA code? [y/N] y

With this, we have already established the GNU Radio semantics for our block coupled with the OOT module. In the following sections, we will focus on the implementation of our block.

The detailed description of coding structure for the block can be found here

Step 3: Fleshing out the code
The next step is to implement the logic for our block. Use your text editor on the file.

The completed code is listed at the end of this section, but study the following first!

The skeleton of the  has the following structure:


 * is the constructor of the block .   calls the constructor of the base class block   defined here.


 * The arguments inside  represents the block name and a call to the make function.


 * The make function  and   is a member function of the class   that signifies the input and output port/s.


 *  and  represents the maximum and number of ports.


 *  and  indicates the datatypes for the input and output port/s which needs to be filled out manually.

Next, we need to modify the constructor. After modification, it looks like this:

The option  is copied to the class attribute. Note that we need

to declare this a private member of the class in the header file ,

Also inside this class is the method, which is pure virtual in  , so we definitely need to override that. After running, the skeleton version of this function will look something like this:

There is one pointer to the input- and one pointer to the output buffer, respectively, and a for-loop which processes the items in the input buffer and copies them to the output buffer. Once the demodulation logic is implemented, the structure of the work function has the form

This work function calls another function, which we also need to add:

Note: the get_minimum_distances function declaration also needs to be added to the class header.

The function  is a maximum likelihood decoder for the QPSK demodulater. Theoretically, the function should compute the distance from each ideal QPSK symbol to the received symbol (It is mathematically equivalent to determining the Voronoi regions of the received sample). For a QPSK signal, these Voronoi regions are simply four quadrants in the complex plane. Hence, to decode the sample into bits, it makes sense to map the received sample to these quadrants.

Now, let's consider the  function. The system needs to know how much data is required to ensure validity in each of the input arrays. As stated before, the  method provides this information, and you must therefore override it anytime you write a   derivative (for sync blocks, this is implicit).

The default implementation of  says there is a 1:1 relationship between noutput_items and the requirements for each input stream. The size of the items is defined by  in the constructor of. The sizes of the input and output items can of course differ; this still qualifies as a 1:1 relationship. Of course, if you had this relationship, you wouldn't want to use a !

Although the 1:1 implementation worked for, it wouldn't be appropriate for interpolators, decimators, or blocks with a more complicated relationship between   and the input requirements. That said, by deriving your classes from,   or   instead of  , you can often avoid implementing.

Refilling the private constructor and overriding the  and   will suffice the coding structure of our block. However, in the  class there exists more specific functions. These functions are covered under advanced topics section

Here is the completed source code:

Step 4: Flesh out the XML file
The .xml provides the user interface between the OOT module displayed in the GRC and the source code. Moreover, the XML file defines an interface to pass the parameters specific for the module. Hence, to access the module inside GRC, it is important to modify the .xml files manually. The XML file for our block is named as  inside the   folder. Presently, the 's version looks like:

Default version:  my_qpsk_demod_cb tutorial_my_qpsk_demod_cb tutorial import tutorial tutorial.my_qpsk_demod_cb($gray_code) ...    ...     ...

in

The parameter  can be put under the   tag.

Adding parameter tag:

 Gray Code gray_code True bool Yes True No      False

Like the work function, the datatypes for the input and output ports represented by  and   tags should be modified.

Modifying source and sink tag:

in    complex

After all the necessary modification the "tutorial_my_qpsk_demod_cb.xml" looks like this:

Modified version:

 My QPSK Demodulator tutorial_my_qpsk_demod_cb tutorial import tutorial tutorial.my_qpsk_demod_cb($gray_code) Gray Code gray_code True bool Yes True No      False in    complex

Step 4 bis: Flesh out the YAML file
Since version 3.8, GNU Radio has replaced the XML files by YAML. They work the same but with a different syntax.

The .yml provides the user interface between the OOT module displayed in the GRC and the source code. Moreover, the YAML file defines an interface to pass the parameters specific for the module. Hence, to access the module inside GRC, it is important to modify the .yml files manually. The YAML file for our block is named as  inside the   folder. Presently, the 's version looks like:

Default version: id: tutorial_my_qpsk_demod_cb label: my_qpsk_demod_cb category: '[tutorial]'

templates: imports: import tutorial make: tutorial.my_qpsk_demod_cb(${gray_code})

parameters: - id: ... label: ...  dtype: ... - id: ... label: ...  dtype: ...
 * 1)  Make one 'parameters' list entry for every parameter you want settable from the GUI.
 * 2)     Keys include:
 * 3)     * id (makes the value accessible as \$keyname, e.g. in the make entry)
 * 4)     * label (label shown in the GUI)
 * 5)     * dtype (e.g. int, float, complex, byte, short, xxx_vector, ...)

inputs: - label: ... domain: ...  dtype: ...  vlen: ...  optional: ...
 * 1)  Make one 'inputs' list entry per input and one 'outputs' list entry per output.
 * 2)  Keys include:
 * 3)      * label (an identifier for the GUI)
 * 4)      * domain (optional - stream or message. Default is stream)
 * 5)      * dtype (e.g. int, float, complex, byte, short, xxx_vector, ...)
 * 6)      * vlen (optional - data stream vector length. Default is 1)
 * 7)      * optional (optional - set to 1 for optional inputs. Default is 0)

outputs: - label: ... domain: ...  dtype: ...  vlen: ...  optional: ...

file_format: 1
 * 1)  'file_format' specifies the version of the GRC yml format used in the file
 * 2)  and should usually not be changed.

The parameter  can be put under the   tag.

Adding parameter tag:

parameters: - id: gray_code label: Gray Code dtype: bool default: 'True'

Like the work function, the datatypes for the input and output ports represented by  and   tags should be modified.

Modifying source and sink tag:

inputs: - label: in dtype: complex outputs: - label: out dtype: byte

After all the necessary modification the "tutorial_my_qpsk_demod_cb.block.yml" looks like this:

Modified version:

id: tutorial_my_qpsk_demod_cb label: My QPSK Demodulator category: '[tutorial]'

templates: imports: import tutorial make: tutorial.my_qpsk_demod_cb(${gray_code})

parameters: - id: gray_code label: Gray Code dtype: bool default: 'True'

inputs: - label: in dtype: complex outputs: - label: out dtype: byte

file_format: 1

Step 5: Install my_qpsk_demod in grc
Now that we have finished the implementation of our block, we need to build and install it. To do so, execute the following commands:

cd ~/gr-tutorial mkdir build cd build cmake ../ make sudo make install sudo ldconfig

Step 6: Quality Assurance (Unit Testing)
In the previous steps of writing the OOT module, we produced the QPSK demodulator, but it doesn't guarantee the correct working of our block. In this situation, it becomes significant to write a unit test for our module that certifies the clean implementation of the QPSK demodulator.

Below is the source of code of the  can be found under

Full QA code

Obviously the  is implemented in python, in spite of we opted C++ in the first case for writing our blocks. This is because GNU Radio inherits the python unittest framework to support quality assurance. And, if you remember it correctly from previous tutorials, swig as part of GNU Radio framework, provides python bindings for the C++ code. Hence, we are able to write the unit test for our block  in Python.

So lets gather a bit of know how on how to write test cases for the block. Okay, lets consider the header part first:

and  are the standard lines that includes gr, gr_unittest functionality in the   file. import the python bidden version of our module, which provides an access our block. Finally,  includes array.

The  file execution start by calling this function. The  automatically calls the functions in a specific order   for creating the top block at the start,   for deleting the top block at the end. In between the  and   the test cases defined are executed. The methods starting with prefix  are recognized as test cases by. We have defined two test cases  and. The usual structure of a test cases comprises of a known input data and the expected output. A flowgraph is created to include the source (input data), block to be tested (processor) and sink (resulted output data). In the end the expected output is compared with the resulted output data.

Finally, the statements in the test cases

determine the result of test cases as passed or failed. The test cases are executed before installation of the module by running  yielding the following output: barry@barry:~/gr-tutorial/build$ make test Running tests... Test project /home/barry/gr-tutorial/build Start 1: test_tutorial 1/2 Test #1: test_tutorial .................... Passed   0.02 sec Start 2: qa_my_qpsk_demod_cb 2/2 Test #2: qa_my_qpsk_demod_cb .............. Passed   1.01 sec

100% tests passed, 0 tests failed out of 2

Total Test time (real) =  1.04 sec

Congratulations, we have just finished writing our OOT module  and a C++ block.

= Advanced topics =

The topics discussed until now have laid the foundation for designing the OOT module independently. However, the GNU Radio jargon extends further beyond these. Therefore, under this section, we drift from the QPSK demodulator and focus on the features that are rarely used or are more specific to the implementation.

To add physical meaning to the discussion, we have taken assistance of the existing modules. The source code excerpts are included thereof. Enthusiastic readers are suggested to open the source code in parallel and play around with their functionalities.

Specific functions related to block
In the last section, we managed out implementation of our block by defining functions like  and. But sometimes special functions need to be defined for the implementation. The list is long, but we try to discuss same of these functions in the following subsections.

set_history
If your block needs a history (i.e., something like an FIR filter), call this in the constructor.

Here is an example

GNU Radio then makes sure you have the given number of 'old' items available.

The smallest history you can have is 1, i.e., for every output item, you need 1 input item. If you choose a larger value, N, this means your output item is calculated from the current input item and from the N-1 previous input items.

The scheduler takes care of this for you. If you set the history to length N, the first N items in the input buffer include the N-1 previous ones (even though you've already consumed them).

The history is stored in the variable.

The  is defined in

set_output_multiple
When implementing your  routine, it's occasionally convenient to have the run time system ensure that you are only asked to produce a number of output items that is a multiple of some particular value. This might occur if your algorithm naturally applies to a fixed sized block of data. Call  in your constructor to specify this requirement,

by invoking, we set the value variable to. The default value of  is 1.

Lets consider an example, say we want to generate outputs only in a 64 elements chunk, by setting d_output_multiple to 64 we can achieve this, but note that we can also get multiples of 64 i.e. 128, 256 etc

The definition of  can be found in gnuradio/gnuradio-runtime/block.cc

Specific block categories
Again the implementation of the  was done using a general block. However, GNU Radio includes some blocks with special functionality. A brief overview of these blocks is described in the table.

In the next subsections we discuss these blocks in detail. Again, enthusiastic readers can find these blocks in the GNU Radio source code.

Source
An example of source block in C++

Some observations:


 * sets the input items to 0, in indicates there are no input streams.
 * Because it connected with the hardware USRP, the  is a sub class of.

Sink
An example of the sink block in C++

Some observations:


 * sets the output items to 0, in indicates there are no output streams.
 * Because it connected with the hardware USRP, the  is a sub class of.

Sync
The sync block allows users to write blocks that consume and produce an equal number of items per port. A sync block may have any number of inputs or outputs. When a sync block has zero inputs, its called a source. When a sync block has zero outputs, its called a sink.

An example sync block in C++:

Some observations:


 * noutput_items is the length in items of all input and output buffers
 * an input signature of gr::io_signature::make(0, 0, 0) makes this a source block
 * an output signature of gr::io_signature::make(0, 0, 0) makes this a sink block

Decimation
The decimation block is another type of fixed rate block where the number of input items is a fixed multiple of the number of output items.

An example decimation block in c++

Some observations:


 * The gr_sync_decimator constructor takes a 4th parameter, the decimation factor
 * The user must assume that the number of input items = noutput_items*decimation. The value  is therefore implicit.

Interpolation
The interpolation block is another type of fixed rate block where the number of output items is a fixed multiple of the number of input items.

An example interpolation block in c++

Some observations:


 * The gr_sync_interpolator constructor takes a 4th parameter, the interpolation factor
 * The user must assume that the number of input items = noutput_items/interpolation

Hierarchical blocks
Hierarchical blocks are blocks that are made up of other blocks. They instantiate the other GNU Radio blocks (or other hierarchical blocks) and connect them together. A hierarchical block has a "connect" function for this purpose.

When to use hierarchical blocks?

Hierarchical blocks provides us modularity in our flowgraphs by abstracting simple blocks, that is hierarchical block helps us define our specific blocks at the same time provide us the flexibility to change it, example, we would like to test effect of different modulation schemes for a given channel model. However our synchronization algorithms are specific or newly published. We define our hier block as gr-my_sync that does synchronization followed equalizer and demodulation. We start with BPSK, the flowgraph looks like

gr-tx ---> gr-channel --> gr-my_sync --> gr-equalizer --> gr-bpsk_demod

Now, our flowgraph looks decent. Secondly, we abstracted the complex functionality of our synchronization. Shifting to QPSK, where the synchronization algorithm remains the same, we just replace the gr-bpsk_demod with gr-qpsk_demod

gr-tx ---> gr-channel --> gr-my_sync --> gr-equalizer --> gr-qpsk_demod

How to build hierarchical blocks in GNU Radio?

Hierarchical blocks define an input and output stream much like normal blocks. For I input streams, let i be a value between 0 and I-1. To connect input i to a hierarchical block, the source is (in Python):

Similarly, to send the signal out of the block on output stream o:

An typical example of a hierarchical block is OFDM Receiver implemented in python under gnuradio/gr-digital/python/digital

The class is defined as:

and instantiated as

Some main tasks performed by the OFDM receiver include channel filtering, synchronization and IFFT tasks. The individual tasks are defined inside the hierarchical block.


 * Channel filtering


 * Synchronization


 * ODFM demodulation

Finally, the individual blocks along with hierarchical are connected among each to form a flow graph.

Connection between the hierarchical block OFDM receiver to channel filter block

Connection between the channel filter block to the OFDM synchronization block.

and so forth.

Hierarchical blocks can also be nested, that is blocks defined in hierarchical blocks could also be hierarchical blocks. For example, OFDM sync block is also an hierarchical block. In this particular case it is implemented in. Lets have a look into it.

Underneath is instant of the hierarchical block. Don't panic by looking at its size, we just need to grab the concept behind creating hierarchical blocks.

OFDM impl

Let's understand the code piece wise. The hierarchical block is C++ is instantiated as follows:

where  is the constructor with parameters   and   is the base class. The block name  is defined following the GNU Radio block naming style.

defines my input items and the output items are either

or

depending on the preprocessor directive.

The individual blocks inside the  block are defined as follows:

Finally the individual blocks are connected using:

-

[1] http://radioware.nd.edu/documentation/advanced-gnuradio/writing-a-signal-processing-block-for-gnu-radio-part-i