Antminer – LED Indicator Red Solid

Hard power-cycle at the PDU for `60 seconds` — not a web-UI soft reboot. A full mechanical disconnect long enough for the control-board filter capacitors to discharge. This clears wedged firmware state, DHCP lease expiry, stratum hangs carried over a brownout, and transient sensor glitches. Time the LED sequence on the way back up with a stopwatch — LED-transition timing is more diagnostic than any log line when the UI is unreachable. Healthy: both LEDs on for ~2 s (lamp test), red extinguishes within ~30 s, green starts flashing at ~2 Hz when stratum binds. If red stays on, the fault is real.

Read the web UI error banner. If the UI loads, navigate to Miner Status → System and capture the exact error string (`ERROR_SOC_INIT`, `ERROR_FAN_LOST`, `ERROR_TEMP_TOO_HIGH`, `ERROR_POWER_LOST`). Screenshot it. The error name tells you which bucket you're in and which Tier-2 step to run first. Skipping this means doing Tier-2 blind. If the UI is unreachable, that's itself a data point — it routes you to Step 7 (control-board recovery).

Verify ambient temperature at the intake. IR thermometer or hand check at the front grille — not the middle of the room. Target ≤ 35 °C for standard S19 / S21, ≤ 40 °C for Hydro. Dust on filters, curtains, or a summer garage warming up by 5 °C is enough to trip `ERROR_TEMP_TOO_HIGH` on a marginally-tuned miner. Shop-vac the intake filter, verify nothing is within 15 cm of the front grille, confirm room ventilation. A miner fine in October and red in July is almost always ambient, not hardware.

Press the `RESET` button for 5 seconds — factory-reset-to-defaults clears any web-UI config state that may be blocking boot. On S19-class the button is recessed on the control board next to the RJ45. This does not re-flash firmware — it only clears user config. If the red LED persists after reset, the fault is real and Tier-2 is the next step. Useful mainly after a failed custom-firmware flash or a bad tuning profile push.

Check the ethernet link. RJ45 LEDs should show link + activity. No link = cable / switch / router problem independent of the red LED but can mask the real diagnostic (no web UI, no SSH looks like control-board dead). Swap the ethernet cable with a known-good; plug the miner directly into the router / switch to rule out a failing wall jack. 30-second test that eliminates an entire false-positive class.

Measure `+12 V` at the PSU-to-hashboard / PSU-to-control-board connector under load. Multimeter on DC, probe while the miner is in its current state (boot, post-boot, or mid-hash). Expect `11.8 – 12.4 V` sustained on a standard S19. Under `11.5 V` = PSU tired, PSU undersized, cable damaged, or circuit undersized. Also measure AC at the PSU input: `235 – 245 V` on 240 V split-phase, `202 – 212 V` on 208 V commercial. Low line voltage drives PSU sag and this fault.

Re-seat every hashboard data ribbon and power harness. Power off at the breaker. Label the three hashboard slots 0 / 1 / 2 with masking tape before disconnecting anything. Visually inspect every connector for blackening, green oxidation, melted housing, or bent pins. Re-seat firmly until you hear the click. Poor ribbon seat is the single most common cause of `ERROR_SOC_INIT` / `Chain[X] find 0 asic` manifesting as solid red LED. Do not force — if a connector resists, look for a bent pin or broken retention clip.

Swap hashboards between slots to isolate the fault. With boards labelled, move the suspect board to a known-good slot. Power on, observe LED + log. Fault follows the board = bad board. Fault stays in the slot = bad control path (cable, connector, or control board itself). This 2-minute procedure is more diagnostic than anything in Bitmain's official docs — tells you whether to spend bench time on the hashboard or the control path before committing any other work.

Swap the PSU with a known-good unit of the correct model + voltage class. APW3 / APW7 / APW9 / APW12 are not cross-compatible across all miner models — check the compatibility matrix on the Bitmain support site or match by the exact PN sticker. Power-class mismatch (APW3++ feeding an S19 that needs APW12) causes `ERROR_POWER_LOST` identical to a dead PSU. Known-good PSU clears red LED = tired PSU. Known-good PSU also fails = upstream (cable, circuit, breaker). Zeus + BitcoinTalk consensus: PSU fan housekeeping rail is independent of main `+12 V` — 'fan spins = PSU works' is a false test.

Verify fan health on every fan. Four fans on S19 / S21 air-cooled, two on S9 / L3+, coolant loop on Hydro. Visual + audio + tach (if UI reachable). Fan at `0 RPM` or audibly grinding fan trips `ERROR_FAN_LOST`. Replace with matched Bitmain fan or `120 mm` dual-ball-bearing, `6000 RPM`-class equivalent (PWM-controlled, 4-pin header). See related `antminer-fan-blade-damage-noise` and `antminer-fan-rpm-too-low` for model-specific guidance.

