Avalon 1266 – PSU Not Detected

Confirm AUC4 is alive and the symptom matches. Browse http://<miner-ip>/, verify Web UI loads, verify AUC4 status LED is green per the A1066 manual mapping (cross-applies to AUC4 with minor deltas — verify against silkscreen). Verify Web UI status reads 'Power Supply Not Detected' / 'PSU init failed' / 'PMBus handshake timeout' (string varies by MM firmware version). If AUC4 is dark or unreachable, this is the wrong page — branch to Avalon AUC Controller Failure instead. The five-second Web UI check rules out half the wrong-page possibilities and costs nothing.

Confirm via cgminer API, not just the Web UI. Curl port 4028 with {"command":"estats"} from a laptop on the same subnet. Parse GHSavg = 0, MW0..2 empty, PS[0..2] = 0, ECMM flagged. The Web UI sometimes goes stale and reports old state; the API tells the truth in real time. If the API actually shows hashing or non-zero PS, you have a different fault — branch accordingly. Save the raw API response for D-Central if you end up shipping the chassis — it's diagnostic gold.

Check for recent physical events. Was the miner moved, dropped, vibrated during shipping, or had a chassis open / PSU swap / harness disturbance in the last 24-72h? Was there a thunderstorm, grid switching event, brownout, or known surge? Recent physical or electrical events are the single biggest predictor of which failure category you're in. Recent service event = likely loose PMBus connector. Recent surge / electrical event = possible PMBus MCU damage on PSU or AUC4 transceiver damage. No recent event + sudden onset = most often vibration-induced cable walk-loose.

Verify you have the right PSU model installed. Pop the chassis lid (no tools deeper than this — visual only) and confirm the PSU model number on the label matches the A1056..A1266 compatible family. If someone wired a Bitmain APW (APW3++ / APW9 / APW12) into the 1266 because the 12V output 'looked compatible', AUC4 will reject the model-ID handshake forever. The fix is 'use a confirmed-compatible Canaan PSU.' Branch to Avalon - PSU Incompatible Model for that case. Verify exact PSU model that ships in current 1266 inventory before trusting cross-model substitutions.

Check MM firmware version stamp via Web UI. Note the exact MM build string. If you flashed firmware in the last 7 days and the fault appeared after that flash, you have a firmware regression — branch to Tier 3 re-flash factory MM image before doing any chassis work. If MM has been stable for months and the fault appeared without a flash, the cause is hardware-side. Document the build string regardless — D-Central needs it if you end up shipping.

Re-seat the AUC4-to-PSU PMBus signal connector. Kill AC at the PDU, wait 60s for bulk caps to discharge — non-negotiable on a 1266 because the bulk caps stay charged dangerously long. Open the chassis. Locate the small PMBus signal connector between AUC4 and the PSU (NOT the heavy 12V output harness). Unplug. Inspect both halves under bright light for blackening, oxide, green corrosion, bent / recessed pins, or any pin shorter than its neighbours. Clean contact surfaces with 99% IPA and a lint-free swab if visibly dirty. Re-seat firmly — feel and hear the click. Power up, repeat the API check. The majority of A1266_PSU_FAIL events on this chassis resolve here.

Zip-tie the PMBus signal cable to the chassis frame. If the re-seat fixed it, the cable will work loose again within weeks unless you secure it. Run a zip-tie around the cable and the nearest chassis rail ~10-15 cm from the connector — close enough that fan-vibration cannot walk the connector loose, far enough that the cable still flexes naturally. The same vibration-prevention principle Zeus Mining documents for the AUC USB cable applies to the internal PMBus harness on the 1266. CAD $0.05 of zip-tie prevents a CAD $50+ future diagnostic visit.

Swap the PMBus signal cable with a known-good donor. If the re-seat alone didn't fix it, suspect a broken conductor inside the ribbon. Fine-gauge ribbons crack internally after 2-4 PSU service events and the break does NOT show on continuity at rest — only under fan-vibration. Pull a PMBus signal cable from a parts-donor or stock spare, swap it in, power up, repeat the API check. Keep a PMBus signal cable as a permanent stock item in your repair kit — they're cheap and wear-prone enough to justify it.

