A Raspberry Pi running a camera and a USB disk reboots at random and the disk keeps dropping out, with nothing in the application logs. How do you check whether power is the cause?

## Why the application logs are empty The symptom set — spontaneous reboots, USB devices disappearing and reappearing, SD card read errors, a board that feels sluggish under load — has one thing in common: none of it is the application's doing, so nothing appears in its log. Undervoltage on a small board is a *hardware* condition that the firmware detects and reports through its own channel, and if you do not know where that channel is you can spend days blaming software. ## The throttle bitmask The firmware exposes the condition through `vcgencmd get_throttled`, which prints something like `throttled=0x50005`. It is a bitmask with two halves: - **Bits 0–3 — happening now.** Bit 0: under-voltage detected. Bit 1: ARM frequency capped. Bit 2: currently throttled. Bit 3: soft temperature limit active. - **Bits 16–19 — has occurred since boot.** The same four conditions, sticky. Bit 16: under-voltage has occurred. Bit 17: ARM frequency capping has occurred. Bit 18: throttling has occurred. Bit 19: soft temperature limit has occurred. That split is the whole diagnostic value. A board being interviewed at a calm moment reports `0x0` in the low bits while the high bits still testify to what happened during last night's load spike. `throttled=0x0` on a machine with meaningful uptime is a genuine all-clear; anything with bit 16 set is a power problem regardless of how healthy it looks right now. ```bash vcgencmd get_throttled # e.g. throttled=0x50005 vcgencmd measure_temp # SoC temperature vcgencmd measure_volts core dmesg | grep -i voltage ``` The kernel also logs under-voltage events, so the journal carries a timestamped history you can line up against your reboots — far more useful than a single instantaneous reading. On a desktop session the same condition draws a lightning-bolt indicator on screen. ## Under-voltage is not the same as thermal throttling Both reduce performance and both set bits in the same mask, but the fixes are opposite. Thermal throttling begins when the SoC approaches roughly 80 °C, with a hard cap near 85 °C; the answer is airflow, a heatsink or a case with a fan. Under-voltage means the 5 V rail has sagged below the firmware's threshold; the answer is electrical. Check `measure_temp` before you buy a fan for a problem that was a cable. ## Why the supply's amp rating misleads people The most common wrong conclusion is "I'm using a 3 A supply, so it can't be power." Undervoltage is about *volts under load*, not the label on the brick. Three things cause a supply that is nominally adequate to sag: - **Cable resistance.** A long, thin USB cable — especially one sold for charging rather than power delivery — drops a meaningful fraction of a volt at 2 A. The supply is fine; the voltage arriving at the board is not. - **Transient draw.** A camera starting up, a spinning disk seeking, or a Wi-Fi transmit burst pulls current in short spikes. A supply that holds 5 V at steady state may dip below threshold for milliseconds, which is enough for the firmware to flag it and enough to knock a USB device off the bus. - **Peripherals powered through the board.** Bus-powered disks and hubs pull their current through the Pi's own regulator and connector. That is what a powered hub or a self-powered enclosure is for. On the Raspberry Pi 5 there is an extra wrinkle worth knowing: the board negotiates over USB Power Delivery, and with a supply that cannot deliver the higher current it restricts the total current available to downstream USB peripherals. A board that runs a bare workload fine but cannot keep a disk alive is exactly that scenario. ## The shape of a good answer An interviewer asking this is checking whether you reach for platform-specific evidence before rewriting code. The strong answer is a sequence: read the sticky throttle bits, correlate the kernel's under-voltage log entries with the reboot times, check the temperature to rule out the other cause, and only then change the electrical setup — a known-good supply, a short thick cable, peripherals on their own power — and re-check that the sticky bits stay clear over a full load cycle. Fixing it and *proving* it stayed fixed with the same bitmask is what separates a real diagnosis from a guess that happened to coincide with a quiet week.