Skip to content

We're upgrading our operations to serve you better. Orders ship as usual from Laval, QC. Questions? Contact us

Bitcoin accepted at checkout  |  Ships from Laval, QC, Canada  |  Expert support since 2016

WM_POWER_LIM Warning

Whatsminer M50S – Power Limit Triggered

Power consumption exceeds limit setting - BTminer governor trips codes 204/205/207/255/256/268/272/273 and pulls frequency back; hashrate runs 5-20% below the 126 TH/s M50S nameplate.

Warning — Should be addressed soon

Affected Models: Whatsminer M50S, M50S+, M50S++

Symptoms

  • MinerTool dashboard shows 'Power consumption exceeds limit setting' or 'Power over limit' banner
  • BTminer event log contains 204 (Power current protecting), 205 (Power current error), 207 (Power input current protecting), 255/256 (Protection of over power output), 272/273 (Warning of excessive power output), or 268 (Power output over-current protection)
  • Realized hashrate 5-20% below the 126 TH/s M50S nameplate with no hashboard-error code set
  • Wall-plug power draw fluctuates by 200+ W on a timescale of seconds - governor cycling up and down
  • LED cycles red-amber-green-red during the ramp to High Performance instead of settling green
  • power.log contains repeated POWER_LIMIT or OVER_POWER lines bracketing the ramp attempt
  • get_miner_info via the TCP 4028 API reports a lower actual power mode than the one you commanded
  • PSU fan audibly ramping to 100% during steady-state mining, not just at startup
  • Miner runs clean on Low mode but trips power-limit within 2-5 minutes of switching to Normal or High Performance
  • Other equipment on the same electrical circuit (shop lights, heater, A/C, compressor) triggers the fault when it cycles on
  • Intake temperature is nominal (below 30 C) - ruling out 600/610 thermal throttling as the cause
  • Codes re-appear immediately after a reboot, not after a delay - indicating a sustained electrical or hardware cause rather than a one-off transient

Step-by-Step Fix

1

Hard power-cycle at the breaker for 30 seconds, then power back on and let the full boot plus ramp complete (5-8 minutes on M50S). Watch the LED cycle red-amber-green. This clears any wedged BTminer governor state that can persist after a failed ramp, a firmware update, or a flaky network reboot - and it is the fastest Tier 1 win before touching tools. Confirm the error code returns before moving on; if it clears on a cold boot and stays clean, you had a transient, not a fault.

2

In MinerTool, drop power mode from High Performance to Normal (Remote Ctrl > Power Mode > Normal), or from Normal to Low, and reboot. Observe for 20 minutes. If the 20x/25x/27x codes clear and hashrate stabilizes, your grid, chip bin, or thermals cannot sustain the higher mode in this environment. Running the lower mode is not a workaround - it is the correct, stable setpoint for your specific unit and your specific install.

3

Audit every device on the same electrical circuit as the miner. Shop lights, fridges, baseboard heaters, compressors, block heaters - anything that cycles on will transiently sag the circuit under M50S load. Move non-essential loads to a different circuit or dedicate the circuit to the miner. Canadian home miners: if the garage miner shares with a block heater in winter, this is almost certainly your trigger - watch the codes fire the moment the heater thermostat cuts in.

4

Export logs via MinerTool (Remote Ctrl > Export Log). Five files come out: upfreq_test.log, power.log, miner.log, system.log, api.log. Archive all five. power.log is the one that matters for this error - it records governor decisions, sampled input/output power, and the exact timestamp the limit tripped. You will need it for Tier 3 work and for any D-Central repair ticket, so capture it while the miner is still in the failing state before any further changes.

5

Verify your BTminer firmware version against the MicroBT portal at support.whatsminer.com. If there is a newer build for your exact M50S hardware revision, plan an update - but only after you have exported and archived current logs, because some firmware updates reset the event log. Verify the firmware signature on the new build (M50S/M60S generations enforce signature verification). Never cross-flash M50S+ firmware onto an M50S.

6

Clamp meter on the AC input hot lead while the miner is at full Normal-mode load. Target current draw: 14-15 A on 240 V split-phase, 16-17 A on 208 V commercial. Any reading materially above that at Normal mode points at PSU inefficiency or a weak board forcing the governor's hand. Measure cold, then after 20 minutes of steady-state load, and compare - a rising current signature at constant frequency is a PSU or chip-level fingerprint.

7

Multimeter on AC voltage at the PSU input under that same full load. Target: 225-245 V on 240 V split-phase, 202-215 V on 208 V commercial. If voltage sags below spec only when another load on the circuit cycles on, you have confirmed a shared-circuit sag problem, not a miner problem. The correct fix is a dedicated 240 V split-phase circuit from the panel, not anything done to the miner itself.

8

