Also known as: embedded SDR, SDR on a Pi, headless SDR
Embedded SDR is software-defined radio deployed on a small, low-power computer — a Raspberry Pi, another single-board computer, or an embedded module — rather than a desktop or server.1 The signal-processing math is identical to what runs on a workstation, but the surrounding constraints are not: a handful of ARM cores, a gigabyte or two of RAM, passive or minimal cooling, a few watts of power budget, and a USB bus that must keep up with a firehose of samples. Embedded SDR is less a distinct technology than the discipline of making a real-time receiver fit — and stay reliable — inside that envelope.
How it works
The pipeline is the same as on any host: a USB front end delivers IQ, the software down-converts and channelizes it, and decoders turn symbols into traffic. What changes is that every stage now competes for scarce resources. Three limits dominate:
- CPU throughput. Real-time DSP must keep pace with the sample rate or the input buffer overruns and data is lost. On a few modest cores this forces careful budgeting — decimate early to the narrowest rate that preserves the signal, avoid redundant filtering, and lean on the ARM NEON SIMD units where the math allows.
- Thermal and power. A small board in a sealed case heats up, and once it hits its limit the firmware throttles the clock — so a decoder that passes on the bench can start dropping samples after twenty minutes in a hot enclosure. Sustained, not peak, load is what matters, and the whole system may need to live inside a few watts.
- I/O bandwidth. High sample rates saturate USB and memory bandwidth; a Pi’s shared USB bus in particular can bottleneck a wideband capture long before the CPU does. Embedded designs favour narrower captures and zero-copy sample handling to avoid moving data more than necessary.
Because these machines are usually headless and unattended, robustness matters as much as speed: the software should recover from a USB glitch, bound its memory, and keep running for weeks. Software is typically built with cross-compilation from a fast desktop to the target’s ARM architecture, or shipped as a portable binary so no toolchain is needed on the board itself.
In practice
Typical embedded-SDR roles are a fixed monitoring receiver at a remote antenna, a portable field scanner, an ADS-B or AIS feeder, or a networked front end that streams IQ to a bigger machine. The design instinct is to do just enough on the board — capture, channelize, decode the target — and push anything heavy (wideband search, machine learning, archival) upstream.
Relevance to SDR
Embedded SDR is where a great deal of real-world receiving actually happens: the low cost and low power of an SBC plus a cheap dongle make it easy to leave a receiver running permanently. The constraints shape the software — efficient DSP, predictable memory, graceful overrun handling — more than any single algorithm does.
GopherTrunk is built for exactly this environment. It is a pure-Go decoder that compiles
to a single static binary with no runtime dependencies, so
deploying to a Pi or other ARM board is a file copy, not a dependency hunt, and
cross-compiling for linux/arm64 is a one-line build. Its
decode chain normalizes each channel to a fixed per-protocol rate and sizes the receiver from
that output, keeping the steady-state CPU cost low and independent of the capture rate — the
property that lets it hold real-time on modest cores. GopherTrunk runs headless and is a
natural fit for unattended embedded deployments; the usual practical limits are the host’s
sustained CPU and thermal headroom and the USB front end’s bandwidth, not the decoder itself.
It does not, and does not need to, offload work to a GPU or accelerator to run in this class
of hardware.
Sources
-
Single-board computer — Wikipedia, on the low-power, integrated boards that host embedded SDR. See also Software-defined radio for the receive-chain stages these boards must run in real time. ↩