New GNU Radio features and PHY/MAC coding

With the recent (and not so recent) additions of stream tagging,
asynchronous message passing, and PDU blocks, there are now much better
facilities for handling packetized data in GNU Radio. Some of this will
seen in the OFDM transceiver code that started at the last hackfest and
will be integrated into 3.6.5, though it was started before the async
message passing was completed so it doesn’t use PDUs yet.

Our intent now (after completing the 3.7 API transition) is to improve
existing transceiver implementations with these in mind.

The concept of PDUs is to encapsulate a vector of data along with a
dictionary of key/value pairs describing the data. For a packet-based
transmitter, these PDUs would be received from a source of packets, such
the TUNTAP virtual network interface, a MAC layer block that generates
PDUs, a TCP or UDP network socket, or some other source of “data with
boundaries”. The PDU metadata could be things like transmission time,
requested modulation parameters, transmit frequency, or other parameters
you might wish to pass along to your own custom downstream blocks.
handling (like adding CRC, header, FEC, scrambling) will be done in the
domain by PDU oriented blocks that use asynchronous message passing to
consume and emit PDUs.

At a certain point in the flowgraph, the processing becomes stream
oriented, and the traditional streaming blocks can take over. However,
with stream tagging, the upstream PDU metadata can still propagate as
needed through these blocks. In addition, we’ll be looking at how to
the streaming modulation blocks smarter by having them respond to inline
streaming tags to change their function. In this way, then, an overall
transmitter hierarchical block will be able to accept discrete PDUs and
stream out baseband RF, with any tags that are meaningful to the
transmitter hardware generated or propagated onward.

A packet receiver would work in reverse, receiving streaming RF baseband
with whatever hardware supplied metadata was tagged onto the stream.
would go through the various streaming synchronization and demodulation
blocks (which might add tags about what they did) until payload
are determined, at which point PDUs would be used to process things like
payload FEC, descrambling, checking CRC, etc. A overall hierarchical
packet receiver block would accept streaming baseband RF and emit PDUs.
MAC layer block listening to this PDU traffic could then forward these
to some consumer of the payloads, like the TAPTUN block, etc., or the
layer block could recognize one of its own packets and handle

One benefit of this architecture is that since everything will be done
blocks (PDU or streaming), all of them can get GNU Radio Companion
and users will be able to experiment with them much more easily than
today’s essentially Python-only code (like benchmark and tunnel and
supporting code).

Some of the ideas here have been experimentally prototyped in the
code by Josh B. and John M. of Ettus R… We (Tom and I)
be working with them to understand the knowledge they’ve gained from
work to see how it can be re-cast using the new, standard capabilities
GNU Radio as I described above.

Exciting stuff ahead.

Johnathan C.
Corgan Labs

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs