PiAxe – 12V DC Rail Undervoltage Drops RPi

SSH into the Pi and run `vcgencmd get_throttled`. Record the hex value. Then `dmesg | grep -iE "voltage|throttl"` and `journalctl -k --since "1 hour ago" | grep -iE "voltage|throttl"`. Bit `0` (`0x1`) = undervoltage right now; bit `2` (`0x4`) = throttling now; bit `16` (`0x10000`) = undervoltage has occurred since boot; bit `18` (`0x40000`) = throttling has occurred. Any non-zero value confirms the rail is or was below the Pi PMIC's `4.63 V` threshold. `0x0` clean = power is fine and your problem is elsewhere.

Sketch your current power topology. Where is `5V` coming from? Where is `12V` coming from? Two separate wall plugs or one shared? Is the PiAxe HAT taking `12V` from a barrel jack, or pulling from Pi GPIO `5V` and stepping up? Is the Pi's USB-C plugged in directly, or fed from a step-down on the HAT? Single-supply topology = root cause confirmed; go to step 4. Two-supply but undersized = step 3.

Verify PSU nameplate ratings against load. Pi 4 needs `5V/3A` (`15 W`) minimum; Pi 5 needs `5V/5A` (`25 W`) for full peripheral current. PiAxe BM1366 needs `12V/2A` sustained, `5A` strongly recommended for transient bursts. If either PSU is undersized, swap with a correctly-rated unit before any other diagnosis. Re-run step 1 after swap.

Split the rails - the canonical fix for this error class. Order the components: official Raspberry Pi USB-C PSU (`5V/3A` Pi 4, `5V/5A` Pi 5) and a dedicated `12V/5A` barrel-jack DC supply (5.5 mm x 2.1 mm by default - verify against PiAxe HAT silkscreen). Wire the Pi's USB-C directly to its dedicated PSU. Wire the HAT's 12V input directly to the 12V brick. Do NOT bridge `5V` between Pi and HAT through GPIO. Power up. Re-run step 1.

Replace the Pi's USB-C cable with an official Raspberry Pi cable or a USB-IF certified `100 W` PD cable from a reputable brand (Anker, Cable Matters, Apple). Cheap unbranded cables drop `0.3-0.5 V` across a meter at `3 A` due to undersized conductors - enough alone to trip the PMIC's `4.63 V` threshold. This single swap clears more undervoltage tickets than any other fix.

Probe the Pi `5V` rail with a multimeter on DC, at GPIO header pin 2 or 4 referenced to a `GND` pin (e.g. pin 6). Run `pyminer.py` at full hashrate while measuring. Target: `>= 4.85 V` sustained, `>= 4.75 V` transient minimum. Any sustained sag below `4.65 V` confirms a droopy rail - PSU undersized, cable resistance too high, or both. If the rail measures solid above `4.85 V` but the PMIC still fires, the dip is sub-millisecond transient (step 7).

Audit GPIO `5V` back-feed and HAT-side step-down quality. If your PiAxe HAT has a `12V -> 5V` step-down for the Pi, scope or measure its output under load - a dip below `4.65 V` during BM1366 burst current confirms the step-down is the failure point. Cleanest fix: stop using the HAT-side step-down entirely; feed the Pi from its own USB-C. If you must use a step-down, source one rated for `5V/5A` continuous with low transient response (LM2596 modules from cheap kits will not cut it - look for buck converters with capable transient response and proper output capacitance).

Reset all sticky throttle bits and re-validate. Power cycle the Pi (full unplug, 30 second wait, replug). After clean boot, run `pyminer.py` for 30 minutes at full hashrate. Re-run `vcgencmd get_throttled`. The high-bit history flags (`0x50000` family) only clear on reboot - so without a reboot you cannot tell if a recent fix actually held. A clean `throttled=0x0` after 30 minutes of full hashing post-reboot is the only honest pass.

Verify Pi 5 PD negotiation if you are on Pi 5. Pi 5 with a generic `5V/3A` USB-C boots in peripheral-limited mode that caps GPIO and USB current at `600 mA`. PiAxe HATs that draw any GPIO `5V` will hit that cap. Use the official Raspberry Pi `5V/5A` (`27 W`) USB-C PSU or a confirmed `27 W` PD-capable third-party. Verify with `dmesg | grep -i pmic` after boot - look for `current limit: 5000mA` (good) versus `current limit: 3000mA` (peripheral-limited).

Eliminate PoE HAT contention if relevant. PoE HATs typically supply `5V/2.5A` to the Pi which is below Pi 4 spec with zero headroom for a stacked ASIC HAT. PoE is for low-power IoT, not ASIC mining. Remove the PoE HAT, route a dedicated USB-C to the Pi, and a dedicated `12V` to the PiAxe. There is no clever way to power both rails from PoE - it does not have the wattage budget.

If you have an oscilloscope, scope the `5V` rail at the Pi GPIO header during pyminer startup and during sustained hashing. Trigger on falling edge below `4.7 V`, single-shot. The BM1366 pulls in nonce-search bursts on microsecond timescales; a marginal supply will dip transiently below `4.63 V` for `200-500 us` and recover before a multimeter sees it. If you capture transient sags below threshold, you cannot fix this with cable / PSU swaps alone - you need the rail-split topology (step 4) to remove the shared current path.

Audit wall outlet voltage. Plug a wall-outlet logger (Kill-A-Watt, P3 P4400, or generic clamp meter that records over time) into the same outlet feeding the PiAxe kit. Run for 24 hours. North American spec is `120 V +/- 5%` (`114-126 V`). If the line dips below `108 V` during peak load hours, your PSU is starving and your `5V` rail sags as a downstream consequence. Same evening-sag mechanism that wrecks Antminer S19s in residential basements, scaled down. Move the PiAxe to a dedicated circuit if the kitchen / shared circuit shows sub-`108 V` events.

Build a multi-PiAxe farm power distribution rack if you are running 3+ units. Single 12V/40A bench supply (Mean Well RSP-500-12 or equivalent) with individual fused taps to each PiAxe HAT, plus a separate USB-C charging hub (Anker 100W+ 6-port) for all the Pis. This is the open-source equivalent of the Antminer farm PDB topology - one beefy industrial supply per voltage rail, fused per unit. Costs about `$200 CAD` to build, scales cleanly to 8-10 units, and eliminates the per-unit PSU lottery entirely.

Add a continuous throttle-monitoring cron job. Edit crontab with `crontab -e`, add: `*/15 * * * * /usr/bin/vcgencmd get_throttled >> /var/log/throttled.log`. Tail occasionally; pipe to a Discord/Telegram webhook if the value goes non-zero. Catches PSU degradation a month before SD corruption. For a multi-unit farm, ship the log into Prometheus / Grafana via node_exporter's textfile collector and alert on any non-zero throttle bit across the fleet.

Switch the rootfs to read-only mode for long-term mining if SD-card corruption from past undervoltage events is a concern. Install the `overlayroot` package (`sudo apt install overlayroot`), enable read-only root in `/etc/overlayroot.conf` with `overlayroot=tmpfs:swap=1`. Reboot. The kernel can no longer write garbage to the SD card during a brownout; logs go to RAM. Trade-off is that config changes need a temporary `overlayroot-chroot` session - acceptable for a dedicated mining Pi.

Escalate to D-Central's open-source / pleb-mining queue if Tier 1-3 fixes pass every gate (`vcgencmd get_throttled` returns clean `0x0`, multimeter reads good rail, scope shows no transients) but the BM1366 still produces zero hashrate. Likely chip-level undervoltage damage from past brownouts. Email support with: Pi model, OS version, photos of the HAT (look for burnt PMIC / cracked caps), `dmesg` and `pyminer` logs, throttled-history log if you have it.

Ship the kit to D-Central for bench work. Pack the PiAxe HAT and (if you suspect Pi PMIC damage) the Pi separately in anti-static bags, double-box with `3 cm` of foam on every side. Include a printed note: Pi model, OS, kernel version, current power topology sketch, the failure mode you observed, the fixes you tried and their results, and any electrical events (surge, reverse-polarity, brownout) the kit lived through. Half an hour of preparation saves billable bench time.

D-Central bench process for undervoltage casualties: visual inspection for burn / cap damage, continuity test on the HAT's `12V` and `5V` rails, BM1366 response test on a known-good Pi 4 + reference dual-rail topology, BM1366 chip replacement from stock if unresponsive, reflow + reassembly, 4-hour burn-in at target `500 GH/s` on solo.ckpool.org. We return the unit with a printed test report. Turnaround `3-7` business days Canada-wide, `5-10` days international.