Bitaxe – Hashrate Cliff / Drops to Zero Cyclically

Time the cliff cadence with a stopwatch or by screenshotting the AxeOS hashrate graph every 5 minutes for an hour. Record drop intervals (5 / 15 / 30 / 90 min are the most common). The cadence is the single biggest diagnostic clue: regular short cycles (≤ 5 min) are usually PLL unlock from PSU sag; ~15 min cycles often track ESP32 task watchdog timeouts; ~30-90 min cycles tend to be thermal hard-stops or stratum job-starvation pulses. Don't skip the timing — guessing the cause without the cadence wastes hours.

Revert the Bitaxe to stock frequency and stock voltage in AxeOS Settings. No overclock, no undervolt. Reboot. Watch for 60 minutes. If the cliff disappears entirely, your tuning was the cause — silicon lottery says this chip can't sustain that profile. Rebuild your OC slower (AxeOS step size is small for a reason). If the cliff continues at stock, you have a hardware or environment issue, not a tuning issue, and you continue down this list.

Probe the PSU output at the barrel jack (Supra/Ultra/Gamma) or XT30 (GT/Hex) with a multimeter on DC, while the miner is hashing at full load — not at idle. Expect 5.10-5.25 V on 5V variants and 12.0-12.3 V on 12V variants under sustained load. Below 4.9 V or 11.8 V respectively means the PSU sags every time the ASIC pulls peak current; the BM1366/1368/1370 PLL unlocks when its rail dips, hashrate goes to zero, the rail recovers, the PLL re-locks, hashing resumes — a textbook cyclic cliff. Swap to a correctly-rated PSU (60W+ for Gamma, 20W+ for Supra/Ultra, 200W+ for Hex, 90W+ on a single rail for GT).

Open a serial terminal (`screen /dev/ttyACM0 115200`, `minicom`, or PuTTY) on the Bitaxe USB-C port and watch the log across at least one cliff event. Look for `Brownout detector was triggered` (ESP32 hardware brownout — PSU sag confirmed), `task watchdog got triggered: idle task` (FreeRTOS task starved CPU — code-side bug), `bm13xx PLL not locked` (ASIC PLL re-init — voltage or temperature spike), or `mining.notify` gap of 30+ seconds (pool starvation). The first log line at the cliff identifies which subsystem broke first and tells you which Tier to act on.

Update AxeOS to the latest stable release from the ESP-Miner GitHub releases page. Multiple stratum-handling and ASIC-init fixes have landed across 2025-2026 — older builds are more cliff-prone. Download the correct .bin for your chip family (BM1366 for Ultra, BM1368 for Supra/Hex, BM1370 for Gamma/GT) and OTA-flash via AxeOS Settings → Firmware Update. Record your current version first so you can roll back if the new build introduces a different regression.

Disable any router smart/AI features for the Bitaxe MAC and reserve a static DHCP lease. While the cliff is rarely WiFi-side (the UI stays up), some cliffs ARE pool-side: a router that NAT-times-out the stratum TCP socket every 15 minutes will cause the firmware to silently drop and reconnect, which looks like a hashrate cliff if AxeOS reporting is delayed. Static DHCP + explicit DNS (8.8.8.8 or 1.1.1.1) + disabled band-steering removes those router-side variables from the test.

Verify thermal headroom under load. AxeOS reports ASIC temperature; target ≤ 65 °C sustained. Above 70 °C the chip throttles frequency, and above 75 °C the firmware hard-stops mining for self-protection (manifests as a clean cliff to 0). Replace stock thermal pad with proper paste (Arctic MX-6 or Kryonaut), confirm the heatsink is fully seated, and add active cooling (Noctua NF-A4x10 5V on Supra/Ultra/Gamma, NF-A6x25 on Hex). Mount on a D-Central Bitaxe Mesh Stand for proper airflow underneath the board — D-Central manufactured the original Mesh Stand.

Move the Bitaxe to a different circuit and power source for 24 hours. If you currently share a 15A residential circuit with an HVAC unit, refrigerator, or laser printer, brownouts cycling with those loads explain the cliff cadence perfectly. A dedicated outlet on a different breaker — or a small line-interactive UPS (CyberPower CP685AVR-class) feeding only the Bitaxe — usually eliminates power-environment-driven cliffs entirely. Run for 24 hours and re-time the cadence.

