Home Miner Not Hashing? The Complete Troubleshooting Bible

Search any home mining community on any given day and you will find the same posts: a Bitaxe that boots but sits at 0 GH/s, a NerdQaxe that reboots every two minutes, a Gamma that lost half its hashrate after a firmware update, a machine that says it is hashing while the pool sees nothing. These devices are open-source hardware running open-source firmware on harvested industrial silicon, and that combination is powerful, cheap and genuinely fragile in ways an appliance is not.

This guide is the reference we wished existed every time we helped someone debug one. It covers the six failure domains that account for nearly every dead or misbehaving unit, teaches you to read the logs the way a repair bench does, and ends with a master symptom table and a dictionary of the actual error lines you will see. It applies to the whole AxeOS family: every Bitaxe (Max, Ultra, Supra, Gamma, Gamma 601/602, GT, Hex), the NerdAxe and NerdQaxe lines including the ++ and Hydro variants, the NerdOctaxe, and by extension any ESP-Miner derivative, including the new BM1373 machines covered in our BM1373 era reference.

One principle before anything else: diagnose before you touch. The order of operations in this guide exists because each step rules out an entire class of causes. Skipping ahead to reflashing firmware when the real problem is a sagging power supply wastes an evening and can leave you with two problems instead of one.

In a hurry? The five fixes that solve most cases

Before reading anything else, try these in order. Together they resolve the majority of “my miner is dead” reports without tools, without logs, and without opening the case.

1. COLD CYCLE, PROPERLY.
   Unplug the power CONNECTOR (not the wall switch).
   Count 60 full seconds. Reconnect.
   Why: regulator faults LATCH and survive every soft
   reboot; only a real power removal clears them.

2. CHECK WHAT IS ACTUALLY POWERING IT.
   USB-C runs the dashboard but CANNOT feed the ASIC.
   A miner on USB-C alone shows 0 GH/s and ~2 W forever.
   Verify the real supply (barrel/XT30) is plugged and
   seated - and that it is the RIGHT VOLTAGE (5 V vs
   12 V: the wrong one destroys the board).

3. TYPE http:// EXPLICITLY.
   Browsers silently upgrade to https:// and fail.
   http://MINER-IP - with the prefix - every time.

4. GIVE IT 2.4 GHz.
   These radios never speak 5 GHz. On mesh routers,
   make a 2.4 GHz-only or IoT SSID, WPA2-AES, and turn
   AP isolation OFF.

5. ASK THE POOL, NOT THE MINER.
   Time since last accepted share on the POOL dashboard
   is the only honest online test. Over 10 minutes =
   dead now, whatever the miner UI claims.

Fixed? Good, close the tab. Not fixed? The triage below
finds your section in 60 seconds.

Find your problem fast

Twenty sections is a lot. Three ways to skip to yours:

By search: every error string in this guide is written verbatim, exactly as the firmware prints it. Press Ctrl+F (Cmd+F on Mac), paste your error message, and you will land on it: that is a design decision, not luck.

By symptom:

By reading style: the next section splits the guide into a beginner path and a pro path.

Choose your path

This guide serves two very different readers, and you should not read it the same way.

First miner, first problem? Follow the numbered road and do not skip: the two safety rules, the built-in self-test, the 60-second triage, and then only the section the triage sends you to. Every fenced block is copy-paste ready, every term you might not know is in the mini-glossary just below, and nothing on the beginner path requires opening the case or owning a multimeter.

Comfortable with a terminal and a meter? Your fast lane: the API section for remote log pulls and fleet checks, the red-lines dictionary to jump straight from an error string to its cause, the per-model quirks table, and the professional bench section at the end, which is where the schematics, the test-point method and the board-level resources live. Sections marked PRO assume you can read a schematic and probe a live board safely.

Mini-glossary for the first-timer

Ten terms, ten seconds each, and the rest of the guide reads twice as fast.

ASIC        the mining chip itself - the only part that
            actually computes hashes
ESP32       the small controller running everything else:
            WiFi, dashboard, talking to the ASIC
AxeOS       the firmware + web dashboard on the ESP32
VCORE       the ~1.0-1.3 V supply feeding the ASIC core -
            made on-board from your 5 V or 12 V input
VRM / TPS546  the regulator circuit that makes VCORE and
            protects the chip by shutting off on faults
stratum     the protocol your miner speaks to the pool
share       a proof of work you submit; the pool counts
            these to know you are alive and honest
HW error %  results the chip computed WRONG - the honest
            health number (keep under 2%)
OTA         update "over the air" through the dashboard,
            as opposed to flashing over USB
NVS         the settings memory that survives reflashes -
            why factory reset exists

Before anything else: two safety rules and one built-in tool

The two rules that prevent dead boards

Rule one: never guess the voltage. Standard single-chip Bitaxes take 5 V; the GT, Hex, NerdQaxe++ and NerdOctaxe take 12 V. Barrel plugs from both families are physically interchangeable, and connecting a 12 V supply to a 5 V board permanently destroys it in under a second. Before every connection, read the label on the brick, not the shape of the plug. This is the single most expensive mistake in the hobby.

Rule two: a hot connector means stop. Warm is a warning; hot, discolored, or smelling of plastic means power off now and replace the cable before the next power-on. Everything else in this guide can wait until tomorrow. This cannot.

Run the built-in self-test

AxeOS ships with a power-on self-test that most owners do not know exists. It exercises five subsystems in sequence and reports the first failure on the screen, which makes it a free, thirty-second hardware diagnosis that names the failing domain for you:

WHAT IT TESTS (in order)      IF IT FAILS, SCREEN SHOWS
  input power rail              POWER FAIL
  core voltage regulator        VCORE FAIL
  I2C sensor bus                (halts during test)
  fan tach feedback             FAN FAIL
  ASIC detection                ASIC FAIL
  short hashing burst           HASHRATE FAIL

HOW TO READ THE RESULT
  POWER / VCORE FAIL   -> Power problems section. The test
                          rejects an input rail more than
                          10% off nominal - measure the PSU.
  ASIC FAIL            -> ASIC problems section.
  FAN FAIL             -> fan unplugged, jammed, or dead
                          tach wire.
  HASHRATE FAIL        -> chip detected but not computing:
                          usually marginal power or a
                          settings problem; return to stock.

