Also known as: record and replay, IQ capture and replay, offline replay
IQ recording and playback is the workflow of writing an SDR’s raw baseband IQ samples to a file, then feeding that file back through the DSP chain later — turning a fleeting radio signal into a frozen dataset you can decode, inspect, and re-decode as many times as you like.1 It is the single most useful habit in SDR development: a recorded capture is reproducible where a live signal never is, so it converts a “sometimes it fails on air” problem into a deterministic one anybody can re-run.
How it works
Recording taps the sample stream immediately after the radio — before any lossy processing — and
writes it to disk as a raw IQ file: interleaved I, Q values in some
sample format, most often the GNU Radio
cfile (complex float32) or an 8-bit cu8 capture. Because the file has no
header, the sample rate and centre frequency must be recorded alongside it, in the filename, a
SigMF sidecar, or documentation.
Playback reads those bytes back at the recorded rate and injects them into the DSP chain at the same point the live radio would — a GNU Radio File Source standing in for the hardware source, or a decoder’s replay mode. The key property is that replay is deterministic: the same file plus the same code always yields the same intermediate samples and the same decode, so any bug that manifests in the capture is reproducible on demand. Replay can also run faster than real time — the file has no clock — which is what makes it practical to sweep parameters or run a regression suite over hundreds of captures quickly.
In practice
For this to be meaningful the replay path must be the same path the live system uses, or a lock in replay would not imply a lock on air. Capturing at the raw-IQ tap, not after demodulation, is also essential: once symbols are sliced, the information needed to debug the front end is gone. A recorded control-channel burst that fails to decode is the ideal bug report — it lets a developer reproduce the exact failure without the reporter’s radio, antenna, or RF environment.
Relevance to SDR
Record-and-replay is the foundation of serious SDR software work: it enables testing without hardware, golden-capture regression suites, and the simulation-driven development loop where a captured or synthesised signal is the fixture. It is how a decoding project accumulates a library of known-good and known-bad signals over time.
GopherTrunk is built around exactly this. Its gophertrunk replay subcommand reads a capture file —
-format u8, f32 (a cfile), or wav — and drives it through the same
production receiver, down-converter, and control-channel pipelines the live daemon runs, so a replay
lock implies an on-air lock and a replay failure makes the capture a reproducible fixture. This is why
the project’s guidance repeatedly asks for the raw .cfile when an on-air problem is reported: the
capture, replayed offline, is what turns a symptom into something a regression test can pin down and a
fix can be verified against.
Sources
-
File Source — GNU Radio wiki, on replaying a recorded raw-IQ file into a flowgraph as a stand-in for a live radio source, the basis of offline decoding. ↩