Avalon 1566 – PSU Not Detected

Hard-power-cycle at the PDU for a full `60 seconds`. Not a Web UI reboot — a true AC disconnect at the breaker or PDU. Wait the full minute for the PSU's input bulk caps and the PSU MCU's latch state to fully drain. Power back up and watch for the dashboard to update from `PSU: not detected` to `PSU: OK` within the first `90 seconds`. This recovers a non-trivial fraction of `A1566_PSU_FAIL` tickets caused by a brownout-induced PSU MCU latch, a wedged AUC4 USB enumeration, or a corrupted MM firmware state. While waiting, listen for the PSU input fan to briefly spin and watch the AUC4 LED through the chassis cutout — those observations route the next steps.

Read the AUC4 LED state during boot. The AUC4 daughterboard carries a small status LED visible through a chassis cutout on the 1566. Solid green = AUC4 alive, USB OK, PMBus to PSU OK; fault is downstream in MM firmware itself (Tier 2 firmware re-flash). Slow blink amber = AUC4 alive, USB OK, PMBus negotiation failing — focus on PSU side. Solid red or rapid red blink = AUC4 silicon in fault — needs replacement (Tier 2 donor swap). Off entirely = AUC4 unpowered; housekeeping rail or USB cable is dead (Tier 2 reseat). Photograph the LED state for your service log — it's the highest-value piece of context you can give a remote diagnostic.

Pull `dmesg` and the MM log over SSH. SSH into the controller (default IP via DHCP table; default credentials per Canaan support docs). `dmesg | grep -i usb` reveals the AUC4's USB enumeration history. `cat /tmp/log/log | grep -iE "auc4|pmbus|psu|A1566_PSU_FAIL"` reveals the MM firmware's view of the PSU enumeration sequence. The log tells you which of the five failure buckets is active before you open the chassis — USB enum fail = cable, no PMBus ack = PSU side, identity mismatch = wrong-family PSU, OCP/OVP latched = PSU output stage, no enumeration attempts at all = MM control-board USB host. Let the log route the triage.

Confirm recent service and firmware-change history. An `A1566_PSU_FAIL` three days after a chassis re-rack is almost always a loose AUC4 USB cable (Tier 2 reseat). An `A1566_PSU_FAIL` right after a firmware flash is an MM image that didn't take cleanly (Tier 2 re-flash). An `A1566_PSU_FAIL` right after a PSU swap is a wrong-family PSU (Tier 2 verify-PSU-compatibility). An `A1566_PSU_FAIL` out of the blue after months of stable mining is most likely a PSU MCU latch from a brownout (60-second AC removal usually clears it), or a genuine AUC4 silicon failure (Tier 2 donor swap).

Verify intake ambient and PSU exhaust path. Per Canaan's published A15 envelope, intake should be at or below `~35°C`. The 1566 PSU's MCU has its own thermal-protection latch separate from the chassis fan curve; a poorly-ducted hot-aisle that recirculates PSU exhaust into PSU intake can trip the MCU latch even when chassis intake reads OK. Measure intake ambient with an IR thermometer at the intake grille — not at room-middle. Confirm PSU exhaust has a clean path to outdoors / to a hot-aisle / to the rest of the room.

Hard power-down and reseat the AUC4 USB cable + AUC4-to-PSU PMBus ribbon + `12V` lugs. Kill AC at the PDU. Wait the full `15 minutes` for PSU input bulk caps and PSU MCU latch state to drain. Open the top cover. Disconnect the AUC4's internal USB cable at both ends; inspect for kinks, strain, partial unseat; reseat firmly. Disconnect the AUC4-to-PSU PMBus ribbon; inspect for bent pins or oxidation; reseat firmly. Loosen, IPA-clean, and re-torque the `12V` DC copper lugs (community torque `1.2 – 1.5 Nm`; Canaan publishes no spec). Cable-tie the AUC4 USB cable to the chassis frame so vibration cannot work it loose again.

DMM-verify controller `5V` standby at the AUC4 USB port. Power down. Disconnect the AUC4 USB cable from the controller side. Apply AC. Probe DC between USB pin 1 (`VBUS`) and pin 4 (`GND`) on the controller's USB port. Expect `~5.0 V`. `~5V` present = the controller is providing power; the AUC4 is the dead unit. `0V` = the controller's USB host `5V` regulator is dead; this is an MM control-board failure (Tier 4 ship to D-Central). This is the cleanest single test that splits 'AUC4 dead' from 'controller USB host dead' — both look like AUC4 LED off from the chassis cutout.