IF THE TEST ITSELF WEDGES
  Screen stuck on SELF TEST over 30 seconds, or an endless
  SELF TEST -> reboot loop: on AxeOS v2.12+ hold the BOOT
  button for 2 seconds during the SELF TEST screen to
  force-skip it and reach the dashboard, then diagnose
  from there. A self-test loop after a firmware flash
  usually means a wrong image for the board.

The self-test runs automatically on first boot and can be triggered from settings. Run it after any hardware event: a transport, a heatsink remount, a PSU change. It converts “something is wrong” into a named subsystem before you have opened a single log.

What the screen is telling you

On models with a display, the OLED is a status instrument, not decoration. It cycles through information screens every few seconds; the BOOT button advances screens manually and wakes a timed-out display. The states worth recognising: the boot splash (firmware alive), the setup-hotspot screen (unconfigured or lost WiFi credentials), the IP address screen (your door into the dashboard), the self-test and FAIL codes above, an overheat warning, and the block-found animation which we hope you meet someday. A display that is dark is not proof of a dead board: check whether the display timeout setting simply switched it off, and whether the pool still shows shares arriving.

The 60-second triage

Before opening a single log, answer five questions. They partition the entire problem space.

Q1  Does anything turn on at all? (LED, screen, fan)
      NO  -> POWER DOMAIN. Go to section: Power problems.
      YES -> Q2

Q2  Does the device reach the AxeOS dashboard / show an IP?
      NO  -> Q2a: Does it broadcast its setup hotspot?
             YES -> WIFI DOMAIN. Go to: Network problems.
             NO  -> BOOT DOMAIN. Go to: Firmware problems.
      YES -> Q3

Q3  Does the dashboard show a hashrate above zero?
      NO  -> Q3a: Does it show a power fault, overheat banner,
             or 0 ASIC chips?
             power fault  -> Power problems
             overheat     -> Thermal problems
             0 chips      -> ASIC problems
      YES -> Q4

Q4  Does the POOL show accepted shares in the last 10 minutes?
      NO  -> STRATUM DOMAIN. Go to: Pool problems.
      YES -> Q5

Q5  Is the hashrate/error rate/temperature what it should be?
      NO  -> Thermal problems or Overclocking gone wrong.
      YES -> Nothing is broken. Close the browser tab.

Notice that Q4 asks the pool, not the device. The single most common wild-goose chase in home mining is debugging a miner whose UI looks perfect while the pool stopped hearing from it an hour ago. The device and the pool each see half the picture, and the guide returns to this asymmetry repeatedly.

How to read the logs

Everything else in this guide is faster if you can read the logs, so this section comes first. There are two log surfaces, and they answer different questions.

The AxeOS web log

Open the dashboard at the miner’s IP address and find the log view. This shows the live runtime log: stratum traffic, share submissions, difficulty changes, temperature events. It is the right tool when the device boots fine and the question is what it is doing now. Its limitation: it starts after the network is up, so it cannot show you a boot failure, and it dies with the web server, so it cannot show you a crash.

The serial console: the ground truth

For anything involving boot, crashes, ASIC detection or WiFi association, you need the serial console. This is the same output the developers read, and it starts from the first instruction.

1. Connect a USB-C DATA cable (not a charge-only cable) from
   the miner to a computer. On some Bitaxe boards a native
   USB-C to USB-C connection fails to negotiate; use a plain
   USB-A to USB-C cable or adapter, which forces legacy 5V.

2. Open a serial terminal at 115200 baud, 8N1:

   Windows:  PuTTY -> Serial -> COMx -> 115200
   Linux:    sudo minicom -D /dev/ttyACM0 -b 115200
             (or: screen /dev/ttyACM0 115200)
   macOS:    screen /dev/tty.usbmodem* 115200

3. Press the RST button on the board (or replug power).
   The full boot log scrolls from the beginning.

ESP-IDF log lines carry a severity letter: I for info, W for warning, E for error. Most terminals render E lines in red. A healthy boot has zero E lines. That is the entire skill of log reading in one sentence: scroll the boot, find the first E, and look it up in the dictionary at the end of this guide. The first error matters most, because later errors are usually cascade damage from the first one.

What a healthy boot looks like

Annotated and abridged. Yours will differ in details but must hit the same milestones in the same order.

rst:0x1 (POWERON_RESET), boot:0x8 (SPI_FAST_FLASH_BOOT)
        <- reset reason. POWERON is normal. Repeated RTC_WDT
           or BROWNOUT resets here are your first red flag.

I (xx) main: Found device config: <your board model>
        <- firmware identified the board. Wrong model name
           here means wrong firmware image was flashed.

I (xx) TPS546: Found TPS546D24A          (TPS-based boards)
I (xx) Power: VCORE set to 1150 mV
        <- the core regulator answered on I2C and the ASIC
           rail is up. If this block is missing or errors,
           nothing downstream can work.

I (xx) bm13xx: Found 1 chip(s)
        <- THE line. The count must equal your board's chip
           count: 1 for single-chip, 2 for GT, 4 for
           NerdQaxe, 6 for Hex, 8 for NerdOctaxe.

I (xx) wifi: connected, IP: 192.168.x.x
        <- network up. Association failures print reason
           codes here (dictionary below).

I (xx) stratum_task: Connected to pool ...
I (xx) stratum_task: mining.subscribe / authorize OK
I (xx) stratum_task: Set difficulty to ...
I (xx) create_jobs_task: New Work: ...
        <- the pool accepted the login and sent work.

I (xx) asic_result: Nonce found, diff xxx of yyy
        <- the ASIC is returning results. Within a minute
           or two you should see shares above pool
           difficulty being submitted and accepted.

Memorise the milestone order: reset reason → board config → regulator → chip count → WiFi → stratum → nonces. Whichever milestone fails first names the section of this guide you need.

Power problems: the number one cause of everything

If home miner faults had a leaderboard, power delivery would hold the top three spots. These boards run 3nm and 5nm silicon at high current from consumer power bricks over consumer connectors, and the margins are thin.

Know your power architecture

