Whatsminer Error 301 – Hashboard SM1 Temperature Sensor Failure
Critical — Immediate action required
Symptoms
- BTMiner web UI displays `Error Code 301` with message similar to `SM1 temp sensor fail` or `hashboard 1 temp read failed`
- Miner status page shows only two hashboards hashing (slot-0 and slot-2) — middle slot reads `0 MHS` or `offline`
- Total hashrate drops to ~66 % of nameplate — e.g. M30S reads 56 TH/s instead of 88 TH/s
- Red LED or red/orange blink pattern on the control board (model-specific code)
- `btminer_log` or `kern.log` shows repeated `i2c_nak on bus-1`, `temp_sensor read timeout SM1`, or `hashboard1 sensor fail` every 5-30 s
- Telnet port 4028 `{"cmd":"devdetails"}` returns `Temp` fields of `0`, `-40`, or `255` for the SM1 position
- Fault persists across reboots and firmware restarts — a power cycle does not clear it for more than minutes
- Problem appeared immediately after a firmware upgrade, physical relocation, or a Whatsminer-tool re-provision
- Slots 0 (SM0) and 2 (SM2) run at full spec hashrate and pass sensor reads cleanly
- MinerTool / WhatsMinerTool reports `hashboard1` status as `error` or `offline` while slots 0 and 2 are `normal`
- Physical inspection shows discoloration, cracked MLCC, or scorched spot near the I2C sensor footprint on the middle hashboard
- Fault follows the board when swapped into slot-0 or slot-2 (board-side), or stays in slot-1 (control-path)
Step-by-Step Fix
Hard power-cycle at the breaker for a full 60 seconds — breaker off, cap drain, then power on. BTMiner caches sensor-fail state in non-volatile memory on some firmware versions, and a soft restart sometimes carries `Error 301` across the reboot even after the underlying cause has cleared. Watch the first 5 minutes of status output after power-up. This alone clears roughly 8-12 % of tickets in D-Central's MicroBT queue — typically the ones caused by transient firmware glitches or line-voltage events.
Verify the miner sits on a stable 240 V circuit with adequate breaker headroom. Whatsminers are notoriously picky about line voltage — below `215 V` sustained at the socket under load you get cascading I2C errors as the control-board rail sags. Check with a voltmeter while hashing. Anything under `225 V` sustained means the circuit is marginal; a dedicated 30 A 240 V run is the right long-term fix. Not a direct cause, but the environment that lets Error 301 fire from an otherwise-marginal hardware condition.
Restart via the web UI rather than just pulling the plug. Some sensor-path glitches clear on a firmware-side reboot that don't clear on a cold cap-drain, because the bus init sequencing differs. Log in, issue a clean firmware restart, wait for full re-boot, re-check status.
Check the top-cover screws — did you recently open the miner? A top cover re-installed off-square pinches the SM1 data ribbon against the chassis lip. It's the embarrassing cause of Error 301 that appears right after a maintenance session. Loosen the top cover screws, slide the cover back `5 mm`, re-tighten. Cost: two minutes, zero dollars. Worth doing before any tool comes out.
Confirm ambient is below `35 °C` at the intake grille, ideally below `30 °C`. Not directly Error 301-causing, but a hot-ambient install stresses the LM75 sensor's own power dissipation and tips marginal sensors into NAK territory. Move the miner, add airflow, or crack a window before chasing component failures. IR gun at the front face is more accurate than a room thermometer.
Pop the top cover and re-seat the SM1 data ribbon. Breaker off, wait 5 minutes. Unscrew the cover carefully. Locate the three hashboard ribbons — SM1 is the middle. Unplug at BOTH ends (control-board and hashboard sides), inspect IDC contacts for oxidation or dust, blow out with compressed air, reconnect firmly until latches click. Close up, power on, re-test. Simple re-seating clears a meaningful percentage of Error 301 tickets on miners healthy before transport.
Replace the SM1 data ribbon with a known-good spare. If re-seating didn't clear it, swap the cable. MicroBT-spec ribbons come from Zeus, D-Central, and parts resellers — specify your exact model (M30S, M31S, M50, M60) because ribbon length and connector pinout vary between generations. Do NOT assume universal fit. Route the new cable along the chassis channel carefully; do not pinch under the hashboard on re-seat. Cost: `$10 - $30 CAD`.
Re-torque the 12V bus-bar M4 nuts on the middle hashboard. Power off, caps drained. Use a torque driver set to `1.0 - 1.5 Nm` (confirm against a calibrated reference if possible). Loose bus-bars develop a high-resistance joint that sags under load, pulls the I2C pull-up rail below spec, and kills the sensor. If you see black oxidation or green corrosion at the contact, clean with a fibreglass pen and a drop of contact cleaner before re-torquing.
Swap SM1 into a different slot to isolate board vs control-path. Power off. Label slots 0/1/2. Lift SM1, physically move it into slot-0 or slot-2. Return the original slot-0 or slot-2 board into slot-1. Power on, wait 5 minutes, re-pull `devdetails`. If the error becomes Error 300 or 302 (follows the board), the board itself is at fault — go to Tier 3. If Error 301 persists with a known-good board in slot-1, the control-board I2C path is at fault — Tier 3/4 control-board work.
Firmware version audit and downgrade via MinerTool if warranted. Pull the exact BTMiner version via the web UI or `{"cmd":"summary"}` over port 4028. Cross-check against altairtech.io and the WhatsMinerTool release notes for this model and chip bin. If your version matches a known SM1 sensor-poll regression, use MinerTool to flash the last known-good build. Back up your config before flashing. Rare but real fix — two specific mid-2022 and mid-2023 builds are community-tagged as regression-prone for the `30x` cluster.
SD-card recovery boot to install a known-good firmware. If MinerTool update failed or the control board is stuck in a boot loop near the Error 301 fault, use the MicroBT SD-card bootloader recovery procedure. Image a MicroSD with the MicroBT-supplied recovery firmware for your exact model (wrong firmware bricks the miner — verify model and chip bin). Insert, power on, wait for the recovery LED sequence, remove card, reboot into the fresh firmware. This is the escape hatch when the miner won't accept a network firmware update.
Scope the I2C bus to confirm sensor vs pull-up vs bus-driver failure. Bench oscilloscope or USB logic analyzer (Saleae Logic 8 etc.) on SDA and SCL at the middle-hashboard connector while the miner flags Error 301. Healthy SMBus poll: clean `0-3.3 V` pulses every few seconds during the poll window. Bus stuck at `3.3 V` during poll = no device responding, sensor dead or disconnected. Bus floating mid-rail = pull-up open-circuit. Bus stuck at `0 V` = short-circuit, usually blown TVS or water-damage residue.
Replace the LM75 / TMP75 sensor on the hashboard. SOIC-8 footprint rework: preheat board to `140-150 °C`, hot-air old sensor off at `310-330 °C` for ~30 s, clean footprint with IPA and lint-free wipe, place new sensor respecting I2C address-strap pins (do not swap pin 1), reflow, natural cool-down. Re-install and re-test. Bench territory — a first reflow by a newcomer is a coin flip on whether the board survives. Practise on a dead board first.
Replace blown I2C pull-up resistors or TVS/ESD diodes. 0402 or 0603 passives on the hashboard's I2C network. Reference ohmmeter measurements from the bus diagnosis step to confirm which component is bad. Replacement is routine SMD rework. Match the original value (`2.2 kΩ` or `4.7 kΩ` pull-up typical, TVS rating depends on generation — verify against a known-good board before ordering).
Control-board I2C mux replacement when the fault stays in slot-1 with a known-good board. If swap-testing confirmed control-board side, the I2C mux IC (PCA9548 family or similar) or its channel-1 output driver is the likely suspect. QFN rework, bench-level job with proper preheat and hot air. Confirm exact part number from the silkscreen before ordering replacement — MicroBT has used different mux parts across generations.
Stop DIY and book a D-Central ASIC Repair slot when any of these are true: Tier 2 cable swap didn't clear it and you lack scope access; visible capacitor bulging, cracked MLCCs, or burnt-component smell near SM1; control-board swap-test confirmed a control-path fault but you lack QFN rework skills; SD-card recovery failed or bricked the miner; hydro/immersion variant with any coolant-intrusion risk; newer M60S+/M66/M66S and no chip-bin-matched sensors on hand; or Tier 3 fix that failed within 30 days. Book at d-central.tech/services/asic-repair/ — Canadian bench, 5-10 business day turnaround, Canada/US/international.
D-Central bench process on an Error 301 case: test-fixture boot of the suspect hashboard with known-good control board and programmable PSU load, chip-count and temp-sensor validation across the full I2C address range, scope trace on SDA/SCL during firmware poll windows, component-level isolation between sensor / pull-up / TVS / footprint damage. Confirmed dead sensor gets matched-generation LM75 / TMP75 replacement with proper reflow profile; confirmed pull-up or TVS failure gets matching passive replacement. Every repaired board runs a 24-hour burn-in at nameplate before return shipping.
Ship safely. Hashboards and control boards in anti-static bags, double-boxed with `>=5 cm` of foam on every side. Include a physical note inside with: full devdetails/summary API dump from the baseline capture, firmware version, model and chip-bin from the miner label, install date, most recent firmware update date, ambient at the install, and which Tier 1-3 steps you've completed plus contact info. A well-documented ship-in saves real dollars — it lets the bench prioritize actual root cause rather than re-running your known-good diagnostics.
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.