Donor AUC4 swap from a sibling 1566. If Step 7 confirmed controller `5V` is healthy and AUC4 LED is still off / red / rapid-red-blink, swap the AUC4 daughterboard with a known-good unit from a sibling 1566. **Critical: the AUC4 is *not* compatible with AUC3 chassis** (1246 / 1366 / 1466 / earlier) — different silicon, USB-vs-IIC, different pinout. Do not attempt cross-generational swap. If you don't have a sibling 1566, source a replacement AUC4 from the Canaan support portal or D-Central's parts inventory. Solid green within `30 seconds` and PSU enumeration confirms the original AUC4 was the fault.

Re-flash the current factory MM firmware via the Web UI. If AUC4 LED is solid green and `dmesg` + MM log both confirm clean USB + PMBus enumeration but the dashboard still says `PSU: not detected`, MM firmware itself is the suspect. Re-flash the correct current MM image via System → Update, following the D-Central AvalonMiner firmware upgrade guide. **VERIFY the image is for A1566** — cross-flashing a 1466 or 1366 image bricks the control board because Canaan signature-checks per-model, and the 1566 image has additional AUC4-specific signing earlier images lack. Canaan blocks rollback; flash forward only.

Swap to a known-good 1566-compatible Canaan PSU. The 1566 PSU is **A15-generation specific** and is NOT interchangeable with the AUC3-era A1326..A1466 PSU family even though chassis-mount mechanics and `12V` lug pinout look similar — AUC4 USB-PMBus expects a specific Canaan-signed PSU MCU firmware older AUC3-era PSUs don't ship. Verify compatibility against the Canaan support portal or your purchase paperwork. Power up; watch for dashboard to flip from `PSU: not detected` to `PSU: OK` within `90 seconds`. **Do not cross-connect a Bitmain `APW`-series PSU** — pinouts differ and wrong-brand PSU on a 1566 can damage both the AUC4 and the MM control board on power-on.

