Avalon 1246 – Only 2 Hashboards Detected
Informational — Monitor and address as needed
Symptoms
- Canaan dashboard or AUC3 Web UI reports **`2 of 3 hashboards detected`**, `board_count: 2`, or `active chains: 2` on the 1246
- cgminer JSON API (`curl http://<miner-ip>:4028 -d '{"command":"estats"}' -H "Content-Type: application/json"`) returns `MW0`, `MW1`, **OR** `MW2` empty/absent while the other two are populated
- `GHSavg` is settled at **`~65-70% of nameplate`** (`~55-60 TH/s` on an 85T unit, `~58-63 TH/s` on a 90T)
- `GHSmm` (theoretical) and `GHSavg` (actual) both drop together — this is not a "one board is running hot and derating," it's a full chain miss
- `PVT_T0` / `PVT_T1` / `PVT_T2` — one of the three temperature arrays is empty or returns placeholder zeros while the other two show live `~55-75°C` readings
- `PVT_V0` / `PVT_V1` / `PVT_V2` — one voltage array is empty, confirming the chain isn't powered or isn't enumerating
- `ECHU[0]`, `ECHU[1]`, or `ECHU[2]` — one chain's error-correction counter sits at zero while the other two accumulate normal low-single-digit traffic
- `PS[0..12]` bits on the PSU status word all read nominal (`0` across the board) — **PSU itself is healthy**, the fault is downstream
- Red status LED is **off** — stock firmware does not escalate a single-chain drop to the red-LED state
- No overheat shutdown, no fan fault banner, no brownout alert
- Kernel log (`dmesg` via serial, or `/var/log/messages` via SSH on rooted firmware) shows one of: `avalon_init_chain: chain 0 no response`, `asic_chain: ch1 enumerate fail`, or `MMCRCFAILED chain 2` repeatedly during boot — the specific chain index points to the dark slot
- Behavior is **persistent** across two `60-second` cold power-cycles
- Hashrate history graph shows a **step-down** at a specific timestamp (not a gradual decline) — that timestamp is when the chain dropped
- Miner was recently: moved, serviced, had a paste refresh, had a ribbon disconnected, or survived a nearby power event
Step-by-Step Fix
Hard-power-cycle at the PDU for a full 60 seconds. AC disconnect at the breaker or PDU — not a Web UI reboot, not a soft restart. Wait the full minute for bulk caps to discharge and MM state to flush. Power up and watch the dashboard for `3/3` boards to appear within the first 90 seconds. A transient AUC3 IIC stall, a brownout-induced wedge, or a stratum-reconnect storm can drop a chain without any underlying hardware fault — the cold cycle clears it. If the chain comes back and holds for 24 hours, you're done; set an alert on `board_count < 3` and move to Prevention. If it drops again within minutes or the chain never comes back, continue.
Identify exactly which slot is dark via the cgminer API. `curl http://<miner-ip>:4028 -d '{"command":"estats"}' -H "Content-Type: application/json"` returns the full status record. Find the chain index (`0`, `1`, or `2`) whose `MW_N`, `PVT_TN`, and `PVT_VN` arrays are empty. Note the physical slot position in the chassis — top, middle, or bottom varies by unit orientation. This slot index drives every subsequent diagnostic. If curl feels intimidating, open the AUC3 Web UI and find which chain panel is empty; same information, slower.
Capture the dashboard / Web UI screenshot and note the timestamp of the drop. Look at your hashrate history — most dashboards graph `GHSavg` over time. Find the step-down from nameplate to `~66%` and note the timestamp. Cross-reference with any power events in your logs (UPS, PDU, smart plug). A drop that coincides with a known power event points to a PSU or feeder cause. A drop with no power correlation points to a gradual hardware fault (ribbon wear, aging PMIC). Record these observations in your service log — they matter more than most people realize when you're triaging which Tier to escalate to.
Check service history and firmware version. Was this miner recently opened for paste refresh, fan replacement, or hashboard swap? A chain that drops within days of a service is almost certainly a reversed power-sequence (Tier 3) or a loose ribbon (Tier 2). A chain that drops out of the blue after months of stable operation points to ribbon wear or PMIC aging. On the Web UI, note the firmware version. If a firmware flash happened in the last 48 hours, a partial flash of one board's MM image is a possible cause — see Tier 2 Step 9 (re-flash).
Confirm intake ambient is within spec. Per the Canaan A1066 manual, inlet air `≤35°C`. A summer garage at `40°C+` at the intake grille stresses PSUs and can cause a per-board power sequence to fail enumeration on the hottest-positioned board. Measure at the intake grille with an IR thermometer, not at room-middle. If intake is high, improve airflow before chasing hardware — Canadian basement shops in winter don't have this problem, Canadian garages in July absolutely do.
Ribbon-swap between the dark slot and a known-live slot. Power down at the PDU. Open the chassis lid. Unplug the ribbon from the dark slot, unplug the ribbon from a live slot, cross-connect them — the ribbon that was on slot `0` now connects to slot `1`'s board, and vice versa. Power up and read the dashboard. If the dark chain has moved to the slot whose ribbon you unplugged, the ribbon is the fault — replace it. If the dark chain stayed at the same physical slot regardless of which ribbon is connected, the fault is the hashboard, the backplane connector, or the control-board connector at that slot — continue to Step 7.
Replace the ribbon if Step 6 localized it. A fresh 1246 / 1266 ribbon is cheap from parts suppliers, Zeus Mining, or a parts-donor chassis. Route the new ribbon away from fan blades. Zip-tie the ribbon at two points to the chassis frame — this single discipline prevents chassis-fan vibration from re-walking the connector loose over the next `12-24 months`. Power up, confirm `3/3`, watch for 24 hours of stable operation before declaring the fix.
Inspect the dark slot's backplane / control-board connector under bright light. With the miner off and the chassis open, shine a flashlight into the connector. Look for bent pins, recessed pins, blackening, greenish corrosion, or cracked housings. Clean any dirty contact surfaces with a cotton swab and `99% isopropyl alcohol`. A bent pin that can't be coaxed back into position is a control-board repair — Tier 4. A dirty-but-intact connector re-seated with fresh IPA resolves a surprising number of "only 2 boards" tickets.
Re-flash the MM firmware for the dark board via the AUC3 Web UI. If the board enumerates then drops after Step 6's ribbon swap didn't move the fault, and Step 8's connector inspection is clean, a corrupt per-board MM image is a real possibility. On the Web UI, initiate a factory MM flash. Verify the image is for the Avalon 1246 specifically — cross-flashing a `1166 Pro` or `1266` image bricks the board because Canaan firmware is signature-checked per-model and rollback is blocked ([community voids, CG-5-canaan]). Do not interrupt the flash once started. Follow the full procedure at [Avalon — Firmware Flash via AUC](https://d-central.tech/asic-troubleshooting/avalon-firmware-flash-via-auc/).
DMM-verify `12V` rail at the dark slot's backplane under load. Power up with the dark board unplugged at the ribbon. Probe DC at the control-board side of the backplane connector — expect `12.0-12.6V` steady. Re-seat the ribbon and re-probe at the board-side connector during the boot window (first 30 seconds). A voltage present at control-board side but missing at board-side with the ribbon installed means the ribbon is the fault (back to Step 6). Voltage present both sides means the board is receiving power but failing to power up locally — Tier 3 territory.
Isolate the dark board by unplugging the other two. Power down. Disconnect the two live boards' ribbons. Power up with only the dark board connected. Does it enumerate alone? If so, you have a PSU that can't carry full three-board load — replace PSU (see [Avalon 1246 — PSU Not Detected](https://d-central.tech/asic-troubleshooting/avalon-1246-psu-not-detected/) for PSU swap procedure). If the dark board still fails to enumerate alone, the board itself has a localized fault — Tier 3 or ship to D-Central.
Capture the control-board serial log at boot via USB-TTL. Connect a USB-TTL serial adapter (FT232 / CH340 / CP2102) to the AUC3 UART header — location varies by AUC3 revision, check the silkscreen. At the documented baud rate, capture the full boot log. Look for the specific chain index's enumeration attempts: healthy chain shows `avalon_init_chain: chain N OK`, dark chain shows `no response`, `MMCRCFAILED chain N`, or no references at all. The serial log is the single highest-value diagnostic when the Web UI is alive but a chain is silent — it tells you whether MM ever tried to talk to that board, whether the board answered at all, and which step of the handshake failed.
Thermal-camera scan the dark board at `60 seconds` into boot. A FLIR ONE Pro or equivalent. Healthy `A3206` chips hit `~55-70°C` within the first minute; a cold chip among hot neighbors is a dead die (chip-level fault, Tier 3/4 reflow or replace). A dramatically hotter chip is a chip-level short — stop immediately before adjacent parts get damaged. Uniformly-cold-board means power isn't reaching the chip bank at all; check Step 15. Uniformly-hot but still not enumerating means chips are alive but the MM / chain-protocol layer is failing — firmware or bus issue.
Scope the `12V` rail at the dark board's input during boot. A 50 MHz handheld scope on the dark board's `12V` input pin. Healthy: clean step from `0V` to `12V` in tens of milliseconds, flat at `12V` thereafter with `<200 mV` ripple. Oscillation or incomplete ramp = PSU / cable problem. `12V` comes up and immediately collapses = per-board power-sequence (`U1/U2/R8/R9`) failing to latch — proceed to Step 15.
DMM diode-check `U1 / U2 / R8 / R9` on the dark board. Remove the board. Per the [Zeus Mining A11/A12 repair guide](https://www.zeusbtc.com/manuals/4848-avalon-a11-a12-series-hash-board-repair-guide), `U1` and `U2` are the primary power-sequence MOSFETs; `R8` and `R9` are the companion sense / gate resistors. Healthy `U1/U2` reads `~0.4-0.6V` forward drop in one direction, open-circuit in the other. Dead `U1/U2` reads dead-short or open in both. `R8/R9` should read nominal resistance — zero or infinity means they're cooked. A reversed ribbon-install sequence (signal-first, or positive-before-negative on insertion) burns all four simultaneously. If any fail, Step 17 has the replacement procedure.
Tune `--avalon7-aucspeed` and `--avalon7-aucxdelay` via CGMiner config. Per the [cgminer source](https://github.com/ckolivas/cgminer), `aucspeed` defaults to `400000` and `aucxdelay` to `19200`. If serial logs show intermittent `MMCRCFAILED` on the dark chain only, the IIC bus to that specific slot is marginal. Halve `aucspeed` to `200000` or double `aucxdelay` to `38400` in your chassis config and reboot. This is pure community lore — absent from Canaan documentation, present only in the cgminer CLI — and it's the difference between shipping a chassis for repair and keeping it running another six months.
Reflow or replace `U1 / U2 / R8 / R9` on the damaged board. If Step 15 identified a burnt component and you have preheat + hot-air + SMD rework skills, replace the exact part from silkscreen. Substitutes with wrong `V_DS`, `R_DS(on)`, or resistor tolerance fail immediately. 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 the replacement, reflow down. Re-check with DMM diode mode before re-installing in the chassis. Iron-only rework on these parts lifts pads and makes the board worse — do not attempt without a hot-air station.
Hashboard swap from a known-good donor 1246 or 1266 board if available. A1246 / A1266 hashboards from the same production generation are physically interchangeable (backplane / ribbon / mounting identical). If you have access to a parts-graded donor board, swap it into the dark slot as a diagnostic. Chassis enumerates `3/3` with the donor board = your original board is the fault (ship to D-Central for component-level repair or decide on replace). Chassis still `2/3` with the donor board = the fault is the control-board side (Tier 4).
Ship the failed board to D-Central for component-level repair. Typical 1246 single-board component-level repair (`U1/U2/R8/R9` rework, any failed DC-DC regulator, paste refresh, per-chip test-fixture verification, 24-hour nameplate burn-in) runs `CAD $110-260` per board, with 5-10 business day turnaround Canada-wide. Include a note with the serial number, the chain index that failed, any `cgminer` API snapshots you captured, and service history. A board that returns passes our bench test under load at full nameplate frequency for 24 hours minimum before it leaves the repair queue — we do not ship boards that pass a five-minute smoke test and fail three weeks later.
Ship the whole chassis if the fault is control-board-side. If Step 18's donor-board swap didn't recover `3/3`, or if you don't have a donor board and all other isolation points to the control-board connector or AUC3, ship the whole chassis. D-Central's bench isolates each slot on a programmable load and a known-good AUC3 to localize the failure point definitively. Bench rebuilds (control + PSU check + burn-in) on a single-chain fault typically run `CAD $200-450` with a 7-10 business day turnaround. Include the PSU in the shipment so we can test your exact power stack — a tired PSU that mostly works on your bench may be an upstream contributor.
Discuss the repair-vs-replace economics honestly. A single-board repair at `CAD $110-260` on a 1246 running at `~85-90 TH/s` recovers roughly `CAD $50-80` of daily revenue at 2026 hashprice — the repair pays for itself in days, not months, at current hashprice. A full two-board chassis repair (if two boards have failed and the third is marginal) at `CAD $300-600` is still economic unless the miner is already near end-of-life on efficiency. D-Central quotes honestly up front: if the repair math doesn't work at your power cost, we'll tell you before we commit bench hours. For pleb miners running `<$0.08/kWh` Canadian hydro or solar, repair almost always wins over replacing with secondary-market 1246 inventory that has unknown service history.
Book the repair and track shipment. Book via [D-Central ASIC Repair](https://d-central.tech/services/asic-repair/). Pack the board (or chassis) in its original Canaan packaging if you have it — otherwise double-box with 5cm+ foam on every side, anti-static bagged, the PSU harness disconnected and taped. Include: signed serial numbers, chain indexes, `cgminer` API dumps, service history, any photos of visible damage, and your contact info. Canada-wide shipping standard; US / international welcomed. Turnaround is typically 5-10 business days for a single board, 7-10 for a full chassis, longer for full chassis rebuilds because of burn-in time.
When to Seek Professional Repair
If the steps above do not resolve the issue, or if you are not comfortable performing these repairs yourself, professional service is recommended. Attempting advanced repairs without proper equipment can cause further damage.
Related Error Codes
Still Having Issues?
Our team of Bitcoin Mining Hackers has been repairing ASIC miners since 2016. We have seen it all and fixed it all. Get a professional diagnosis.
