Field Guide · technology

Also known as: ZeroMQ, ZMQ, 0MQ

ZeroMQ for SDR is the use of the ZeroMQ (ZMQ) message-passing library — via GNU Radio’s ZMQ source and sink blocks — to carry IQ streams between separate processes or machines.1 It lets a single flowgraph be cut into pieces that run independently: a sink block in one process publishes samples onto a ZMQ socket, and a source block in another subscribes to them, with ZeroMQ handling the framing, buffering, and reconnection.

source flowgraph… → ZMQ PUB sink SUB source → …subscriber A SUB source → …subscriber B ZMQ socket (tcp://)
A ZMQ PUB sink publishes IQ from one flowgraph; SUB sources in other processes subscribe to the same stream over a socket.

How it works

ZeroMQ is a socket library that sits a level above raw TCP: it moves discrete messages rather than a byte stream, and builds in patterns for how endpoints relate. GNU Radio wraps four of these as block pairs:

  • PUB / SUB — one publisher fans a stream out to any number of subscribers, each getting a copy; subscribers can come and go, and a slow one is dropped rather than stalling the publisher. Ideal for broadcasting one radio’s IQ to several consumers.
  • PUSH / PULL — a pipeline/load-balancing pair: pushed messages are distributed round-robin across the pullers, useful for spreading heavy DSP across worker processes.

A GNU Radio ZMQ sink serialises the samples of its input stream (with optional stream tags) into ZMQ messages and binds or connects a socket at a tcp://host:port address; the matching source on the other side deserialises them back into a GNU Radio stream. Because the transport is just a URL, the two halves can be threads, separate processes on one box, or programs on different machines, with no change to the flowgraph logic. ZeroMQ’s internal queues absorb jitter, and its automatic reconnection means a restarted consumer rejoins without tearing down the producer.

Relevance to SDR

ZeroMQ is GNU Radio’s standard tool for inter-process and inter-host IQ movement, and the reason it matters is architectural: it lets you decompose a monolithic flowgraph. A stable, expensive front end (tune, filter, decimate) can run as one long-lived process publishing baseband IQ, while experimental decoders attach and detach as SUB subscribers without disturbing it — a much more flexible topology than a single graph. It also bridges GNU Radio to non-GNU-Radio programs, since ZeroMQ has bindings in most languages, so a Python or C++ analysis tool can consume the same published stream. Compared with the dedicated network IQ streaming servers, ZMQ is lower-level and more general: it does not know it is carrying IQ, which is exactly what makes it composable. It embodies the message-passing style of connecting DSP components, as opposed to a single shared in-process stream.

GopherTrunk does not use ZeroMQ — it is a self-contained pure-Go application with an internal streaming pipeline rather than a GNU Radio flowgraph, and it has no GNU Radio dependency. ZeroMQ is relevant here as the wider ecosystem’s answer to a problem GopherTrunk solves internally with Go channels and ring buffers: getting sample streams from one processing stage to the next, and occasionally to another process, without losing or blocking on data. Where GNU Radio reaches for a ZMQ block, GopherTrunk moves the same samples over an in-process bus.

Sources

  1. ZMQ PUB Sink — GNU Radio wiki, documenting the ZeroMQ sink/source blocks and the PUB/SUB and PUSH/PULL patterns for carrying streams between flowgraphs. ↩

See also