Whatsminer M30S – Share Rejection Spike

Hard power-cycle the M30S at the breaker for 30 seconds, then power back up. Cold reboots clear wedged stratum-session state that soft restarts leave behind. Resolves ~10% of 2030 cases on miners that have been running 30+ days.

Verify pool URL, port, and worker string in WhatsminerTool → Pool config. A single-character typo in the worker name (case-sensitive on many pools) causes the pool to reject every share. Re-type from scratch, do not copy-paste.

Add a second geographically different pool as a fallback (Foundry, Braiins, Ocean, F2Pool, ViaBTC). This is your fastest A/B diagnostic: identical reject% on both = miner/network; one-sided = pool/path.

Get the miner off Wi-Fi, powerline, or mesh network. Run a real Ethernet cable to a managed switch on the same LAN segment as your router. Stratum protocol is latency-sensitive and consumer wireless almost always adds jitter that causes reject% climb.

Restart your router; confirm the miner pulls a stable DHCP lease. Check for outbound firewall rules or ISP-level blocks on stratum ports (3333, 4444, 25). If your ISP blocks non-standard ports, try a pool that offers port 443 (HTTPS) — rarely blocked.

Check firmware version string in the status page. Note the 20xxxxxx.xx build date. If older than 12 months, plan to flash to the current official MicroBT build. If brand-new and the problem started after the flash, plan to roll back — MicroBT doesn't publish changelogs, so cross-check community channels for known-buggy builds.

Power down at the PDU. Open the chassis. Re-seat all three hashboard ribbon cables at the adapter plate — press firmly, listen for the click. Re-seat the adapter plate itself if socketed. Visually inspect for blackening, bent pins, dust bridging. This is the Whatsminer 'holy trinity' fix — 30-40% of M30S 2030 cases resolve here.

Inspect the button board. The M30S environment temperature sensor lives on the small button board, not the control board (per Zeus Mining). If temps look off at the same time reject% spikes, the button board sensor is drifting — cheap swap.

Pull `miner.log`, `api.log`, `system.log`, `power.log`, `upfreq_test.log` via WhatsminerTool Remote Ctrl → ExportLog. Grep for code=2030, code=2040, code=540/541/542, code=206/250/251, stratum_notify, difficulty changed. Correlate timestamps with your reject% spikes — the log schema is undocumented but the patterns are reliable.

Measure DC output at the PSU-to-hashboard copper bus under load. Multimeter on DC, miner hashing at full power. Spec: PSU label voltage ± 3% sustained. Sag more than that = PSU tired or circuit undersized. Swap PSU with a known-good unit of the same M30S-rated model.

Measure AC line voltage at the wall while the miner is running. Target 235-245 V on 240 V split-phase, 202-212 V on 208 V commercial. Anything below indicates circuit undersized, neighbour peak-load sag, or grid dropping. This is the 'evening reject% spike' signature.

Run mtr or pathping from a LAN client to your pool's stratum endpoint for 5 minutes. Look for any hop above 100 ms RTT or >0.5% packet loss. Canadian miner pointing at a Singapore pool eats 5-8% stales before any hardware is touched — switch to a regional replica.

If code 2040 co-appears with 2030, disable asicboost in WhatsminerTool → Misc. Not every pool supports asicboost cleanly; some accept the work but silently reject share-level asicboost flags. 30-second toggle test.

Swap in a known-good PSU of the same M30S-rated model (V100, P21E-12, or equivalent). Do not mix M30S and M50S PSUs — MicroBT enforces a model-locked firmware handshake (code 8700). Tired PSU caps cause voltage skew that manifests as reject%.

Flash the latest official MicroBT firmware for your exact M30S hardware revision (M30V1/M30V2/M30V3). Verify the hardware string matches the firmware's supported-hardware list before clicking Start Upgrade — wrong firmware trips code 8410. Do NOT flash custom firmware (Vnish, Asicdip, HiveOS) on M30S — anti-tamper codes 100001/100002/100003 will fire. DCENT_OS is Antminer-only and will not run on MicroBT hardware.

Per-board disable via WhatsminerTool to isolate the offending hashboard. Disable SM0, run 15 minutes, note reject%. Re-enable SM0, disable SM1, repeat. The board whose absence drops reject% below 1% is the bench candidate. Undocumented but supported — lets you keep running at 2/3 hashrate while you wait on repair.

Inspect capacitors and MLCCs on the suspect hashboard under magnification. Bulging electrolytics near the PMIC, cracked MLCCs in the domain rails, or visible heat damage = component-level repair territory. Soldering iron + hot-air work, not reflow.

Reflow the suspect chip if you've isolated a specific chip via per-board analysis and see a solder joint void on thermal imaging. Preheat bottom of board to ~150 °C, top-side hot air 310-330 °C for ~30 s over the BM1362/BM1366 package, cool naturally, re-apply thermal paste, reassemble. Hot-air rework station required.

Re-torque the copper busbars between PSU and each hashboard to community-derived spec (~1.5-2.0 Nm for M30-series). MicroBT doesn't publish this (CG-4 gap). Loose busbars cause output current imbalance (code 241) and can masquerade as share rejection under heavy load.

Stop DIY and ship to D-Central when: reflow on one chip fails within 30 days; two hashboards show chip-ID read failures at the same position; PMIC/voltage-domain IC shows heat damage; you see capacitor bulging or burnt-component smell; or reject% is still above 2% after all Tier 1-3 steps. D-Central bench process for M30S: ribbon + adapter plate test, per-chip isolation via MicroBT service-level tooling, BM1362/BM1366 chip replacement with graded stock, PSU handshake verification, 24-hour nameplate burn-in.