Before this:Finding the control channelAnatomy of a trunked call: request, grant, release
Following a system end to end
Key takeaways With the control channel locked, GopherTrunk runs a continuous loop. It decodes the control channel, sees a talkgroup grant, tunes a receiver to the assigned voice channel, demodulates and decodes it, feeds the vocoder frames to a speech decoder, and plays and records the audio tagged with the talkgroup and radio ID. Because it keeps reading the control channel in parallel, it can follow several calls at once. Every stage is visible in the web console — which makes watching the pipeline the fastest way to confirm it’s healthy.
This is the trunking equivalent of From antenna to audio: the whole chain assembled, but with the trunking logic in the middle. We’ll follow a single dispatch call from a grant on the control channel to a labelled recording on disk.
Stage 1 — the control channel is decoded continuously
GopherTrunk is locked to the control channel and reading its signalling stream every moment. Affiliations, registrations, and — the part we care about — channel grants flow past. This decoding never pauses; it’s the running map of the system, and you can watch it scroll in the CC Activity panel.
Stage 2 — a grant is seen
A user keys up. Their radio requests a channel, the system finds a free one, and the control channel broadcasts a grant: “talkgroup 101 → voice channel 3.” GopherTrunk reads it, notes the talkgroup, the voice-channel frequency, and the transmitting radio ID. This is the moment a call is born — the anatomy-of-a-call request-and-grant arc, seen from the decoder’s side.
Stage 3 — the voice channel is tuned and decoded
GopherTrunk tasks a receiver to tune to voice channel 3 and runs the full receive chain on it — filter, demodulate, recover symbols, decode. Because it’s still reading the control channel in parallel, it can do this and catch the next grant elsewhere, capturing multiple simultaneous calls across the system. Periodic grant updates let it join calls already in progress (late entry), so nothing slips by.
Stage 4 — the vocoder reconstructs the voice
The voice channel doesn’t carry audio — it carries vocoder frames, speech compressed to a few kilobits per second by a codec like IMBE (P25 Phase 1) or AMBE+2 (DMR, P25 Phase 2). GopherTrunk feeds those frames into a matching speech decoder, which reconstructs an audible waveform. This is the step that turns abstract bits back into a human voice.
Stage 5 — audio out and recording
The reconstructed audio is played live in the console and written to a file tagged with the talkgroup, radio ID, timestamp, and system. From here GopherTrunk can stream it onward to services like Broadcastify or RdioScanner. The call that began as a grant on the control channel is now a labelled recording — and the engine is already following the next one.
Watching the whole thing live
The web console lets you watch every stage at once, which is the fastest way to confirm the pipeline is healthy:
| Stage | Where to watch | Healthy sign |
|---|---|---|
| Control channel decoded | CC Activity | Affiliations and grants scrolling steadily |
| Grant seen | CC Activity | A grant row: TG ← radio @ frequency |
| Voice channel followed | Active-call view | A call appears with a live audio meter |
| Who’s transmitting | Radio IDs | The source radio ID labelled on the call |
| Audio out | Active-call view | Audible playback, a written recording |
If you want the engineering view of this same flow — the components and data paths behind the panels — the architecture page lays it out. When a stage doesn’t light up, this table doubles as a troubleshooting starting point.
Quick check: how does GopherTrunk know which voice channel to tune for a new call?
Recap
- The control channel is decoded continuously — the running map of every call.
- Each grant names a talkgroup and voice channel; GopherTrunk tunes and decodes that channel.
- The vocoder reconstructs audio from the decoded frames.
- Audio is played and recorded, tagged with talkgroup, radio ID, and timestamp.
- Reading the control channel in parallel lets GopherTrunk follow many calls at once.
- The web console shows every stage live, which doubles as a health check.
Next, we tackle the hardest real-world case: a system spread across multiple sites and simulcast transmitters, in multi-site & simulcast in practice.
Frequently asked questions
What happens after GopherTrunk locks a control channel?
It reads the control channel’s grants in real time. When it sees a talkgroup granted a voice channel, it tunes a receiver to that channel, demodulates and decodes it, runs the vocoder frames through a speech decoder to produce audio, and plays and records the result tagged with the talkgroup and radio ID. Then it’s immediately ready for the next grant.
Can GopherTrunk follow more than one call at once?
Yes. Because it decodes the control channel continuously, it knows every voice-channel grant as it happens and can task receivers to capture multiple simultaneous calls across the system. It mixes or queues them for playback and recording according to the priorities you set, so a busy system doesn’t drop calls.
How does GopherTrunk know which voice channel to tune?
The control channel announces it. Each grant names the talkgroup and the voice channel it’s been assigned, so GopherTrunk reads the grant, looks up the frequency, and tunes a receiver there. Periodic grant updates let it catch calls already in progress, so late entry is handled too.
Where can I watch this pipeline happen?
The web console shows each stage live — the CC Activity panel for control-channel grants, the Radio IDs panel for who’s transmitting, and the active-call view for audio. The architecture page is the engineering view of the same flow. Watching these together is the fastest way to confirm the whole chain is healthy.