NMAxe v3.1.03 notes add Nexus board support and recovery safeguards
Source report: 2026-09-22 · Editorial analysis published: 2026-09-23
The NMAxe repository lists v3.1.03 with NMQAxe++ Nexus support, board auto-detection and HCN recovery. Operators should verify model-specific release assets before flashing.
Analysis and practical implications
This section is our analysis and illustrative calculations, separate from the source report.
What the repository published
The ESP-Miner-NMAxe repository added a September 22 entry for version 3.1.03. Its release notes describe support for the NMQAxe++ Nexus board using a BM1373 ASIC, automatic board-revision detection, recovery logic and user-interface changes. This is open-source firmware for a family of compact Bitcoin miners built around ESP32 control hardware. The notes are upstream project information, not a test performed by ASIC.tools. At the time of our check, the repository's separate Releases page still showed v3.1.02 as the latest packaged release, so users should confirm that matching v3.1.03 assets are actually available before attempting an upgrade.
Nexus support and board identification
Version 3.1.03 adds a new NMQAxe++ Nexus board variant based on BM1373. The notes also say QAxe++ and QAxe++ Rev6.1 can be distinguished during boot through the GPIO46 strapping pin. If firmware does not match the detected board, the interface should display a full-screen wrong-firmware overlay with the board name instead of failing silently. This safeguard reduces ambiguity but does not make every binary universal. The project's earlier guidance says users must select firmware for the exact device model. Operators should record the PCB revision, controller type and current image before downloading anything.
HCN automatic recovery
The new HCN auto-reinitialization is intended to react when the software detects channel imbalance, missing channels or a lack of progress. The miner can perform a fast Vcore power-cycle recovery, with at least fifteen minutes between attempts. A bounded interval is useful because repeated power cycling can hide a persistent hardware, power or thermal fault. After an upgrade, monitor recovery count, individual-channel hashrate, temperature, supply voltage and pool shares. If the same channel repeatedly drops, preserve logs and inspect connectors, cooling and power quality instead of treating automatic recovery as proof that the underlying problem is solved.
Presets, benchmark results and limits
The release notes list ECO, Normal and Turbo operating presets and benchmark charts that can store roughly 28 to 80 historical results. They also mention clamping frequency and Vcore to hardware limits. Presets are convenient starting points, not guaranteed stable settings for every ASIC sample, power supply or ambient temperature. A configuration that produces a short benchmark peak may deliver worse accepted-share efficiency over hours if errors, heat or throttling increase. Compare accepted hashrate and wall power after thermal equilibrium, and keep the factory baseline so a problematic tuning change can be reversed.
Cooling and voltage protections
According to the notes, v3.1.03 adds a fan-speed safety ceiling and corrects the Nexus Vcore calibration offset. Those changes directly affect thermal and electrical control, which is why model matching is essential. Do not copy a voltage value from another board revision merely because the web interface accepts it. Verify fan operation before mining, watch ASIC and regulator temperatures, and avoid unattended testing after a major firmware change. A software ceiling cannot compensate for a blocked heatsink, loose connector, undersized power supply or incorrect sensor reading. Stop the device if temperature or electrical behavior differs materially from the known baseline.
Boot, interface and API changes
The project says startup stability was improved and the update interface now shows a version timeline with release notes synchronized from the GitHub repository. API responses gain a maxTarget field and a record of the last over-the-air update result. These fields can help fleet dashboards distinguish an available limit from a chosen setting and identify failed upgrades. Automation should treat new or missing fields defensively: first query one test unit, store the old response schema and update parsers before rolling out broadly. An HTTP response that says an OTA completed still does not replace checking the running version, pool connection and accepted shares after reboot.
A cautious upgrade procedure
First export or photograph pool, network, frequency, voltage and temperature settings. Identify the exact model and PCB revision, then obtain the corresponding image from the official repository or official web flasher and verify the file name and checksum when one is published. Upgrade one noncritical unit with stable power; do not interrupt the erase, flash or first boot. Confirm the running version, configuration, fan behavior, chip detection and pool acceptance. Observe it through a full warm-up period before expanding to the fleet. Keep the documented wired recovery method available because OTA failure can require a direct ESP32 flash.
A successful boot is only the first validation step. Confirm that every ASIC channel is detected and that submitted shares are accepted by the intended pool. Preserve serial logs from the test unit, because they can reveal resets or calibration errors that a dashboard average hides. Roll back if stability, temperature or efficiency deteriorates.
What remains to verify
The README entry is valuable documentation, but operators still need a tagged release, downloadable assets and checksums that match their boards. Review open issues for device-specific problems and do not assume a README date proves that an image has completed release packaging. ASIC.tools will link only to a verifiable upstream download and will not mirror an unconfirmed binary as official firmware. The current evidence supports a limited conclusion: the upstream project documents v3.1.03 features for Nexus and related boards, including safer detection and recovery behavior, while each user must still verify exact hardware compatibility and asset availability before flashing.
Before a fleet rollout, save the exact upstream URL, tag, commit hash, file checksum and installation time for the test device. That record allows an operator to reproduce the image and determine whether two miners really run identical code. Use a maintenance window, local access and a known-good backup of settings. After reboot, compare frequency, voltage, temperature, fan speed, accepted and rejected shares, and wall power against the pre-upgrade baseline. Watch long enough to catch the fifteen-minute recovery interval described in the notes. If a board is not explicitly listed as supported, stop and ask the upstream project rather than selecting a similarly named image. Firmware can improve safeguards, but careful identification and staged deployment remain the strongest protection against an avoidable outage.
Source: NMminer1024 / GitHub ↗
Mining calculator ↗
