ESP-Miner 2.15.2 adds BM1372 and BM1373 support for Bitaxe
Source report: 2026-09-18 · Editorial analysis published: 2026-09-19
The stable release expands chip support and fixes networking and interface issues; operators should match firmware assets to the exact board.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
What was released
The Bitaxe project published the stable ESP-Miner 2.15.2 release on 18 September 2026. The official changelog lists drivers for BM1372 and BM1373 ASIC chips, changes to the update-page asset message, a correction for swarm IP addresses, improved WPA 2/3 compatibility, protection against reconnect storms caused by slow clients, and interface fixes. The release also adds ST7789 display support for Bitaxe Color on Naja Duo and Gamma Hex. This is firmware for compatible open-hardware Bitaxe devices, not a universal image for every Bitcoin ASIC miner.
Why the chip drivers matter
A board can only control a hashing chip correctly when firmware understands its registers, clocking, voltage behavior and error reporting. Adding BM1372 and BM1373 drivers therefore expands the hardware that the ESP-Miner codebase can address, but it does not by itself promise a higher hashrate on an older board. The practical result depends on the exact PCB revision, power stage, cooling, chip count and configuration supplied by the device maker. Operators should treat the release note as compatibility information, not as an independent benchmark or profitability claim.
Network and stability changes
Several smaller fixes are operationally important. A wrong swarm address can make a fleet view misleading even when individual devices keep hashing. Disabling RSNO client support is intended to restore compatibility with mixed WPA 2/3 access points. The reconnect-storm fix addresses a failure mode in which slow browser or API clients repeatedly consume connections. None of these changes replaces basic segmentation: miners should remain on a dedicated LAN or VLAN, the dashboard should not be exposed directly to the internet, and remote access should pass through a VPN or a controlled gateway.
Safe upgrade checklist
Before flashing, record the board model and revision from the device page and label, export or photograph pool, wallet, Wi-Fi and tuning settings, and download only the asset intended for that board. Read the release notes and verify the download checksum when one is supplied. Update one noncritical device first, keep stable power during the write, then wait for the reboot without interrupting it. Afterward confirm firmware version, pool connection, accepted-share rate, temperature, fan behavior and hardware-error count. A ten-minute dashboard check is not enough; compare at least one normal operating window.
What to measure after installation
Use the same pool, frequency, voltage, cooling and measurement window as before the upgrade. Compare accepted hashrate rather than only the instantaneous local reading, because rejected and stale shares determine what the pool credits. Log power at the wall, chip and regulator temperatures, resets, Wi-Fi drops and error rate. If a new build is unstable, preserve logs and revert using the project’s documented recovery path. Do not compensate for instability immediately with more voltage: first return to stock settings and isolate firmware, network and thermal variables.
Decision for operators
Owners of hardware that needs BM1372 or BM1373 support have the clearest reason to adopt 2.15.2. Fleets affected by swarm-address, mixed WPA or client-reconnection problems may also benefit after a controlled test. A stable installation without those symptoms can wait for a maintenance window; the presence of a newer version is not by itself an emergency. Keep the exact previous image and configuration backup. The official release page remains the authoritative place for assets and later corrections, so operators should recheck it immediately before flashing.
Source: bitaxeorg ↗
Mining calculator ↗
