Every day someone posts the same three problems: a Bitaxe that boots but sits at 0 GH/s, a NerdQaxe rebooting every two minutes, a machine that claims to be hashing while the pool sees nothing.
I got tired of writing the same answers, so I wrote them all down properly.
https://solofury.com/blog/home-miner-troubleshooting-bible/Free, no signup, no email wall. Available in 10 languages.
What's in it- Six failure domains that explain nearly every dead unit: power, ASIC init, thermal, network, stratum, firmware
- A 60-second triage — five questions that tell you which domain you're in before you touch anything
- How to read the serial log at 115200 baud, with an annotated healthy boot so you know which milestone failed
- A master symptom table, 31 rows, symptom to likely cause to first action
- A dictionary of red error lines written verbatim as the firmware prints them, so Ctrl+F on your exact string lands on the answer
- Model-specific quirks for Ultra, Gamma 601/602, GT, Hex, Touch, NerdQaxe++, clones, and the BM1373 generation
- A PRO bench section: three DC measurements that partition any power fault, plus what a repair bench can and can't fix
Three things that surprise people1. USB-C powers the ESP32, not the ASIC. A board running on USB-C alone boots, serves the dashboard, and hashes at exactly 0 GH/s drawing about 2W. It imitates a dead regulator precisely. This costs the community hours every week.
2. A latched TPS546 fault survives software restarts. The fault state lives in the regulator's own status register until input voltage is physically removed. Restarting from the web UI, calling the restart API, pressing the ESP32 reset button — none of them clear it. There's a whole class of GitHub issues about BM1370 boards stuck at 0 GH/s where the restart endpoint fixes nothing and a power cycle fixes everything.
3. Hardware error rate is the honest number, dashboard hashrate is a claim. A chip at 5% errors can display a proud hashrate while effective output quietly drops below what a lower clock would deliver. Tune toward accepted shares per hour, never the dashboard figure.
Also coveredAxeOS ships a power-on self-test most owners don't know exists — it names the broken subsystem in about 30 seconds. And there's a REST API on port 80 that pulls the device logs over the network, so the serial cable is only needed for boot-time failures and crash loops. There's a fleet health script in there too.
On sourcingCompiled from the ESP-Miner issue tracker and release notes, the ESP-IDF fatal errors documentation, community repair bench material, and the failure patterns that keep coming back in the Bitaxe / NerdAxe / NerdQaxe communities. Every primary source is linked at the end — 14 official links, no mirrors.
Corrections welcomeI run a solo pool, so I'll be upfront: the guide links to our connection page in one place. Everything else is vendor-neutral and points at the open source projects.
If you hit a failure mode that isn't covered, or you think something in there is wrong, post it here. It's maintained as a living document and I'd rather fix it than defend it.
