NerdQAxe – High Rejected Share Rate

Cold power-cycle the NerdQAxe by unplugging the 12V barrel jack or XT30 connector for a full 10 seconds, then plug back in. Soft reboot via the dashboard preserves the stratum task's TCP state and replays the broken behaviour. Hard power-cycle resets the ESP32-S3 stratum state machine cleanly and clears 20-30% of reject events caused by transient vardiff desync or session age.

Revert tune to factory stock via Web UI. Set ASIC Frequency to 490 MHz (NerdQAxe++) or 480 MHz (original NerdQAxe) — verify against your variant — and core voltage to 1150 mV. Save and cold power-cycle. Watch reject% for 30 minutes. If it drops under 2% your tune was beyond silicon-lottery and you'll rebuild it slower.

Switch to the closest regional pool endpoint. Web UI Settings Stratum, replace URL with public-pool.io:21496, mine.ocean.xyz:3334, stratum.braiins.com:3333, or pool.d-central.tech for Canadian operators. Save and cold power-cycle. Pool latency above 200ms average drives stale-share rejects on top of any chip-side issue and inflates your reject percentage.

Verify your BTC payout address one character at a time against the pool's getting-started page. Some pools silently reject shares from invalid or unsupported address formats (Taproot bc1p on a SegWit-only pool, or a Lightning address pasted by mistake). Dashboard symptom looks identical to a reject flood. Copy-paste from a clean source, never from memory.

Cross-check pool-side dashboard against firmware-side dashboard. Visit the pool's worker page in a browser. If pool-side effective hashrate reads 10-40% lower than firmware-side local hashrate, rejects are being silently absorbed and the pool number is the truth. This confirms you're on the correct page rather than chasing a firmware-display bug.

Ping the pool host from a laptop on the same LAN for 60 seconds. Record min/avg/max RTT and packet loss. Above 200ms avg RTT is a stale-share generator on top of whatever rejects you have. Above 300ms plus any packet loss guarantees some rejects are stales not hardware errors. Switch to a closer regional pool or stop chasing chip-side fixes until network is clean.

Multimeter the 12V rail under load. DC mode, probe at the device-side connector while mining at full tune. Expect at least 11.8V sustained with no visible droop when chips load. NerdQAxe++ requires 12V/10A/120W minimum. If sag is present, swap to a regulated Meanwell RSP-150-12, the D-Central NerdQAxe++ PSU, or a known-good 12V/15A brick. Re-test reject rate for 30 minutes.

Open the per-chip HW% view and identify the worst chip. Web UI Stats Per-Chip, or curl http://<nerdqaxe.ip>/api/system/info and parse the chip array. Record each chip's individual HW% over 10 minutes. The worst chip's HW% sets your tune ceiling because the firmware uses unified frequency across all four chips at this time.

Rebuild OC slowly from stock. Tune in +10 MHz steps with a 10-minute stability window between each step. Watch all four per-chip HW% columns. Stop at the step before the worst chip crosses 2% HW% sustained — that is this specific NerdQAxe's silicon-lottery ceiling. Increasing core voltage by +10mV between frequency steps can give 10-20 MHz headroom on the limiting chip; watch power and VREG temp.

Switch pool family for a 30-minute A/B test. Cold power-cycle between switches. If rejects clear on a different pool family you have a pool-side vardiff interaction issue and either stay on the working pool or open a ticket. If rejects fail similarly on both you have a hardware-side issue and continue down the tier list.

Capture serial console at 115200 baud for 10 minutes of steady-state mining. USB-C data-capable cable into the NerdQAxe's serial port. Open screen /dev/ttyUSB0 115200 on Linux, PuTTY on Windows, or Chrome WebSerial via the shufps web flasher console mode. Capture mining.notify, mining.submit, mining.set_difficulty events and JSON-RPC error responses. Save the log — this is what the maintainer asks for.

Roll back firmware to the previous stable. Note current version. Download previous stable .bin from github.com/shufps/ESP-Miner-NerdQAxePlus/releases for your exact board variant — the silkscreen on the PCB tells you which fork. Web-flash via the shufps web flasher — Chrome or Edge with WebSerial enabled. Wrong .bin for wrong variant bricks the device. Verify variant before flashing.

Packet-capture the stratum session for ground truth. From a laptop on the same LAN with tcpdump or Wireshark, capture the TCP session between NerdQAxe IP and pool IP for 5 minutes. Examine mining.notify, mining.set_difficulty, your mining.submit payloads and the pool responses. Capture tells you definitively whether rejects are stales (error 21), low-difficulty (error 23), or other.

Reflow or re-paste the worst chip if per-chip view consistently flags the same BM1368 even at stock frequency and IR/thermal points to that chip running 5-10 C hotter than its neighbours. Power off, remove heatsink, isopropyl 99% the die and cold plate clean, re-apply Arctic MX-6 or Kryonaut. Replace any compressed pad with 1.5mm or 2.0mm silicone. Re-test reject rate.

Disable WiFi power-save and retest. ESP32-S3 firmware sometimes ships with WiFi power-save enabled by default which adds latency to stratum traffic. If your firmware build exposes a WiFi Power Save toggle, disable it and cold power-cycle. If it does not expose the toggle, this is a build-time choice — open an issue or compile your own from source with the option flipped.

Stop DIY when: same chip is fouling shares even at stock and even after fresh paste/pad, two different chips show degradation on the same board, you see VREG heat damage or capacitor bulging on the PCB, or rollback to multiple older firmware versions has not cleared the issue. You are now in chip-replacement or board-replacement territory — book a D-Central NerdQAxe service slot.

D-Central can stock-swap or component-repair NerdQAxe boards when chip replacement is the right call. As a NerdQAxe pioneer in the open-source mining ecosystem, we keep BM1368 salvage-grade and new-old-stock inventory specifically for this. Email support@d-central.tech with serial log, photos of the per-chip view, and PSU make/model.

Community escalation: shufps issue tracker. For firmware-side issues reproducible across multiple NerdQAxes, file a clean issue at github.com/shufps/ESP-Miner-NerdQAxePlus/issues with firmware version, board variant, pool, full serial log capture, packet capture if available, and a description of the failure mode. The maintainer responds. The open-source ecosystem only works because operators feed reproducible bug reports back upstream.