Bitaxe – Serial RX Invalid 11 Error After Hours of Mining

Cold power-cycle the Bitaxe: unplug USB-C or barrel jack, wait at least 30 seconds, replug. This forces the ESP32-S3 to re-initialize UART from silicon boot and guarantees a clean RX queue. Do NOT rely on the AxeOS web UI 'reboot' button — a soft reboot restarts the ESP-Miner task but does not always drop the UART driver state. This single move recovers the majority of units immediately.

Open AxeOS dashboard, check Best Difficulty and Hashrate. If hashrate has returned to nameplate (~1 GH/s Ultra, ~1.2 GH/s Gamma, ~3-6 GH/s Hex) within 5 minutes of the cold reboot, you are hashing cleanly again. Note the firmware version from System -> firmware and the current pool URL from Settings -> Pool. You will need both in Step 5 and Step 6.

Check your pool. If you are on `public-pool.io:21496` or a self-hosted Public Pool instance running on an Umbrel / Start9 / Raspiblitz / Bitcoin Core node, you are on the highest-risk pool for this bug. Low-volume stratum endpoints have longer idle gaps between `mining.notify` pushes, which is exactly what starves the UART drain loop. Note this — you will decide whether to stay on Public Pool with a watchdog, or swap pools, in later steps.

Increase ambient airflow around the miner. Thermal stress does not directly cause Serial RX invalid 11, but higher chip temperature destabilizes timing on the UART line and makes the firmware's assumptions more fragile. Aim for intake ambient <= 30 C. If the Bitaxe is inside an enclosure or stacked with other units, space them out and verify airflow.

Swap pools as a diagnostic test. In AxeOS Settings -> Pool URL, switch temporarily to `stratum+tcp://solo.ckpool.org:3333` (CKpool solo) or `stratum+tcp://mine.ocean.xyz:3334` (Ocean). Leave for 24 hours. If Serial RX invalid 11 does not return, you have confirmed pool-correlated UART starvation. Decide: stay on new pool long-term, or return to Public Pool with the watchdog from Step 10.

Flash the latest AxeOS / ESP-Miner release. Download the firmware bundle from github.com/bitaxeorg/ESP-Miner/releases. Use the AxeOS web uploader at /#/settings and flash BOTH the main firmware and the `www.bin` partition — a partial flash that misses `www.bin` leaves the UI broken but firmware live. Reboot. Verify the new version on the dashboard. Builds >= v2.2.0 ship improved UART buffer handling.

Raise pool difficulty where the pool supports it. In AxeOS Settings, some pools accept a `?d=<value>` suffix on the worker name to request a higher minimum difficulty (e.g. `ssuffix.worker?d=8192`). Longer-lived jobs = fewer dispatch gaps = steadier RX drain cadence. Check your pool's docs before setting — values outside the accepted range get silently clamped or rejected.

Connect USB-C and open a serial console at 115200 baud (PuTTY on Windows, `screen /dev/tty.usbserial-* 115200` on macOS/Linux, or `idf.py monitor` if you have ESP-IDF installed). Capture 30 minutes of boot + runtime logs during normal hashing. Save the log. When the error eventually reoccurs, compare timestamps against pool `mining.notify` gaps to confirm pool-correlated starvation.

If you run multiple Bitaxes, stagger your AxeOS firmware versions intentionally across units. Flash one unit to the latest release, leave others on the previous known-good build for 2-4 weeks, and compare failure rates. This protects against a firmware regression taking down your whole fleet, and gives you real data on which builds fix or regress this specific error.

Install a LAN watchdog for automated recovery. Point UptimeRobot, Home Assistant, or a cron on your home-lab Pi at `http://<bitaxe-ip>/api/system/info` and parse the JSON `hashRate` field. Trigger a smart plug (Shelly Plug S, TP-Link Kasa, Zigbee plug on HA) to power-cycle the Bitaxe when hashRate == 0 for more than 10 minutes. This is the single most reliable workaround while the ESP-Miner team iterates on the root cause.

For Bitaxe Hex operators specifically: confirm the 12V XT30 input is clean and supplied by a quality brick rated for at least 5A continuous. Marginal 12V can cause UART brownouts on the shared bus that look identical to Serial RX invalid 11. Swap the supply for a known-good unit and re-test. D-Central stocks 12V supplies matched to Hex.

Capture a UART-level logic trace. Connect a cheap USB logic analyzer (Saleae Logic 8 clone, $15-40) to the ESP32-to-BM TX/RX lines, probe at 1 MHz sample rate, and record a normal session + a failing session. Look for the exact byte sequence at the moment the parser logs `invalid 11` — you will see the `aa 55` preamble misaligned against the expected frame boundary. This confirms UART drain starvation vs any hardware fault.

Build and flash ESP-Miner from source with a larger UART RX ring buffer. Clone github.com/bitaxeorg/ESP-Miner, in `components/bm1366/bm1366.c` (or 1368/1370 equivalent), locate the `uart_driver_install` call and increase the RX buffer size from 1024 or 2048 bytes to 4096 or 8192. Rebuild with `idf.py build flash monitor`. Test under Public Pool for 24 hours. If the error frequency drops materially, PR the change upstream.

Add a periodic UART queue flush to the idle path. In the same firmware file, add a timer callback that runs every 500 ms and reads any queued bytes from the UART RX buffer without waiting for a command response. This prevents the ring buffer from wrapping during pool-idle periods. Open a pull request to ESP-Miner — this is exactly the kind of contribution the Bitaxe maintainers welcome.

If Tier 3 firmware work is beyond you, escalate to D-Central's pleb-mining support queue. We triage Bitaxe failures weekly, can confirm whether your specific unit's failure pattern matches known firmware bugs vs actual hardware damage, and have BM1366 / 1368 / 1370 replacement chips in stock for the edge cases where the ASIC is truly toasted.

Ship the Bitaxe to D-Central for bench work if the chip itself is suspected. Pack in an anti-static bag, double-box with 3 cm of foam on every side, include a printed note with: AxeOS version, pool URL, exact error line, how many hours before first failure, and whether cold reboot temporarily recovers. That information is worth an hour of diagnostic time — which we would otherwise bill you for. Ship to the D-Central address on the Repair Service page.

D-Central bench process for hard failures: USB-C enumeration test, ESP32-S3 boot-log capture via UART, BM chip response test with a known-good AxeOS image, chip replacement with graded BM1366 / 1368 / 1370 from our stock if the chip itself is dead, reflow + reassembly, 24-hour burn-in on Ocean pool at nameplate. Turnaround 3-7 business days Canada-wide, 5-10 days international.

If the Bitaxe is unrecoverable, D-Central offers a replacement credit toward a new unit from our stock: Supra, Ultra, Gamma, GT, Hex, or Max when Max ships. We also stock every Bitaxe accessory — the original D-Central Mesh Stand, heatsinks for Bitaxe and Bitaxe Hex (we developed the first ones), PSUs, cases. Ask the pleb-mining queue for a quote when you ship the failed unit.