Bitaxe – Flatline of Death (Hashrate Frozen / No New Shares)
Critical — Immediate action required
Symptoms
- AxeOS dashboard hashrate graph is a perfectly horizontal line (non-zero) for 5+ minutes
- "Shares Accepted" and "Best Difficulty" counters stop incrementing for 10+ minutes
- `/api/system/info` still responds with fresh timestamps, RSSI, and temperature
- Pool-side dashboard shows worker offline or "last share N hours ago" while AxeOS says miner is hashing
- Serial log (115200 baud) shows `asic_result_task` messages stopping at a specific timestamp
- Serial log shows `unhandled result in stratum message` or `unhandled method in stratum message`
- `wifi:bcn_timeout,ap_probe_send_start` line in log history immediately before the flatline
- AxeOS soft-restart appears to fix it, but flatline returns within minutes
- Only a full cold power-cycle (10+ seconds unplugged) durably clears the state
- Onset is intermittent: minutes, hours, or days between events — no fixed trigger
- Frequency correlates with WiFi/ISP events, router reboots, or pool maintenance windows
- Temperature remains nominal (below 70 °C) during the flatline — it is not a thermal event
Step-by-Step Fix
Cold power-cycle the Bitaxe: unplug the 5V barrel jack (Supra/Ultra/Gamma) or 12V XT30 (GT/Hex) for a full 10 seconds, then repower. The AxeOS soft-restart button clears the UI state but not always the stuck stratum socket or ASIC UART buffer — 10 seconds unplugged guarantees the ESP32-S3's internal state fully drains. Expect normal hashrate oscillation (±15%) to resume within 2 minutes of repower.
Update AxeOS to the latest stable release from the ESP-Miner GitHub releases page. 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. Multiple flatline-related fixes have landed since v2.4.x. Record your current version before flashing so you can roll back if the new version introduces a different regression.
Reposition the Bitaxe for stronger WiFi or provision a dedicated 2.4 GHz SSID. Target RSSI ≥ -65 dBm as reported in AxeOS. The ESP32-S3 is 2.4 GHz only; if your router uses band-steering on a combined SSID, create a Bitaxe-only 2.4 GHz network to eliminate steering confusion. WiFi beacon timeouts are the single most-reported trigger of flatlines per ESP-Miner issue #252.
Reserve a static DHCP lease for the Bitaxe MAC address in your router settings. This prevents silent 3 AM lease-expiration disconnects that trigger stratum desync. While in the router UI, set AxeOS's DNS explicitly to 8.8.8.8 or 1.1.1.1 — some ISP DNS servers timeout quietly and stall stratum hostname resolution, which looks like a flatline from AxeOS's perspective.
Disable router smart/AI features for the Bitaxe MAC: AiMesh band-steering (Asus), OneMesh client steering (TP-Link), Orbi Smart Connect, and any generic client-power-saving toggles. Consumer routers sometimes deem a Bitaxe's small keepalive traffic as 'inactive' and throttle it, which is a textbook silent flatline trigger.
Install a scheduled smart plug (Kasa HS103, Shelly Plus Plug S, or equivalent) in front of the Bitaxe PSU. Configure it to power-cycle the miner for 30 seconds every 6-12 hours. This is the pragmatic hardware watchdog while upstream lands a firmware fix — it bounds your worst-case lost hashrate to half the cycle interval. A $15 plug pays for itself in recovered share submissions within a month on any home-miner rig. Ensure the plug is rated for 24/7 operation.
Probe the PSU output at the barrel jack or XT30 connector with a multimeter while the miner is hashing at full load. Expect 5.10-5.25 V on Supra/Ultra/Gamma standard or 12.0-12.3 V on GT/Hex. Below 4.9 V or 11.8 V respectively indicates your PSU cannot sustain load; brownout-adjacent conditions cause ESP32 and ASIC UART glitches that mimic the flatline bug. Swap to a correctly-rated PSU (60W+ for Gamma, 20W+ for Supra/Ultra, 200W+ for Hex) and observe for 24 hours.
Connect a USB-C cable and open a serial terminal (screen, minicom, or PuTTY) at 115200 baud. Look for `Brownout detector was triggered` in recent log history. Any occurrence is a dead giveaway that your PSU is marginal and must be replaced before firmware-side fixes will stick. Also scan for wifi:bcn_timeout entries to confirm WiFi is in the failure chain.
Mount the Bitaxe on a D-Central Bitaxe Mesh Stand or equivalent airflow-positive support. Bare-feet mounting on a flat desk traps heat around the ESP32-S3 and VRM — both sit on the top side next to the ASIC. Measurable reduction in RF glitches (and therefore WiFi timeouts and stratum desyncs) on rigs in warm ambients (>28 °C room temperature). D-Central manufactures the original Mesh Stand — we were the first shop to make them.
On AxeOS v2.5.x+, configure a backup stratum pool. Primary: your preferred solo pool (Solo CK, Public Pool, Ocean, Braiins). Backup: a different pool on a different upstream path. When stratum desync occurs, failover can sometimes re-home the connection before the ASIC task stalls. Not all flatlines benefit, but configuring it has zero downside.
For diagnostic contribution, build ESP-Miner from source with CONFIG_LOG_DEFAULT_LEVEL_VERBOSE=y and flash the verbose build. Run until flatline occurs (hours to days). Capture the last 5 minutes of serial log. Pattern identifies which subsystem stalled: missing `asic_result` lines = ASIC task; missing `mining.notify` responses = stratum; missing `wifi:sta:state` transitions = WiFi driver. Post to ESP-Miner issue #1053 — upstream is actively triaging and your data directly helps land a fix.
Build and flash a firmware branch containing a pending watchdog PR. Check open PRs on the bitaxeorg/ESP-Miner repo tagged with watchdog, stratum, or flatline keywords. As of 2026-04 there are multiple in-flight candidates adding hung-task detection to `asic_result_task` and a stratum socket keepalive. Requires the ESP-IDF toolchain and C familiarity. Test rigs running PR branches show dramatically reduced flatline frequency.
Wire an external hardware watchdog module between the PSU and the Bitaxe. A TPL5110-based board (Adafruit 2858) or a Witty Pi Mini repurposed can monitor a heartbeat GPIO pulse from the ESP32-S3 and hard-cut power if the pulse stops. Bitaxe exposes unused GPIOs on its debug header. Overkill for a single miner; worth it for a 10+ Bitaxe home farm where scheduled restarts would hurt aggregate uptime.
A/B test by moving to a different stratum pool for a week. Some pools' stratum implementations handle `client.reconnect` messages more robustly than others. If flatline frequency changes meaningfully between pools, you have confirmed stratum interaction is in the failure chain. Report findings to issue #1053 — this kind of A/B data is valuable for upstream debugging.
Stand up a Raspberry Pi Zero 2W (or equivalent) on the same LAN running a 5-minute cron that polls `/api/system/info`, parses the hashrate field, and triggers a Shelly or Kasa smart-plug API power-cycle if hashrate has not changed value for 15 minutes. This is the full DIY SRE loop — monitor, detect, remediate. Open-source scripts exist on GitHub (search 'bitaxe watchdog raspberry pi'). Zero user intervention once set up.
If the Bitaxe flatlines on every boot within 60 seconds, or flatline events coincide with ASIC: None in System Info, or with sudden power-draw changes, stop Tier 1-3 and treat as hardware failure. BM1366/1368/1370 UART contact issues, TPS546 regulator faults on Gamma/GT, and ESP32-S3 flash corruption are the usual culprits. These do not clear with firmware updates or smart-plug watchdogs — they need bench diagnostics.
Ship to D-Central for bench diagnostic. We've been in the Bitaxe ecosystem since the first unit shipped — manufactured the original Mesh Stand, built the first Bitaxe and Hex heatsinks, and maintain the full ESP32-S3 / BM1366 / BM1368 / BM1370 diagnostic chain in-house. Include serial log dump, firmware version, pool name, and flatline frequency notes in the package — saves 30-60 minutes of bench time and reduces your repair cost. Canada-wide, US, and international shipping accepted. Turnaround 5-8 business days.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.
