Also known as: file-based DSP testing, hardware-free DSP testing, offline radio testing
Testing DSP without hardware is the practice of verifying a radio’s signal-processing code by feeding it recorded or synthesized IQ samples from a file, rather than from a live SDR dongle over the air.1 Because the input is a fixed byte stream, the same test produces the same result every run — no antenna, no drifting propagation, no transmitter that happens to be off the air today. This turns a physically awkward, non-reproducible experiment into an ordinary, fast, automatable software test.
How it works
An SDR decode chain is, at its core, a pure function over a stream of complex samples: baseband IQ goes in, and bits, audio, or metadata come out. Nothing in the digital filters, the demodulator, the timing recovery, or the framing logic actually requires the samples to be arriving in real time from silicon. So the test harness substitutes a file source for the device driver, streams the recorded samples through the identical processing graph, and checks the result.
The recorded input comes from two places:
- Captures — real off-air recordings saved once (an IQ recording in a cfile or SigMF) that exercise the decoder against genuine signals, imperfections and all.
- Synthetic signals — IQ generated by code with known parameters (a modulator fed a known bit pattern, optionally with added noise or frequency offset), which lets a test assert the exact right answer, not just “it decoded something.”
Because the sample stream is byte-identical each run, any change in output is attributable to the code, not the environment — the essential property that makes these tests trustworthy in a regression suite.
In practice
Hardware-free tests slot directly into an ordinary unit-testing framework and run in continuous integration on machines that have no radio attached.2 A capture is typically kept small (a fraction of a second is often enough to lock and decode a few frames), committed alongside the code, and paired with the expected decode. Synthetic generators are convenient for edge cases you cannot easily capture on demand — a specific error-correction failure, a precise carrier offset, a burst at threshold SNR — because you dial the impairment in exactly.
The main limitation is honest scope: a file test proves the DSP and protocol logic are correct, but it cannot exercise the USB transport, the tuner’s gain staging, or true real-time scheduling under load. Those still need a device, or a separate end-to-end test. The discipline is to push as much correctness as possible into the file-testable core and keep the irreducibly hardware-bound part thin.
Relevance to SDR
This is one of the highest-leverage practices in building SDR software, because the alternative — plugging in a dongle and hoping the right transmission happens during your test window — is slow, non-reproducible, and impossible in CI. Every serious decoder project keeps a corpus of captures for exactly this reason.
GopherTrunk is built around it. Its replay command streams a captured
cfile through the very same downconvert-and-decode
path the live scanner uses, so a trunking control channel can be decoded, and
regressions caught, entirely from files — no dongle in the loop. Real reporter
captures are replayed to reproduce field bugs deterministically, and the decode
chain is deliberately rate-invariant (it normalizes to a fixed channel rate),
so a capture taken at one sample rate reproduces the same in-channel result as
another. That property is only trustworthy because it is pinned by file-based
tests. Paired with golden test vectors and
synthetic signals, this lets almost the
entire radio be validated on a laptop with no antenna in sight.
Sources
-
Software-defined radio — Wikipedia, on SDR as software processing of digitized baseband samples, which is what makes file substitution possible. ↩
-
Continuous integration — Wikipedia, on automated, repeatable test execution that hardware-in-the-loop testing cannot easily satisfy. ↩