Bitaxe – Hashrate Below Expected (30-50% of Spec)

Open AxeOS, screenshot per-chip stats, total hashrate, frequency, and Vcore setting. Before changing one variable, capture the current state - per-chip HW%, per-chip individual hashrate, per-chip temperature, total hashrate, set frequency, set Vcore. This is your baseline. Without it you cannot tell whether the next change made things better or worse, and you cannot get useful help from the bitaxeorg Discord, OSMU wiki, or D-Central support if you eventually need it. A screenshot also distinguishes 'all chips uniformly underperforming' (tune problem) from 'one chip failed' (subset failure) - different repair paths entirely.

Confirm variant and expected nameplate. Read your variant from the AxeOS dashboard (Supra, Ultra, Gamma, GT, Hex) and cross-reference against the published nameplates: Supra ~700 GH/s, Ultra ~500 GH/s, Gamma ~1.2 TH/s, Hex ~3 TH/s. These are well-tuned targets, not stock-out-of-box guarantees - your specific chip may be +/- 10-15% from nameplate due to silicon variance. '50% of expected' means a Gamma at ~600 GH/s or below, not a Gamma at 1.05 TH/s (which is normal silicon variance). Confirm you are actually at 50%.

Power-cycle the board with a full 30-second discharge. Unplug everything (USB-C, main PSU, fan, accessory). Wait 30 seconds - bulk caps need time to discharge before NVS state stabilizes. Replug. Watch the boot sequence in AxeOS. A non-trivial fraction of '50% hashrate' tickets recover after a clean cold boot because something in the firmware state was wedged from a previous bad-power event or graceless shutdown.

Enable autotune in AxeOS Settings. If autotune was disabled (manual mode), enable it. If it was enabled, verify it is actually running by watching the frequency / Vcore numbers in the dashboard over a 30-minute window - they should drift as autotune searches. Static values for 30 minutes mean autotune is parked, not running. Re-enable, power-cycle, watch again. Autotune is not free and not instant - give it real time.

Run autotune from a clean cold boot for 30+ minutes. After enabling, full power-cycle, then leave the board hashing under a real pool workload (not idle, not test mode) for at least 30 minutes. Watch the hashrate climb from default toward variant nameplate. If autotune lands you within 5-10% of nameplate, you are done - recovery via autotune alone resolves a meaningful fraction of cases. If autotune parks at 50%, your chip needs manual tuning intervention (Tier 2).

Check firmware version against the bitaxeorg releases page. Open AxeOS dashboard -> System Info -> firmware version. Cross-reference against bitaxeorg/ESP-Miner releases. If you are on a known-buggy autotune build, roll forward (or back) one version. Re-flash via the Bitaxe Web Flasher (bitaxeorg.github.io/bitaxe-web-flasher/) - Chrome or Edge required (Web Serial API). After re-flash: full power-cycle, re-run autotune from clean state.

DMM the input rail under hashing load. Supra/Ultra/Gamma: probe at the USB-C or barrel input - must hold >=4.85 V sustained under load. Hex: probe at the XT30 connector - must hold >=11.5 V sustained under load. 'Under load' means the board is actively hashing at full draw, not idle and not test mode. Voltage sag below those thresholds starves the downstream regulator. If you see sag, swap to a known-good spec-matched PSU before doing further work - a tired PSU is the cheapest possible fix for 'low hashrate' complaints and is missed often.

DMM Vcore at the TPS546 output (or equivalent regulator) under hashing load. Locate the Vcore test point - silkscreened on most revisions, in the bitaxeorg hardware schematics if not. Expected: ~1.20-1.30 V for BM1366/BM1368 (Supra, Ultra, Hex), ~1.00-1.20 V for BM1370 (Gamma family). Probe under load. If reading is 0.05 V+ below the AxeOS commanded value, your regulator is undervolting at the chip pin even when the firmware thinks it is hitting target. Note this delta - it is a key data point for any escalation.

Manual tune: raise Vcore +25 mV over stock target. Disable autotune in AxeOS. Set Vcore to stock target plus 25 mV (e.g., from 1.25 V to 1.275 V on a BM1368). Keep frequency at stock. Power-cycle, hash for 15 minutes, monitor HW% and total hashrate. If HW% drops below 1% and hashrate climbs toward nameplate, your chip needed a touch more voltage. Lock this in. If HW% is still >2%, continue to Step 10.

Manual tune: drop frequency -25 MHz from stock. With the +25 mV Vcore from Step 9 still applied, reduce frequency by 25 MHz from stock (e.g., from 525 MHz to 500 MHz on a Gamma). Power-cycle, hash for 15 minutes, monitor. Slightly lower frequency reduces per-cycle compute stress and gives the chip a wider voltage margin. The combination of +25 mV / -25 MHz recovers a substantial fraction of '50% hashrate' Bitaxes where the chip lost the silicon lottery.