Multimeter on DC at the PSU-to-hashboard busbar or connector during a ramp to the target power mode. Expect 13.8-14.2 V sustained. Anything below 13.5 V under load means the PSU cannot hold output regulation. Rule out the cable/connector first by re-seating, then swap with a known-good M50S-spec PSU. Critical: M30S and APW-series PSUs are NOT cross-compatible with M50S - different ceiling, different firmware handshake; using the wrong PSU trips code 201 (Power supply and configuration file mismatch).

9

Power off at the breaker and re-torque the copper busbar screws between PSU and hashboards to approximately 3.5 Nm (verify against MicroBT service bulletin for your exact revision). Loose busbar contact is an overlooked cause of apparent power-limit faults: contact resistance creates a small voltage drop, the governor compensates with more current, and the limit trips. Use a proper calibrated torque driver, not feel. Inspect each busbar face for oxidation or pitting while it is apart.

10

Reset the power_limit value via the MinerTool TCP 4028 API (or the dashboard power-limit field, if exposed) to the factory default for your target power mode. If anyone ever issued a set_power_limit command, or imported a config from another rig or model, that nvram value persists across firmware updates and silently caps the miner below nameplate. This is a single-line fix for the 'stuck at below-nameplate hashrate' flavour of this error.

11

Swap the PSU with a known-good M50S-spec unit. If the power-limit codes clear, your original PSU had internal sensor drift or a regulation fault that a field multimeter could not easily catch. Log the failing PSU's serial and consider shipping it to D-Central for a bench post-mortem - that data helps track MicroBT PSU failure patterns across the Canadian fleet. Expect to pay $200-$500 CAD for a new or secondary-market M50S PSU depending on availability and condition.

12

Re-apply thermal paste on all 198 chips across the three hashboards. Remove the heatsinks, clean old paste with 99% IPA and lint-free wipes, apply a uniform thin layer of Arctic MX-6 or Thermal Grizzly Kryonaut, and replace any compressed-looking thermal pads on the spacers. Dried paste raises per-chip Tj, which raises per-chip current draw at the same frequency, which pushes the governor into limit territory. This alone clears roughly half the 'power-limit + aging board' cases seen on the D-Central bench.

13

From your api.log per-chip dump, identify any chip drawing current out of family with its siblings or running consistently hotter. Reflow it: flux the BGA, preheat bottom side to ~150 C, top-side hot air at 310-330 C for approximately 30 seconds, let cool naturally, re-paste, reassemble. SM3H packages tolerate one reflow cycle well. A second reflow on the same chip rarely helps - at that point you are replacing the chip via a D-Central bench repair.

14

Visually inspect the voltage-domain MLCCs and electrolytic capacitors on the high-current board. Bulging electrolytics, cracked MLCCs, discoloration around the DC-DC converter, or any burnt-component odor = replace the caps before you re-flash, re-ramp, or power-cycle anything further. Continuing to run High Performance on a cap-damaged board accelerates the damage and risks taking out the PSU - a $200+ failure from a $5 part. Soldering-iron and hot-air work, not a reflow job.

15

Flash the last-known-good BTminer firmware for your exact M50S hardware revision. MicroBT publishes per-revision firmware on support.whatsminer.com - verify the signature (enforced on M50S/M60S generations), and confirm the build matches your revision exactly. Do not cross-flash M50S+ firmware onto an M50S - it bricks the control board. After the flash, reset the power_limit to factory default again, as some firmware updates re-import the previous value.

16

Stop DIY and book a D-Central ASIC Repair slot when: (a) a PSU swap did not clear codes and DC rail is within spec under load, pointing at hashboard voltage-domain failure, (b) visible cap damage, discoloration, or burnt-component odor anywhere, (c) a chip reflow cleared codes but they returned on the same position within 30 days, or (d) api.log shows severe chip-bin mismatch across boards and you cannot source matched-bin replacements. You are now in test-fixture territory - further DIY risks damaging adjacent components and wasting money.

17

D-Central bench process for M50S power-limit faults: test fixture with programmable DC load, BTminer debug build that exposes per-board and per-chip current draw at multiple frequency setpoints, PSU pad tester with calibrated sensor comparison (catches the sensor-drift failures a field multimeter cannot), SM3H chip replacement from bin-matched graded inventory, full reflow and re-seal, and 24-hour burn-in at the power mode you actually intend to run - not just Normal. We test at High Performance if that is your operating target.

18

Ship hashboards and the PSU (both, if the PSU is suspect) in anti-static bags, double-boxed with at least 5 cm of foam on every side. Include the power.log, api.log, miner.log, and system.log you exported in Step 4, plus a note with observed symptoms, firmware build, power mode at failure, intake/ambient temperature range, and your wall-plug power-meter readings. This saves D-Central diagnostic time, which saves you money on your invoice. Canada-wide shipping, 5-10 business days turnaround, US and international welcomed.

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.