Single-chip Bitaxe (Max/Ultra/Supra/Gamma)
  Input:      5 V via barrel jack (5.5x2.1mm) or USB-C
  Current:    up to ~5 A on Gamma at stock, more overclocked
  Regulator:  TPS546D24A digital buck (older boards: DS4432U
              DAC + INA260 monitor) steps 5V down to ~1.1-1.3V
              ASIC core at very high current
  Window:     regulator turns on ~4.8 V, trips below ~4.5 V

12 V family (GT, Hex, NerdQaxe++, NerdOctaxe)
  Input:      12 V via XT30 connector or barrel
  Current:    NerdQaxe++ ~8+ A at full load; Octaxe more
  Risk:       connector heating; PSU sag under load

CRITICAL FACT: USB-C on current Bitaxe boards is for the
ESP32 and flashing ONLY. It cannot power the ASIC. A board
running on USB-C alone boots, shows the dashboard, and
hashes at exactly 0 GH/s while drawing ~2 W. This precisely
mimics a dead regulator and wastes hours every week across
the community.

Power Fault Detected: what actually happened

The TPS546 regulator polls four protections: overcurrent, overvoltage, undervoltage, overtemperature. When one trips, the regulator latches off and AxeOS shows the power fault banner. The ASIC loses its rail; the ESP32, fed separately, keeps the UI alive. Two facts govern the fix:

• The latch survives soft reboots. The fault state is held in the regulator’s own status register until input voltage is physically removed. Restarting from the web UI, calling the restart API, or pressing the ESP32 reset button does not clear it. This is documented behavior, not a bug, and it is also why one specific GitHub issue class exists: BM1370 boards stuck at 0 GH/s drawing 5 W where the restart endpoint fixes nothing but a power cycle fixes everything.
• The trip is a symptom; the cause is upstream. The regulator is protecting a chip worth more than the board around it. The overwhelming majority of recurring trips trace to input power, not to the regulator.

The fix sequence, in order:

1. COLD CYCLE. Unplug the power connector itself (not the
   wall switch). Count a full 10 seconds. Some boards need
   60 seconds for bulk capacitors to discharge and clear an
   ESP32 brownout-hold state. Reconnect. This alone resolves
   the majority of one-off power faults.

2. REMOVE USB-C. If anything is plugged into USB-C, unplug
   it and verify the real supply (barrel/XT30) is seated.
   Rule out the USB-C-only trap described above.

3. MEASURE UNDER LOAD. Multimeter on DC at the input
   connector WHILE THE MINER IS HASHING:
     5 V boards:  expect 4.9-5.3 V sustained.
                  Below 4.8 V = supply is the problem.
     12 V boards: expect 11.8-12.2 V sustained.
                  Below 11.4 V = supply is the problem.
   A no-load measurement proves nothing: cheap bricks show
   a perfect 5.0 V idle and collapse to 4.4 V under load.

4. ELIMINATE THE PATH. Plug the PSU straight into a wall
   outlet: no power strips, no extension cords, no
   daisy-chains. Low-grade strips add measurable drop.
   Wiggle the barrel jack: if the screen flickers, the
   jack or cable is worn.

5. UPGRADE THE SUPPLY. Minimum honest spec:
     single-chip 5 V boards:   quality 5 V / 5 A dedicated
     NerdQaxe++ class 12 V:    12 V / 10 A (120 W) minimum
   Phone chargers and universal adapters are the single
   most common root cause in this entire guide.

The XT30 warning

The 12 V family pushes 8 or more amps through an XT30. The connector is rated for it; the hand-soldered pigtails behind it often are not. Inspect for discolored pins, a connector warm to the touch, cold solder joints or loose crimps. A high-resistance joint at 8 A heats, oxidises, resists more, and heats further: this is the one failure mode in home mining that ends in melted plastic. If the connector has ever been hot enough to discolor, replace the cable, do not reuse it. NerdQaxe units that crash with a PSU error and a Guru Meditation code trace to exactly this rail sagging under load.

Brownout: the crash that is not a crash

The ESP32 has a hardware brownout detector. When the 3.3 V rail dips, it prints Brownout detector was triggered and resets. A miner that reboots every few minutes, especially when the ASIC ramps to full load, is almost never a firmware problem: it is the supply dipping at the moment of maximum draw. The fix is steps 3 to 5 above. Do not chase firmware for a brownout loop.

ASIC problems: the chip is not answering

The boot log line to watch is the chip count. The firmware enumerates the ASIC chain over UART and prints how many chips answered. Anything other than the full count for your board is this section.

Zero chips detected

The dashboard shows ASIC count 0 or the log shows an init failure. Causes, in observed frequency order:

1. Latched regulator or held brownout state. A chip with no core voltage cannot enumerate. Do the full 60-second cold discharge before anything else: unplug the main PSU, USB-C and every accessory, wait a full minute, repower. This alone closes a meaningful fraction of cases.
2. Wrong firmware image. Flashing the image for a different board, even once, can leave a wrong device config in non-volatile storage that persists across reflashes. If the boot log’s board model line does not match the physical board, do a full factory reset, then flash the correct image. A BM1366 image on a BM1370 board will never find the chip.
3. Mechanical event. The classic sequence: the unit was moved, dropped, shipped, or the heatsink was retightened, and it never hashed again. Under the ASIC is a BGA (ball grid array) of solder joints; flex cracks them. Uneven heatsink mounting pressure does the same. If the timeline fits, it is a bench repair (reflow), not a settings problem.
4. Factory escape. A brand-new unit that has never hashed once is disproportionately likely to be a cold solder joint from manufacturing. Do not spend a weekend on software: run the cold discharge and firmware check, then invoke the vendor warranty.

Partial chip count: the multi-chip signature

A Hex reporting 3 of 6, a NerdQaxe reporting 2 of 4, a GT reporting 1 of 2. Multi-chip boards enumerate the ASICs as a daisy-chain, so a single dead or disconnected chip breaks detection at that point in the chain: the count tells you roughly where the break is. A four-chip board showing 2 has a problem at chip 3. Causes are the same as above (power margin, cracked joint) plus one specific to multi-chip: one weak chip in the chain that drops out only at higher frequency. If the full count returns at stock clocks but chips vanish when overclocked, you have found the weakest die in your silicon lottery, and the ceiling of the whole board is its ceiling.

