Bitaxe – Hashrate Fluctuating Wildly Minute-to-Minute

Switch the AxeOS chart to the 1-hour and 24-hour views before doing anything else. AxeOS → Dashboard → time-window selector. If the 1-hour view is flat at variant nameplate ±5%, your wild fluctuation is 5-minute display granularity. The chip is fine. Stop here unless the longer-window views also oscillate, in which case continue down the tier list.

Cold power-cycle for 10 seconds. Unplug USB-C (Supra/Ultra/Gamma) or the XT30 / barrel input (Hex/GT) for a full ten seconds, then plug back in. Soft reboot via the dashboard preserves NVS settings and rolling-window state; cold power-cycle resets the ESP32-S3 and clears any stuck averaging state. Run 15 minutes, re-check the 1-hour chart. Clears about 10% of cases.

Replace the USB-C cable with a known-good data-capable PD-rated cable. Charge-only cables and unmarked bargain cables drop voltage under load and produce exactly this symptom. Use a properly rated 5A E-marker cable (Anker, UGREEN, or similar) of the shortest practical length. On Hex/GT, confirm the XT30 pigtail is correctly crimped — a marginal crimp on a 12V 4A line will show up as flux.

Move the Bitaxe to a dedicated wall outlet not shared with high-load appliances. Anything else on the same circuit — space heater, microwave, vacuum, hair dryer, second mining device — will cause line voltage to swing during their on-cycles. Plug into an outlet on a separate breaker. If your test outlet is in a different room and the symptom clears, line-side sag was the root cause.

Wire the Bitaxe to Ethernet (where supported) or move closer to the WiFi access point. WiFi adds 20-80 ms of jitter and re-transmissions; on busy 2.4 GHz channels, that jitter can produce a share-cadence saw-tooth that looks identical to hashrate flux. If your variant has Ethernet, run a short CAT5e/CAT6 cable. If WiFi-only, move within 2-3 metres of the AP and re-test.

Multimeter the PSU rail under load. DC voltage with min/max recording, probe at the Bitaxe input under full tune for 10 minutes. 5V variants: expect 4.95-5.10 V sustained, spread <100 mV. 12V variants: expect 11.85-12.15 V sustained, spread <200 mV. Anything sagging or spreading wider is your cause. Swap PSU with a known-good unit rated at least 1A above nominal draw.

Replace the wall-side PSU with a quality unit. No-name USB chargers and dollar-store wall warts are the canonical Bitaxe flux source. Use a known-good unit: Apple 20W USB-C, Anker 30W USB-C PD, Mean Well series for 12V variants, or a USB-PD trigger board (ZY12PDN) with a 45W+ PD wall adapter. Mean Well sealed-construction supplies are bench-validated for clean output under continuous load.

Reset tune to factory and re-tune in small steps. AxeOS → Settings → Tune → Reset to default. Save, cold power-cycle, run 30 minutes. If the 1-hour chart flattens, your previous tune was beyond this chip's silicon-lottery ceiling. Re-tune in 10 MHz / 25 mV increments with a 10-minute stability window between each step. Stop at the step before the chart starts oscillating beyond ±5% on the 1-hour view.

Confirm chip temperature stays under 65 °C. AxeOS dashboard surfaces chip temp. Under full tune the BM136x / BM1370 should sit 45-60 °C ambient 25 °C, climbing to 60-65 °C ambient 30 °C. If you see >70 °C sustained, the firmware is throttling and your flux is the throttle cycle. Improve cooling: clean heatsink fins, replace fan if pushing less than nameplate CFM, refresh thermal paste, or lower ambient temperature.

Override the pool hostname with a fixed IP in AxeOS. From a laptop, run dig +short <pool-host> (or nslookup on Windows) to resolve the pool's stratum hostname to an IP. In AxeOS → Settings → Stratum, replace the hostname with the literal IP plus port (e.g. 203.0.113.42:21496). Save, cold power-cycle. Eliminates anycast / geo-DNS endpoint flipping mid-session as a flux variable.

