Field Guide · technology

Also known as: gr-osmosdr, osmosdr source

gr-osmosdr is a GNU Radio block — an Osmocom Source and matching sink — that presents a single, uniform interface to a wide range of software-defined-radio front ends.1 Instead of using a different, device-specific source block for each radio, a flowgraph drops in one osmosdr source and selects the hardware with a short device argument string such as rtl=0, hackrf=0, or airspy=0. From the GNU Radio Companion canvas it makes almost any supported dongle look the same, which is why it became the standard starting block for practical SDR flowgraphs.

RTL-SDR HackRF Airspy bladeRF osmosdr source args: "rtl=0" rest of flowgraph one block, chosen by device string, streams IQ into the graph
gr-osmosdr abstracts many front ends behind one GNU Radio block: a device-argument string picks the radio, and the same IQ stream flows into the rest of the flowgraph.

How it works

gr-osmosdr is a thin dispatch layer over a set of per-device back ends. When a flowgraph opens the source, the block parses the device-argument string, loads the matching back end, and configures the hardware through it. The back ends wrap the native libraries — librtlsdr for RTL-SDR, libhackrf for HackRF, libairspy for Airspy, libbladeRF for bladeRF, UHD for USRPs, and others — plus a SoapySDR back end that in turn reaches any Soapy-supported device. Once open, the block exposes a common set of GNU Radio parameters:

  • Tuning and rate — center frequency, sample rate, and frequency correction, applied uniformly regardless of the underlying radio.
  • Gain — a normalized overall gain plus the named gain stages (LNA, mixer, VGA/IF) a device happens to expose.
  • Optional features — bias-tee power, antenna selection, and bandwidth, surfaced where the hardware supports them.

The block then streams complex IQ samples into the flowgraph like any other source. Multiple devices can be opened at once, and a matching sink provides the transmit direction for radios that transmit. In effect gr-osmosdr does for GNU Radio flowgraphs what SoapySDR does at the library level: collapse many device-specific SDKs into one interface — and indeed newer setups often let gr-osmosdr reach hardware through SoapySDR.

Relevance to SDR

For years gr-osmosdr was the practical answer to “how do I get samples from my dongle into a GNU Radio flowgraph,” and it remains extremely common in tutorials, published flowgraphs, and shipped tools. Because a flowgraph written against it is hardware-agnostic, the same .grc file runs on whatever radio a user owns simply by changing the device string — a major reason GNU Radio examples are so portable across the RTL-SDR, HackRF, and Airspy that dominate the hobby. It sits alongside gr-soapy as the two standard ways a GNU Radio Companion graph talks to real hardware.

GopherTrunk does not use gr-osmosdr or GNU Radio at all. GopherTrunk is a pure-Go trunking scanner that talks to its supported front ends (RTL-SDR, Airspy, and network IQ sources) through its own Go device layer, shipping as a single static binary with no GNU Radio runtime. The design intent is the same as gr-osmosdr’s — one uniform interface over several dongles so the decode path does not care which radio is attached — but GopherTrunk implements that abstraction itself in Go rather than borrowing GNU Radio’s block.

Sources

  1. gr-osmosdr — Osmocom project wiki, documenting the common source/sink block, device-argument strings, the per-device back ends (RTL-SDR, HackRF, Airspy, bladeRF, UHD, SoapySDR), and the exposed tuning/gain parameters. ↩

See also