Avalon 1166 Pro – 0 Hashboard Detected

Hard-power-cycle at the PDU / breaker for a full 60 seconds. Not a Web UI reboot — a true AC disconnect. Wait the full minute for PSU bulk caps to discharge and MM state to flush, then power back up and watch the dashboard for 3/3 boards to appear. This is the cheapest diagnostic on any Canaan chassis and recovers a meaningful fraction of 0 hashboards tickets caused by wedged MM state after a brownout or network hiccup. While waiting, note any red LEDs, unusual PSU fan behaviour, or burnt smell — those observations steer the rest of the triage.

Check network path to the AUC3 before chasing hashboards. Browse to http://<miner-ip>/ — does the Web UI load? Ping the IP from a laptop on the same subnet. If the AUC3 is unreachable, the failure is not 0 hashboards detected — it is an AUC3 / network problem and the correct playbook is the AUC USB / network-loss page, not this one. Confirm the control board is alive and networked before spending time on PSU and hashboard diagnostics.

Inspect for physical damage and capture recent service history. Walk around the miner: burnt smell, discoloured PSU housing, melted output harness, visible capacitor bulging, burn marks near the control board? Was the miner moved, opened, had a hashboard or PSU swapped, or had paste refreshed in the last 30 days? Service history is the highest-value context — a 0/3 right after a paste refresh almost always points to a reversed power sequence or a loose ribbon; a 0/3 out of the blue almost always points to PSU or feeder event.

Confirm firmware version and firmware-change history on the AUC3 Web UI. A failed MM firmware flash presents as 0 hashboards because the MM code itself cannot enumerate. Canaan blocks downgrade so if you recently flashed a newer MM image and it broke the chassis, you need the specific MM recovery path for that version — see the Avalon firmware-flash-failure playbook. If firmware has been stable for weeks and the miner just died, firmware is not the fault.

Confirm intake ambient. Per the Canaan A1066 manual, inlet air should be at or below 35°C. An overheated PSU can cut output and present as 0 hashboards even though this is not an overheat error. Canadian garages in summer and any ducted setup with bad return-air flow hit 40°C+ at intake and kill PSUs long before hashboards. Measure at the intake grille with an IR thermometer, not at room-middle.

DMM-verify the PSU output at the control-board harness under load. Disconnect the PSU-to-control-board harness; probe DC with the miner off — expect 12.0 to 12.6V open-circuit. Reconnect firmly; power up and re-probe during the boot window (first 30 seconds) — expect >=11.8V sustained. A PSU that reads 12.3V open and collapses to 8V under load is tired regardless of hours on it. Multimeter leads are the cheapest Tier-2 diagnostic and they resolve this fault class definitively.

Swap to a known-good A1166 Pro-compatible Canaan PSU. Use a confirmed-working PSU from the A1056 / A1066 / A1066 Pro / A1126 Pro-S / A1146 Pro / A1246 / A1266 family — all share the same connector and output spec. Do NOT cross-connect a Bitmain APW-series PSU; Canaan and Bitmain pinouts differ and wrong-brand PSU is a documented failure mode. Power up and observe 3/3 on the dashboard within the first 90 seconds.

Re-seat every ribbon, harness, and signal cable in the chassis. Kill AC. Open the chassis. Unplug every control-board-to-hashboard ribbon and the PSU-to-control harness. Inspect each connector under bright light for blackening, corrosion, green oxide, or bent / recessed pins. Clean any dirty contact surfaces with 99% isopropyl alcohol and a lint-free swab. Re-seat firmly — feel and hear each click. Bad connectors are a statistically large contributor to this chassis's 0/3 reports because of the vibration profile from the chassis fans.

Cable-tie the AUC3 ribbon and PSU harness to the chassis frame. If Step 7 or Step 8 resolved the fault and you found corrosion / wear at a connector, secure the affected cable to the frame with a zip-tie so chassis-fan vibration cannot work the connector loose again. Zeus Mining documents this exact failure mode on the 1246 and the fix applies identically here: the AUC USB cable (where external) or the internal IIC ribbon drifts under vibration until contact is marginal.

Swap the AUC3 IIC ribbon if you have a spare. If all PSU checks pass and re-seating does not help, the IIC ribbon between the control board and the hashboards is the next cheapest suspect. A cracked conductor inside the ribbon's flex section does not show on visual inspection — the only way to isolate is to swap. Spare ribbons are cheap from parts suppliers or pulled from a parts-donor chassis.

Isolate one hashboard at a time by unplugging the other two. Power down. Disconnect boards 1 and 2. Power up and read the dashboard: does board 0 enumerate alone? Repeat for 1 and 2. All three pass alone but fail together = PSU can carry single-board current but sags under three-board load; replace PSU. One fails alone = that board has localized power-sequence or chip-level damage; ship that board (Tier 3 or 4). None enumerate alone = control-board / AUC3 is the fault (Tier 3 or 4).

Re-flash the factory MM firmware via the AUC3 Web UI if the control board is reachable and you suspect a partial firmware corruption. VERIFY the image is for A1166 Pro specifically — cross-flashing a 1246 image onto a 1166 Pro bricks the control board because Canaan firmware signature-checks per-model. Rollback is blocked, so only flash the current correct image or newer. Follow the Avalon firmware-flash-via-AUC procedure and do not interrupt the flash once it has started.