I2C errors: the sensor bus, not the miner

A confusing class: the miner hashes normally while Power, ASIC Temp and Input Voltage read as dashes, null or zero, and the log shows I2C transmit/receive errors or timeouts. The hashing path (UART to the ASIC) and the telemetry path (I2C to the regulator’s PMBus, the temperature sensor, the current monitor) are separate buses. One can fail while the other runs. Known trigger: a firmware regression band around AxeOS v2.13/v2.14 where the sensor read path fails silently on a subset of units. Also caused by any accessory sharing the I2C header: an added OLED or external sensor with a flaky connector can wedge the bus for the onboard sensors. Strip to stock, cold cycle, and if it is the firmware band, update forward or roll back one release.

The dangerous side effect: without temperature feedback the fan curve cannot run, so the fan pins at one speed. If telemetry is dead, treat thermal protection as dead too and do not leave the unit unattended until it is fixed.

Thermal problems: heat is a budget, not an event

The numbers that matter

ASIC core temp     target:  55-62 C sustained
                   worry:   above 65 C constant
                   trip:    ~75 C -> firmware Overheat Mode

VREG temp          runs 10-15 C hotter than the core under
                   load; on BM1370/BM1373 boards this is
                   often the limiting sensor, not the core

Overheat Mode      hashing stops, fan pins to 100%, UI stays
                   alive; auto-clears with hysteresis when
                   temp falls back to roughly 65 C

Diagnosing by pattern

Overheats immediately from cold — mounting problem. The heatsink is not making contact: missing or torn thermal pad, dried or absent paste, uneven screw torque, or a heatsink knocked loose in transport. A chip with no heatsink contact goes from ambient to trip in seconds. Remount, apply a rice-grain of quality paste, tighten screws in a cross pattern evenly.

Overheats after 10 to 30 minutes — capacity problem. Contact is fine but the system cannot reject heat as fast as it makes it. Causes stack: ambient above roughly 27 C, unit in a cabinet, drawer or sealed enclosure, intake or exhaust blocked, dust mat on the fins, or an overclock the cooling was never sized for. Give it 10 cm of clear air on both sides, clean the fins, and if it started after a frequency change, that change was too far.

Slow drift over weeks — maintenance problem. Same settings, temperature creeping one degree at a time: dust accumulation or thermal paste drying out. Paste on these boards is a consumable; replacing it every 6 to 12 months is normal.

Overheat after a firmware update — curve problem. Fan and heat curves change between releases; a documented example around v2.11 shifted default fan behavior enough that units ran several degrees warmer and slightly slower at stock settings. Check the release notes, set the fan speed manually a step higher, or adjust the target temperature if your firmware exposes PID control.

The fan itself

A fan reporting 0 RPM at any temperature is unplugged, jammed by a cable, or dead. A fan screaming at 100% constantly means either a genuinely hot chip (see above) or dead temperature telemetry driving the curve blind (see the I2C section). Replacement 40mm and 60mm fans are cheap; premium quiet ones (the usual community pick is a Noctua) drop noise below 40 dB and are the single best-value hardware upgrade on any of these units.

Network problems: the ESP32’s WiFi worldview

The radio in every one of these machines speaks 2.4 GHz only. Not 5 GHz, not 6 GHz, no exceptions, no firmware fix. An enormous share of setup failures reduce to that sentence colliding with how modern routers behave.

The mesh router problem

Modern mesh systems broadcast one combined SSID and steer clients between bands. The ESP32 cannot join the 5 GHz side, and band steering can prevent it from settling on 2.4 GHz. The reliable fixes, most routers support at least one:

Option A  Create a dedicated 2.4 GHz-only SSID (best)
Option B  Use the router's "IoT network" feature - several
          vendors added this exactly for devices like these
Option C  Disable band steering / "smart connect" so the
          bands appear as separate SSIDs

Then verify on the 2.4 GHz SSID:
  Security       WPA2-Personal, AES only (not TKIP, and
                 WPA3-only networks will fail)
  Channel        fixed 1, 6 or 11 in congested areas,
                 not Auto
  Channel width  20 MHz
  AP isolation   OFF  <- with it on, WiFi connects but the
                 dashboard is unreachable from your LAN,
                 which looks exactly like a dead device
  MAC filtering  off, or add the miner's MAC to the list

Reading WiFi failures in the serial log

The serial console prints a disconnect reason on every failed association, and the reason names the fix:

AUTH_EXPIRE / auth failed      wrong password (PSK). Retype
                               it; watch for smart quotes if
                               pasted from a phone.
NO_AP_FOUND                    SSID not visible on 2.4 GHz:
                               band steering, hidden SSID,
                               out of range, or 5 GHz-only.
beacon timeout                 signal too weak or channel
                               congestion; move the unit or
                               fix the channel.
ASSOC_TOOMANY                  router's client limit reached.
Brownout detector triggered    not WiFi at all - the radio's
                               power spike at association is
                               sagging a weak supply. Fix
                               power, not the network.

That last one deserves emphasis: WiFi transmit is the biggest instantaneous load spike the ESP32 makes. A marginal supply that survives idle dies at association, so a unit that “crashes when connecting to WiFi” is usually a power problem wearing a network costume.

Reachability without WiFi failure

Two router-security features deserve special mention because they block miners by design. ASUS AiProtection and the equivalent on some TP-Link models classify stratum traffic as suspicious and silently drop it: the miner joins WiFi perfectly and then cannot reach any pool. If a unit connects to WiFi but every pool connection fails, and the same pool works from a phone hotspot, disable the router’s protection feature or whitelist the miner before touching anything else.

And one browser quirk that generates endless false alarms: AxeOS serves plain HTTP on port 80. Modern browsers silently upgrade bare addresses to HTTPS, which fails, and the miner looks dead. Type the prefix explicitly: http:// before the IP, every time. If it still fails, try another browser and disable ad-block extensions for local addresses.

If the miner has an IP but you cannot open the dashboard: AP isolation (above), a client-list quirk in the router, or mDNS. The device advertises itself as a .local hostname; when several units use the same hostname, modern firmware appends a MAC-derived suffix automatically, but stale mDNS caches on your computer can still point at the wrong unit. When in doubt, use the raw IP from the router’s DHCP table, and give each unit a distinct hostname.

