A hotspot that misbehaves is usually diagnosed from its logs. Every fault on this page is invisible in them. The application logs record what the software did; they say nothing about the voltage arriving at the board, the temperature of the chip, the condition of the card underneath, or whether the radio 30 cm away is deafening itself.
Raspberry Pi's own documentation states that all models require a 5.1 V supply, and that on models since the B+ the low-voltage detection triggers when "the supply voltage drops below 4.63 V (±5%)."
It rarely presents as a power problem. The symptoms are indistinguishable from software faults, which is why they are so often chased in the wrong place:
The Pi's demand is not high but it is spiky. A supply that holds 5.1 V under a steady draw can sag below threshold during a transient — and a thin or long USB cable drops more voltage than the supply's rating suggests.
On a Pi 3, 4 or 5 — the boards used for duplex and repeater builds — the detection exists and can be read:
vcgencmd get_throttled
0x0 means nothing has gone wrong since boot. Anything else decodes bit by bit:
| Bit | Meaning |
|---|---|
| 0 | Under-voltage detected — right now |
| 1 | Arm frequency capped — right now |
| 2 | Currently throttled |
| 3 | Soft temperature limit active |
| 16 | Under-voltage has occurred since boot |
| 17 | Arm frequency capping has occurred since boot |
| 18 | Throttling has occurred since boot |
| 19 | Soft temperature limit has occurred since boot |
So 0x50005 sets bits 0, 2, 16 and 18: under-voltage now, throttled now, and both have
happened before. 0x50000 sets bits 16 and 18 only — it happened earlier and has passed.
The sticky bits are the useful ones. A hotspot that browses cleanly at midday may still report
0x50000 from a sag at three in the morning.
0x50000, sets bits 16 and 18 — which that table does not define at all. If a table you
are reading puts "under-voltage has occurred" at bit 4, it will mislead you.
dmesg | grep -i voltage journalctl -k | grep -i voltage
The kernel ring buffer records hardware events the application logs never see. Undervoltage warnings, SD card read errors and USB resets all appear here and nowhere else.
Raspberry Pi documentation gives a hard limit of 85 °C on all models. Between 80 °C and 85 °C the Arm cores are progressively throttled back; at 85 °C both the cores and the GPU are throttled. The Pi 3B+ additionally has a soft limit, 60 °C by default, at which the clock drops from 1.4 GHz to 1.2 GHz.
vcgencmd measure_temp
A hotspot is a harder thermal case than a Pi on a desk, for reasons that compound:
Throttling does not announce itself. It presents as a dashboard that has become slow, a device that takes a long time to respond, or audio that stutters under load — all of which look like software problems. On a 3B+ the soft limit at 60 °C is reached far more easily than the numbers suggest, because 60 °C is not a temperature a sealed case has any trouble reaching.
The SD card is a hotspot's only storage and the component most likely to fail. Three separate mechanisms are at work, and they are usually confused with one another.
An SD card holds pending write operations in a controller cache. Removing power without a clean shutdown leaves those writes incomplete, and the result is a filesystem that was consistent when you pulled the plug and is not when you restore power. This is the single most common way a working hotspot becomes a dead one, and it is entirely preventable — the dashboard's shutdown exists for this.
The two faults are linked. Marginal power produces exactly the same effect as pulling the plug, repeatedly, at moments you never observe. Where a hotspot has been through several cards, the supply is worth measuring before the next one is blamed.
A hotspot writes to its card constantly — logs, dashboard state, host file updates — and consumer SD cards have limited write endurance and modest wear levelling. The Raspberry Pi Linux project's own issue tracker carries an open report describing the operating system's default logging and journaling behaviour as "SD-hostile", characterising it as high-churn writing of low long-term value.
Counterfeit cards compound it. A card whose label claims more capacity than the chip provides will appear to work perfectly until the write pointer passes the real capacity — which on a device that writes slowly may be weeks after purchase, presenting as a mysterious fault with no obvious cause.
Some faults cannot be fixed at all, because they were determined before the device was powered on. Each of these is diagnosable in a minute if you know to look, and baffling if you do not.
A commercial radio bought secondhand may be built for a frequency range that does not include the amateur allocation. The radio is not faulty; it will simply refuse the codeplug, or accept it and transmit nothing usable. The band split is stamped on the radio and stated in the model number, and it is the first thing to check on a surplus purchase — before the price.
The three modem types look broadly alike in a photograph. A hotspot board has one ADF7021 and one antenna connector. A duplex board has two of each. A repeater board has neither — no RF chip, no antenna connector — because it is designed to plug into a repeater's existing radios. A repeater board bought as a hotspot cannot transmit at all, and nothing in the software will explain why.
On the original Pi Zero W and the Pi 3A+, the dashboard features that parse logs — resolving callsigns to names, talkgroup numbers to names — are absent by design. WPSD's documentation states these boards "don't have the headroom and aren't supported for these features." Their absence is not a fault and no amount of reinstalling will produce them.
Modem firmware is matched to the crystal on the board, commonly 14.7456 MHz or 12.2880 MHz. Flashing the variant for the wrong crystal produces a modem that will not work, from a procedure that appeared to succeed.
A hotspot's transmitter is small. WPSD's documentation puts the ADF7021 in the 0.10 to 0.25 W range. But the duty cycle is unlike anything else in an amateur station: on a busy talkgroup the hotspot may key for minutes at a time, repeatedly, all day, and it does so a few feet from the receiver that is listening to it.
Two consequences follow, and neither appears in a log:
Log-driven troubleshooting is correct for network and configuration faults, and it is what every distribution's documentation teaches, because that is where most problems are. None of the faults on this page will appear there. They need a different set of commands:
| Question | Command | Available on |
|---|---|---|
| Has the supply sagged, ever? | vcgencmd get_throttled | Pi 3, 4, 5 — not the Zero range |
| How hot is it now? | vcgencmd measure_temp | All models |
| What has the hardware reported? | dmesg | grep -i "voltage\|mmc\|error" | All models |
| Is the card throwing errors? | journalctl -k | grep -i mmc | All models |
| How long has it really been up? | uptime | All models |
The voltage and temperature numbers are from Raspberry Pi's own documentation, not from secondary accounts. The ADF7021 power figure and the single-core limitation are quoted from WPSD's documentation. The bit-table correction was verified by decoding the worked examples given alongside the incorrect table, which only resolve correctly under the official numbering.
Two claims rest on fewer sources than the rest and are marked here rather than buried: the statement that the Zero range carries no undervoltage detection rests on two origins — the Raspberry Pi documentation and a forum discussion — and the SD-hostile logging characterisation comes from a single open issue on the Raspberry Pi Linux tracker.
Return to n6jet.com — 73 de N6JET
Sources and further reading: Raspberry Pi — Power Supplies documentation · Raspberry Pi — Frequency management and thermal control · raspberrypi/linux issue 7234 — SD-hostile logging and journaling defaults · Hackaday — Raspberry Pi and the Story of SD Card Corruption · Raspberry Pi Forums — reading input voltage on the Zero · Handheld and Hotspot Troubleshooting · Pi-Star and WPSD