6Messages, Tags, and Packet Communications
6.1 Introduction
It is well known that the GNU Radio scheduler works on continuous streams of data [Rondeau, 2013]. The flowgraph we build to set up a communication chain moves data continuously from source blocks to sink blocks. The scheduler ensures uninterrupted streams by allocating appropriate buffer sizes between blocks. This way of working is appropriate for continuous communication schemes (e.g. Digital Audio Broadcasting (plus) [DAB+]) but not for packet communications (e.g. WiFi). Although it is not currently possible to change the way the scheduler works, several mechanisms have been introduced to handle bursty communication cases. The first mechanism concerns “tags.” Tags are designed to hold metadata and control information. They are associated with a particular sample in the data stream (e.g. the start of a 96 ms DAB+ frame). If not blocked, they flow downstream from block to block. In this manner, subsequent blocks following the one that has added the tag can be notified that a specific event has occurred, such as reaching a definite voltage threshold. The major limitations with tags is that they are only accessible inside a block work function and that they can only propagate in one direction, i.e. from source to sink. On the other hand, the interesting feature of the tag interface is that it is isosynchronous with the data stream. To cope with tag limitations, a more general message passing interface has been introduced. ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access