Why digital DMR audio breaks up (cuts out) and how to fix it

Digital audio has an annoying trait: it is either there or it is not. An analog radio on a weak signal hisses and crackles, but you can still make out the speech. DMR behaves differently — while everything is fine the audio is clean, like a phone call, but the moment something breaks, the voice turns into a "robot," shatters into fragments and drops into silence. There is almost no in-between state.

The good news: the causes of this "broken" audio are quite specific and fall into three layers — radio frequency, network, and the app/phone layer. If you troubleshoot layer by layer, the problem can almost always be pinned down in ten minutes. Let's go through each layer and give a clear checklist.

Where the "robot" actually comes from

Voice in DMR is encoded by a vocoder into a stream of frames. The frames come in a tight rhythm — roughly every 60 ms — and each carries a slice of speech. The decoder on the receiving side reconstructs the audio from these frames. Lose a frame on the air or in the network, and the decoder has nothing to play, so it outputs silence, a click, or an artifact. A few losses in a row, and you hear that very "robot."

That is why the key diagnostic question is always the same: where are the frames being lost — on the air or in the network? The whole fix depends on the answer.

Layer 1. Radio frequency (RF)

The most obvious suspect. If the radio is far from the hotspot, with a wall or two between them, a poor antenna or an SWR mismatch — some frames arrive with errors and are lost on the radio leg. The symptom: the audio breaks up more the farther away or the worse positioned you are.

The marker of an RF problem is a high BER (Bit Error Rate). If the BER in the hotspot logs creeps up (a few percent or more), the cause is almost certainly on the radio side. What to check:

• signal level and distance to the hotspot, indoor reflections;
• antenna and SWR — a bent or "wrong" antenna kills reception;
• modem frequency drift — cheap MMDVM boards drift in frequency, which raises BER even with the radio close by;
• the BER norm and how to read it — see what BER is considered normal.

Layer 2. Network

And here is where it gets really tricky. Voice travels from the hotspot to the network and back over UDP — a protocol with no delivery guarantee. A packet is lost, nobody retransmits it, the frame simply vanishes. And unlike RF problems, BER will be 0%: the radio leg is perfect, the breakup happens beyond the hotspot.

The classic and extremely common case is Wi-Fi power-save on a Raspberry Pi. To save energy, the Pi's Wi-Fi adapter is set by default to sleep between packets. An occasional ping (one ICMP per second) passes perfectly, and the person concludes "the network is fine." But the adapter in this mode cannot keep up with the dense stream of DMR frames every 60 ms: while it is waking up, frames are lost. The result is broken audio with zero BER and a "normal" ping.

Other network causes:

• mobile internet jitter — on LTE/4G the latency jumps around, frames arrive unevenly, and the buffer cannot smooth them out in time;
• an overloaded or weak Wi-Fi channel, a router placed too far away;
• port-forwarding and NAT issues where the stream is routed badly — see hotspot behind NAT;
• in general, if the hotspot behaves strangely, start with what to do if the hotspot does not work.

Layer 3. App and phone

If you are listening to the air in a radio app on a smartphone, one more source is added. The mobile network is "jittery": latency floats, frames arrive in bursts and with spread. If the app's receive buffer is thin (minimal delay for the sake of "liveness"), it cannot smooth out this spread in time — and the audio breaks up on the phone side, even though the hotspot and the network up to it are fine.

This is fixed with a solid jitter buffer: the app accumulates a small reserve of frames (tens to hundreds of milliseconds) and plays them out evenly, riding through short network gaps. In the DMRhub app, reception goes through a server-side AMBE vocoder, so buffering and smoothing rest on the server and the client, not on the radio itself. More on working with a smartphone — DMR radio on a smartphone.

How to diagnose: one simple sign

The whole diagnosis comes down to separating RF from network. Open the hotspot logs (MMDVMHost writes them in detail) and watch two numbers during reception:

• BER high, packet loss low → the problem is on the RADIO. Antenna, distance, SWR, frequency calibration.
• BER around 0%, packet loss high → the problem is in the NETWORK. Wi-Fi power-save, jitter, channel, power supply.
• both fine, but it only breaks up in the app on the phone → the app layer, a thin buffer on a jittery mobile network.

This simple test saves hours. The vast majority of "audio breaks up" complaints with clean BER come down precisely to the network — and specifically to a sleeping Wi-Fi on the Pi.

Fix checklist

• Wired Ethernet instead of Wi-Fi. The most reliable cure for a stationary hotspot: plug in a cable and forget about wireless quirks.
• Disable Wi-Fi power-save on the Raspberry Pi if a cable is not possible. This removes the lion's share of "network" dropouts at BER 0%.
• Proper power supply. Power dips on the Pi and modem cause both network failures and frequency drift. A good 5V/3A PSU and a quality cable are not a luxury.
• Modem frequency calibration. Removes RF dropouts and inflated BER on budget boards.
• Antenna and placement. Raise the hotspot, fit a decent antenna, do not hide it in a metal cabinet.
• A stable channel for mobile internet. If the hotspot hangs on LTE — pick a spot with a steady signal; jitter is only cured by channel stability.
• A solid jitter buffer in the app. For reception on a smartphone, evenness matters more than minimal latency.

Conclusion

Broken "robotized" DMR audio is lost voice frames, and the whole question is where they are lost. High BER means the problem is on the radio: antenna, distance, calibration. BER near zero with rising packet loss means the network, and most often it is a sleeping Wi-Fi on the Raspberry Pi: the ping passes, but the dense stream of frames every 60 ms does not. A thin buffer in the app on a mobile network adds its own contribution at the phone. Separate these layers by the two numbers in the logs, run through the checklist — and the air will become clean.