Bitaxe Gamma 601 / 602 Repair Service

Bitaxe Gamma 601 repair fixes the fault that dominates this model — one problem wearing two faces: AxeOS reporting Power Fault Detected. Check your Power Supply., or a board that boots, joins its pool and holds 0 GH/s while drawing roughly 5 W with a cold chip. Both are repairable at component level.

A Bitaxe Gamma 601 on the bench usually arrives still lit up. The fan spins, AxeOS answers on the network, the pool shows the worker connected — and the chip stays cold at 0 GH/s, or a red power-fault banner sits across the dashboard. We take these in as complete devices, isolate the 5 V input path and the single TPS546D24A core rail at component level, and hand the unit back only after it hashes on its own diagnostic surface. Board revisions 601 and 602 are serviced on this page; they share the same ASIC and the same stock tuning.

Technical Diagnostics and Common Issues with Bitaxe Gamma 601 / 602

Quick Symptom Checklist

• AxeOS shows Power Fault Detected. Check your Power Supply. across the dashboard and the telemetry tiles read Not available - Power fault.
• The device boots, connects to Wi-Fi and the pool, but holds 0 GH/s while pulling about 5 W from the wall and the heatsink stays cold.
• The screen shows DEVICE OVERHEAT! followed by Power, frequency and fan configurations have been reset. Go to AxeOS to reconfigure device. — and afterwards the dashboard reads Bitaxe frequency is set low - See settings.
• Self-test stops with SELF-TEST FAIL! and a short code such as VCORE:PWR FAULT, POWER:FAIL, VCORE:FAIL or HASHRATE:FAIL.
• The screen header ASIC STATUS: is followed by ASIC chain detection failed; on the serial console this appears as ASIC initialization failed - chip chain detection failed or Mining start failed - ASIC not detected.
• The dashboard flags Danger: Low Voltage or Danger: High Temperature, the OLED is blank while the fan still spins, or the hashrate field reads -- h/s.

Try This Before You Ship It In

Most of what reaches us is genuinely hardware, but a real share of Gamma faults are a supply, a cable, a fan or a stale setting. Work through this first — if none of it moves the needle, the fault is on the board and that is what we fix.

1. Pull the power for 30 seconds. Not the Restart button in AxeOS — unplug it. The 0 GH/s-at-5-W state does not always clear on a warm restart, and the project's own issue tracker is split on whether a soft restart ever recovers it. A full cold cycle is the only version that is not in dispute.
2. Check the supply and the cable before anything else. This board is 5 V DC only through a 5.5 × 2.1 mm centre-positive barrel jack and needs more than 4 A (20 W). A bench or ATX supply will trip the power fault even at a correct-looking 5.1 V. Thin or long cable runs drop enough to do the same.
3. Confirm the fan is the right fan, fitted the right way. It must be a 5 V 4-pin PWM unit — a 3-pin loses PWM control entirely, and a fan that is not a 5 V part can load the rail hard enough to throw a power fault on its own. The airflow must blow into the heatsink, not away from it.
4. Put frequency and core voltage back to stock: 525 MHz and 1150 mV. Settings survive in NVS, so a unit that was tuned on better cooling will misbehave the moment it goes back on the stock brick and heatsink. If the device is sitting in overheat, use the disable overheat mode control at the bottom of the AxeOS settings tab — without it the board stays derated at 400 MHz indefinitely.
5. Reflash to stock with a USB-A to USB-C cable. C-to-C does not enumerate on revisions before 602. Use the official web flasher and select the board number — 601 or 602 — explicitly; skip that step and the flasher reports success while the device fails to come up. If the dashboard is dead but the device answers, http://<device-ip>/recovery will still load.
6. Rule out the network before blaming the board. This device is 2.4 GHz only. Combined 2.4/5 GHz SSIDs and router IoT-protection features break the join, and a local node that withholds work will show up as a near-100 percent error rate on perfectly healthy hardware.
7. Scan it and read the telemetry. Run the built-in self-test, then pull http://<device-ip>/api/system/info. That JSON exposes per-domain hashrate, error rate, voltages and temperatures — enough to tell a dead chip from a bad supply without opening anything. NerdScan reads the same data across every AxeOS miner on your network at once.

If you send it in, that JSON and a serial boot log are the two most useful things you can attach — we have diagnosed units down to a single failed hash domain from those alone.

Model-Specific Patterns We See on Bitaxe Gamma 601 / 602