Verify 12V standby at the PSU output harness with a DMM. Power up. DMM on DC, probe at the PSU-side of the output harness with no hashboards drawing current (AUC4 hasn't enabled them). Expect 12.0-12.6V open-circuit on standby. If the rail reads <11.8V or no output at all, the PSU primary stage is dead — this isn't 'comm-not-detected,' it's 'PSU dead.' Replace the PSU and skip the comm-channel work entirely. If 12V is healthy on standby but the comm channel is dark, the PSU is physically alive but protocol-dark — continue with comm-isolation steps below.

Cable-manage all internal harness routing while the chassis is open. Since the lid is already off, dress every cable away from fan blades, hot MOSFETs on the hashboards, and sharp metal edges. Chassis-fan vibration in a 1266 running three hashboards at full nameplate is non-trivial — poorly routed harness is the root cause of roughly one in four return visits for the same PSU_FAIL ticket. Verify percentage against D-Central's 1266 repair-queue data.

Swap to a known-good compatible Canaan PSU. Use a confirmed-working PSU from the A1056..A1266 family — verified currently-stocked Canaan inventory, no Bitmain APW substitutes. Power up, repeat the API check. If 'PSU detected' with the donor and hashboards enable, the original PSU's PMBus MCU is dead — replace permanently. If still dark with the donor PSU, the fault is AUC4-side and you need to continue to control-board work in Tier 3.

Capture the AUC4 boot log via USB-TTL during a cold boot. Connect an FT232 / CH340 / CP2102 USB-TTL adapter to the AUC4 UART header (location varies by AUC4 board revision — check silkscreen). Capture the full boot log including MM firmware init. Search the log for 'PMBus init started', 'PMBus init OK', 'PMBus init failed', 'psu_probe timeout', 'i2c-tools timeout on PSU address'. Exact phrasing varies by MM build. The log distinguishes 'AUC4 never tried' (firmware fault) from 'AUC4 tried, PSU never replied' (cable / connector / PSU MCU) from 'AUC4 tried, response was malformed' (physical-layer integrity).

Scope the PMBus lines (SDA / SCL) at the AUC4 header during a cold boot. A 50 MHz handheld scope (Hantek / Siglent / Rigol entry-level) on each line captures physical-layer integrity. From the laptop, hold the AUC4 in a reset loop. Healthy: clean digital transitions at the expected 100 kHz or 400 kHz PMBus clock, valid response frames from the PSU within milliseconds of each probe. Comm-lost flavours: AUC4 not transmitting at all (transceiver dead) / AUC4 transmitting cleanly but no response (PSU MCU dead) / corrupted, noisy, or partial transitions (cable / connector physical-layer issue). One scope capture distinguishes the three sub-cases under five minutes.

Inspect AUC4 silicon under magnification. A dead PMBus transceiver IC on the AUC4 often shows hairline package cracks, discoloured solder pads, scorched silkscreen marks from a prior surge event, or visible burn smell on the PCB. Under 10x-20x magnification scan the cable-input side of the AUC4. Cracked transceiver, cracked adjacent MOSFET, or burnt regulator = surge damage, component-level work required and probably bench-only. Visually clean = transceiver failure less likely; the fault is more likely PSU-side or cable-side.

Inspect PSU control-board silicon under magnification. Same procedure on the PSU's control-side (the small daughter-board or SMD section that handles PMBus and PSU status, separate from the main switching stage). Same indicators: cracked package, discoloured pads, scorched silkscreen, burn smell. The PSU control-board is more often surge-damaged than AUC4 because it sits closer to the AC-input domain electrically. Verified against D-Central's 1266 PSU teardowns.

Re-flash the factory MM firmware image for the 1266. If Step 12's serial log shows the AUC4 never executed PMBus init at all, MM firmware itself may have a corrupted PSU-init code path. Re-flash the current correct factory MM image for the 1266 specifically via the AUC4 Web UI. VERIFY the image is for 1266 — the 1266 has a distinct MM signature from the 1166 / 1246 / 1346, and Canaan signature-checks per-model on flash. Cross-model flash bricks the AUC4. See Avalon 1246 - Firmware Flash Failure for the proper flash procedure and recovery if the flash fails midway.

Replace the PSU control board (component-level). If Step 15 confirmed PSU-side PMBus MCU damage and you have preheat + hot-air + SMD rework capability, the PSU control board is replaceable from a parts-donor PSU with healthy comm silicon. Pull the donor control board, verify PMBus MCU is alive on a breadboard with a serial loopback test, transplant. If you don't have the SMD skill set or a confirmed-good donor, ship the PSU to D-Central — bench transplant runs CAD $90-180 and is faster than buying a new PSU at CAD $180-420.

Replace the AUC4 control board (component-level or whole-board). If Step 14 confirmed AUC4-side PMBus transceiver damage, two paths: whole-board AUC4 replacement (parts-donor or Canaan replacement, simpler), or component-level transceiver IC replacement on the original AUC4 (cheaper, requires preheat + hot-air + exact-part-number sourcing from silkscreen). Component-level is bench territory unless you have prior SMD experience. Use the EXACT part number from silkscreen — substitute transceivers with different protocol support fail handshake immediately.

Stop DIY when both swaps (PSU and AUC4) with confirmed-good donors fail to restore handshake. The fault is in the chassis wiring harness, in a third combined component, or in a path the field-swap procedure can't isolate. At that point you need a bench fixture with programmable loads, a logic analyzer on the PMBus lines, and component-level isolation tooling. D-Central's bench substitutes one component at a time against a known-good reference until the handshake completes — typically 1-2 hours of bench time at shop rate, vs. days of field swap-and-pray.

Stop DIY when you see burnt silicon, cracked packages, discoloured pads, capacitor bulging, or a burnt-component smell anywhere in the chassis. Surge damage to one named component almost always correlates with collateral damage to adjacent silicon — input MOSFETs, 3.3V regulators, MCUs, surge clamps. Replacing only the visibly burnt part leaves the rest of the surge-stressed silicon ready to fail under the next transient. D-Central's bench process re-checks the whole input-protection chain, recaps where appropriate, and tests the repaired chassis under three-board load before shipping back.

Stop DIY if you don't have preheat + hot-air SMD rework capability and the fault narrows to component replacement. Iron-only rework on PMBus transceiver ICs or PSU MCU silicon lifts pads, breaks vias, and turns a CAD $90-180 bench repair into a CAD $300-500 'we have to replace the whole control board because the original is now scrap' repair. Ship the chassis at the first hint of needing component-level work unless you genuinely have the toolchain and the practice.

Ship with full context. Pack the chassis WITH the PSU (we need your exact stack to reproduce the fault — a shipped bare chassis without its PSU is a 50% diagnostic with both hands tied). Include: a copy of your last cgminer API response, your Tier 3 USB-TTL serial log capture if you took one, the MM firmware build string, service history (when the chassis was opened, what was swapped, when the fault first appeared), and any ascset|0 responses from your diagnostic. Every minute of context is a minute of bench time saved. Match serial number on the chassis to the serial number on the PSU on the shipping note. Canada-wide standard shipping; US / international welcomed. Anti-static bags around the AUC4, double-box with >=5 cm foam on every side.