Burst Transmission in GNU Radio Sample Streams with Eventstream

There are a handful of ways to transmit bursts of information using GNU Radio.   Perhaps most widely known is when using Ettus UHD based devices, burst transmit mode may be used to schedule bursts of samples within a properly tagged stream.   This results in accurately timed bursts and low latency transmission, but it also relies upon specific Ettus hardware and makes software only loopback simulation impossible.

This alternative method of burst transmission using the eventstream (http://github.com/osh/gr-eventstream) source block to interleave bursts into a sample stream is hardware independent, and allows precise timing of bursts in the sample stream in a hardware independent way which works well in loopback software simulation.   The performance cost is a slightly higher latency penalty than the UHD burst mode due to reliance on back-pressure within the GNU Radio transmit stream.  But it does have the nice side effect of resolving the ugly “flushing the end of a burst” nastiness which may be present when sending the end of a tagged stream burst through GR blocks and/or transfer to a UHD device.

Signal Source

Our burst signal source in this case is the random pdu generator block.   The message strobe block sends it a message every 500ms telling it to generate a new burst of between 50 and 2000 bits in length.   We ensure that each byte contains a single bit by anding a mask of 0x01 in this generator block.   Finally we go through a PDU PSK burst mapper block to map the random bits into a complex constellation points in our new complex float PDU.

These bursts are plotted using the gr-pyqt burst plotters for reference before continuing down the chain.   They are burst only and and no “off” time exists at this point in the graph.

Eventstream Source / Burst Scheduling

The eventstream source block, void of any events, simply produces zero valued samples at a rate limited by downstream back-pressure.   A variety of transmit handlers may be used to produce output into this sample stream at precise times and lengths.   One convenience handler which is provided is the PDU Handler, which is internal to the eventstream source block, and allows you to simply pass a PDU of samples into the block to be sequenced into the output stream without worrying about the more complex trigger/handler paradigm.

Once we pass a complex float PDU into the schedule_event port, the block checks for an “event_time” tag on the event to tell it what precies sample index time to schedule the burst at.   When this value is not provided, a time of 0 is assumed, which is the case in this example.   The source block defines and “Early Behavior” which defines what should happen if an event arrives with a time which is too early for the current stream nitems_written(0) value (number of samples which have been produced).   The options here are to DISCARD, throw away events which are too early, BALK, or throw an exeption and stop running when such event arrive (useful for debugging), or ASAP, to simply schedule them at the earliest possible time available.   In this case we use ASAP to schedule the events as soon as possible.



Coming out of the eventstream source block, we throttle the stream to limit production rate to our desired sample rate, add some gaussian noise to make plots more interesting, and then plot the power of the resulting sample stream with roughly time periodic bursts in it.   We can see that plotting a burst tirggered roughly every 500ms does result in a burst being scheduled into the stream roughly every 500ms.   If we wanted this to be exactly 500ms in samples, we could set the “event_time” tag on the event to the proper sample index desired, but this exercise will be left to a future example.


Leave a Reply

Your email address will not be published. Required fields are marked *