What is a Digital Radio Controller (DRC)?

The DRC is a software methodology for controlling multi-channel digital radios in a way that is portable across differing radio hardware. It consists of supporting C++ classes and the drc OpenCPI component specification against which OpenCPI DRC workers are created (component vs worker brief). Because this specification is hardware-agnostic, OpenCPI applications developed against it are intrinsically portable across radios.

How mature is the DRC?

The DRC base classes have been unit tested in C++ and several DRC workers have been verified in lab environments for RF applications – primarily for radios based on the multi-channel AD9361 RF transceiver. There is ongoing work to add Xilinx RFSoC transceiver support. The unit tests can be downloaded and quickly (~45 sec) built and run outside of the lengthy OpenCPI framework build process.

An OpenCPI application exists which provides runtime, hardware-in-the loop verification (register access only, no RF verification) for any DRC worker. New hardware can be tested with this application by passing a hardware-specific CSV file of test cases as a command-line argument, and using the OCPI_LIBRARY_PATH to force deployment of the DRC worker under test.

How is the DRC different than other frameworks?

The DRC brings radio control standardization to the OpenCPI framework. It is unique in its ability to allow independent channel control for multi-channel transceivers while simultaneously validating each channel against existing operating channels which are “locked”.

What DRC examples exist?

See the FMCOMMS2/3 DRC worker (with additional FPGA decimation/interpolation workers) and test application.

How does the DRC work?

A DRC has 3 main supporting C++ classes:

1. A Constraint Satisfaction Problem (CSP) solving engine that is used to model multichannel radio parameters and the complex interactions among them. A CSP contains variables (X), their domains (D), and their constraints (C). The constraints define an N-dimensional feasible region which collapses to a single point as radio parameters are “locked” to single values. This uses constraint propagation techniques, including backtracking invalid configurations.
   
2. A Configurator which is a software emulation of radio hardware capabilities. This maps the generic CSP API to the standardized, multichannel settings of a DRC.
   
3. The DRC itself, which provides an API for getting and setting the list of standardized radio parameters as well as arbitrating between requested configurations (for which the Configurator is queried for allowability) and the get/set API (which forwards on configurations to hardware register accesses, once the Configurator confirms the parameters are allowable). The get/set API knows nothing about radio limitations and simply attempts to set the requested values with no guarantee of success.

How do I create (and test!) a DRC?

1. Create a table which maps the generic DRC parameters to their radio-specific constrained ranges (example here)
2. Create a table which maps the generic DRC state transitions to the radio-specific behavior for each state transition.
3. Create a CSP class which enforces the constraints described in step 1 (example here)
4. Create a Configurator class which serves as a software emulation of the hardware constraints described in step 1 (example here). Create and verify its unit test (example here).
5. Create a DRC class which defines how to get/set parameters on the radio hardware itself, and implements the transition specifics described in step 2 (example here).
6. Create the radio-specific DRC worker which maps the generic API of the DRC class to the DRC component properties (example here). Create a CSV file containing known-good/bad configurations and state transitions similar to the unit test in step 3 (example here) and run the drc_test_app against it to ensure DRC application compliance.