Avalon 1446 – Hashboard 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 PSU bulk caps to discharge and MM firmware state to flush. Power back up, watch the dashboard for `3/3` to appear. This is the cheapest possible diagnostic on any Avalon chassis and recovers a non-trivial fraction of CHAIN_FAIL 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 on a 1446.

Pull `estats` from the cgminer API before you touch the hardware. `curl http://<miner-ip>:4028 -d '{"command":"estats"}'`. Read `SYSTEMSTATU`, `MW0/MW1/MW2`, `ECHU`, and especially `PS[0..2]`. If `PS[0]` has bits `512`, `1024`, or `2048` set, you have a PSU output-channel trip and the board is exonerated — chase the PSU, not the hashboard. If the dark chain's `MW` array is empty and `ECHU` unreadable, confirmed CHAIN_FAIL at the IIC handshake level. This five-second API query saves an hour of screwdriver work on almost every 1446 ticket.

Check the MM firmware log. SSH in (or use the Web UI's "System Log" viewer if enabled) and grep `/tmp/log/log` for `chain`, `iic`, `EEPROM`, `PS`, `MMCRCFAILED`. The log tells you which of the six failure buckets is active before you open the chassis — IIC nack means dark board, EEPROM fail means corrupt identity, PS bitmap means PSU trip, MMCRCFAILED means marginal bus. Let the log route the triage.

Confirm recent service history and firmware-change history. A CHAIN_FAIL three days after a paste refresh is almost always a reversed power-sequence (Tier 3 damage to `U1/U2/R8/R9`) or a loose ribbon (Tier 2 reseat). A CHAIN_FAIL right after a firmware flash is an MM image corruption (Step 10). A CHAIN_FAIL out of the blue after months of stable mining is a PSU event, a connector oxidation, or an age-related PMIC failure. Service history is the single highest-value context you can give a remote diagnostic or a bench tech — on a 1446 it's the difference between a 60-minute callback and a 4-hour dig.

Confirm intake ambient. Per the A13/A14-family spec, intake air should be at or below `35°C`. Some 1446 MM firmware revisions silently mask detection failures as thermal foldback — a hot intake looks like a dead board on the dashboard. Measure at the intake grille with an IR thermometer, not at room-middle. In a Canadian basement in winter this isn't usually the fault; in a summer garage or a poorly-ducted hot-aisle it can be.

Hard power-down and reseat the signal ribbon + `12V` lugs on the missing chain. Kill AC at the PDU. Wait `5 minutes` for electrolytics to drain. Open the top cover. Disconnect the signal ribbon on the dark chain; inspect both connector faces under bright light for oxidation, green oxide corrosion, or bent/recessed pins. IPA-swab both sides (`99%` IPA + lint-free) if the miner has lived in a dusty environment. Reseat until you hear the click. Loosen, clean, and re-torque the `12V` DC copper lugs (community torque `1.2 – 1.5 Nm`; Canaan publishes no spec). Close up, power on, re-pull `estats` to confirm `3/3`.

DMM-verify `12V` at the hashboard input lug under boot load. Disconnect the `12V` lug from the PSU side. Probe DC with miner off — expect `12.0 – 12.6V` open-circuit from the PSU. Reconnect firmly, power up, re-probe at the lug during the boot window (first `30 seconds`) — expect `≥11.8V` sustained into load. A PSU that reads `12.3V` open and collapses to `8V` under load is tired regardless of hours on it. The 1446 draws roughly `3,100-3,300W` at nameplate, so PSU sag under load is the quiet killer — it shows up as intermittent CHAIN_FAIL before it shows up as full shutdown.

Swap to a known-good 1446-compatible Canaan PSU. Use a confirmed-working PSU from the `A1326 / A1346 / A1366 / A1446 / A1466 / A15xx` family (shared PSU part, documented by Bit2miner). Power up, observe `3/3` on the dashboard within the first `90 seconds`. Do NOT cross-connect a Bitmain `APW`-series PSU; Canaan and Bitmain pinouts differ and wrong-brand PSU is a documented failure mode. If `PS[0]` bits `512` / `1024` / `2048` clear on the swap, the old PSU had an output-channel trip and needs replacement.

Swap the suspect board into a known-good slot. Power down. Swap the dark hashboard with one of the known-good boards (swap slots `1` and `3`, keep orientation). Power up and read `estats`. Fault follows the board = the board itself is bad (ship to D-Central or bench repair). Fault stays with the slot = MM control board, AUC3 bridge, or PSU output channel for that slot is the fault (continue with Step 10 or 11). This swap isolates where the fault lives in under five minutes and is the highest-value Tier-2 diagnostic on the 1446 chassis.

Re-seat every ribbon, harness, and AUC3 USB connection in the chassis. Kill AC, disconnect every control-board-to-hashboard ribbon, every PSU output harness, and the AUC3 USB/ribbon connection. Inspect each connector pin-by-pin under bright light. IPA-clean dirty contacts. Re-seat firmly. Cable-tie the AUC3 ribbon and PSU harness to the chassis frame so chassis-fan vibration cannot work connectors loose. Zeus Mining documents this exact vibration failure mode on the 1246 — it applies identically to the 1446 because the fan mount geometry is unchanged.

Re-flash the current factory MM firmware image via the AUC3 Web UI. If Step 2's log scan showed `EEPROM read fail` without IIC nacks, or if the chassis had a failed firmware flash recently, re-flash the correct current MM image following the D-Central Avalon firmware upgrade guide. VERIFY the image is for A1446 — cross-flashing a 1346, 1366, or 1466 image bricks the control board because Canaan signature-checks per-model. Rollback is blocked. Do not interrupt the flash.

Capture the MM 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 MM revision — check silkscreen). Capture the full boot log at the documented baud rate. Hashboard-handshake attempts, IIC init messages, `MMCRCFAILED` errors, and per-chain enumeration outcomes all surface here. This is the single highest-value diagnostic when the Web UI says `2/3` but the cgminer API and the MM log can't agree on which chain — the serial log is ground truth on a 1446.

