NerdQAxe – Low Hashrate on One Chip
Warning — Should be addressed soon
Symptoms
- AxeOS chip table shows one of four chips at 15-25% below the other three (typical: three at 0.50-0.55 TH/s, one at 0.35-0.42 TH/s)
- Total device hashrate reads roughly 75% of nameplate (~3.6 TH/s on a NerdQAxe++ that should be ~4.8 TH/s at stock 490 MHz)
- shufps ESP-Miner-NerdQAxePlus logs show recurring `asic[N] reg read mismatch` or `chain init partial` for the same chip index across reboots
- Thermal delta between the worst chip and its best sibling exceeds 5 °C at steady state (usually the low chip runs cooler, not hotter)
- Per-chip voltage in AxeOS reads normally (~1.20-1.30 V core) but hashrate stays depressed — points at mechanical, not electrical
- HW% on the affected chip spikes above 2% while the other three sit under 0.8%
- Rejected / stale shares ticking up on the pool dashboard, stratum connection otherwise stable
- Cold-boot restores full hashrate for 5-30 minutes, then the same chip drifts down again (classic thermal-pad decoupling signature)
- Firmware version is a shufps v1.0.3x build (the fork powering every modern NerdQAxe++)
- Pressing the affected heatsink down with a pencil eraser momentarily restores the chip's hashrate — the cleanest zero-tool diagnostic
- VRM / MOSFET cluster near the barrel jack running >80 °C at stock frequency
- Serial boot log (115200 baud) shows `count_asic_chips = 3` instead of the expected 4
Step-by-Step Fix
Hard power-cycle: unplug the 12V barrel jack for a full 10 seconds. Wait for the ESP32-S3 LED to fully dark and the TPS546 rail to fully discharge before reconnecting. Watch the AxeOS chip table for 15 minutes. This clears wedged driver state and forces a full chain re-enumeration. About 1-in-10 'one chip low' reports on NerdQAxe++ are pure firmware state after a stratum drop and need no physical fix at all.
Revert to stock frequency and voltage. In AxeOS Settings -> ASIC, set frequency to 490 MHz and voltage to 1200 mV — NerdQAxe++ factory defaults on BM1368. Save, reboot, watch 15 minutes. If the low chip recovers, the previous OC/UV tune was past the silicon lottery for your weakest chip. Rebuild the OC in 25 MHz steps from stock, leaving 10 minutes of stability between each step.
Open AxeOS Settings -> Monitoring -> ASIC and record each chip's hashrate, voltage, temperature, and HW% over a 10-minute baseline window. Screenshot for reference. This table is the source of truth on the device. Baseline for a healthy NerdQAxe++ at 490 MHz is four chips at roughly 1.2 TH/s each. Identify which chip index (0, 1, 2, or 3) is low — you will need that position throughout the rest of the procedure.
Check the firmware build in AxeOS Settings -> System (e.g. v1.0.36). Cross-reference against the shufps ESP-Miner-NerdQAxePlus GitHub releases and issues. Known-regression builds include v1.0.36 with the stratum-disconnect-every-4-40-min bug (issue #501). If you are on a flagged build, flashing a 30-day-old stable release from github.com/shufps/ESP-Miner-NerdQAxePlus/releases via the web flasher is a valid Tier-1 fix before you open the case.
Verify ambient air temperature is <30 °C at the NerdQAxe++ intake and confirm the 12V PSU is a quality branded unit rated for continuous load at 8A minimum. Generic wall adapters that work fine on a single-chip Bitaxe can sag under the four-chip NerdQAxe++ load, and one chip will always feel it first. If your PSU is anything less than a proper 12V 8A brick from a recognized brand, swap it as a Tier-1 diagnostic before going deeper.
Run the eraser test. Boot the miner, let it run 5 minutes for stable temperatures, then press a clean pencil eraser straight down on the center of the low chip's heatsink with moderate pressure for 10 seconds. Watch the AxeOS chip table. If the low chip's hashrate jumps to match its siblings during the press and drops when you release, you have just confirmed spring-clip or thermal-pad failure with zero tools — 100% mechanical. This is the single cleanest diagnostic in open-source mining.
Reseat the spring clip. Power off at the barrel jack. Carefully unhook the spring clip from the low chip's heatsink — note the orientation before you remove it. Inspect: is the clip visibly bent, stretched, or holding less tension than its siblings? Compare its free height to a known-good neighbour. If it is clearly looser, gently re-bend it back to match the good one. Reseat the heatsink, confirm the clip engages both anchor points firmly, power back on, and monitor 15 minutes.
Replace the thermal pad or paste. With the power off and the heatsink removed, clean all old paste / pad residue from both the chip die and the heatsink base using 99% isopropyl alcohol and a lint-free wipe. Apply either a thin, uniform layer of Arctic MX-6 paste to the die OR a fresh 0.5 mm thermal pad rated for >6 W/mK. Reseat the heatsink and reattach the spring clip with a firm seat. Cold-boot and re-baseline the chip table.
Add a MOSFET / VRM heatsink kit if your VRM temperatures hit >80 °C at stock or you plan to overclock at all. Attach small copper heatsinks to the MOSFET cluster near the barrel jack using thermal adhesive (not paste — adhesive, so the sinks do not fall off). Solo Satoshi's MOSFET placement guide documented a 15 °C drop on VRM temps from this mod. For any NerdQAxe++ running 600 MHz or higher, this is effectively mandatory, not optional.
Probe each chip's voltage domain against ground with a multimeter set to DC while the miner is hashing at full power with the cover off. Expect ~1.2 V core at stock. If the low chip's rail reads meaningfully lower than its siblings (>30 mV delta), the VRM phase feeding that chip is weak — stop here and proceed to Tier 3 / 4, this is repair-bench territory. If all four rails read within spec, the root cause is thermal or mechanical and Tier 2 should cover it.
Capture a serial log. Connect a USB-C cable from your computer to the NerdQAxe++ and open a serial monitor at 115200 baud (screen on macOS/Linux, PuTTY or Tera Term on Windows). Power-cycle and capture the full boot sequence. Look for `count_asic_chips = 4` and the per-chip handshake lines. A chip that fails handshake shows as `reg read mismatch` or drops from the count entirely. Save the log — it is the single most useful artifact if you end up filing a GitHub issue against shufps or sending the board to D-Central.
Flash the latest 30-day-stable shufps firmware release. Download from github.com/shufps/ESP-Miner-NerdQAxePlus/releases, then use the web flasher at espressif.github.io/esptool-js/ with the USB-C cable. NerdQAxe++ ships without a physical flash-button sequence so the web flasher is the clean path. After flash, restore pool settings and let the miner stabilize 20 minutes before re-baselining. The shufps fork iterates publicly; not every build is production-grade, which is why a recent stable with calm issue tracker beats the freshest build.
Reflow the marginal BGA chip if serial logs confirm chain-init partial and the cold chip is repeatably the same index. Remove the heatsink, mask off neighbouring chips with Kapton tape, apply no-clean flux around the package, and reflow with a preheat-plus-hot-air setup: preheat bottom side to ~150 °C, top-side hot air at 310-330 °C for ~30 seconds, then let it cool naturally. BM1368 tolerates a reflow cycle well. Re-paste and reassemble. This is the exact same profile you would use on a Bitaxe Supra — identical chip family.
Replace the BM1368 chip if reflow does not cure it. Source a graded chip from a dead Bitaxe Supra / NerdQAxe salvage board or from secondary market. Desolder the failed chip with hot air, clean the pads with solder wick and flux, reball if needed (or buy pre-balled), and reflow the replacement onto the pads. Verify continuity with a multimeter on a few known-good pads before powering up. This is the most advanced DIY operation on the device — the failure mode where a Bitaxe practice bench pays for itself twice over.
Roll back to a known-good shufps firmware if the latest misbehaves on your specific hardware revision. Known-stable anchors in this fork track upstream Bitaxe AxeOS release cycles — if upstream v2.14.x is clean on Supra, the equivalent shufps build is usually your safest rollback target. Always confirm the exact version string against open GitHub issues before flashing. Wrong firmware on a unit that happens to have a hardware revision the build does not support can leave you worse off, not better.
Stop DIY and book a D-Central ASIC Repair slot when you have: done the eraser test, confirmed spring tension is fine, replaced the thermal pad, and the same chip is still cold and low after 24 hours of stable hashing. OR when serial logs show the chip dropping from chain-init. OR when per-chip voltage reads >30 mV below siblings. OR when you have already reflowed once and the issue returned within 30 days. You are now in chip-replacement and VRM-repair territory. D-Central repairs NerdQAxe on the same bench that handles Bitaxe Hex and Supra.
At the D-Central bench, the process runs: serial log capture against a known-good reference unit, thermal imaging under load, per-chip voltage domain isolation, chip replacement with graded BM1368 silicon (salvaged-grade or new-old-stock), BGA reball, reflow, then a post-repair 24-hour burn-in at nameplate 490 MHz / 1200 mV with per-chip logging exported back to the customer. The same repair bench that turns around broken Bitaxe Hex boards and Bitaxe Supra boards handles NerdQAxe++ — shared chip family, shared tooling, shared institutional knowledge.
Ship safely. Pack the NerdQAxe++ PCB in an anti-static bag, then double-box with at least 5 cm of foam on every side. Remove the 12V PSU from the shipment and keep it at home — ship the board only unless D-Central has specifically asked for the PSU as well. Include a printed note with: which chip index is low (0/1/2/3), firmware version string, when the issue started, any relevant serial log, and your contact info. Clean intake notes save D-Central diagnostic time, which saves you repair cost.
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.