Stratum and pool problems: the last mile

The device boots, hashes, and the pool is where truth is decided. This section is where the miner-side view and the pool-side view have to be read together.

Connection refused or unreachable

Check in this order:
1. URL exact:   stratum+tcp://host:port  - no https://, no
                trailing slash, port present and correct
2. DNS:         can another device on the same LAN resolve
                the host? Some ISP routers and DNS filters
                (or Pi-hole style blockers) eat mining
                domains silently.
3. Port:        some networks block uncommon outbound ports.
                Test from a phone hotspot: if it connects
                there, the home network is filtering.
4. Pool region: try the pool's other regional endpoint -
                you may be seeing a single-region outage.

Authorize fails

The pool refused the login. On a solo pool the username is your wallet address plus worker name, and the address is the whole identity: there is no account to mistype. Causes: an address with a typo (one character is enough), an address from the wrong chain (see below), a worker name containing spaces or special characters, or a password field the pool expects to be non-empty (use x).

The wrong-chain address: the silent killer

The single most damaging configuration error in multi-chain SHA-256 mining, and it can fail in two different ways:

• Loud failure: the pool validates address format per chain and rejects the authorize or every share. Annoying but safe: you notice within minutes.
• Silent failure: an address that is format-valid on more than one chain, or a pool that does not deep-validate, accepts your shares all day, and then the payout cannot reach you. On a non-custodial solo pool, block rewards are paid coinbase-direct to the address string you configured. There is no support ticket that reverses a coinbase paid to an address you cannot spend from.

The rule: the address must be native to the chain you are pointing at, generated by a wallet for that chain, and test-verified. If you rotate one physical miner between chains, keep a written table of chain-to-address and re-check the username field every single time you change the stratum URL. This is worth more than every other tip in this section combined.

Shares rejected: reading the reject reasons

Rejects are not one problem; the reason string in the log tells you which of four problems you have.

"job not found" / stale       You submitted work for a job
  in small bursts right       the pool already replaced -
  after new blocks            normal at block changes. Under
                              ~1-2% total: ignore. Sustained
                              higher: network latency or
                              WiFi packet loss - check RSSI,
                              try the nearer pool region.

"above target" /              The share does not meet the
"low difficulty share"        difficulty the pool assigned.
                              Persistent cases: a mismatch
                              after a difficulty change, or
                              hardware errors corrupting the
                              result. Check the HW error %.

"duplicate"                   Same nonce submitted twice.
                              Occasional: harmless retry
                              artifact. A stream of them:
                              known failure state where the
                              ASIC loops on one nonce - the
                              chip has wedged. Power cycle;
                              if it recurs at your current
                              clocks, back the overclock off.

everything rejected           Configuration, not luck:
                              wrong-chain address, malformed
                              worker name, or wrong port
                              (e.g. a high-diff port meant
                              for big ASICs).

Hardware error percentage: the honest number

The dashboard hashrate is a claim; the hardware error rate is a confession. It counts results the ASIC returned that fail verification. Under 2 percent is healthy. Rising error rate with rising temperature means thermals; rising error rate at constant temperature after a settings change means the frequency/voltage point is beyond this chip’s silicon. A chip at 5 percent errors can show a proud hashrate while your effective hashrate quietly drops below what a lower clock would deliver. When tuning, optimise accepted-shares-per-hour, never the dashboard number. Full method in the tuning section of the BM1373 reference, and background on what share difficulty means in the best share explainer.

”The miner says it is hashing but the pool shows nothing”

The most posted symptom in every community, so here is the complete resolution path:

1. POOL SIDE, time since last accepted share:
   over 10 minutes = the connection is dead NOW, whatever
   the miner UI says. Dashboard averages decay over ~an
   hour and hide fresh disconnects. "Hashrate above zero"
   is NOT an online test; "recent last-share" is.

2. MINER SIDE, live log:
   Are shares being SUBMITTED? If the ASIC finds nonces
   but nothing submits, the stratum socket is wedged -
   restart the miner.
   Are submissions ERRORING? Read the reject reason table.

3. IDENTITY: is the pool dashboard you are staring at
   filtered on the same wallet address AND coin the miner
   is configured for? A surprising number of these are a
   BTC dashboard open while the miner points at BCH, or a
   stats page for yesterday's test address.

4. FALLBACK: is a fallback pool configured, and did the
   miner silently fail over to it? Your hashrate may be
   arriving at the OTHER pool. Check the fallback's stats.

Configure the fallback, always

Every AxeOS-family device supports a fallback pool. A miner with no fallback that loses its stratum socket at 2 a.m. does nothing until you notice, and the decaying dashboard average makes sure you notice late. Set the fallback to a second region of your pool so a single-region issue never idles the machine. Region hosts and ports for every chain are on the connection page.

Firmware problems: flashing, bricking, recovering

The two-file OTA and the half-brick

AxeOS updates ship as two artifacts: the firmware binary and the web interface image (www.bin). A documented failure mode is the OTA stalling during the www.bin stage, leaving firmware and UI out of sync: the device boots and mines but the dashboard is blank or broken. This is not a brick. Browse directly to the recovery URL:

http://<miner-ip>/recovery

and re-upload the web image. If the device does not boot at all after a failed update, the USB web flasher (Chrome or Edge, USB-C data cable) rewrites the full factory image and recovers essentially every soft-brick. Three rules make flashing boring instead of terrifying:

• Match the image to the board exactly, down to the revision. The revision number is printed on the PCB itself and shown in the AxeOS System section: a Supra 401 needs the 401 image, not the 402. Know the two file types on the releases page: the full esp-miner-factory-REV-vX.X.X.bin (bootloader + partitions + UI + firmware, for USB flashing and full recovery) and the smaller esp-miner.bin (firmware-only, for OTA through the dashboard). Using one where the other belongs is a classic half-brick recipe. Gamma image on a Gamma, Ultra on an Ultra. A wrong image can persist a wrong device config in NVS that survives ordinary reflashes; the cure is factory reset plus correct image.
• Never flash over WiFi on a marginal connection or marginal power. The stall-during-www.bin failure correlates with exactly those two.
• Know your rollback target. Regressions happen: a telemetry-loss band around v2.13/v2.14, a fan-curve change around v2.11 that ran units hotter, an update path around v2.4.3 that froze on some hardware revisions until users downgraded. Before updating, note your current version; if the new one misbehaves, the previous release is one web-flash away on the project’s releases page.