• Power fault on the single 5 V rail. This is the most common thing we see. On the serial console it decodes as The output voltage is NOT within the regulation window. PGOOD pin is asserted. or, when the regulator has stopped answering entirely, Cannot find TPS546 regulator - Device ID mismatch with a device ID reading back as Device ID: ff ff ff ff ff ff. The Gamma has less margin here than its siblings: one 5 V input, no fuse, no input protection, roughly 19 to 22 W of draw. Multi-chip 12 V boards simply do not fail this way as often.
• 0 GH/s at about 5 W with a cold chip. The board comes up, the network is fine, the pool is issuing work, and nothing hashes. Power draw sits near a quarter of normal and the heatsink never warms. This one is open on the project's own tracker with maintainers assigned, and the reports there disagree about whether a soft restart ever clears it. We do not rely on one either way: the unit gets a full cold cycle and a clean flash before any conclusion is drawn about the silicon.
• The regulator runs hotter than the ASIC, and the recovery looks like a failure. On this board the TPS546D24A routinely reads warmer than the chip it feeds. Once the ASIC passes 75 °C or the regulator passes 105 °C the firmware latches overheat, wipes the tuning and steps the device down by 100 mV and 100 MHz at a time — floor 1000 mV and 400 MHz. Owners read the resulting slow, quiet, stable device as broken. It is not broken; it is protecting itself, and the real work is finding why it got hot.
• Heatsink mount failure that kills the chip weeks later. The heatsink sits on plastic push-pins with the die in the middle of the board, which makes it a single-point fulcrum. Pins snap or pull through — usually on the underside, where nobody sees it — coplanarity goes, and the ASIC dies some time afterwards with no obvious connection to the moment it was disturbed. Worth knowing before you order a chip: reflowing a heat-killed BM1370 does not bring it back. Only replacement does.

Hardware Notes

Diagnostics Focus

• The 5 V input and the single core rail, in that order. Because everything hangs off one 5 V input with no fuse and no input protection, we characterise the supply, the barrel jack and the TPS546D24A before we form any opinion about the ASIC. The regulator's own PMBus fault words tell us whether we are looking at a regulation-window fault, an over-current event, a thermal trip or a dead I2C bus — four very different repairs that all surface to the owner as the same red banner.
• Per-domain hashrate inside the single chip. The four hash domains inside the BM1370 are individually visible in the device's own telemetry. A board reporting close to 100 percent error rate with output pinned near a quarter of normal is a domain-level silicon fault, not a tuning problem — and newer firmware surfaces faults that older builds averaged away, so a device that appears to have broken right after an update frequently had the defect all along.

Diagnostic Decision Tree

Our Professional Repair Process

Gotchas

• Tuning survives in NVS, and it will fail the board on stock hardware. A device that was overclocked on a bigger cooler and a stronger supply keeps those settings when it is unplugged. Put it back on the stock brick and stock heatsink and it reads as a supply failure — and after a reflash it will stop in self-test on VCORE:PWR FAULT. More flashing will not clear that state: recovery is a specific power-and-button sequence performed on the board itself, after which the Wi-Fi has to be set up again. We do that at intake.
• A burnt regulator is usually the symptom, not the fault. When the BM1370 fails short it can take a nearby regulator down with it. That is why a board can come back from a cheap regulator swap and still refuse to hash — the part that was replaced was never the cause. On a single-ASIC board there is no second chip to compare against, so we establish which of the two actually failed before quoting anything, and you are not paying twice for one fault.

Typical Service Scenario

• Ran fine for months, then a red banner. The unit sat on a shelf, the room warmed up over summer, and one day AxeOS came up with a power fault that will not clear across two different supplies and a reflash. Usually the regulator or the input path, occasionally the fan that was swapped six months earlier.
• Something got moved. The device was picked up, knocked, or carried to a different room. It kept working for a while and then went to 0 GH/s or -- h/s. When we open it, a heatsink push-pin has failed on the underside and the die has been running without proper contact since the day it was disturbed.
• Maintenance made it worse. Owner repasted it or fitted a quieter fan, and it has not hashed since. This one is common enough that we ask about recent maintenance at intake as a matter of routine — the fix is often a fan spec or an orientation, and occasionally it is damage done during disassembly.

What Happens After Intake

Intake and photographs of the received condition, including the exact board revision read from the boot log rather than the silkscreen. Incoming inspection of the barrel jack, the 5 V input path, the regulator area, the fan header, the display pins and the heatsink mount — with particular attention to the underside of the board, where a failed push-pin hides.

Diagnostics next: we capture a full serial boot log and the device's own JSON telemetry, decode the regulator's PMBus fault word, measure the core rail against its 1150 mV target under load, and compare per-domain hashrate inside the chip. That sequence separates a firmware or configuration problem from real silicon before anything is desoldered.

Then component-level repair on whatever the diagnostics actually implicated — input path, regulator, low-dropout rails, fan control, display circuit, or the ASIC itself where the die is confirmed dead and replacement makes economic sense. Cleaning and thermal interface replacement follow, with the heatsink remounted properly rather than pressed back onto tired plastic.

Validation is done through the device's own diagnostic surface, because this is a self-contained miner rather than a loose board: the built-in self-test must pass, AxeOS must report sane voltages and temperatures, the JSON telemetry must show all four hash domains contributing, and the unit then runs a minimum two-hour burn-in under real mining load. We use two hours rather than one here on purpose — there is no second board to carry the customer if this one fails after return. Extended testing beyond that is available as a separate add-on.

Diagnostics & Validation Equipment

Bench power diagnostics with current logging, multimeter fault isolation on the 5 V and core rails, thermal inspection across the regulator and die, the device's own diagnostic surface — serial console, built-in self-test, AxeOS and its JSON telemetry endpoint — and live burn-in under real mining load. Bench fixtures built for loose industrial hashboards have no application to a complete device like this one and play no part in validating it.

All repairs are performed personally by Aleksandr Muranov, 7 years of ASIC repair experience. See credentials →

Contact our repair team today and get your miner back to full power.