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:

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).
  • FleetSync — Kenwood in-band signalling (fleet / unit ANI).
  • 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. A TETRA channel is channelized to its own 144 kHz tap (DMR/P25 use 48 kHz), and each wideband TETRA control channel also gets four per-timeslot same-carrier voice taps on that tap (the wideband twin of the control SDR’s cc:same-carrier taps), so its voice follows on the same dongle through the shared per-carrier demux — no role: voice SDR needed. This is the supported way to monitor two TETRA systems at once from one SDR: with a single role: control/auto tuner the hunter is a time multiplexer that camps on the first system that locks, and the daemon now warns at startup when several systems share one control SDR.

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?