Whatsminer Error 560-562 – Hashboard Loss of Balance
Warning — Should be addressed soon
Symptoms
- BTMiner log contains repeated `Error Code: 560` (or 561 / 562) entries during steady-state hashing
- API call `{"cmd":"summary"}` on port 4028 reports per-chain `MHS av` where one board is 10-15% below the others
- Web UI dashboard shows three colored bars per board with one visibly shorter, often orange or red
- Realized total hashrate running 5-20% below nameplate as a clean step-down, not random flutter
- MinerTool (WhatsMinerTool) fleet view flags this unit with a 560 / 561 / 562 banner
- Pool rejected-share rate is normal (this is a speed problem on one board, not a wrong-hashes problem)
- Per-board temperature on the flagged board trends 2-5 C cooler than siblings, OR 3-5 C hotter due to firmware overvoltage compensation
- `{"cmd":"devs"}` shows per-chip Frequency varying by more than 50 MHz across the chain on the flagged board
- Problem appeared after a power event, voltage spike, overclock attempt, firmware update, or missed paste-service interval
- Flag affects only one of the three hashboards; the other two report tightly-matched healthy hashrate
- Fan duty has increased on the flagged side without any change in ambient (firmware fighting the imbalance with cooling)
- Chip count via `{"cmd":"devdetails"}` reads full nameplate - this is a performance fault, not a missing-chips fault
Step-by-Step Fix
Hard power-cycle at the PDU for a full 60 seconds: breaker off, capacitors drain, breaker on. A soft reboot can carry stale Error 560 state across; a true cold start clears it and any transient post-firmware-update glitches. Watch the first 15 minutes of BTMiner log via SSH or the web UI log tab. Clears roughly 6% of 560 tickets in D-Central's Whatsminer queue with zero tools and zero risk.
Pull the API baseline. `echo -n '{"cmd":"summary"}' | nc <miner-ip> 4028 > summary-baseline.txt`, then repeat for `{"cmd":"devs"}` and `{"cmd":"devdetails"}`. Save all three to a single file named `<miner-serial>-560-baseline-<date>.txt`. This is the first artifact D-Central's bench asks for if escalation becomes necessary, and doing it yourself makes you a faster customer to help.
Sanity-check firmware variant against hardware variant. Air-cool firmware on an air-cool board, hydro firmware on hydro. Find the model sticker, find the firmware build via web UI or MinerTool, confirm match against support.whatsminer.com. Wrong firmware on the wrong cooling variant produces chronic 560 because per-board tuning targets are structurally wrong. A ten-second check that occasionally is the entire fix.
Reset MinerTool reporting and re-fetch. Some MinerTool builds cache a stale 560 flag and report it past resolution. Disconnect the miner from MinerTool, restart MinerTool, reconnect. If the banner clears, the actual fault was already resolved by an earlier reboot and MinerTool was lying about live state.
Power off at PDU for 5 minutes. Reseat the flagged hashboard fully. Free the fin stack with Torx T8 or T10, label the slot, remove the board, inspect the adapter-plate connector and 12 V (or 14.5 / 15 V) bus contacts for oxidation, black tarnish, bent pins, missing retention screws. Wipe contacts with 99% IPA on a lint-free wipe. Reseat firmly until the latch and every retention screw is fully engaged. Power on, 15 minutes, re-pull `summary`. MicroBT's official 'plug in adapter plate and re-screw hashboard' fix lives here, and it does work when this is the root cause.
Hashboard swap between slots. Power off. Move the flagged board to a different slot, move that slot's board to the original. Power on, wait 15 minutes, pull `summary`. If the slow follows the board to its new slot, the board is the problem. If slow stays in the original slot regardless of which board is in it, the control-board / cable / slot-specific power path is the problem. Highest-information 30-minute diagnostic without a multimeter.
Inspect and replace data cables and ribbon connectors. Power off. Unplug the data ribbon between the control board and the flagged hashboard. Inspect both ends for bent pins, cracked insulation, burn marks. Replace with a known-good spare (d-central.tech/product-category/replacement-parts/ stocks Whatsminer data cables). Reseat firmly. Power on, 15 minutes, re-pull `summary`. Damaged ribbons can produce phantom 560 that intermittently moves between slots as the cable flexes.
Verify PSU output rail under load. Multimeter on DC, probe at the PSU-to-hashboard connector with the miner hashing at full nameplate. Expect the board's designed bus voltage (12 V nominal for M30-series; 14.5 V for M50/M50S+; ~15 V for M60-series - confirm against your model's spec sheet). Reading more than 200 mV below nominal under load = PSU tired or the mains circuit is undersized. Sagging rail produces uniform under-frequency across an entire board, classic Bucket 4 (mechanical / supply) signature.
Reset to factory and run a clean autotune cycle. Via MinerTool or web UI: factory-reset, reflash the exact current stable BTMiner build for your model and cooling variant, boot, let the autotuner run a full cycle (20-40 minutes M30-series, 30-60 minutes M50/M60 depending on chip count). Pull `summary`. Bucket 5 (autotune over-correction after a power event) clears here. If imbalance returns within 30 minutes of a clean autotune, autotune is not the cause.
Compressor-blow the fin stack and hashboard. Miner off, real air compressor at 80-90 PSI, blow from exhaust side back through intake. A dust layer under the heatsink causes a specific chip cluster to throttle on temperature, producing 560 rather than a thermal-sensor fault. Zero-cost step worth doing during any board pull regardless of root cause.
Map per-chip frequency on the slow board. From `{"cmd":"devs"}` on port 4028, list every chip's reported `Frequency`. Three patterns to recognize: scattered slow chips (3-8 chips well below board mean, rest at nameplate) means silicon drift; contiguous block of slow chips matching a domain layout means PMIC / domain failure; uniform low frequency across all chips means bus voltage / mechanical / firmware. The pattern decides whether you reflow specific chips, repair a domain, or chase the supply chain.
Cold-vs-hot frequency comparison. Power off, sit 30 minutes at room temp. Power on, pull `devs` in the first 60 seconds. Hash 30 minutes, pull again. Specific chips' frequencies climbing as the board warms means cold-solder joints (reflow-recoverable). Frequencies staying flat or dropping as the board warms means silicon dying (replacement, not reflow). This 30-minute test splits cases between the $120 reflow bucket and the $300+ replacement bucket with zero tools.
Reflow the suspect chips. Bench-tier work: preheat bottom of the board to 150 C on a preheat station, top-side hot air at 310-330 C for ~30 s centred on each target chip, natural cool-down. Reapply Arctic MX-6 or Kryonaut, reassemble fin stack with even torque. One reflow is routine on BM128x / KS3 / N1 silicon. A second reflow on the same chip within 90 days rarely holds - at that point the chip is dying, not the joint.
Domain voltage probe under load. Multimeter on DC, probe each voltage-domain output stage on the slow board with the miner hashing at full power. Reference your model's teardown thread on bitcointalk.org for probe points. Healthy domains hold target Vcore within ±20 mV across all domains on the board. A single domain reading 30+ mV below the others is the failed-PMIC / failed-domain signature. Also probe the inductor across each phase - a cracked or shorted inductor reads as a sagging domain.
Per-domain component-level repair when Step 14 isolated a failed voltage domain. Bench-tier: inductor replacement, MOSFET swap, PMIC resoldering, matching-spec capacitor replacement (electrolytics + MLCCs near the failed phase). Hot-air rework station, solder paste, flux, known-good replacement parts, matching-spec only. With the skills and parts, $25-$75 in components plus 2 hours of bench time. Without, ship the board to D-Central.
Stop DIY and book a D-Central ASIC Repair slot when any is true: two or more voltage domains have failed on the slow board; reflow attempted and chips re-failed within 30 days; visible capacitor bulging, cracked MLCCs, or burnt-component smell; slot-specific 560 persists after a known-good-control-board swap; per-chip frequency map shows silicon-death pattern across more than 25% of the board; or Tiers 1-3 are complete and the imbalance is unchanged. Book at d-central.tech/services/asic-repair/. Typical turnaround 5-10 business days from Canada / US / international.
D-Central bench process on an Error 560 case: test-fixture boot with programmable load, full per-chip frequency-vs-voltage characterization map, per-domain ripple measurement under load, thermal-camera survey at full hash, UART chain-integrity trace via logic analyzer. Single-chip drift cases get graded-stock chip replacement with proper reflow profile and 24-hour burn-in. Domain-failure cases get matching-spec component repair - not a blanket board swap; we keep your original serial. Mechanical-only cases get connector-and-paste service plus a written report on what was actually wrong.
Ship safely. Hashboard in anti-static bag, double-boxed with at least 5 cm of foam on every side. Include a physical note inside with: full `summary`, `devs`, and `devdetails` dumps from Step 2; BTMiner firmware version + build date; installation date; last paste-refresh date; ambient at install; Tier 1-3 steps completed and outcomes. Every minute the bench spends reconstructing fault history adds to the repair bill. A documented ship-in saves real dollars and real turnaround time.
Decision point when the repair quote exceeds 60% of a refurb hashboard's price: take the refurb. D-Central carries graded refurb boards for most Whatsminer models; the economics favour replace over repair past a certain damage threshold (typically when more than 25% of a board's chips are flagged silicon-dying or two or more domains have failed). Original boards ship to D-Central's R&D stream for component salvage, supporting the next generation of Mining Hacker parts inventory.
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.