Crash loops: reading a Guru Meditation

A Guru Meditation Error is the ESP32’s kernel panic. The word in parentheses is the clue:

Guru Meditation Error: Core X panic'ed (REASON)

LoadProhibited /       firmware bug touching invalid memory -
StoreProhibited        note your version, check the issue
                       tracker, roll back one release
IllegalInstruction     corrupted flash or overwritten stack -
                       full re-flash via USB
Cache error /          usually follows PSRAM problems (below)
DoubleException
Interrupt wdt timeout  a task hung - often network-related;
                       check for a known issue on your version

One panic ever: ignore it. A loop: identify whether it is the same reason each time (firmware or hardware fault: act on the table) or interleaved with brownout messages (it is power: stop reading panics and go fix the supply).

PSRAM failures: the Nerd-family special

NerdQaxe, NerdOctaxe and other boards built on the ESP32-S3-WROOM-1 module use external PSRAM. A boot banner showing a PSRAM ID read error or init failure, followed by a StoreProhibited panic as soon as the firmware touches external RAM, has five known roots: counterfeit modules with no PSRAM die, a firmware built with the wrong PSRAM mode (octal vs quad), cold solder under the module, brownout during the init window, or an aging die. The practical triage: rule out power first (as always), flash the exact vendor-built image for your board (which encodes the right PSRAM mode), and if the error persists on clean power with correct firmware, the module itself is the fault, which is a warranty or bench case.

Overclocking gone wrong: recovery and prevention

The failure signature: raised frequency or voltage, and now the unit crashes, flatlines after minutes-to-hours, throttles, or one chip on a multi-chip board vanishes. The physics is unforgiving in one specific way: instability from a too-high clock often takes time to appear. A setting that survives a 10-minute test can fail at minute 40 when the board reaches full thermal soak, which is why every stability claim shorter than 24 hours is provisional.

RECOVERY (if the unit still boots):
  Web UI -> set frequency and voltage back to stock ->
  save -> cold power cycle (clear any latched fault).

RECOVERY (if it crash-loops before you can reach the UI):
  USB web-flash the factory image - this restores stock
  operating points. Then factory-reset to clear NVS.

PREVENTION (the whole method in five lines):
  - one 25 MHz step at a time, voltage untouched
  - 30 minutes minimum per step, watching HW error %
  - error above 2% = back off one step; that is the wall
  - only then raise voltage in 25 mV steps if you accept
    the extra heat; stay inside the 1100-1300 mV window
  - 24 hours at final settings before you call it stable

And one honest note: undervolting for efficiency fails identically to overclocking for speed, just in the other direction: too little voltage for the clock produces the same errors and hangs. Silicon lottery applies to both edges.

Diagnosing over the API: the power user’s shortcut

Every AxeOS-family miner exposes a REST API on port 80, and it changes what troubleshooting looks like: no screen needed, no clicking through dashboards, and it scales from one unit to a fleet. The full specification lives in the openapi.yaml file in the ESP-Miner repository; these are the calls that matter for diagnosis.

The five diagnostic calls

# Everything at once: hashrate averages, temps, voltage,
# power, fan RPM, shares, best difficulty, WiFi RSSI,
# uptime, firmware version, free heap
curl http://MINER-IP/api/system/info

# ASIC-specific state: chip model, count, frequency, voltage
curl http://MINER-IP/api/system/asic

# Time-series history the dashboard charts are drawn from
curl "http://MINER-IP/api/system/statistics?columns=hashrate,asicTemp,vrTemp,power"

# THE UNDERRATED ONE: download the device logs remotely.
# No serial cable, no PuTTY - pull the log over the network
# and grep it for the red lines from the dictionary below.
curl http://MINER-IP/api/system/logs

# Which unit is which? Makes the device identify itself
# (screen/LED) - invaluable in a rack of identical boxes
curl -X POST http://MINER-IP/api/system/identify

That logs endpoint deserves a sentence of its own: most of the serial-console section of this guide can be performed from your couch with that one call, as long as the device boots far enough to serve HTTP. The serial cable remains necessary only for boot-time and crash-loop failures.

Reading /api/system/info like a mechanic

Six fields in that JSON answer most tickets before they are filed:

FIELD (typical name)      WHAT IT TELLS YOU
hashRate / hashrate_10m   the claim - compare against pool
temp / asicTemp           the 55-62 C budget from the
                          thermal section
vrTemp                    the regulator side - often the
                          real limiter on BM1370/BM1373
voltage                   input rail AS THE BOARD SEES IT:
                          a software multimeter. Sagging
                          under 4.9 V at load = PSU, proven
                          without opening the case
power                     watts drawn - 2 W on a "hashing"
                          unit = the USB-C-only trap
sharesAccepted /          the ground truth pair; rejected
sharesRejected            climbing = reject-reasons table
wifiRSSI                  stronger than -70 dBm is healthy;
                          weaker explains stale shares
freeHeap                  slowly shrinking across days =
                          the memory-leak class of firmware
                          bug; note version, check tracker

Fleet health in one loop

With more than one unit, stop checking dashboards. This loop prints a one-line health summary per miner and flags the dead ones:

#!/bin/bash
# fleet-check.sh - adjust IPs to your swarm
for IP in 192.168.1.101 192.168.1.102 192.168.1.103; do
  J=$(curl -s -m 5 "http://$IP/api/system/info")
  if [ -z "$J" ]; then
    echo "$IP  UNREACHABLE"
    continue
  fi
  echo "$J" | python3 -c "
import sys, json
d = json.load(sys.stdin)
print('$IP  %-10s %6.1f GH/s  %4.1fC  %4.1fW  acc:%s rej:%s' % (
  d.get('hostname','?'),
  d.get('hashRate',0),
  d.get('temp',0),
  d.get('power',0),
  d.get('sharesAccepted','?'),
  d.get('sharesRejected','?')))"
done

