Whatsminer M50S – Low Hashrate
Warning — Should be addressed soon
Symptoms
- Dashboard realized hashrate sits **more than `5%` below nameplate** for 30+ minutes at stock profile (`126 TH/s` M50S, `138 TH/s` M50S+, `142 TH/s` M50S++)
- WhatsminerTool → Miner Info → Diagnosis shows **chip count below `156 per chain`** on one or more chains
- `upfreq_test.log` shows a chain failing the frequency ramp at a specific chip index (example: `chain 1 chip 87 upfreq_fail`)
- One chain reports `0 TH/s` while the other two hash at near-nameplate — hashboard or ribbon fault
- `miner.log` contains co-occurring codes `2340` / `2350` (hashrate fluctuation), `236` / `238` / `268` (PSU), `430` / `520` (chip bin), or `540` / `541` / `542` (chip ID error)
- Pool-reported hashrate trails your local dashboard by more than `5%` over a 4-hour window (share variance on top of low raw rate)
- Temperature per chain drifts up `3–5 °C` vs baseline with no ambient change — thermal throttle is active
- PSU fan runs at `>85%` duty cycle during steady-state (not just startup)
- Hashrate recovers briefly after a reboot and then decays over 30–90 minutes — textbook thermal or PSU drift
- Fans ramp audibly in sync with small hashrate dips — firmware power-keeping engaged
- Miner has been shipped, moved, or had its lid opened in the last 90 days — vibration-seated fault
- Ambient at the intake regularly crosses `30 °C`, or the chassis is stacked / cornered with recirculation of hot exhaust
- Firmware version is on a sub-`20220901` build (known stratum + upfreq regressions on early M50S images)
- Custom firmware (Vnish / Asicdip) is installed and `100001` / `100002` / `100003` anti-tamper codes are visible in the log
Step-by-Step Fix
Log a 15-minute baseline in WhatsminerTool (realized hashrate, each chain, temp, fan RPM, PSU input / output). Screenshot or CSV it.
Export logs and grep for the code set (`2340`, `2350`, `236`, `238`, `268`, `430`, `520`, `540`–`542`, `6xx`, `5110`–`5112`, `100001`–`100003`).
Check Miner Info → Diagnosis for chip count below `156` per chain.
Hard power-cycle the miner for 60 seconds at the breaker.
Shop-vac the intake filter and grille; verify no recirculation; confirm intake ≤ `30 °C` at the grille.
True-RMS meter on AC at the PSU C19 inlet under full load. Target `230–245 V` on 240 V, `202–212 V` on 208 V.
DC-probe the PSU-to-hashboard connector under full load. Target `14.6–15.0 V` sustained on M50S-class PSUs.
Cross-check PSU-reported input voltage vs meter. Drift `>5%` = swap PSU.
Re-seat every 40-pin ribbon cable at both ends. Re-seat the hashboard DC connectors. Inspect for blackening, bent pins.
Swap the suspect hashboard to a known-good slot. Observe 30 minutes. Follows board = board fault; stays in slot = control path.
Flash the current MicroBT-signed stable for your hardware revision via WhatsminerTool. Do not attempt DCENT_OS or Antminer firmware. If on custom firmware with `100001`–`100003` codes, revert to signed stock.
Refresh thermal paste on all hashboards. Arctic MX-6 or Thermal Grizzly Kryonaut. Thin uniform layer. Inspect PMIC / voltage-domain thermal pads for cracks or hardening — replace if in doubt.
Reflow the worst-performing chip (once an `upfreq_test.log` position is isolated). Preheat bottom side to `~150 °C`, top-side hot air at `310–330 °C` for `~30 s`. `BM1398`-class BGAs tolerate a reflow cycle well.
Replace a bad chip if reflow doesn't hold. Source a bin-matched replacement — mismatched bins drag the whole chain down (`430`/`520` territory). Bin compatibility tables are not published by MicroBT; confirm against D-Central's internal decoder before replacing.
Replace the 40-pin ribbon cable and / or the adapter plate if re-seat fixes the problem but it returns within 90 days — the ribbon is worn.
Stop DIY. Triggers: chip-index failure reproduces on two different boards (PCB-level); visible heat damage, bulged caps, or burnt smell; signature / integrity damage that won't clear after rollback; miner dropped, submerged, or struck by lightning. Book a D-Central ASIC Repair slot — turnaround 5–10 business days Canada-wide.
Bench process at D-Central: test fixture with programmable load, chip-level isolation via WhatsminerAPI (`TCP 4028`) scripted sweep, bin-matched chip replacement from D-Central's graded inventory, reflow + reseal, PSU sensor verification and rotation if drift is suspected, 24-hour nameplate burn-in post-repair.
Ship safely. Hashboards in anti-static bags. PSU wrapped separately. Double-box with `≥ 5 cm` foam on every side. Include a printed note with observed symptoms, firmware version, log snippets (highlight any codes), electrical context (`120 V`? `240 V`? `208 V`? what else is on the circuit?), and contact info. Saves us diagnostic time, saves you bench-hour charges. Key rules of the road: - Do not reflash DCENT_OS on a Whatsminer. DCENT_OS is D-Central's open-source Antminer firmware — it runs on Bitmain-class silicon and control boards. Flashing it to M50S-class hardware will brick the control board and is a common cause of "paperweight" customer tickets. - Rule out power before you touch silicon. The biggest avoidable cost we see is operators ordering hashboard repairs for what was a sagging `12 AWG` extension cord. - Baseline before changing anything. A 15-minute Status log saves you from chasing ghosts after you've already swapped three things.
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.