Flash DCENT_OS — D-Central's open-source Antminer firmware, the Mining Hackers' option on S9 / S17 / S19 / S19 Pro / S19j / S19j Pro / S19 XP / S21 family. All the per-chip HW%, per-chain enumeration telemetry, explicit boot-state dashboard, tuning, autotuning, and Stratum V2 support of the commercial alternatives; fully open-source, maintained publicly on GitHub, no licensing fees, no vendor lock-in. DCENT_OS surfaces the `bootloader → kernel → userspace → mining-engine → stratum` state boundaries explicitly — the single biggest diagnostic upgrade on a red-LED-on-solid Antminer, because it tells you exactly which stage failed. Alternatives if your hardware isn't yet covered: Braiins OS+, LuxOS, Vnish.

Inspect the control-board `CR2032` RTC battery. On aging Antminers the coin cell drains. Below `2.5 V`, the clock resets to epoch at every power-off; modern pool TLS cert validation fails silently, which on some firmware builds surfaces as solid red LED + `Pool: Dead`. `$2` fix: replace the cell, SSH in, set the clock with `date -s 'YYYY-MM-DD HH:MM:SS'`, configure NTP if available. Pool should clear within minutes. This is the $2 fix Bitmain's surface docs don't mention.

Reflow the worst chip on the suspect hashboard. If DCENT_OS / Braiins OS+ per-chip data isolates a specific chip position driving `reg crc error` or `find 0 asic`, remove the heatsink, apply flux, reflow with preheat + hot air (preheat `150 °C` bottom side, top-side `310 – 330 °C` for ~30 seconds). Let cool naturally, re-apply Arctic MX-6 or Thermal Grizzly Kryonaut, reassemble. BM1398 / BM1362 / BM1368 / BM1393 BGA packages tolerate a reflow cycle well; community data says roughly 30% of 'dead' chips are cold solder joints that one reflow resolves permanently.

Check voltage-domain neighbours of any failing chip (Zeus domino rule). S19-family hashboards run 76 BM1398 chips in 38 voltage domains. One failed chip cascades voltage stress to its domain partner; replacing only the dead chip without inspecting the adjacent one is the most common avoidable repeat-repair on our bench. Thermal-image both positions under load with an IR cam or FLIR ONE — > 5 °C delta vs the rest of the chain means the partner chip is next. Source: Zeus Mining S19 Pro Hashboard Repair Guide.

Inspect PMIC / caps / fuses for visible damage on the hashboard and control board. Look for bulging electrolytics, cracked MLCCs near the PMIC, burnt resistors or fuses, discolouration on PCB near any power path. Any one = stop DIY. You can swap a blown fuse or bulging cap with a soldering iron if you have the exact replacement PN and experience; if not, the board goes to the bench. Do not repeatedly apply power to a board with a suspected short — Zeus Mining's dichotomy-method (break chain at midpoint, measure, halve again) applies.

Stop DIY and book a D-Central ASIC Repair slot when: (a) fault follows the hashboard across slot-swap and re-seating, per-chip data isolates a chip, reflow failed or isn't in your skill set; (b) control board fails to reach userspace (no UI, no SSH) and SD / eMMC reflash doesn't recover it — especially S19 XP / S21 / newer where eMMC + UART recovery is fixture-required; (c) PSU main-rail failure with housekeeping fan spinning; (d) visible damage anywhere; (e) known-good PSU + known-good hashboard swapped in and miner still reads red. Test-fixture territory, DIY upside has run out. Turnaround 5 – 10 business days; Canada / US / international.

D-Central bench process for a `LED_RED` miner: test fixture with programmable load and official Bitmain test binaries; control-board eMMC / SD recovery including UART unlock on S19 XP / S21 / newer; `CR2032` RTC battery replacement and clock oscillator validation; per-chip isolation with the Zeus domino-check (inspect voltage-domain neighbours before returning to service); chip replacement with graded BM1398 / BM1362 / BM1368 / BM1393 salvage or new-old-stock where available; PSU board-level repair (output-cap replacement, secondary rectifier, sense-wire repair) or swap from graded inventory; reflow and re-seal; 24-hour nameplate burn-in before return.

Ship safely. Pack hashboards in anti-static bags, double-box with ≥ 5 cm of foam on every side. Include a note with the exact error string, firmware version, screenshots of the red LED sequence timing, `kern.log` / `messages` excerpts, pool config, and your contact info. Better notes = less bench diagnostic time = lower repair cost. D-Central also accepts full miner chassis; for Hydro variants, drain coolant before shipping and note any leak history.