Avalon 1246 – PSU Communication Lost

Confirm the fault via the cgminer API, not the Web UI. Curl port 4028 with {"command":"estats"} from a laptop on the same subnet. Parse PS[0] PS[1] PS[2] — all zero flags the fault. Then issue a harmless ascset|0 read to disambiguate real comm-lost from Web UI staleness. This five-second check saves an hour of chasing a phantom fault. Canaan's stock Web UI will sometimes report 'OK' because the hashboards are enumerating while PS[0..2] is actually dark — the API tells the truth.

Verify the miner is still hashing at near nameplate. Same API call returns GHSavg and MW0..2. If you're at >=75 TH/s on a stock 1246 (nameplate typically ~85-90 TH/s depending on SKU and firmware), the miner is earning while you diagnose. No urgency, take your time. If hashrate has collapsed, you have a second concurrent fault that needs a separate playbook (chain-fail, hashboard-not-detected, etc.) — branch to those pages first.

Check for recent physical events. Was the miner moved, bumped, had its PSU swapped, or had its chassis opened in the last 72 hours? Was there a thunderstorm, grid switching event, or brownout? Recent physical or electrical events are the single biggest predictor of which failure category you're in. Move / service event = likely loose connector. Electrical event = possible MCU damage on PSU or control board.

Check for wrong-brand PSU. If the miner is running a Bitmain APW series PSU wired into the 1246 (wrong-brand cross-wiring is a documented failure mode — some operators try it when a Canaan PSU dies), PS[0..2] will stay zero forever because the comm protocol is Canaan-proprietary. The fix is 'use a Canaan PSU from the A1056..A1266 family.' The hashboards may be hashing fine on the 12V rail but the comm surface is dark by design.

Watch the pattern for 30 minutes. Intermittent PS[0..2] — zero sometimes, valid other times, random-seeming — almost always means a loose connector. Permanent zero across reboots and across time means dead silicon. Write a quick cron or shell loop that curls the API every minute and logs PS[0..2] with timestamps; 30-60 minutes of data separates 'cable' from 'silicon' before you open the chassis.

Re-seat the PSU signal connector at the control board. Kill AC at the PDU, wait 60 seconds for caps to discharge, open the chassis. Locate the small signal connector between PSU and control board — NOT the heavy 12V output harness. Unplug, inspect pins under bright light for blackening, oxide, green corrosion, or bent / recessed pins. Clean contact surfaces with 99% IPA and a lint-free swab if anything is visibly dirty. Re-seat firmly; feel and hear the click. Re-apply AC, let the miner boot, re-check PS[0..2] via API. This resolves the majority of comm-lost events on this chassis.

Zip-tie the signal cable to the chassis frame. If Step 6 resolved the fault, the cable is wear-prone and will do it again within weeks unless you secure it. Zip-tie the cable to a chassis rail ~10-15 cm from the connector so chassis-fan vibration cannot walk the connector loose. Zeus Mining's A1246 guide documents this exact remediation for the AUC USB cable; the same principle applies to the internal PSU signal harness.

Swap the PSU signal cable with a known-good spare. If re-seat alone didn't fix it, suspect a broken conductor inside the ribbon. Ribbons crack internally after repeated flexing (typical after 3-5 PSU removals during a miner's life) and the break doesn't show on continuity at rest — only under vibration. Pulled-from-parts cables are cheap; buy a spare and keep one in your repair kit. Swap, re-test via API.

Swap to a known-good Canaan PSU from the A1056..A1266 family. If the signal cable swap didn't fix it, the PSU's onboard MCU is likely dead even though the 12V rail is fine. Use a confirmed-working Canaan PSU: A1056 / A1066 / A1066 Pro / A1126 Pro-S / A1146 Pro / A1166 Pro / A1266 all share the same connector and comm protocol. Do NOT substitute a Bitmain APW series PSU — the pinout differs and even if the hashboards run, PS[0..2] will stay zero because the comm protocol is Canaan-proprietary.

Verify the 12V rail under load with a DMM. Double-check hygiene — the fault is named 'comm lost' not 'power lost,' but confirming the 12V rail is healthy rules out a combined fault. Probe the PSU output at the board-side harness: expect 12.0-12.6V open-circuit, >=11.8V sustained during boot. If the rail is also sagging, the PSU has progressed from comm-fault-only to power-fault-plus-comm-fault — replace immediately and branch to the avalon-1246-psu-not-detected playbook for the hard-fault case.

Cable-manage all harness routing while the chassis is open. Since you have the lid off, dress all cables away from fan blades, away from hot MOSFET areas on the hashboards, and away from sharp metal edges. Chassis fan vibration in a 1246 is non-trivial — poorly-routed cable harness is the root cause of roughly one in four return visits for the same comm-lost fault.

