Also known as: file source block, file sink block, IQ file reader/writer
A file source is a flowgraph block that reads samples from a file and pushes them into a signal-processing pipeline; a file sink does the reverse, writing the samples flowing past it out to disk.1 Together they let an SDR flowgraph run entirely on stored data — the source stands in for a radio’s receive path, and the sink stands in for a radio’s transmit path or simply captures an intermediate stream for later inspection.
How it works
Inside a streaming flowgraph, every block has the same contract: pull a buffer of samples from upstream, do work, push a buffer downstream. A file source has no upstream — it simply reads the next chunk of bytes from an open file, interprets them according to a declared sample format (e.g. interleaved 32-bit float I/Q, or 8-bit unsigned like raw RTL-SDR), and emits them as complex samples. A file sink has no downstream — it serializes each incoming buffer to disk in the chosen format.
Two details make or break correct use:
- Format agreement. The reader must interpret bytes exactly as the writer laid them down: the same sample type, I-before-Q ordering, and endianness. A cfile (interleaved float32) and a SigMF recording (data plus a metadata sidecar naming rate and format) are the two common conventions; guessing wrong turns a clean signal into noise.
- Rate. A raw IQ file carries no timestamps, so the source has no idea how fast to emit samples — it just reads as fast as it can. That is exactly right for an offline decode (run flat out), but wrong for anything that must behave as if in real time, which is what a throttle block is for.
In practice
For offline batch processing — running a decoder over a capture to see what it extracts — you want the file source to run at full speed, with no throttle, so the job finishes in a fraction of real time. For feeding a UI or a real-time-paced demo, you insert a throttle after the source so the graph consumes samples at the recording’s true rate rather than saturating a CPU core and rendering a waterfall that scrolls past instantly.
File sinks are the recording half of the loop: tap one anywhere in a graph to capture baseband for a bug report, or the demodulated output to compare against a golden vector. Recording a short segment once and replaying it forever is the foundation of simulation-driven development and hardware-free testing.
A common gotcha is the end of file: a source can either stop (right for a finite test) or loop back to the start (handy for a continuous demo), and the two behaviors give very different test semantics — a looped file re-introduces a discontinuity at each wrap that timing-recovery loops must re-acquire.
Relevance to SDR
Source and sink blocks are a defining convenience of software radio: because the device is just another block, replacing it with a file changes nothing downstream. GNU Radio ships explicit File Source and File Sink blocks, and essentially every SDR framework offers equivalents; the SigMF standard exists precisely so a recording made by one tool can be replayed by another without ambiguity.
GopherTrunk embodies the source side directly. Its replay path opens a
recorded cfile and streams the samples through the
identical downconvert-and-decode chain the live scanner drives from a dongle — the
file is the source, and the decoder cannot tell the difference. This is what makes
GT’s control-channel decoding reproducible from committed captures and lets field
bugs be reproduced from a reporter’s raw recording. GT is a receiver, so its
emphasis is squarely on the source (reading captures) rather than a transmit-style
sink, though writing intermediate baseband to a file for offline analysis fits the
same model.
Sources
-
File Source block — GNU Radio Wiki, on reading raw sample files into a flowgraph and the format/rate considerations involved. ↩