Hotspot won't join the DMR network: systematic troubleshooting

A hotspot only seems temperamental at first glance. When it "won't join the network," the cause is almost always one of a dozen perfectly concrete issues, and nearly every one can be caught in five minutes if you work in order instead of yanking at everything at once. This article is systematic troubleshooting: we descend from the "hardware" (power, modem) through the settings (frequency, Color Code) to the network (NAT, port forwarding) and finish on the air (the radio can't hear the hotspot). Go down the list from top to bottom, and the problem turns up.

Let's agree on the vocabulary up front. A hotspot is a tiny bridge: a single-board computer (Raspberry Pi, Orange Pi) or an ESP board plus an MMDVM radio module that listens to your radio on the air and carries the voice to the internet, to the network's master server. "Won't join the network" can mean three different ailments: the hotspot doesn't see the modem, the hotspot didn't log in to the master, or the hotspot logged in but the radio "can't hear" it. These are three different diagnoses, and they're treated in different ways.

Step 0. First, localize: where exactly is the break

Before fixing anything, work out which of the three lines the signal is stuck on. This saves you an hour.

• The LEDs on the MMDVM board. Most boards have a PWR (power) LED and a modem activity indicator. If only power is lit and there's no "life" — the problem is at the hardware or modem-firmware level.
• Status in the dashboard / Last Heard. Did the hotspot appear in the device list and go "online"? Then it reached the master — look for the problem on the air now (frequency, CC, mismatch). Didn't appear — the problem is between the hotspot and the master (login, NAT, ports).
• The radio is silent on receive, but others can hear you. A classic TX/RX mismatch or the wrong Color Code on the radio's side.

Remember this split: "can't see the modem" → hardware, "not online in the dashboard" → network, "online, but the air is dead" → frequency/CC/calibration. Next we break down each block.

1. Power and voltage sag — cause #1 that people think of last

Nine out of ten "mysterious" hotspot problems are power. A single-board computer under load plus a radio module transmitting means short but vicious current spikes. A cheap power supply or a thin microUSB cable can't hold the spike, the voltage sags below 4.8–5.0 V, and the circus begins: the modem "drops out," Wi-Fi breaks, the system reboots out of nowhere.

How to check and fix:

• Power supply. For a Raspberry Pi, get an honest 5 V / 3 A unit (not "a charger from an old phone rated 1 A"). For a Pi Zero, 2.5 A is enough, but no less.
• The cable — the main culprit. A thin or long USB cable drops voltage across its own resistance. Swap the cable for a short, thick one before you start blaming the software.
• The sag symptom in Pi-Star/Linux. On a Raspberry Pi, the sign of being underfed is the "lightning-bolt icon" and under-voltage detected messages in the system log. See it — replace the PSU; you can stop diagnosing there.
• USB hub and peripherals. If a 4G USB modem or a disk is also plugged into the single-board computer — power them separately, otherwise they steal current from the MMDVM on transmit.

2. Modem not detected — the hotspot can't see its "radio half"

A hotspot is two halves: a computer (the single-board computer) and a radio modem (MMDVM). If the computer can't see the modem, there's nothing to join the network with. Symptoms: the MMDVM log spins an endless "Opening" / "Modem not responding," and there's no modem firmware version at startup.

How to check and fix:

• Connection type. HAT boards sit on the GPIO and talk over UART (a port like /dev/ttyAMA0 or /dev/serial0). USB dongles — over /dev/ttyUSB0 or /dev/ttyACM0. Specify the wrong port in the settings and the modem is "not detected," even though it physically works.
• UART conflict with the console. On a Raspberry Pi, the serial console and Bluetooth like to take the very UART the HAT needs. If you set the system up by hand — disable the serial console and remap Bluetooth, otherwise the modem will be "busy."
• Contact and seating. The board seated poorly on the GPIO header, a pin got bent — the modem "comes and goes." Pull it off and seat it again, fully home.
• USB chip driver. Cheap dongles on CH340/CP2102 sometimes need the chip to be recognized by the system. Check that the device even showed up in the USB device list.

3. Wrong frequency — the hotspot is on the network, but in the wrong "lane"

The hotspot logged in, it's "online" in the dashboard, but there's no air. The first suspect is frequency. A simplex hotspot works on a single frequency for both receive and transmit, and the radio must be set exactly on it. Drift apart by ten kilohertz and the link either breaks or doesn't exist at all.

• Simplex vs duplex. Most amateur hotspots are simplex: one frequency. In the radio, the RX and TX of this channel must match the hotspot frequency. If you have a duplex board (two frequencies, a split), the radio's RX/TX frequencies mirror the hotspot's frequencies.
• Band plan and range. Make sure the frequency lies in the amateur band your radio supports (UHF/VHF) and doesn't overlap with nearby repeaters.
• The crystal's real frequency. Cheap modems "lie" by a few kHz due to crystal spread — there's a separate point below on calibration. If everything is set correctly and the link is marginal — it's almost certainly the modem's frequency offset.

4. Color Code — the "timeslot password" without which the radio stays silent

Color Code (CC) in DMR is an identifier from 0 to 15 that must match between the hotspot and the radio, otherwise the receiver simply ignores the foreign signal (in spirit, it's like the sub-tone on analog radios: no match — no open). Frequency correct, hotspot online, but no reception — check the CC first.

• CC match. The Color Code in the hotspot settings and in the radio's channel (codeplug) must be identical. By default, in many hotspots it's CC1 — check that the radio has the same.
• Where to look in the radio. CC is set in each digital channel separately. You copied a channel, forgot to fix it — and you'll have a "dead" channel among the working ones.
• Timeslot. On a simplex hotspot, a single slot is usually used (often TS2). If the codeplug has a different one — the radio and the hotspot are talking "through different doors."

5. TX/RX mismatch — I hear others, but they don't hear me (or vice versa)

The trickiest case: there seems to be a link, but it's one-way. You receive someone else's voice, but no one hears your TX — or the other way around. This is a TX/RX mismatch, and it has two big groups of causes.

• Frequency offset on transmit and receive. On cheap modems, TX and RX can "drift" differently. It's fixed by tuning the TX/RX offset separately — more on that below, under calibration.
• Modulation levels (TX/RX level). A DAC/ADC level on the modem that's too high or too low distorts the signal: the radio catches "mush" instead of data. This is the standard level edit in the MMDVM settings.
• Inversion / polarity. Some boards require TX or RX inversion. If the air is "there, but won't decode" — try toggling the inversion.
• Overheating and drift. The modem warmed up after an hour of work — the frequency drifted. If the link "worked and disappeared after 20 minutes," think about thermal drift and compensate with calibration.

The key idea: a mismatch is almost always fixed not by replacing hardware, but by carefully tuning the offset and levels. That's exactly what calibration is.

6. No login to the master — the hotspot is "not online" in the dashboard

The hotspot doesn't appear in the device list, and there's no successful "logged in" in the logs. This is the "hotspot ↔ master server" line, and here the set of causes is purely a networking one.

• The hotspot itself has no internet. Trivial, but check it: Wi-Fi connected, IP obtained, DNS resolving. Does a ping to the master go through? Half of "I can't log in" is "there's no network at all."
• Wrong master address or port. A typo in the server name, an extra space, the wrong port. Cross-check the connection parameters against what the DMRhub dashboard gave you.
• Wrong password/ID. The hotspot logs in under your DMR ID. If the ID isn't registered or the connection password is wrong, the master politely refuses. If you don't have an ID yet — that's the first step, see DMR ID registration.
• The clock on the device. A badly skewed clock on a single-board computer breaks TLS handshakes and authentication. Check that NTP has synced the time.
• A firewall on the provider's side. Some mobile operators block non-standard ports. If it logs in on home Wi-Fi but not on 4G, the cause is the operator.

7. NAT and port forwarding — when the master can't "call back"

DMR voice traffic travels over UDP, and here NAT comes into play — the way your home router hides the hotspot behind a single external address. The classic symptom: the hotspot logged in (the outbound connection went through), but the voice goes only one way or breaks up — because the return UDP packets from the master can't find their way to the hotspot behind NAT.

• UDP keep-alive. Modern network masters hold the "hole" in the NAT open with regular packets. If the hotspot sits quiet — the NAT closes the port and the return traffic is lost. Usually it's fixed by the hotspot sending keep-alives itself, but with aggressive NAT, forwarding helps.
• Port forwarding. On the router, forward the network's UDP port to the hotspot's internal IP. It's best to pin the internal IP to the device with a static reservation (DHCP reservation), otherwise after a router reboot it "moves" and the forward stops working.
• Double NAT / CGNAT. If the provider hands out a "grey" IP (CGNAT), forwarding on your router is powerless — you're behind someone else's NAT. The sign: the external IP in the router doesn't match what the "my IP" sites show. The solutions are to order a public IP from the provider or to bring up a tunnel.
• UPnP. Sometimes it's enough to enable UPnP on the router and forwarding configures itself automatically — but you can't rely on that; manual forwarding is more reliable.

8. Watchdog — the hotspot reboots itself in a loop

A watchdog ("watchdog timer") is a mechanism that restarts a service or the whole system if it "hangs." A useful thing, but in a broken configuration it turns into a seesaw: the hotspot starts, something goes wrong, the watchdog kills it, it starts again — and so on in a loop, never really joining the network.

• Symptom. The device appears and disappears in the dashboard every 1–2 minutes; in the logs — repeated starts of the MMDVM service.
• The root cause is almost always lower down. The watchdog isn't the disease, it's a symptom. Most often it's "tripped" by power (sag, point 1) or a dropped modem (point 2). Fix the root cause — the seesaw stops.
• Overheating. The board heats up on transmit; in a closed case with no ventilation, the single-board computer throttles and hangs — the watchdog is in play again. Give it airflow or a heatsink.
• A corrupt SD card. Cheap/worn microSD cards return read errors, the system hits a fault, the watchdog reboots. If the reboots are chaotic — re-flash the image onto a good card.

9. The radio can't hear the hotspot — the last meter to the air

The hotspot is online, green in the dashboard, you even see the neighbors' voice in Last Heard — and the radio is still deaf. That means the problem is at the very last meter, between the hotspot's antenna and the radio's antenna.

• Frequency and CC once more. 90% of "deaf" radios are points 3 and 4: the frequency drifted or the wrong Color Code is in the channel. Re-check the specific channel you're on.
• Signal too weak / too far. A simplex hotspot is milliwatts. Go to the next room through two walls — there'll be no reception. Bring the radio closer to check.
• The hotspot's antenna. You forgot to screw on the antenna, or there's a "stub" for the wrong band — range drops to a meter. Check that the antenna is in place and matched to your band.
• Modem frequency calibration. If there's a link up close but it breaks at a couple of meters — the modem is offset in frequency. That's calibration again.
• Wrong timeslot / group call. The radio is set to listen to the wrong group or slot — it physically hears the hotspot, but "filters" the traffic. Check the RX group and talkgroup in the codeplug.

Fridge-door checklist

In short, run the hotspot through this list from top to bottom — and in 95% of cases you'll find the cause:

• Power — an honest 5 V / 3 A PSU, a short thick cable, no under-voltage.
• Modem — detected, visible in the logs with a firmware version, the correct port.
• Login to the master — internet present, correct address/port/ID, synced clock.
• NAT/ports — no CGNAT, UDP forwarding to a static internal IP.
• Frequency and Color Code — match between the hotspot and the radio on the specific channel.
• TX/RX — no mismatch, levels and offset calibrated.
• Watchdog — not rebooting in a loop (and if it is — look for power/modem/overheating).
• The air — the antenna is in place, the radio is nearby, the correct slot and RX group.