Run it from cron every five minutes, pipe it to a notification of your choice, and a 2 a.m. failure becomes a 2:05 a.m. alert instead of a morning surprise. Field names vary slightly across firmware versions; dump the raw JSON once and adjust.

The API can also fix things

# Restart without touching the hardware
curl -X POST http://MINER-IP/api/system/restart
#   (remember: this does NOT clear a latched TPS546
#    power fault - that still needs the physical unplug)

# Return an overclock experiment to sane values remotely
curl -X PATCH http://MINER-IP/api/system \
  -H "Content-Type: application/json" \
  -d '{"frequency": 525, "coreVoltage": 1150}'

# Fix a fat-fingered pool config without the web UI
curl -X PATCH http://MINER-IP/api/system \
  -H "Content-Type: application/json" \
  -d '{"stratumUser": "YOUR_WALLET.worker1"}'

One honest caveat: the API has no authentication. Anyone on your LAN can read and reconfigure your miners. On a home network that is usually acceptable; on a shared or guest-accessible network, put the miners on their own VLAN or IoT segment: which, conveniently, is the same fix the WiFi section already recommended.

Per-model quirks: know your board’s personality

Beyond the universal failure modes, each board family has signature behaviors worth knowing before you debug one.

The master symptom table

The red-lines dictionary

The error strings you will actually see, in one place, written verbatim so that Ctrl+F finds them. Find your line, get your direction.

LINE IN LOG                        MEANING -> WHERE TO GO
---------------------------------------------------------------
Brownout detector was triggered    supply dipped -> Power
rst:0x.. (BROWNOUT_RESET)          same, shown at reset banner
Power Fault Detected               TPS546 latched -> Power
TPS546 status / regulator fault    same family -> Power
VCORE init failed /                firmware cannot program the
  device ID mismatch               regulator: wrong image or
                                   I2C issue -> ASIC + Firmware
i2c_master_transmit_receive err /  sensor bus down -> ASIC
  ESP_ERR_TIMEOUT near boot          section, I2C subsection
Found 0 chip(s) / ASIC init fail   chip not answering -> ASIC
Chip count N of M                  chain break at N+1 -> ASIC
Device has overheated /            75 C trip -> Thermal
  Overheat Mode
VREG temp over limit               regulator side hot -> Thermal
wifi: NO_AP_FOUND                  2.4 GHz visibility -> Network
wifi: AUTH_EXPIRE / auth fail      wrong password -> Network
wifi: beacon timeout               weak signal/channel -> Network
wifi_disconnect reason: N          look N up; fix per reason
Stratum connection failed /        cannot reach pool -> Stratum
  connect errno
authorize failed                   login refused -> Stratum,
                                   address & worker checks
job not found (on submit)          stale share -> Stratum
above target / low diff share      diff mismatch or HW errors
duplicate share                    wedged nonce -> power cycle,
                                   then reduce clocks
Guru Meditation Error: (REASON)    panic -> Firmware, read the
                                   reason word
esp_psram: PSRAM ID read error /   PSRAM init -> Firmware,
  Failed to init external RAM        Nerd-family subsection
E (xx) esp_image: checksum failed  corrupt flash -> USB re-flash
[www.bin / blank UI after update]  recovery URL -> Firmware

Preventive maintenance: the 15-minute monthly ritual

Nearly everything above is cheaper to prevent than to debug.

MONTHLY
  [ ] Dust: fins and fan blades (compressed air, fan held)
  [ ] Pool-side check: accepted vs rejected trend, and
      HW error % still under 2
  [ ] Glance at temps: any drift vs last month?
  [ ] Physically touch the power connector: warm is a
      warning, hot is a stop

EVERY 6-12 MONTHS
  [ ] Replace thermal paste (it is a consumable)
  [ ] Inspect XT30/barrel pins for discoloration
  [ ] Re-verify PSU under load with a multimeter

EVERY FIRMWARE UPDATE
  [ ] Read the release notes BEFORE flashing
  [ ] Note current version (your rollback target)
  [ ] Flash on stable power, ideally wired-adjacent WiFi
  [ ] Re-check pool config after: updates can reset fields

ALWAYS
  [ ] Fallback pool configured (second region)
  [ ] Distinct worker names across the fleet
  [ ] Written table: chain -> wallet address
  [ ] Stock settings written down before any tuning

When it is truly hardware: what is repairable

You have cold-cycled, factory-reset, reflashed the correct image on verified-good power, and the fault persists. That is the definition of a hardware problem. The realistic repair map:

• Bench-repairable (hot air, microscope, steady hands or a professional): failed TPS546 or buck-stage components, cracked ceramic capacitors, cold solder joints under the ASIC or the ESP32 module (reflow), worn power connectors, dead fans. These are routine for any ASIC repair bench.
• Sometimes recoverable: a board with a dead short on the 5 V rail (near-zero ohms to ground, power off) — do not keep applying power; the short must be found and removed first.
• Usually terminal: an ASIC that ran without heatsink contact beyond a few seconds, thermal-runaway aftermath, or a chip fed the wrong core voltage during an improvised VRM repair. On a single-chip board the chip is most of the board’s value: past a certain point, replacement beats repair.

Community-level help lives on the OSMU Discord and the ESP-Miner GitHub issue tracker: before filing, search the tracker first, because a striking share of “my unit is broken” reports are known issues with a fix already merged in the next release. When filing, a complete report gets answered in hours where a vague one dies in silence. Copy this template:

BOARD:      (exact model + revision, e.g. Gamma 602)
FIRMWARE:   (AxeOS version, from dashboard or /api/system/info)
PSU:        (voltage, amps, brand - and: measured under load?)
POOL:       (URL + port + coin)
SYMPTOM:    (one sentence: what happens, since when)
TRIGGER:    (what changed right before: update? move? OC?
             heatsink remount? nothing?)
TRIED:      (cold cycle 60s? factory reset? reflash? stock
             clocks? self-test result?)
LOG:        (paste the boot log from serial 115200 or from
             curl http://IP/api/system/logs - at minimum
             the first E-line and ten lines around it)

That template is not bureaucracy: it is the exact information a repair bench collects first, in the order they collect it.

PRO: the bench section — schematics, test points, and the meter