Tune `--avalon7-aucspeed` and `--avalon7-aucxdelay`. Defaults per cgminer source are `aucspeed 400000` and `aucxdelay 19200`. If serial logs show intermittent `MMCRCFAILED`, drop `aucspeed` to `300000` (or `200000` if severely marginal) and bump `aucxdelay` to `24000` (or `38400`). The `avalon7` flag prefix still applies to the A14-series codebase — Canaan never renamed the upstream cgminer flags. This is undocumented in Canaan materials and lives only in the cgminer `ASIC-README` — pure community lore that keeps worn ribbons hashing for another quarter.

Measure hashboard domain and core rails with DMM on the dark chain. Probe at the silkscreened test points during the boot window. Per the A13/A14-family spec, domain rail is `1200 – 1320 mV`, core rail is `290 – 350 mV`. If `12V` is present at the input but the domain or core rail reads `0 mV`, the on-board PMIC / buck converter is dead or a fuse / bulk cap has failed short. This diagnosis sends the board to Tier 3 rework or D-Central ship.

Inspect `U1`, `U2`, `R8`, `R9` on the dark hashboard with DMM in diode-check mode. Per the Zeus Mining A11/A12 repair guide — whose topology carries forward to the A13/A14 family — `U1/U2` are the board's primary power-sequence MOSFETs and `R8/R9` are the companion sense/gate resistors. 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. If identified, replace the exact silkscreened part (substitutes with wrong `V_DS` or `R_DS(on)` fail immediately). Requires preheater + hot-air rework + SMD skills — iron-only rework lifts pads.

Swap donor AUC3 from a 1346 / 1366 / 1466 / 1566 chassis. If fault stays with the slot across board-swap (Step 9) and re-seating doesn't help, the AUC3 bridge or MM control board is suspect. The A13/A14 family shares AUC3 part identity across the 1346 / 1366 / 1446 / 1466 / 1566. A parts-donor AUC3 from any of those chassis is a valid swap-out for isolation. Chain enumerates on donor AUC3 = your AUC3 is dead. Still dark = MM control board itself (Tier 4).

Scope the `12V` rail at the hashboard input during boot. A 50-MHz handheld oscilloscope 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. The scope capture distinguishes PSU faults from per-board faults more reliably than DMM averaging, which hides transient events on a worn 1446 PSU.

Re-flow suspect components on a visibly-damaged hashboard. If Step 15 identified a specific bad part and you have preheater + hot-air + SMD skills, replace `U1`, `U2`, `R8`, or `R9` on the affected board. Pre-heat bottom side to `~150°C`, top-side hot air at `~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. Use the exact silkscreen P/N — wrong `V_DS` or `R_DS(on)` parts fail on first power-on. This is bench territory; do not attempt with a soldering iron alone.

Stop DIY when multiple hashboards in the same chassis show identical `U1/U2/R8/R9` damage or identical PMIC signatures. Two or three boards with the same burnt power-sequence parts means a feeder event (surge, brownout recovery, lightning-induced transient on the input feed) simultaneously damaged all of them. That is a full-chassis bench rebuild: multi-board component-level repair, PSU replacement, control-board surge-input-MOSFET inspection, and a full 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 for the A14 silicon, and only returns boards that pass burn-in.

Stop DIY when the MM control board / AUC3 is suspected dead. A control board that shows zero LED activity at power-up with a known-good PSU, or persistent `MMCRCFAILED` after AUC3 donor-swap, requires a bench fixture to localize. The MM3v2-lineage control board has a `12V → 3.3V` chain with multiple stages, any of which can fail on a surge event. D-Central carries parts-graded control boards and AUC3 daughterboards from the A13/A14 family for swap-out and cross-references repair-queue logs across the 1346/1366/1446/1466/1566 fleet to localize recurring fault patterns.

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 — a tired PSU that mostly works on your bench may be the root cause of what looks like "hashboard dead," and we can only diagnose the fault if we can reproduce it. Include a note with: serial number, observed symptoms (screenshots of `2/3` dashboard, captured `PS[0..2]` / `ECMM` / `MMCRCFAILED` lines from the MM log, which slot is dark), service history (when opened, what was done, firmware flashes in last 30 days), and contact info. Saves bench diagnostic time and saves you money. Canada-wide shipping; US / international welcomed.

Discuss repair-vs-replace up front. A full 1446 bench rebuild (three-board component-level inspection + PSU + control board + burn-in) runs `CAD $750 – $1,600` depending on what we find. A used 1446 on the secondary market in early `2026` runs roughly `CAD $1,500 – $2,800` depending on condition. The math usually favours repair when the miner is otherwise healthy and your power cost is below `~$0.08/kWh`; at `>$0.12/kWh` the efficiency gap to a 1466 or 1566 starts to change the calculation. D-Central quotes honestly before committing bench hours — if the economics don't work we'll say so, and sometimes the right answer is "salvage the PSU, sell the boards that test alive on our bench, and put the cash toward a next-gen chassis."