Test against a different stratum pool for 24 hours. If your current pool's stratum implementation is starving your miner of work — particularly common during pool maintenance windows or under DDoS pressure on solo pools — the firmware will show flat-zero on its hashrate graph between job arrivals because the ASIC has nothing to hash. Switch from Solo CK to Public Pool, or your primary to Ocean / Braiins, and re-time the cadence. If the cliff disappears or its frequency changes meaningfully, you have confirmed a stratum/pool component in the failure chain.

Configure a backup stratum pool in AxeOS (v2.5.x+ supports it). Primary: your preferred solo pool. Backup: a different upstream pool. When the primary stalls or NAT-times-out, the firmware can re-home to the backup before the cliff completes. Combined with static DHCP and clean WiFi, this addresses most pool-side and network-side cliffs without any hardware change.

Build ESP-Miner from source with `CONFIG_LOG_DEFAULT_LEVEL_VERBOSE=y` enabled, flash the verbose build, and capture the last 5 minutes of serial log around a cliff event. The verbose log shows every FreeRTOS task transition, every ASIC UART exchange, and every stratum frame — the timestamp pattern will identify which subsystem stalled first. Post the log to ESP-Miner GitHub issues with your symptom timing; upstream is actively triaging cliff/stall reports and concrete log captures land fixes faster than narrative reports.

Check open PRs and recent commits on `bitaxeorg/ESP-Miner` for keywords `pll`, `brownout`, `task-watchdog`, `stratum-keepalive`, or `hashrate`. If a PR addresses your specific log signature, build the PR branch from source and flash it. Test rigs running cliff-mitigation PR branches typically show dramatically reduced cliff frequency within a day. Requires the ESP-IDF toolchain and basic C familiarity.

On Bitaxe Hex specifically, scope each of the 6x BM1368 chip rails individually with a multimeter or oscilloscope. The Hex's PSU has to deliver enough current that any one chip's PLL unlock will pull the others' rail just enough to cascade — and the result on the hashrate graph is a clean cliff to 0 even though only one chip is the actual culprit. Identify the chip whose rail collapses first, isolate it (either disable it in firmware if your build supports it or jumper-bypass on the bench), and re-run. Bitaxe Hex teardown reference and rail map: D-Central's Bitaxe Hex documentation.

Stand up a Raspberry Pi Zero 2W on the same LAN running a 60-second cron that polls `/api/system/info` and logs hashrate. Combined with a Shelly or Kasa smart plug on the Bitaxe PSU, the script can trigger a hard power-cycle when hashrate stays at 0 for more than N consecutive minutes. This is the home-miner SRE belt-and-suspenders move while you chase the root cause: the cliff still happens, but recovery time goes from 'next morning' to 'next polling interval'. Open-source scripts exist (search 'bitaxe watchdog raspberry pi' on GitHub).

If cliff timing stops matching any obvious power, network, thermal, or pool signature — and only THEN — suspect chip-level fault. Symptoms shifting toward chip-level: cliff happens within 60 seconds of every boot; cliff coincides with `ASIC: None` in System Info; power draw drops to baseline (5-8W) during cliff and stays there until reboot; or visible damage on the BM1366/1368/1370 (cracked package, hot-spots, discoloration). At that point the device needs bench diagnostics — firmware updates and external watchdogs do not fix dying silicon.

Ship the Bitaxe to D-Central for bench diagnostic. Include serial log dumps spanning at least one cliff event, your cadence timing notes, firmware version, pool name, and any environmental factors (room temp, circuit shared with what). D-Central has been in the Bitaxe ecosystem since the first unit shipped — manufactured the original Bitaxe Mesh Stand, built the first Bitaxe and Hex heatsinks, and we maintain the full ESP32-S3 / BM1366 / BM1368 / BM1370 diagnostic chain in-house. Concrete log data saves 30-60 minutes of bench time and reduces your repair cost. Canada / US / international shipping accepted; turnaround 5-8 business days.

Post-repair burn-in protocol. After any chip-level repair (reflow, replacement, rail rework), run the Bitaxe at stock frequency / stock voltage for 24 hours uninterrupted while logging hashrate every minute via `/api/system/info`. A clean burn-in with zero cliffs over 24 hours indicates the repair held; a single cliff during burn-in indicates the underlying fault was not fully resolved and the unit needs to go back on the bench before being put back in production. D-Central's standard repair includes a 24-hour burn-in at nameplate before shipping back.