Wi-Fi or Ethernet for a hotspot: why packets are lost and audio breaks up

A scenario familiar to many: the hotspot is assembled, the radio decodes the repeater at BER 0.0%, the indicators are green — yet the voice on the air breaks up, stutters, drops syllables. The first thing people blame is the antenna or the RF side. But in nine cases out of ten the culprit is not the radio path, it is the network between the hotspot and the router. And most often, specifically, Wi-Fi.

DMR is a dense realtime stream: a voice superframe pushes UDP packets to the network server roughly every 60 ms, with no buffering and no retransmission. Lose a packet and you lose a piece of speech forever. A link that handles web and video perfectly (where a buffer smooths over any dropouts) can turn out to be unusable for DMR. Let's look at why this happens and what to do about it.

Why Wi-Fi drops DMR while ping doesn't notice

The main culprit is Wi-Fi power saving (power-save). To save current, the Wi-Fi chip periodically goes to sleep between the access point's beacons and wakes only for short windows. For ordinary traffic this is invisible: the data waits in the router's buffer until the next wake-up. But DMR can't wait — a packet that arrives while the radio is asleep either arrives tens of milliseconds late (jitter) or is lost entirely.

The insidious part is that ordinary diagnostics mask this. Run a ping to the router — the sparse once-a-second packets get through with 0% loss, because the chip manages to wake up for each one. But a dense DMR stream (16–17 packets per second) loses 15–40% under the same conditions. The MMDVMHost logs meanwhile show perfect over-the-air BER — because the radio reception is fine; it is the network delivery that breaks.

How to tell network loss from RF loss

Before changing anything, it's worth pinning down the problem precisely. A few practical checks:

• Look at the BER in the log. High BER (single and double digit percentages) with stuttering means RF: antenna, frequency, signal level. Low BER with stuttering means the network.
• A long ping with a short interval. Run ping -i 0.06 (a flood every 60 ms, like DMR) to the router for a couple of minutes. If loss and latency spikes show up specifically on the frequent ping but not on the ordinary one — the diagnosis is made.
• Move to a wire. The most honest test: plug in an Ethernet cable and repeat the same conversation. If the audio became smooth, it was Wi-Fi 100%.
• Neighboring networks. On 2.4 GHz in dense housing, dozens of other people's access points jam the air. A Wi-Fi scan will show how noisy the channel is.

If the audio breaks up even on a wire, the cause is not Wi-Fi and it's worth checking other nodes. A detailed breakdown of the symptoms is collected in the article hotspot not working, and reachability issues from outside are covered in hotspot behind NAT.

Solution #1 (best): an Ethernet cable

A wired connection removes the problem entirely. No power-save, no jitter from other networks, stable latency. If the hotspot sits in a fixed location — run a twisted pair; it is the most reliable solution, full stop.

• The Raspberry Pi 3B/3B+/4 has a built-in gigabit or 100-megabit port — just plug in the cable and DHCP will pick up an address.
• The Raspberry Pi Zero/Zero 2 W has no port — but the problem is solved by a cheap USB-OTG to Ethernet adapter (on a chip like the RTL8152). Linux picks these up with no fuss.
• If the router is far away, a PowerLine adapter (HomePlug) over the mains wiring is better than Wi-Fi. The latency is more predictable.

Practice shows it: a hotspot that moves from the Pi Zero's built-in Wi-Fi to USB-Ethernet stops "gurgling" instantly — without a single edit to the config.

Solution #2: if it has to be Wi-Fi — tame it

You can't always run a cable (a hotspot in a car, at a cabin, in an attic). In that case Wi-Fi has to be configured properly. In order of priority:

Disable power-save — a mandatory step

This is the most important thing. A one-off command (resets after a reboot):

• iw dev wlan0 set power_save off — you can check the current state with iw dev wlan0 get power_save.

To make the setting survive a reboot, on systems with NetworkManager (current Raspberry Pi OS based on Bookworm) set the connection parameter 802-11-wireless.powersave = 2 (the value 2 means "off"):

• nmcli connection modify <name> 802-11-wireless.powersave 2
• On older systems without NetworkManager, the line iwconfig wlan0 power off in a startup script or a brcmfmac driver rule does the job.

Signal and band

• Closer to the router. The higher the signal level, the fewer link-layer retransmissions and the more stable the delivery. A hotspot behind two walls at the edge of coverage is a common cause of broken audio.
• 5 GHz instead of 2.4 GHz. The 5 GHz band is less congested and gives less jitter. But note: the built-in Wi-Fi on the Pi Zero 2 W and the basic Zero is 2.4 GHz only. For 5 GHz you need a Pi 3B+/4 or an external USB adapter.
• A fixed channel on the router. Auto channel selection sometimes jumps right in the middle of a QSO. Pick a free channel manually based on the scan results.

Solution #3: proper power

A non-obvious but real factor: a voltage sag hits the Wi-Fi radio first of all. Under-volting makes the chip misbehave, retransmissions and losses go up — and from the outside it looks like "bad Wi-Fi". A cheap 5 V / 1 A charger and a thin cable are the classic trap.

• Use a power supply with an honest current rating (for the Pi 3/4 — 2.5–3 A and up), ideally with a voltage slightly above 5 V under load.
• The cable should be short and thick. A meter-long "noodle" microUSB drops half a volt on the wires alone.
• A sign of under-volting is a lightning-bolt icon in the corner of the screen or throttling entries in the system log.

A detailed breakdown of power, currents and cables is in the separate article on hotspot power. Don't skip this point: half of all "network" complaints are cured by changing the charger.

Checklist: audio breaks up with clean BER

• 1. Logs: is BER near zero? Then the problem is the network, not RF.
• 2. Plug in Ethernet and test the same conversation — did the audio even out? Wi-Fi is to blame.
• 3. No way to run a cable — disable power-save: iw dev wlan0 set power_save off + make it stick via NetworkManager (powersave 2).
• 4. Reboot and confirm that power-save stayed off.
• 5. Move the hotspot closer to the router, switch to 5 GHz where possible, fix the channel.
• 6. Check the power: a quality 2.5–3 A PSU and a short, thick cable.
• 7. If the audio breaks up even on a wire — dig further with the troubleshooting checklist.

Conclusion

If the hotspot decodes the air with clean BER but the voice breaks up — the network is almost always to blame, not the radio. On a Raspberry Pi with Wi-Fi, the first suspect is the chip's power saving: it drops the realtime stream of DMR frames while staying invisible to an ordinary ping. The best remedy is Ethernet; if a wire isn't available — disable power-save and make the setting stick, move closer to the router, switch to 5 GHz, and provide honest power. Work through the checklist above — and the stuttering will go away.