Common Symptoms

Find the closest match below. Each entry tells you which log to check first and what’s usually behind it. This is a starting point, not an exhaustive diagnostic tree — read the actual log line you get, since “Network error” and “Invalid TG” both look like “it’s broken” but mean completely different things.

See Using the Log Viewer if you haven’t opened it yet.

No RX or TX audio

Check this log: MMDVMHost

Likely causes:

  • Modem type not selected, or the wrong one selected — see No Modem.

  • RX/TX offset wrong for your modem — see Radio Offset.

  • Modem needs calibration/BER tuning — see Calibrating your Modem / Tuning BER.

  • Radio-side settings (frequency, offset, DUP, color code, talkgroup/contact) don’t match what you configured in WPSD — this is a radio-programming mismatch, not a WPSD bug. Check the relevant Zero to Hero guide for your radio.

Hotspot won’t key up / can’t transmit

Check this log: MMDVMHost

Likely causes:

  • Same as “no audio” above — offset/calibration/modem-selection issues usually show up here first.

  • Wrong DUP/offset setting on the radio for a simplex node — see the D-Star “DUP” tip if you’re on D-Star, but the same logic (simplex needs DUP+/DUP- at zero offset, not “off”) applies broadly.

  • Mode is paused — see Pausing and resuming modes.

Parrot (or other routing) works sometimes, breaks intermittently

Check this log: DMRGateway

Likely cause: If you’re also logged into VoxDMR or QSO One on your phone/PC at the same time as WPSD, that’s almost certainly it, not WPSD. Those apps connect to BrandMeister using the BM Rewind protocol (confirmed for VoxDMR; strongly suspected for QSO One), while WPSD connects using the proper MMDVM/Homebrew Repeater Protocol — and Rewind doesn’t appear to support DMR ID ESSIDs. With both devices hitting BrandMeister under the exact same, un-suffixed DMR ID at the same time, BrandMeister has no way to tell them apart, so Parrot and other routing breaks unpredictably.

Fix: Give your hotspot a unique BrandMeister Network ESSID (01-99) on the Configuration page so it registers as a distinct device — see DMR ID Collisions and the ESSID Field — or log out of VoxDMR/QSO One while using WPSD. (Neither app is supported by the WPSD team; this is just the known mechanism.)

Network Status indicator is red

Check this log: the gateway log for whichever network(s) are failing — e.g. DMRGateway for a DMR network. The specific rejection reason is almost always right there in the log.

Likely causes:

  • Bad system clock. Many digital voice networks reject connections from a device whose time is significantly wrong, and most SBCs have no battery-backed RTC — if the hotspot loses power and reconnects to the Internet slowly (or not at all) before trying to connect, the clock can be off enough to cause exactly this. Check Admin -> Advanced -> System / Device Details -> Time Synchronization Status — it shows whether the system clock is actually synced and to what source. Once real Internet access is confirmed, it should sync and correct itself within a minute or two.

  • Bad network credentials — wrong DMR ID or password for that specific network. The gateway log will show an authentication rejection, not a generic timeout, when this is the cause.

  • General network/firewall issues — see Firewall and port requirements.

  • The specific reflector/master/host is down or was pruned — see the “Can’t link/connect” entry above.

Mode Status indicator is red

Check this log: MMDVMHost — this is a different problem from Network Status above; it means MMDVMHost itself can’t talk to the modem/RF hardware, before any network is even involved.

Likely causes:

  • Modem not detected, wrong modem type selected, or a modem/firmware mismatch — see No Modem and run sudo wpsd-detectmodem over SSH to confirm what’s actually connected and whether the firmware on it is current.

  • Bad or loose physical connection to the modem/HAT.

Dashboard shows a transmission that never ends (“stuck”/”phantom” TX)

What’s happening: This is a display glitch, not a real transmission — your hotspot is not actually stuck keying up. It happens when something interrupts MMDVMHost mid-transmission (a mode getting paused, a network drop, etc.) right as it was transmitting, before it gets the chance to log that the transmission actually ended. The dashboard reads that log to decide whether you’re currently transmitting, and without that missing “end of transmission” entry, it just keeps showing TX as active indefinitely — even though nothing is actually happening on the air.

Fix: Over SSH, run:

sudo wpsd-system-manager -fl

This cleans up the specific log entries that are confusing the dashboard, without touching anything else. The stuck indicator should clear within a few seconds.

If that doesn’t clear it, there’s a more thorough option:

sudo wpsd-system-manager -pl

This restarts all WPSD services and clears out the day’s logs entirely — the same net effect on the dashboard as a reboot — and it always resolves it.

We get asked about this a lot, so if your RX/TX status looks “stuck,” try this before assuming something’s actually wrong with your hotspot or radio.

Dashboard won’t load / unreachable

Check this log: MMDVMHost is still worth a glance (confirms the box itself is alive), but this is usually a network problem, not a WPSD-service problem — there’s no dashboard-specific log to view from the dashboard if you can’t reach the dashboard.

Likely causes:

  • http://wpsd.local (or similar .local address) doesn’t resolve. This almost always means your network doesn’t support mDNS/Bonjour-style .local discovery — common on some routers, guest/isolated Wi-Fi, and some Android devices. It’s a network limitation, not a sign WPSD isn’t running. Find the hotspot’s IP directly from your router’s connected-devices list and browse to that instead.

  • Hotspot’s IP changed (no static/reserved IP set) — see Giving your hotspot a consistent IP address for the long-term fix so this stops happening.

  • Wi-Fi never actually connected after initial setup — see Initial Dashboard Access.

  • If you can reach it locally but not remotely, that’s expected — see Firewall and port requirements for what’s exposed by default.

Caller Details / Talkgroup Names not showing

Not a bug — these features work by parsing the MMDVMHost/gateway logs in real time, which takes meaningfully more CPU than core hotspot functions. Single-core boards (original Pi Zero W, Pi 3A+) don’t have the headroom and aren’t supported for these features. See the FAQ for the full explanation. A multi-core SBC (Pi 3B/3B+ or newer, Pi 4, Pi 5, Zero 2 W, etc.) is required.

Update fails, hangs, or won’t apply

Check this log: MMDVMHost and the specific gateway logs for services that may have failed to restart post-update.

Likely causes:

  • Auto-Updates and Diagnostics was disabled at some point — see the warning under Auto-Updates and Diagnostics; this silently stops updates entirely, not just notifications.

  • Interrupted update (power loss, disconnected mid-update) — see Resetting WPSD for recovery options.

Config restored but something’s still wrong / lost after restore

Likely causes:

  • The restore was double-clicked or interrupted — restores run as an unlocked background process, and clicking twice fires a second overlapping restore. See Backup and Restore Configuration.

  • Passwords are not part of a backup — restoring doesn’t revert your dashboard password, it leaves the current one in place. Same section above covers this.

MMDVMHost (or another service) keeps restarting / won’t start

Check this log: MMDVMHost, or the specific service that’s failing — look for the error immediately before the restart, not just the fact that it’s restarting.

Likely causes:

  • Modem not detected/wrong type — see No Modem and run sudo wpsd-detectmodem over SSH to confirm what’s actually connected.

  • A hand-edited config file conflicting with what the Configuration page expects — see How WPSD Manages Hostfiles for why hand-edits and WPSD’s managed configs don’t mix well, and Profiles as your way back to a known-good state.

Duplicate or “ghost” transmissions / double-keying

Check this log: the relevant gateway log — look for the same traffic being routed twice.

Likely causes:

Still stuck after checking the logs against the above? Time to ask for help — and bring the zip from Download All Logs with you.