Capture the control-board serial log at boot via USB-TTL. Connect an FT232 / CH340 / CP2102 USB-TTL adapter to the control-board UART header (location on silkscreen — varies by AUC3 revision). Capture the full boot log during a cold boot. MM firmware logs PSU handshake attempts, IIC / serial init results, and any 'PSU init failed' / 'PSU handshake timeout' messages. A persistent handshake timeout at boot after confirmed swaps points to the control-board comm transceiver. No handshake attempt at all in the log points to MM firmware fault; re-flash factory MM as a sanity step.

Scope the signal line during a known ascset|0 write. A 50 MHz handheld scope (Hantek / Siglent entry-level) on the signal line captures physical-layer integrity. From the laptop, issue a benign ascset|0 read command in a tight loop. Healthy: clean digital transitions at the expected baud, valid response frame from the PSU within milliseconds. Comm-lost: either no transmit activity (control board not sending), transmit without response (PSU not receiving / replying), or corrupted / noisy transitions (physical-layer integrity issue). Distinguishes the three sub-cases in under five minutes.

Tune CGMiner --avalon7-aucspeed and --avalon7-aucxdelay if the fault correlates with IIC-adjacent behaviour. Defaults per the cgminer source are aucspeed=400000 and aucxdelay=19200. If the control-board-to-PSU comm channel shares any silicon path with the IIC bus (revision-dependent) and the IIC bus is marginal from worn ribbon or vibration, halving aucspeed to 200000 or doubling aucxdelay to 38400 can restore reliable comm. Undocumented in Canaan materials; lives only in the cgminer CLI.

Inspect the control-board comm-transceiver chip under magnification. A dead comm transceiver IC on the control board often shows hairline package cracks, discoloured solder pads, or a scorched silkscreen mark from a prior surge event. Under 10x-20x magnification look for any of these near the cable-input side of the control board. Cracked MOSFET or cracked transceiver = surge damage, component-level replacement required. Visually clean = transceiver failure less likely; look at the cable again or suspect the PSU-side MCU.

Re-flash the factory MM firmware. If Step 12's serial log shows no handshake attempt at all, MM firmware itself may have a corrupted PSU-init table. Re-flash the current correct factory MM image via the AUC3 Web UI. VERIFY the image is for 1246 specifically — cross-flashing a 1166 Pro or 1266 image onto a 1246 bricks the control board because Canaan signature-checks per-model and blocks downgrade. See avalon-1246-firmware-flash-failure for proper flash procedure and recovery.

Replace the control-board comm transceiver (if you have the skill set). Preheat bottom side to ~150°C, hot air top-side at ~320°C, desolder the suspect IC, clean pads with braid + flux, place replacement, reflow down. Use the EXACT part number from silkscreen — substitutes with different protocol support fail immediately. If you don't have preheater + hot-air + SMD experience, ship the control board rather than risk lifting pads.

Replace the PSU-side MCU (if you have the skill set and a known-good donor). Canaan PSUs are repairable at the component level if you have a parts-donor PSU with a healthy comm MCU and the desoldering skills to transplant it. D-Central's bench does this regularly; most home shops do not. If attempting it, pull the donor MCU first and verify it's alive on a breadboard with a serial loopback test before transplanting. If the donor is cooked too, buy a new PSU instead.

Stop DIY when both swaps (PSU and control board) with known-good parts don't restore PS[0..2]. The fault is in the chassis wiring harness OR the cable OR there's a combined fault across multiple components. At that point, the diagnostic path needs a bench fixture with programmable loads and a logic analyzer — not DIY gear. D-Central's bench process isolates the comm channel against a known-good PSU and a known-good control board, then substitutes one component at a time until PS[0..2] returns valid bytes.

Stop DIY when you see burnt silicon, cracked packages, or discoloured pads on the control board. Surge damage to the comm transceiver often correlates with damage to adjacent silicon — input-side MOSFET, 3.3V regulator, MCU. Replacing only the visibly-burnt part leaves the miner vulnerable to the next surge event because adjacent damaged-but-working parts will fail next. D-Central's bench recaps and re-checks the whole input-protection chain, not just the named failure part.

Ship with full context. Pack the chassis with the PSU (we need your exact stack to reproduce the fault), a copy of your last PS[0..2] API response, service history (when opened, what was swapped, when the comm-lost first appeared), and any ascset|0 responses you captured during diagnostic. Every minute of context is a minute of bench time saved and a minute of turnaround shortened. Serial number on the chassis matches the serial on the PSU — include both. Canada-wide standard shipping, US / international welcomed.

Discuss repair-vs-replace on the PSU specifically. A compatible A11-series PSU costs CAD $180-420 new or graded-salvage. A component-level comm-fault repair at D-Central bench runs CAD $75-160. If the PSU is 5+ years old and the comm MCU has died, the rest of the unit is at end-of-life on the same timeline — repair might be false economy. D-Central quotes up front so you can choose. For control-board-side comm-fault, repair almost always wins economically — control boards cost more than PSUs and have more failure paths.