Whatsminer – LED Status Code Reference

Read the LED cadence and write it down. Stand in front of the miner and watch the LED for 30 seconds. Time blinks per second against a stopwatch or phone clock — slow (~1 Hz) vs fast (~2-4 Hz) is the single most important distinction. Note the colour (red/amber/green/off) and any secondary LEDs on the control-board face. This is the most-skipped step on remote-diagnostic tickets; operators consistently misreport cadence from memory. Match against the colour × cadence matrix before touching anything.

Wait out the boot sequence. If the LED is slow-green-blinking and the miner was just powered on, it is in `BOOT` / `RAMP` state. Whatsminer firmware takes 2-5 minutes for full boot, hashboard enumeration, frequency ramp, and pool connection. Hydro-cooled M53/M56/M63/M66 units delay ramp until coolant passes 10 °C — in a cold ambient room this can push first-hash to 15-20 minutes. If you're still inside that window, wait. Come back and re-check cadence after the window closes. Don't yank cables on a miner that is booting correctly.

Hard power cycle at the breaker, 60 seconds off. Not a soft restart — the control-board watchdog and PSU latch both need full rail discharge to release a wedged fault state. After 60 seconds off, power on and observe the LED for the first 90 seconds. Roughly one in five warning-state LEDs and one in seven critical-state LEDs clear on a clean cold boot after a brownout, grid event, or firmware upgrade. Soft-reset does not discharge the watchdog — the breaker cycle is specifically required.

Verify the miner appears in WhatsminerTool IPFOUND scan. Launch current WhatsminerTool on a laptop on the same subnet. Run IPFOUND. The miner should appear within 10 seconds. Appearance confirms control board is alive and network stack is up — immediately narrows the fault to hashboard, PSU, thermal, or pool/stratum. No appearance confirms the fault is at control-board or network layer; proceed to Step 9 for direct-cable test. Either outcome changes next steps significantly.

Use the Traffic Light Flash feature in a multi-miner room. If you're in a farm or workshop with multiple Whatsminers and aren't 100% certain which chassis corresponds to the pattern you're troubleshooting, right-click the miner in WhatsminerTool and select `Traffic Light Flash`. Target unit flashes its LED in an identification burst (three amber flashes, pause, repeat) for 30-60 seconds. Eliminates working on the wrong miner — a mistake that has cost D-Central bench techs multiple hours of chasing ghosts. Do this ID step every time.

Export the log bundle via WhatsminerTool. Right-click the miner → `Remote Ctrl` → `ExportLog`. Retrieve five files: `miner.log`, `system.log`, `power.log`, `api.log`, `upfreq_test.log`. Open each in a text editor and search for `code=`, `fault:`, `error_code=`, or any `0x` hex string. The numeric code you find is the actual diagnosis; the LED just told you the severity class. Cross-reference against the code-to-LED table to identify the correct subsystem workflow. Five minutes of work that typically turns 'red LED, no idea' into 'code 263 on the PSU, check input voltage.'

Measure line voltage at the outlet under load with a multimeter. Reading at idle (miner off) should be `235-245 V` on 240 V split-phase or `202-212 V` on 208 V commercial. Take a second reading during ramp (miner booting, partial load) — voltage should drop no more than 5 V on 240 V or 4 V on 208 V. Sag below `220 V` on a 240 V circuit under load indicates undersized wiring, loose breaker crimp, or marginal PDU. Fix the electrical side before blaming the miner — weak circuits alone will trigger fast-red PSU fault codes repeatedly.