Scope the rail. Two-channel scope, AC coupling, 100 mV/div, probe at Bitaxe input pads under full hash. Clean rail = <50 mV peak-to-peak, no visible 60 Hz / 120 Hz. Dirty rail = visible AC ripple, sometimes with low-frequency oscillation tracking the BM136x duty cycle. If you see ripple, the PSU's bulk capacitance is failing or the supply is undersized. A bench supply with adjustable current limit isolates the variable cleanly.

Replace TPS546 buck converter if the rail is clean into the board but oscillates out of the buck. The BM136x core rail (~1.15-1.30 V) is generated on-board by the TPS546. A failing buck shows up as core-rail ripple visible on a scope at the chip pad with a flat input rail. Hot-air rework job: flux + preheat to ~150 °C bottom side, top-side 300-320 °C for 30 seconds. D-Central's bench can do this for you if you don't have the rework setup.

Refresh thermal paste and check heatsink mount. BM136x packages are small and benefit from quality paste — Arctic MX-6, Thermal Grizzly Kryonaut, Noctua NT-H2. Remove existing paste with IPA 99%, apply a thin uniform layer, reseat heatsink with even pressure. On Bitaxe Hex, confirm all six chips have identical paste application — paste asymmetry causes per-chip flux that aggregates into board-level oscillation. D-Central pioneered the Bitaxe and Bitaxe Hex heatsinks.

Roll AxeOS firmware to the last-known-good version for your board revision. AxeOS → System → OTA, or web-flash via https://bitaxe.org/flash. Download the matching .bin from https://github.com/bitaxeorg/ESP-Miner/releases. Match your exact board revision printed on PCB silkscreen — Ultra 205/207, Gamma 601/602, Hex 303/304. Wrong .bin for wrong board bricks the device. Watch boot log on serial.

Build ESP-Miner from source with verbose logging around the hashrate-averaging window. Clone bitaxeorg/ESP-Miner. Locate the rolling-window math in the dashboard hashrate computation (typically in main/global_state.c or a dashboard helper file). Add ESP_LOGI traces around the window-update logic. Build with ESP-IDF v5.x, flash via USB-C. Reproduce the flux while watching serial logs. Submit fixes upstream.

Stop DIY and ship to D-Central when (a) factory-flashed Bitaxe with bench-validated 5V 4A or 12V 4A+ PSU and known-good cable still shows 1-hour view oscillation >±10% over a stable wired LAN with <50 ms RTT to a regional pool, (b) scope shows clean rail at the input but core rail ripples at the chip, (c) AxeOS chip temp and frequency read flat but hashrate oscillates and serial-console raw nonce rate also oscillates, or (d) physical damage is visible (scorched USB-C port, cracked PCB, bulged cap, blown fuse on VIN, lifted BGA pad on BM136x).

D-Central bench process for a Bitaxe with BITAXE_HASH_FLUX: test fixture with a bench supply at variant-spec voltage and 2x current headroom, scope on input rail and core rail, known-good wired LAN to public-pool.io:21496 with sub-50 ms RTT, factory-flash of current stable AxeOS matched to your board revision, replay your symptom set. If the bench rig reproduces, the failure is on the board — TPS546 swap, BM136x reflow, or board-level signal-integrity issue. Repair from D-Central's parts inventory or board-swap from D-Central's Bitaxe stock.

Ship safely. Pack the Bitaxe in an anti-static bag. Double-box with at least 3 cm of foam on every side. Include a note with: observed flux pattern (peak-to-peak swing, period in seconds, 1-hour vs 5-minute view delta), pool URL + port + SSL setting, AxeOS firmware version, board revision (printed on PCB), tune profile (frequency + core voltage), PSU brand/model used in your test, and saved serial log if captured. Saves D-Central's bench tech 30 minutes of preliminary diagnostics, which saves your repair cost.