Capture the control-board serial log at boot via USB-TTL. Connect a USB-TTL serial adapter (FT232 / CH340 / CP2102) to the control board's UART header; location varies by AUC3 revision — check the silkscreen. Capture the full boot log. MM boot messages, MMCRCFAILED errors, IIC init failures, and hashboard-handshake attempts appear here. This is the single highest-value diagnostic on a 0/3 miner where the Web UI is alive but the boards are silent — the serial log tells you which of the four failure categories (PSU comm / IIC bus / per-board power / chip-short) is actually active.

Measure U1 and U2 on each hashboard with a DMM in diode-check mode. Per the Zeus Mining A11/A12 repair guide, U1 and U2 are the hashboard's primary power-sequence MOSFETs. A burnt U1 or U2 from a reversed install sequence (negative last, positive first, signal first) reads dead-short or open-circuit in diode mode. R8 and R9 are the companion sense / gate resistors and burn in the same event. All four parts are cheap to replace but require hot-air rework and surface-mount soldering. If you find a dead U1/U2/R8/R9 on a specific board and you have the skill set, replace and re-test. Multiple boards with identical damage = surge event — ship the whole chassis.

Tune CGMiner --avalon7-aucspeed and --avalon7-aucxdelay if serial logs show intermittent MMCRCFAILED. Defaults per the cgminer source are aucspeed=400000 and aucxdelay=19200. If the IIC bus is marginal (worn ribbon, vibration-stressed connectors), halve aucspeed to 200000 or double aucxdelay to 38400 and retest. This is undocumented in Canaan materials and lives only in the cgminer CLI — a hallmark of A11-series diagnostic lore that lives in the community.

Inspect for surge damage on the control-board power-input MOSFET. A surge event often takes out the control board's 12V to 3.3V input-side MOSFET. Signature: no activity on control-board LEDs at power-up, or flicker-then-dark behaviour. Under magnification look for hairline cracks in the MOSFET package, discolouration of solder pads, or cooked silkscreen nearby. Replacement is a hot-air rework job. This failure mode typically takes out the control board alone — PSU and hashboards are fine — so isolation by swap is straightforward if you have a parts-donor AUC3.

Scope the 12V rail at the hashboard input during boot. A 50 MHz handheld scope captures the rail-up ramp during MM power sequence. Healthy: clean step from 0V to 12V in tens of milliseconds, flat at 12V thereafter with <200 mV ripple. Damaged PSU or cable: oscillation, overshoot, or incomplete ramp. Damaged per-board power sequence: rail comes up and immediately collapses as U1/U2 fail to latch. This single scope capture distinguishes PSU faults from per-board faults more reliably than DMM averaging.

Reflow suspect components on a visibly-damaged hashboard. If Step 14 identified a specific bad component and you have preheater + hot-air + SMD skills, replace U1, U2, R8, or R9. Use the EXACT part number from silkscreen — substitutes with wrong V_DS or R_DS(on) fail immediately. Pre-heat bottom to ~150°C, top-side hot air ~320°C, desolder the failed part, clean pads with braid and flux, place replacement, reflow down. Re-check with DMM diode mode before re-installing.

Stop DIY when multiple hashboards show identical U1/U2/R8/R9 damage. Three boards with the same burnt MOSFET set means a feeder event (surge / brownout recovery / lightning transient) simultaneously damaged all three. That is a full-chassis bench rebuild: three-board recap + re-flow campaign, PSU replacement, control-board surge-input-MOSFET replacement, and 24-hour nameplate burn-in. Shotgun-replacing at home rarely lands — D-Central's bench isolates each board on a programmable load, verifies each chip's PVT_V and PVT_T against a known-good baseline, and only returns boards that pass burn-in.

Stop DIY when the control board / AUC3 is suspected dead. Step 16's surge-damage signature — or a control board that shows zero LED activity at power-up with a known-good PSU — requires a bench fixture to localize. The AUC3 has a 12V to 3.3V chain with multiple stages, any of which can fail. D-Central carries parts-graded AUC3 control boards for swap-out and cross-references repair-queue logs for this chassis family.

Ship properly: pack the chassis in its original Canaan box if possible or double-box with 5cm+ foam on every side. Include the PSU so we can test your exact stack — a tired PSU that mostly works on your bench may be the root cause of what looks like 'all boards dead.' Include a note with serial number, observed symptoms (screenshots of the 0/3 dashboard, any PS[0..2] / ECMM values), service history (when opened, what was done), and contact info. Saves diagnostic time and money. Canada-wide shipping, US / international welcomed.

Discuss the repair-vs-replace economics up front. A full 1166 Pro bench rebuild (PSU + three-board component-level + control + burn-in) runs CAD $700 to $1,400. A used 1166 Pro on the secondary market in late 2025 runs CAD $800 to $1,500. The math is not automatic either way. D-Central quotes before committing bench hours — if the repair economics do not work we will tell you. Sometimes the right answer is 'salvage the PSU for parts, sell boards that still test alive, and put the cash toward a 1246 or 1266.'