`15-minute` AC removal to clear a latched PSU MCU. If `dmesg` showed `psu: ovp/ocp/otp latched` in Step 3, the PSU MCU is in a sticky protection state from a previous trip event. Kill AC at the PDU. Wait a full `15 minutes` (the PSU's input housekeeping cap holds the MCU latch state surprisingly long). Re-apply AC. The MCU should boot fresh, PMBus enumeration should complete, and the dashboard should flip to `PSU: OK`. If the latch returns within hours of clearing, the PSU has an underlying fault (Tier 3 component-level inspection or Tier 4 ship).

Capture the MM control-board serial log via USB-TTL. Connect a USB-TTL serial adapter (`FT232` / `CH340` / `CP2102`) to the MM control board's UART header (location varies by MM revision — check silkscreen). Capture the full boot log at the documented baud rate. The serial log captures kernel-level USB host errors that `dmesg` over SSH cannot reach if the network stack hasn't started — `dwc2: enumeration failed`, `dwc_otg: host channel error`, USB-PHY init failures, AUC4-specific USB enumeration retries. Highest-value diagnostic when AUC4 LED is off and controller `5V` is unclear.

Scope the AUC4 USB-host `5V` rail under load. A 50-MHz handheld scope on the controller's USB-port `VBUS` pin captures the `5V` rail behaviour during AUC4 enumeration. Healthy: clean `0 → 5V` ramp at AC power-on, flat at `5V` thereafter with `<100 mV` ripple. Damaged controller `5V` reg: oscillation, sag below `4.5V` under load, incomplete ramp. Damaged AUC4 short-circuit: `5V` collapses as soon as AUC4 cable is connected (cable-removal test: `5V` returns to spec = AUC4 shorted; `5V` stays sagged = controller `5V` reg is the failure).

Inspect the AUC4 daughterboard under magnification. With AUC4 removed, inspect under bright light at 5-10× magnification: USB connector for bent pins or solder fractures from cable strain, PMBus connector for the same, USB-to-PMBus bridge IC for any visible heat damage or discoloration, support passives for cracked MLCCs or bulging electrolytics, silkscreen near the bridge IC for evidence of past surge events. A surge-damaged AUC4 typically shows discoloration on the silkscreen near the bridge IC's `5V` input pin or on the `12V` PMBus side. Photograph findings; if visible damage is present, the AUC4 is replace-only at home.

Verify PMBus signal integrity at the AUC4-to-PSU ribbon with a scope. With AC applied, AUC4 LED in amber-blink, probe PMBus `SCL` and `SDA` lines at the ribbon connector on the AUC4 side. Healthy: clean `~3.3 V` square-wave activity on both lines during PMBus enumeration sweep, no excessive ringing or DC offset. Marginal cable: ringing, slow rise / fall edges, DC offset. Dead PSU MCU: `SCL` clocks normally (AUC4 is master) but `SDA` shows no slave-side activity (no PMBus replies from PSU). Splits cable failures from PSU MCU failures cleanly.

Inspect PSU output-side bulk caps and current-sense resistors. With AC removed and `15-minute` drain complete, open the PSU (warranty implications — confirm before proceeding). Inspect output-side bulk electrolytic capacitors for bulging, leaking, or visible age. Inspect current-sense resistors on each `12V` output channel for discoloration, cracking, or solder-joint fatigue. A failed current-sense resistor latches the OCP comparator and produces a sticky OCP latch on every power-on that an external `15-minute` AC removal can't clear. PSU bench work involves charged HV-side caps; identification at home is fine, replacement is D-Central job.

Donor MM control-board swap from a parts-graded 1566. If Step 7 confirmed controller `5V` is dead, the MM control board's USB host stage has failed. A parts-graded 1566 MM control board from D-Central's repair-queue salvage inventory is a valid swap-out, but the swap requires Canaan-signed firmware re-flashing for the new board and a full chassis re-pairing with the AUC4. This is bench territory — the swap is mechanically straightforward but the firmware-pairing dance is fiddly enough that we recommend D-Central handle it.

Stop DIY when Tier 2 PSU swap, AUC4 swap, MM firmware re-flash, and AC-removal clear all fail. The fault has narrowed to one of: AUC4 silicon damage with no available donor, MM control-board USB host failure (controller `5V` reg or USB-host IC), PSU MCU silicon failure with output-stage damage, or MM control-board eMMC corruption blocking even a recovery flash. All four are bench-level repairs requiring parts-graded inventory, programmable load fixtures, and burn-in capability. Shotgun-replacing parts at home rarely lands on a 1566.

Stop DIY when multiple 1566 chassis in the same fleet show identical `A1566_PSU_FAIL` patterns. A fleet-wide pattern means a feeder event (surge, brownout recovery, lightning-induced transient) simultaneously damaged the AUC4 stages or MM control-board USB hosts across the fleet. That is fleet-level triage: feeder inspection, surge-protection upgrade, AUC4 inventory check, MM control-board surge-input-stage inspection per chassis, and a coordinated repair-vs-replace decision across the fleet. D-Central handles fleet-level work — send the chassis as a batch and we'll cross-reference the failure patterns against our repair-queue logs from other 1566 fleet operators.

Stop DIY when the PSU is suspected fully dead and you don't have a known-good 1566-compatible donor. A1566-compatible PSUs are still scarce on the secondary market relative to the AUC3-era A1326..A1466 PSU family — the 1566 platform is current-gen and the A15-generation PSU MCU is Canaan-signed, so unbranded clones don't work. D-Central carries graded-salvage 1566 PSUs and can quote replace-vs-bench-repair honestly based on the failure mode. PSU bench repair on a 1566 PSU is component-level work on a charged HV-side; do not attempt at home unless you specifically have HV-rated tooling.

Ship the miner properly. Pack the chassis in its original Canaan box if you still have it, or double-box with `5cm+` foam on every side. Include the PSU and the AUC4 — a tired PSU or a marginal AUC4 that mostly works on your bench may be the root cause, and we can only diagnose if we can reproduce. Include a note with: serial number, observed symptoms (screenshots of `PSU: not detected` dashboard, captured `dmesg` USB lines, captured `/tmp/log/log` `auc4`/`pmbus` lines, AUC4 LED state photographs), service history (when opened, what was reseated, firmware flashes in the last 30 days, any PSU or AUC4 swaps), and contact info.

Discuss repair-vs-replace up front. A full 1566 controller-side bench rebuild (AUC4 swap + USB-host reg replacement on the MM control board if needed + PSU bench inspection + Canaan-signed firmware re-pair + post-repair burn-in at nameplate `~185 TH/s`) runs `CAD $400 – $1,200` depending on what we find. A used 1566 on the secondary market in late 2025 / early 2026 runs roughly `CAD $3,000 – $5,500+` depending on bin and condition. The repair math heavily favours repair on a 1566 — even a controller-side rebuild plus a graded-salvage PSU replacement is a fraction of replacement cost. D-Central quotes honestly before committing bench hours.