GNU Radio 3.10 OOT Module Porting Guide

The major changes in the GNU Radio 3.10 release that impact OOTs are:

• C++ modernization (C++17)
• Introduction of gr-pdu
• ATSC Block Refactoring
• New Logging Infrastructure
• OOT structure
• QT Frequency/Waterfall block ranges

There is a decent chance that your OOT doesn't actually require changes to be transitioned to 3.10.

Porting Guide

C++ modernization

GR 3.10 uses C++17 which allows some nice language features. Some might affect your OOT. Please document any needed changes here

Versioning Your shared object files

You may want to edit the /lib/CMakeList.txt file in order to set a version. The default VERSION_PATCH is set to git, you may want to edit it to 0 for your first version. Then when you need to push out a modified version remember to edit the version numbers before building. If you leave the VERSION_PATCH at git the install directory may eventually become littered with old libgnuradio-yourproject.so.git-commit-number files and soft links.

OOT Structure

3.10 restructures the OOT file structure to more closely resemble the in-tree components. OOTs created with 3.9 should have no issue being interpreted by modtool and the macros to do python bindings. But creating a new OOT will be slightly different and have a different structure. OOTs created with 3.10 will not work with modtool from 3.9, but they still should be able to compile with 3.9

Logging

The logging backend was overhauled, but most of the old logging API remains in place. So, GR_LOG_WARN(d_logger, "Warning!"); still works.

You are, however, encouraged to use the newer API that allows for in-line format string usage (which is only evaluated if the logging at the given level is actually activated). Benefit: This might remove the need to use Boost just to get boost::format; it's also faster when active, and the overhead when inactive is minimal (TODO: link to PR comment where speed was benchmarked).

d_logger->warn("Unable to read {:d} items from buffer '{:s}'; resetting to default value {:f}",
               num_items,
               name,
               default_float_value);

Outside of blocks, where you might not have access to a readily set up logger:

#include <gnuradio/logger.h>
…
  gr::logger logger("my thing that logs");
  logger.info("Setting up this rather complicated thing");

Notice that this is really a logger object, not a smart pointer, as the use cases for non-block loggers aren't always clearly cut. If you have a (non-block) class that needs to log something:

// test.cc
#include <gnuradio/logger.h>

class my_thing
{
private:
    gr::logger _logger;

public:
    my_thing(const std::string& name)
        : _logger("my thing " + name)
    {
        _logger.info("constructed");
    }
    ~my_thing() { _logger.warn("I don't like being destructed!"); }
};

int main() { my_thing thing("gizmo"); }

yielding (after a $CXX $(pkg-config --cflags --libs gnuradio-runtime) $(pkg-config --cflags --libs spdlog) -o test test.cc && ./test)

my thing gizmo :info: constructed
my thing gizmo :warning: I don't like being destructed!

QT FFT Size Ranges

For QT Frequency Sink and QT Waterfall Sink: because of the interaction between the block and some of the graphical elements such as the control panel, we have limited the available fft sizes to powers of 2 between 32 and 32768 to keep the widget in a well defined state. Flowgraphs with values for fft size that are not powers of 2 will show an error in GRC, but for python flowgraphs, will force it to a default value.

API Changes

Removal of Decimation Parameter from FIR objects

There was previously a decimation value in the constructor of a kernel::fir_xxx object that has now been removed

ATSC Blocks

The inputs and outputs of the ATSC blocks previously passed structs that contained data and metadata. These have now been broken out into separate streams.