Avalon – AUC USB Connection Lost

Power-cycle the whole rig for 30 seconds at the PDU. Not a soft reboot — a real cold power-down. Clears USB session state and any latched FTDI weirdness at the host and AUC3.

Re-seat the USB cable at both ends. Push until you feel the click at the USB-B end on the AUC3 and the USB-A end at the controller. The USB-B end is your #1 suspect — fan vibration works it loose first.

Watch the AUC3 LED during boot. Blue = initialising or idle, green = working normally, red = comm issue or rejected shares (per the 2018 Canaan PDF, which conflates hardware-comm and pool-reject into the same red state).

Verify pool settings haven't changed. Since Canaan's red-LED state conflates hardware and pool, confirm you can reach your pool from another device. `ping stratum.poolname.com` and `telnet stratum.poolname.com <port>` are valid quick checks.

Override the default DNS. Stock Avalon firmware defaults to `114.114.114.114` (a Chinese public DNS that resolves unreliably outside China). Set the miner DNS to `8.8.8.8` or `1.1.1.1` to eliminate a whole class of ambiguous 'is it USB or is it DNS' failures.

Zip-tie the USB cable to the chassis frame to stop it hanging off the AUC3 port under fan vibration. Zeus Mining documents this fix for the A1246 specifically; it applies to every AUC3-based Avalon.

Swap the USB cable with a known-good shielded USB-A-to-USB-B, 1 m maximum, ferrite bead preferred. Long (2-3 m) cables collect noise on data lines and drop under load. Short + shielded eliminates an entire failure vector.

Move the cable to a different USB port on the controller. On a Raspberry Pi, use the port farthest from the Ethernet jack — the onboard USB controller shares bandwidth with Ethernet on older Pis, and a heavy pool-side stream can starve USB.

Check `dmesg` / `journalctl -k` on the host for enumeration. SSH in, run `dmesg -w`, then pull-and-re-insert the AUC3 USB cable. Expected: `usb X-Y.Z: new full-speed USB device number N` followed by `FTDI USB Serial Device converter now attached to ttyUSBx`. Missing the second line = driver or permissions; missing both = hardware or cable.

Verify the host user is in the `dialout` group on Linux. `groups $USER` should include `dialout`. If not, `sudo usermod -aG dialout $USER` and re-login. Fixes the #1 'FTDI enumerates but cgminer can't open it' failure on custom controller images.

Reinstall the FTDI driver on Windows. Download the official driver from ftdichip.com rather than relying on Windows Update. Zeus Mining documents FTDI driver conflicts as a root cause of AUC 'socket connect error'.

Test DC power at the AUC3. The AUC3 runs off USB 5 V. Some controllers sag below 4.75 V under load, and the FTDI bridge gets unhappy below 4.5 V. Multimeter on DC at the USB-B jack's +5 V / GND pins while the rig is running; expect >=4.8 V. Below that, power the AUC3 via a powered USB hub.

Drop AUC3 IIC speed and raise transfer delay. Edit cgminer launch config and set `--avalon7-aucspeed 200000 --avalon7-aucxdelay 24000` (substitute `avalon8` or `avalon10` for matching generation). These flags are undocumented in Canaan's materials but live in the cgminer ASIC-README. Conservative values double bus headroom.

Split long daisy chains across two AUC3s. One AUC3 supports up to 5 MMs. Six or more is unsupported; beyond 3-4 on older AUC revs you see intermittent CRC failures even with a perfect cable. If you're running 5+ MMs on one bridge, order a second AUC3.

Reflash the controller SD card. On A11/A12-era Avalons the controller is typically a Raspberry Pi running Armbian/OpenWrt. SD-card write-wear degrades the filesystem over 2-3 years of continuous logging. Dump current config, image a fresh SD from Canaan's firmware portal or a verified community image, boot from the new card.

AUC3 isolation swap. Pull the suspect AUC3, label it, install a known-good AUC3, restart cgminer with original defaults. Fault follows the AUC3 to a second rig = dead AUC3, order replacement. Fault stays on the first rig with the known-good AUC3 = chassis IIC harness or MM #1 is the problem.

Run cgminer standalone on a Linux PC with the AUC3 and hashboards in the daisy chain. If the fault clears, the on-chassis controller or its SD card is the problem; if it follows the AUC3, the AUC3 is dead. Fastest way to isolate controller vs AUC3 without buying a replacement AUC3.

Check for an FTDI chip-level fault with a USB-protocol analyzer (Saleae Logic or equivalent). Capture the USB enumeration handshake. An AUC3 that enumerates but drops under load will show bulk-transfer NAKs or STALLs. Bulk errors at the USB layer = FTDI bridge is dying and no cable/driver work will help.

Stop DIY when: the AUC3 swap proves the AUC3 dead but you don't have a replacement, OR a known-good AUC3 still drops on your rig, OR the controller shows storage corruption that reflash doesn't fix. Book a D-Central ASIC Repair slot at https://d-central.tech/services/asic-repair/ .

Ship safely. Place the AUC3, suspect USB cable, and the controller each in its own anti-static bag. Double-box with >=5 cm of foam on every side. Include a note with observed symptoms, firmware version, `dmesg` excerpts, cgminer log snippet, and flag any non-stock cgminer flags so we can match config at the bench.