Advanced & power-user features

This is the rest of GopherTrunk — the parts you reach for once you’re running a serious setup or want to integrate it with other tooling. The same single binary that’s been recording your calls also carries a terminal cockpit, a bench of signal scopes, an offline analysis workbench, a dozen more decoders, and typed APIs.

Before you start. This guide assumes Going further — comfort with config.yaml, the terminal, and a multi-dongle pool. It’s comfortable with command-line subcommands and a little signal-processing vocabulary.

The terminal cockpit and signal scopes

The web console isn’t the only front end. The TUI is a full-screen terminal cockpit with the same panels — ideal over SSH or on a headless box. It also exposes GopherTrunk’s signal scopes, the tools for seeing why a signal does or doesn’t decode:

• Constellation — the IQ scatter plot; tight clusters mean a clean signal.
• Eye diagram and Symbol scope — watch the demodulated symbols and how open the “eye” is.
• Plots, Symbol histogram, and Tuning meters — spectrum, symbol distribution, and receiver health at a glance.

Use these to chase down a marginal site: too much gain, a frequency-error offset, or a simulcast signal that needs a different demodulator.

Offline analysis: SigLab and the workbench

Beyond the live daemon, the binary carries a workbench of subcommands for working with recorded captures instead of a live radio:

• gophertrunk capture records raw IQ off a live dongle to a file.
• gophertrunk replay / analyze / identify decode a capture offline, auto-detect its protocol, and export the results to JSON / YAML / CSV.
• gophertrunk test grades a decode against expected results.

SigLab wraps this workbench in a terminal and a browser console (gophertrunk siglab / siglab serve) so you can replay, inspect, and grade decodes without a radio attached — the natural home for diagnosing a tricky capture or building a regression fixture. The Architecture reference describes the decode pipeline these tools drive.

Many more receivers

Trunked voice is just the start. GopherTrunk also decodes, each as an opt-in receiver with its own log and console panel:

• ADS-B — aircraft transponders, with a live map.
• AIS — marine vessel positions.
• APRS / AX.25 — amateur packet, beacons, and messages.
• DSC — marine digital selective calling, including distress.
• MDC1200 — Motorola in-band signaling (PTT IDs, emergency).
• M17 — the open digital-voice link layer.

Which of these are on by default, and how to enable the rest, lives in Opt-in features.

Following multiple systems and sites

GopherTrunk can follow several trunked systems at once, but how they map onto SDRs depends on the path:

• One control channel per SDR (classic path). Each system in your config is followed by its own control receiver, so following N systems — or N sites of the same network, since each site is added as its own system with its own control-channel frequency — needs N SDRs with role: control.
• Many systems on one wideband SDR. A role: wideband device can follow several carriers at once from a single dongle, as long as they all fit in its IQ band. This wideband multi-system path covers DMR (Tier II/III), P25 (Phase 1/2), and TETRA control channels — so multiple TETRA sites/systems can now share one wideband SDR. Note the boundary: the wideband path multiplexes control channels; a TETRA channel is channelized to its own 144 kHz tap (DMR/P25 use 48 kHz), and TETRA voice grants still follow on a role: voice SDR (or its own control SDR’s same-carrier voice), not on a wideband voice tap.

Either way, when the same call is heard on several networked or simulcast sites, cross-site call deduplication saves it once instead of once per site: enable recordings.dedup (a call with the same talkgroup + source already recorded from another monitored system within the window — default 60 s — is skipped). Live follow and monitoring are unaffected; the gate is recording-only.

Remote and recorded sources

Your dongle doesn’t have to be on the same machine — or even a physical radio:

• Remote SDRs — drive a dongle on another host over rtl_tcp, or professional hardware (USRP, LimeSDR, bladeRF, SDRplay) over SoapyRemote.
• Baseband IQ record / replay — capture the wideband IQ stream to disk and later mount the recording as a virtual dongle, so you can re-run decodes against the exact same RF.

APIs and integrations

The daemon is built to be driven by other tools. Everything the consoles do runs over public APIs:

• HTTP REST + Server-Sent Events + WebSocket — the same API the web console uses; point your own scripts and dashboards at it.
• gRPC — typed clients for calls, talkgroups, and radio IDs.
• Prometheus /metrics — scrape GopherTrunk into your monitoring stack.
• rigctld integration — speak the Hamlib wire protocol so amateur-radio logging tools (Cloudlog, GridTracker, satellite trackers) can read and set frequency.

Squeeze out every decode

When you’re chasing the last few percent of a difficult system:

• Vocoders and Voice calibration — how GopherTrunk turns digital voice frames into audio, and how to tune it.
• DMR encryption — supply keys to decode protected DMR traffic you’re authorised to monitor.
• FEC opt-outs — per-protocol error-correction toggles, documented in Opt-in features, for matching pre-stripped captures.

You now have the complete picture

From “what is this?” to driving the APIs, you’ve seen the whole of GopherTrunk: the conceptual map, a first call, everyday operation, a richer setup, and the power-user surface. Where to from here:

• Architecture — the full design: the multi-consumer IQ fan-out, the DSP chain, the voice pipeline.
• Status and Roadmap — what ships today and what’s coming.
• Support — where to get help and how to report issues.

← Back to the start: What is GopherTrunk?