Whatsminer M30S – Low Hashrate

Power cycle the miner at the breaker for 30 seconds. Not a soft reboot from the WhatsminerTool — a full cold power-off. Clears wedged driver state after firmware updates and resets the PSU's internal fault latches. Verify the IPFOUND button still responds after boot; if the miner doesn't report its IP within 3 minutes, jump to control-board diagnostics.

Confirm high-performance mode is active. WhatsminerTool → Remote Ctrl → Set Power Limit. Verify you aren't unintentionally running in power-keeping mode (which caps hashrate deliberately) or a custom power limit. Reset to factory power limit and re-baseline hashrate for 15 minutes. Power-keeping mode is intended for anti-freeze scenarios on hydro units and is a common source of "mysterious" low hashrate on M30S air-cooled units where someone fat-fingered it.

Clean the intake and measure ambient. Shop-vac the front intake filter, wipe the grille, and verify nothing is within `15 cm` of the front of the miner (no shelves, no curtains, no second miner blowing hot exhaust into it). Measure ambient with an IR thermometer at the front grille, not room-middle. Target `≤ 30 °C` for high-performance mode. In a Canadian summer garage this can drift above spec without the operator noticing.

Check for a firmware update — or a firmware downgrade. WhatsminerTool → Firmware Upgrade. Note your current build string (e.g. `20251209.16`). Visit `support.whatsminer.com` for the latest stable build for your exact hardware revision. If the symptom started right after your last upgrade, roll one version back instead of forward. MicroBT does not publish changelogs, so the community is the ground truth here — check Whatsminer threads on BitcoinTalk and r/gpumining before you flash.

Verify pool connection and share flow. Pool page should show steady accepted shares with a realized hashrate that matches the miner's dashboard within `±2%` over a 1-hour window. If pool hashrate is much lower than dashboard, you have a network or pool-side issue, not a hardware issue — and a different error (`stratum high rejection rate`, code `2030`) may apply.

Measure PSU output voltage under full load. Multimeter on DC, probe the PSU-to-control-board bus while the miner is hashing at rated power. The M30S internal PSU should hold steady within MicroBT's spec. Voltage sag under load = tired PSU. Note the reading at idle vs under load — more than a few percent drop indicates PSU degradation. If your miner has an external PSU variant, swap it with a known-good unit.

Measure input AC voltage at the miner inlet. Multimeter on AC, probe the input terminals. Target `235-245 V` on 240 V split-phase Canadian/US residential, `202-212 V` on 208 V commercial. If input voltage sags below `228 V` under load, your circuit is undersized or your neighbourhood grid is weak. This is the single most common "mystery M30S low hashrate" cause in North American residential setups.

Re-seat every hashboard cable. Power off at the breaker. Disconnect each hashboard-to-adapter ribbon cable, visually inspect the contacts for oxidation or black discoloration, reconnect firmly. Do the same for the adapter plate's power connectors. Ribbon-cable oxidation is a creeping M30S problem after 18-24 months in humid or dusty environments — Vancouver Island operators know this one well.

Export `upfreq_test.log` and `miner.log` via WhatsminerTool. Remote Ctrl → ExportLog. Open both files. `upfreq_test.log` shows per-chain, per-chip frequency ramp results — flag any chip position that timed out. `miner.log` reports the final chip count per chain. If count is `<105` on any chain, identify which chip is missing by position.

Swap hashboards between slots. Power off. Label slots 0/1/2 with tape. Move the weakest-reporting hashboard into a known-good slot. Power on, baseline for 15 minutes. If the fault follows the board, it's a bad board (Tier 3). If the fault stays in the slot, it's a bad control path (ribbon, adapter plate, or control board).

Check chip count and bin type compatibility after any hashboard transplant. If you recently swapped boards between M30S units (e.g. from an M30S+ to an M30S, or between M30S revisions), MicroBT codes `430-432` / `520-522` may trigger silently. Run WhatsminerTool → Device → verify bin type is consistent. Mismatched bins cause derated ramp without a prominent error flag.

Reflow the identified failing chip position. If Tier 2 diagnostics isolated one chip via `upfreq_test.log` timeout, remove the board from the miner. Remove the heatsink (M30S uses thermal pads + screws, not clips). Flux the target chip, preheat the board from below to `~150 °C`, top-side hot-air at `310-330 °C` for 30-45 seconds until the solder mask relaxes and the chip self-aligns. Let it cool naturally, re-apply thermal interface material, reassemble. This is a lower-risk repair on M30S chips than on Bitmain S19 boards because the MicroBT package tolerates a reflow cycle reasonably well.

Refresh thermal paste on all chips of a suspect board. If the board is old (>18 months) and the miner runs in a warm environment, dried paste alone can cost 5-10% hashrate. Remove the heatsink, clean old paste with isopropyl alcohol 99% and a lint-free wipe, apply a uniform thin layer of Arctic MX-6 or Thermal Grizzly Kryonaut. Don't glop it on — uniform thin layer. Pay particular attention to the PCH and voltage-domain ICs where thermal pads often fail before the paste does.

Inspect and replace visibly-failed passives. Bulging electrolytic capacitors, cracked MLCCs, or discoloration near the PMIC indicates voltage domain damage. This is soldering-iron work, not reflow work — desolder the failed part with fresh flux and braid, solder in the replacement with care for footprint and polarity. If you're not comfortable with this, stop and go to Tier 4.

Flash the last-known-good Whatsminer firmware for your exact hardware revision. Verify the revision on the adapter plate sticker before flashing — MicroBT's firmware is picky about hardware revision and flashing wrong bricks the control board. If you're running a custom firmware (Vnish or similar) and getting `LOW_HASH` with no chip-level cause visible, revert to stock and re-baseline before blaming hardware. Custom firmware on Whatsminer can conflict with the anti-tamper checks (codes `100001`/`100002`/`100003`), which masquerade as low hashrate.

When to stop DIY. Stop and ship the miner (or just the affected hashboards) to D-Central when any of: (a) per-chain diagnostics isolated the same chip *position* failing on two different boards in the same rig — that's adapter-plate or control-board level, not chip-level; (b) PMIC / voltage-domain IC damage is suspected; (c) a reflowed chip comes back to `upfreq_test` timeout within 30 days; (d) you see any burnt-component odor, visible discoloration on PCB traces, or capacitor bulging. Further DIY here risks damaging adjacent parts worth more than the repair.

What D-Central does on the bench. Programmable test fixture with simulated pool traffic and per-chain current monitoring; per-chip diagnostics using MicroBT service tools; chip replacement from graded M30S-class silicon inventory (MicroBT bin-matched); full reflow and re-seal; 24-hour nameplate burn-in at stated performance mode before shipment back. Canada-wide shipping, US/international welcomed. Typical turnaround: `5-10 business days` from receipt.

Ship safely. Pull each hashboard if you're only sending boards, not the chassis. Anti-static bags, double-box with `≥ 5 cm` foam on every side. Include a note with observed symptoms, firmware version/build string, power environment (240 V split-phase? 208 V commercial?), and contact details. This saves our bench time — and your dollar — by a solid chunk on intake diagnosis.