Manual tune: try +50 mV / -25 MHz if +25 / -25 did not recover. Maximum safe Vcore headroom on stock thermal solution is roughly +50 mV over chip nominal - beyond that you risk thermal runaway on a stock heatsink. Verify chip temperature stays under 70 C at the new tune. If hashrate recovers and thermal is in band, lock this in. If you have hit +50 mV and you are still at half-rate, the chip is degraded - Tier 3 or escalation.

Verify per-chip stats after each manual tune change. On multi-chip boards (Hex, GT, NerdQAxe), every tune change should produce uniform per-chip behavior. If one chip's HW% spikes after a Vcore increase while the others stay clean, that chip has a different operating point than the others - possibly degraded or a partial failure. Note this and consider per-chip-domain manual tuning if the firmware supports it, or escalate to chip-level diagnosis.

Scope the Vcore rail under load with a 100 MHz handheld scope. A clean rail under steady-state hashing is flat with sub-50 mV ripple. A starved or oscillating rail will show clear sag transients during chain-init or work-dispatch transients, or visible ripple in the 100+ mV range. Either pattern indicates the regulator's compensation network is operating outside its happy zone - usually means a degraded bulk capacitor or a partial fault in the feedback loop. Tier-3 diagnosis pointing at component-level repair, not tuning.

Inspect bulk capacitors on the input rail and Vcore output. Power off, remove heatsink, visually inspect the electrolytics and ceramic caps near the input connector and around the TPS546 / regulator. Bulging electrolytics, cracked MLCCs, or visible solder issues at the cap pads = component replacement needed. Capacitor aging on a Bitaxe that has been in service for 18+ months is a real failure mode that produces exactly the 'stable but underperforming' pattern this page covers.

Reflow the BM1366 / BM1368 / BM1370 chip if HW% is uniformly elevated despite voltage being clean. A chip with a marginal BGA joint can produce silent throttling: nonces compute but a fraction land in the hardware-error band because of intermittent connectivity to one or more pins. Single-chip reflow on a preheater + hot-air station (~150 C bottom, ~310-330 C top, ~30 seconds) recovers a fraction of these. Re-paste, remount heatsink, re-flash firmware, re-tune. Same procedure documented on the Bitaxe Hex one-chip-dead page - the technique is identical for single-chip Supra/Ultra/Gamma.

Replace the chip if reflow does not hold. D-Central keeps BM1366, BM1368, and BM1370 chips on the shelf for single-chip swap repairs. Desolder the dead chip with hot air + low-melt solder, clean pads with braid + flux, place a replacement, reflow with a proper BGA thermal profile, inspect alignment under the microscope before powering. After reflow: fresh paste, heatsink remounted, firmware re-flashed, autotune re-run. This is a Tier-4-comfortable-for-bench job; ship it if you do not have the tool stack.

Stop DIY if voltage is clean, autotune does not recover, and per-chip stats do not isolate a single failing chip. That combination indicates a deeper hardware issue - regulator drift, capacitor aging, chip-wide silicon degradation from prior thermal abuse, or board-level silicon damage. These are bench-level diagnoses that require controlled-temperature fixtures and component-level test gear. Ship the board.

Stop DIY on chip-level rework if you do not have a real preheater + controlled-temperature hot-air station + rework microscope. BM1366 / BM1368 / BM1370 are BGA packages. Iron-only rework rips pads. Without controlled temperature you char the FR-4 or blow adjacent passives. D-Central's bench has the full BGA rework stack, plus chip inventory for the swaps that need them.

Ship to D-Central with screenshots, tuning history, and PSU. Anti-static bag, double-box. Include a note with: variant + revision, AxeOS firmware version, screenshot of per-chip stats at the depressed hashrate, screenshot of any tuning attempts and outcomes, the input PSU you are using (we test your actual stack), and any context (recent firmware update? brownout? new-out-of-box? running for 18+ months?). Canada-wide shipping, US/international welcomed. Turnaround 5-10 business days.

Consider repair economics vs replacement. Tuning recovery at D-Central is CAD $0 (we do it as part of any repair assessment). Bench-level tune + voltage tweak + autotune session: CAD $40-90. Single-chip replacement (BM1366 / BM1368 / BM1370): CAD $85-175. Component-level regulator / capacitor repair: CAD $60-130. Full Bitaxe replacement (variant-dependent): CAD $150-400. The math almost always favors repair on these - a $90 tune session that recovers a $320 Gamma is the right move every time.

Log the tune profile in your mining operator log. Whatever the resolution, record: variant, board revision (silkscreen), AxeOS firmware version, final Vcore setting, final frequency setting, final autotune-on-or-off state, total hashrate at the locked profile, ambient temperature, date. If you run multiple Bitaxes (solo-mining stack, heat-recovery setup), the per-chip silicon-lottery profile across the fleet is operational intelligence - you will see patterns in which chip date-codes need more Vcore, which firmware versions destabilize autotune, and which PSUs sag on which variants.