Re-seat every cable connection. Power off at the breaker. Remove the top cover (Phillips #2, typically six screws). Re-seat: every hashboard ribbon at both hashboard and control-board ends; the PSU-to-control-board signal cable (multi-pin harness, not the DC bus bars); the PSU DC output lugs to hashboards — visually inspect for discolouration, brown heat marks, or melted insulation. Any visible heat damage, stop and escalate to Tier 4. Reassemble, power on, observe LED for 90 seconds. Re-seat alone resolves roughly 15-20% of fault-state tickets on the D-Central bench — vibration walks Whatsminer ribbons loose over time.

Direct-cable network test. If the miner doesn't appear in WhatsminerTool IPFOUND, plug a laptop directly into the miner's Ethernet port with a known-good cable. Configure laptop NIC for DHCP. Run IPFOUND from the laptop. Appearance = upstream network issue (managed switch, VLAN, PDU-integrated switch, DHCP server). No appearance + link LED off = control-board PHY dead or firmware never reached network init. No appearance + link LED on = firmware hanging before the Whatsminer management daemon starts. Both point at control-board or firmware work, not network.

Swap PSU with a known-good unit (same model family). On multi-miner sites, pull a PSU from a healthy miner and swap it into the faulty one. Whatsminer PSUs are factory-matched and not universally interchangeable — confirm matching part numbers (`P221B`/`P222B` for M30S family, `P22C` for M50S family). LED clears with known-good PSU = PSU failure confirmed; order correct replacement. LED still fast-red with known-good PSU = fault is not in the PSU, return the donor. This single swap eliminates multiple hours of guesswork on PSU-suspect tickets.

Hold RESET for exactly 3 seconds (only if LED is slow-red and logs point at network/pool/config, not fast-red). Power the miner on, wait for boot completion (LED stops slow-green-blinking), then press and hold `RESET` for exactly 3 seconds. LED enters alternating red-green flicker during the reset. Release at 3 seconds. Miner reboots, comes up with DHCP enabled, re-acquires network config fresh. Do NOT use this during fast-red — it wipes config without fixing the underlying critical fault, escalating a recoverable issue into a bench trip.

Pull hashboards one at a time to isolate a bad board. Power off. Remove one hashboard (note the slot — typically numbered 1/2/3 from left). Power on with two boards installed. LED clears = removed board is faulty, stop here. LED still fast-red = power off, re-install that board, remove the next. Repeat until a single failing board is identified, or all three are confirmed healthy and the fault is control-board or PSU. Miner won't hash with fewer than 3 boards, but boot completes and the LED pattern exposes the isolation — that's enough to narrow the diagnosis.

Flash stock firmware via MicroSD recovery. Download the correct image for your exact model from the MicroBT portal — M30S, M30S+, and M30S++ firmware are not interchangeable, mismatch triggers `code=8410`. Write to MicroSD with Etcher or Win32DiskImager. Power off. Insert MicroSD into the control-board slot. Power on holding `RESET` per the model-specific recovery procedure. LED goes through recovery-flash sequence (alternating green/amber, then slow green when complete). Wait the full 10-15 minutes — interrupting mid-write is a reliable way to brick the EMMC. Remove MicroSD, reboot.

Clear anti-tamper (`100001`/`100002`/`100003`) traps with full EMMC format. If LED is fast-red and logs show integrity codes, and the miner has a history of custom firmware (Vnish, Asicdip, HiveOS, jailbroken builds), a simple re-flash often doesn't clear it — partial custom binaries survive on EMMC and fail the next integrity check. Only reliable fix: full EMMC format via MicroSD recovery (select full-format option, not default upgrade), then stock flash. Warning: on some factory-custom-firmware M50/M60 units (Asicdip partners), re-flashing stock after full format hard-bricks — signing keys don't match. Confirm factory origin before attempting.

Refresh hashboard thermal paste. If LED is slow-red or amber with thermal-sensor codes (`300`-`352`, `600`-`610`) and ambient, airflow, and intake are within spec, suspect dried paste on hashboard ASICs. Whatsminer ASIC paste ages in 18-30 months of continuous duty; a 3+ year M30S is overdue. Pull the hashboard, unscrew the heatsink, clean old paste with 99% IPA and lint-free wipes, apply a fresh thin layer of Arctic MX-6 / Thermal Grizzly Kryonaut (no generic drugstore paste). Reassemble, reinstall, boot. Thermal sensor readings typically drop 8-15 °C after a proper re-paste.

Check control-board EMMC integrity. If recovery flash fails repeatedly or boots that worked yesterday stop working overnight, suspect EMMC wear-out. Whatsminer control boards run ARM Linux on onboard EMMC; 3-5 years of continuous writes hit wear-leveling exhaustion. Signs: recovery flash completes but reboot returns to fast-red, filesystem errors in `system.log`, RTC drift indicating NVRAM corruption. No field-serviceable fix — EMMC is soldered. Control-board replacement is the remedy; book via D-Central ASIC Repair. Don't keep wasting MicroSDs on a worn-out EMMC.

Cross-reference PSU hex codes against rail measurements. If `power.log` shows `0x0001`-`0x2000` alongside fast-red LED, map hex ranges: `0x0001`-`0x00FF` = input-side (line voltage, input fuse, rectifier); `0x0100`-`0x0FFF` = conversion-side (PFC, transformer, PMBus); `0x1000`-`0x2000` = output-side (regulators, caps, current sensors). Measure rails under load: main 12 V bus `12.0-12.6 V` static and `11.6-12.4 V` under load; 5 V standby `4.95-5.15 V` always. Rails out of window confirm PSU failure — replace. MicroBT doesn't publish this hex-to-root-cause mapping; D-Central internal data.

Ship to D-Central for bench repair. When to stop: LED stays fast-red after Tier 1-3 exhausted; visible damage (burns, swollen caps, blown fuses); PSU rails fail verification with a known-good PSU; EMMC recovery fails on multiple MicroSDs; `100001`-`100003` traps on factory-custom units where stock flash risks hard-brick; chassis smell of ozone or hot electronics. Ship with a complete ticket: exact model, firmware version, LED cadence and colour observed, log bundle, photos of any damage, history of custom firmware, known grid events. Book via D-Central ASIC Repair. Turnaround is 5-10 days on M30S/M50S, 7-14 days on M60S/M63/M66.