This section assumes you can read a schematic and probe a powered board without shorting adjacent pins. If that sentence gave you pause, stop here: everything above this line is solvable without opening the case, and a slipped probe on a live 3nm board turns one problem into two. For everyone else, this is where open hardware pays off.

Why these boards are different from every other miner

Bitaxe hardware is licensed CERN-OHL-S and designed in KiCad, and every schematic, PCB layout and bill of materials is public. That means you are never guessing what a component is or where a rail runs: you can open the exact schematic for your exact board revision, find the net, and measure it. No Antminer owner has ever had that privilege. Each hardware repository also carries a section most people never open: the HW issues page with known bugs, reworks and errata per revision. Before diagnosing any board-level fault, check whether your revision has a documented erratum: a striking share of “mystery” hardware faults are already written down there with the rework that fixes them.

The multimeter method: three rails tell the whole story

Power-path faults localise with three DC measurements, taken in order. Probe on ground first, respect the sequence, and measure under load where indicated.

RAIL 1 - INPUT (5 V or 12 V depending on family)
  Where:   input connector / input pads (see schematic)
  Expect:  5 V family:  4.9 - 5.3 V  WHILE HASHING
           12 V family: 11.8 - 12.2 V WHILE HASHING
  Reads low under load only -> PSU or cable (most cases)
  Reads 0 with a good PSU  -> input protection blown or
                              a short downstream: check
                              resistance to ground POWER
                              OFF - near-zero ohms = short,
                              stop applying power, find it

RAIL 2 - 3.3 V (the ESP32's supply)
  Where:   3.3 V net per schematic (ESP32 module supply)
  Expect:  3.2 - 3.4 V steady
  Missing with input OK -> the small 3.3 V regulator or
  its passives: explains "completely dead, no USB
  enumeration" with a proven-good brick

RAIL 3 - VCORE (the ASIC's supply)
  Where:   output of the TPS546 buck stage / ASIC core net
  Expect:  roughly 1.0 - 1.3 V, matching the value set
           in AxeOS
  Missing with input OK and 3.3 V OK -> the buck stage:
  latched fault (cold-cycle first, always), or failed
  TPS546 / inductor / surrounding passives
  Present but wrong value -> regulator programming or
  PMBus comms: cross-check what AxeOS thinks it set

CONFIRMATION MEASUREMENTS
  Continuity input-connector -> regulator input: finds
  broken traces and cracked jack solder joints
  TPS546 die temp via dashboard vs finger-hover: a
  regulator too hot to approach at idle is failing

Those three rails partition every power fault: input bad = upstream of the board; input good, 3.3 V bad = the small regulator; both good, VCORE bad = the buck stage; all three good = the fault is not power, go back to the ASIC section. Ten minutes with a 20-dollar meter replaces hours of speculation.

What a repair bench can and cannot do

ROUTINE (hot air + microscope + steady hands)
  - TPS546 / buck-stage component replacement
  - cracked ceramic capacitors (visual: hairline across
    the body; electrical: short or open)
  - BGA reflow under ASIC or ESP32 module (the post-drop
    and post-remount fault class)
  - connector replacement (worn barrel, cooked XT30)

POSSIBLE WITH PATIENCE
  - hunting a 5 V rail short (thermal camera or the
    isopropyl-evaporation trick over suspect areas)
  - ESP32-S3 module swap (needs reflash after)

NOT WORTH IT / TERMINAL
  - ASIC replacement on single-chip boards: the chip is
    most of the board value and donor chips are harvested
    anyway - a new board wins on cost and certainty
  - anything after thermal runaway or wrong-polarity input
    across the whole rail

Reading the schematic like a repair tech

Three habits that make the open schematics actually useful. First, find the power tree page and trace input to VCORE once on paper before probing anything: you now know every component that can kill the rail. Second, note the reference designators (R12, C34, U3) of the buck stage: forum posts and errata refer to parts by designator, and matching them to your board takes seconds with the layout file open. Third, compare revisions when a fault is revision-specific: the changelog between, say, a Gamma 600 and 601 tells you exactly what the designers fixed, which is often exactly what fails on the older one.

The open-source resource library

Every primary source in one table. Bookmark this section: half the value of open hardware is knowing where the originals live, and every link below is the official upstream, not a mirror.

Key takeaways

• Six domains cover nearly every failure: power, ASIC, thermal, network, stratum, firmware. The 60-second triage tells you which one you are in before you touch anything.
• Power is the number one cause and the number one impostor: it masquerades as WiFi crashes, firmware panics, wedged chips and dead boards. Measure the input under load before believing any other theory.
• A latched regulator fault survives every soft reboot. Physical unplugging for 10 to 60 seconds is a real diagnostic step, not superstition.
• USB-C powers the ESP32, never the ASIC. A board on USB-C alone perfectly imitates a dead miner at 0 GH/s.
• Learn the serial console at 115200 baud. The first E-line in a boot log names your problem faster than any forum thread.
• The built-in self-test names the failing subsystem in 30 seconds, and the REST API pulls the logs, the telemetry and even the fix over the network: use both before reaching for a serial cable.
• Never connect a 12 V supply to a 5 V board. The plugs are interchangeable; the boards are not.
• The ESP32 speaks 2.4 GHz only; band steering and AP isolation are the two router features that break most setups.
• Pool-side truth beats miner-side optimism: time since last accepted share is the only honest online test, and 10 minutes is the threshold.
• The wallet address must be native to the chain being mined. On a non-custodial pool this is the one error with no recovery path.
• Hardware error percentage is the honest performance number; the dashboard hashrate is a claim. Tune to accepted shares, and require 24 hours before calling any setting stable.
• A hot power connector is the one symptom that means stop now, not debug later.

Compiled from the ESP-Miner issue tracker and release notes, ESP-IDF fatal-error documentation, community repair-bench documentation, and the recurring failure patterns reported across the Bitaxe, NerdAxe and NerdQaxe communities, as of 20 July 2026. Firmware behavior described here (fault latching, overheat thresholds, recovery URLs, known regression bands) reflects AxeOS/ESP-Miner releases current at publication; check the release notes for your version. This guide is maintained as a living reference: if you hit a failure mode not covered here, tell us through the contact page and we will add it.