Also known as: ka9q-radio, radiod, KA9Q radio
ka9q-radio is Phil Karn’s answer to a structural waste in
networked SDR: most protocols ship the whole digitized passband to each client, which
then throws away everything but one channel.1 ka9q-radio inverts that. A single
radiod process owns the front end, channelizes the entire passband once with an
efficient FFT-based channelizer, and publishes each channel —
hundreds at a time, if asked — as its own RTP stream on an IP multicast group. Any
number of consumers on the LAN then subscribe to just the channels they want, and adding a
listener costs the network nothing it was not already carrying.
How it works
radiod reads the hardware (RX888, Airspy, RTL-SDR, and others), runs the passband through
a fast-convolution filter bank, and maintains one demodulator instance per configured
channel — each with its own frequency, bandwidth, and mode (IQ, USB, FM, …). Each channel’s
output goes out as RTP on a multicast group, identified by an SSRC (by convention, the
channel’s frequency in Hz), alongside a status multicast group carrying metadata —
sample rate, output socket, signal levels — as typed key/value pairs. Control uses the same
status group: a consumer can create or re-tune channels remotely by sending commands to it.
Service discovery rides mDNS, so streams have names like hf.local rather than bare
multicast addresses. The consumer-side toolbox (monitor, pcmrecord, digital-decoder
front ends) is deliberately small and composable in the Unix style.
Contrast the models: rtl_tcp ships one client the raw passband; SoapyRemote gives one client remote control of a device plus its stream; SpyServer multiplexes clients but demodulates per client on the server. ka9q-radio alone makes the channel — not the device — the shared network product, which is what lets one antenna on a rooftop serve a whole shack (or a whole club) of independent decoders.
Relevance to SDR
For a trunking scanner the model is a natural fit: a trunked system is a set of known
channels, and a radiod instance can carry the control channel and every voice channel of a
site simultaneously from one front end. GopherTrunk consumes ka9q-radio natively
(internal/sdr/ka9qradio/, config key ka9q_radio): each configured {addr, ssrc} pair
appears to the scanner as a virtual tuner — the driver resolves the status group via mDNS,
learns the channel’s data socket, sample rate, and encoding from a status poll, and can
re-tune the channel through radiod’s command interface. The practical wins are physical:
radiod runs on a small computer at the antenna, the samples cross the LAN instead of
lossy coax, and several GopherTrunk instances (or GopherTrunk plus other ka9q consumers)
share one front end without contending for USB.
Sources
-
ka9q-radio — Phil Karn, KA9Q, on the multicast channelize-once architecture, radiod, and the RTP/status stream design. ↩