Field Guide · concept

Also known as: waterfall display rendering, scrolling spectrogram rendering

Waterfall rendering is the process that turns a continuous stream of frequency spectra into the scrolling, colored spectrogram — the “waterfall” — that dominates most SDR interfaces. Each fresh FFT becomes one horizontal line of the image: frequency runs left to right, each pixel’s color encodes signal power at that frequency, and successive lines push older ones down (or up), so time flows down the screen and a transmission traces a bright vertical streak.1

FFT |X|² → dB colormap new row older rows scroll down
Each FFT frame is scaled to dB, colored, and appended as one row; the accumulated rows form a scrolling time-frequency image.

How it works

The pipeline is a fixed sequence of stages, repeated once per frame:

  1. FFT. A block of IQ samples is windowed (to control spectral leakage) and transformed to the frequency domain, yielding one complex value per bin.
  2. Magnitude and dB. Each bin’s magnitude squared gives its power; taking 10·log10 compresses the enormous dynamic range of RF into decibels, so a weak signal 60 dB below a strong one is still visible.
  3. Normalize to a range. The dB values are clamped between a floor and a ceiling (often user-adjustable “contrast/brightness”), mapping the interesting band into the 0–1 range the colormap expects.
  4. Colormap. That 0–1 value indexes a color gradient — a lookup table — turning each bin into a pixel. Perceptually uniform maps (viridis, inferno) are preferred over rainbow maps because equal power steps look like equal color steps.
  5. Scroll and blit. The new row is written to the display and previous rows are shifted, commonly by treating the image as a ring buffer of rows so no pixels are actually copied — only the starting offset moves.

In practice

The rate mismatch between data and eyes drives most design choices. FFTs may arrive hundreds of times a second, far faster than a useful scroll; renderers therefore average or decimate frames per output row, or accept every FFT but scroll slowly. Averaging several FFTs per row (Welch-style) also smooths the noise so faint carriers stand out. The visible frequency resolution is set by FFT size, and the time resolution by how many samples each frame covers — the classic time-frequency trade.

Rendering is a natural fit for the GPU: the FFT output is uploaded as a texture and a fragment shader applies the colormap, so the CPU never touches individual pixels. Browser SDR clients do exactly this with WebGL — the colormap becomes a 1-D texture lookup in the shader and the scroll is a texture coordinate offset, letting a full-width waterfall run at display refresh rate on modest hardware. On the CPU, the same result is achieved with a precomputed color lookup table and a ring-buffer image.

Relevance to SDR

The waterfall is the signature visualization of software radio: it makes bursts, frequency-hopping systems, trunking control channels, and interference immediately legible in a way a single instantaneous spectrum trace cannot, because it preserves history. Essentially every SDR GUI — SDR#, GQRX, SDRangel, CubicSDR, and web-based clients — is built around one, and the rendering quality (colormap choice, dB scaling, frame averaging) strongly affects how weak a signal a human can spot.

GopherTrunk is primarily a headless decoding engine rather than a spectrum GUI, so heavy interactive waterfall rendering is not its focus — it spends its compute locking and decoding trunking traffic, not painting pixels. The underlying FFT and dB-power math it performs for signal detection and diagnostics is exactly the front half of the waterfall pipeline; the colormap-and-scroll back half belongs to a UI layer, and GT relates it to the broader ecosystem of SDR front-ends rather than shipping a GPU renderer of its own.

Sources

  1. Spectrogram — Wikipedia, on the time-frequency-intensity image that a waterfall renders row by row. ↩

See also