Avalon Series – AUC USB Connection Lost Guide

Hard power-cycle at the PDU for 30 seconds. AC-off, count to 30, AC-on. Soft reboots don't always re-init the USB host stack on the Avalon controller. After 60-90 second boot, curl the cgminer API on port 4028 and check PS[0..2]. About one in five AVALON_AUC_USB_LOST events clears with a cold power-cycle alone — the controller's USB stack was wedged and the bus re-enumerated cleanly on cold boot.

Confirm the fault via the cgminer API instead of trusting the Web UI. curl http://<miner-ip>:4028 -d '{"command":"estats"}'. Parse PS[0], PS[1], PS[2] — zeros or empty = real fault; valid bytes = Web UI staleness. The Web UI is known to lag the actual fault state by 30-120 seconds on most Avalon MM firmware builds. Five-second check that saves an hour of phantom-chasing.

Watch for a pattern across 30 minutes. Run a one-line shell loop on a laptop: while true; do curl -s http://<ip>:4028 -d '{"command":"estats"}' | grep -E 'PS[' ; sleep 60 ; done. Intermittent zeros = cable / connector / vibration. Permanent zeros = silicon. The data separates the two failure paths in 30-60 minutes before you open the chassis.

Check for any recent physical event in the last 72 hours: miner moved, bumped, PSU swapped, chassis opened, thunderstorm, brownout, grid switching event. Recent physical events almost always point at the cable or a loose connector. Recent electrical events almost always point at the PSU MCU or controller-side USB silicon. The history narrows the search before you pick up a tool.

Visually inspect both ends of the AUC cable without unplugging anything yet. Wiggle the cable at each connector while watching PS[0..2] on the API in real time. If the fault state changes when you wiggle either connector = cable / connector mechanical issue confirmed; you don't need any further diagnostic before swapping the cable.

Swap the AUC USB-A to USB-B cable with a known-good <=1 m cable with a clip-on ferrite. Power off at the PDU, wait 60 seconds. Unplug both ends of the existing cable. Inspect connectors for blackening, oxide, pin recession. Plug in the replacement. Power on, wait for 60-90 second boot, re-check PS[0..2]. If the fault clears, zip-tie the new cable to the chassis frame 10-15 cm from each connector — vibration is what killed the original. Keep two spare cables in your repair kit at all times.

IR-thermometer the AUC dongle casing under load. Run the miner under steady-state mining for 15 minutes, then point an IR thermometer or thermal camera at the AUC dongle. Healthy: <=45 C casing. Marginal: 45-60 C. Failing: >60 C or you can't hold a finger on it. A hot dongle is a leading indicator that the USB transceiver inside is going out of regulation. Re-locate the dongle to free air, mount a 40mm fan blowing across it, re-test.

Re-seat all USB connectors on both ends. With AC off, unplug the AUC cable at the controller, at the AUC dongle, at the PSU-side harness if applicable. Inspect for visible damage. Clean contact surfaces with 99% IPA and a lint-free swab if there's any dust, oxide, or sticky residue. Reconnect firmly — feel and hear the click on USB-B latches; on USB-A, feel for the friction-fit seating depth.

Multimeter the 12V rail at the board-side harness while hashing. Probe DC under full-load mining. Expect >=11.8 V sustained, 12.0-12.6 V typical. If the rail is sagging, the PSU has progressed from comm-fault-only to combined comm + power fault — replace the PSU and branch to avalon-1246-power-supply-communication-lost for the combined-fault playbook.

Add a USB-A to USB-B extension cable plus a second clip-on ferrite if the AUC dongle has to live in a hostile location — behind a fan exhaust, in a recessed corner, in immersion fluid. Run a 1-2 m extension to relocate the dongle to a friendlier spot. This is one of the most common D-Central retrofit recommendations on 1346 / 1366 / 1466 chassis where Canaan's stock cable layout puts the AUC in airflow dead zones.

SSH into the controller and tail -f /tmp/log while the fault is live. Default root / model-specific password (recover via avalon-1346-ssh-unreachable if locked out). Watch for AUC USB read err, usb_bulk_transfer timeout: -110, AUC re-init, auc_xfer failed: -71. The exact line tells you which layer is failing — physical layer (transceiver / cable), protocol layer (firmware mismatch), or host layer (controller USB stack).

dmesg | tail -50 on the controller for kernel-side USB messages. Look for usb 1-1: device descriptor read/64, error -71 or usb 1-1: device not accepting address X, error -71. These are kernel-level USB enumeration failures that point at the controller-side USB host silicon or PHY, not the cable. Cross-confirm by swapping a known-good AUC dongle into a different controller and seeing if the fault follows the controller.

Force-reset the controller's USB host stack without rebooting: echo 0 > /sys/bus/usb/devices/usb1/authorized && sleep 2 && echo 1 > /sys/bus/usb/devices/usb1/authorized. This re-enumerates USB on the host side without a full chassis reboot. If this recovers the fault temporarily but it returns within minutes, the controller's USB stack is unstable — typically SD-card filesystem rot.

Re-flash the factory MM firmware for your specific chassis model. Verify the MM image matches your hardware: 1166 MM != 1246 MM != 1346 MM != 1366 MM != 1446 MM != 1466 MM != 1566 MM. Canaan signature-checks per model and a wrong-model flash bricks the controller. Use the AUC Web UI flash path or stage a known-good image. See avalon-firmware-flash-via-auc for procedure and avalon-1246-firmware-flash-failure for recovery.

Swap the AUC dongle with a known-good unit from the same revision generation: AUC2 to AUC2, AUC3 to AUC3, AUC4 to AUC4. Cross-revision swaps are NOT guaranteed — connector mechanics differ between AUC3 and AUC4, and firmware signing differs across generations. If the swap clears the fault, the original dongle's transceiver or onboard regulator is dead — discard or salvage as a parts donor.

Re-image the controller SD-card from a known-good factory image. SD-card filesystem corruption is the silent killer of 2+ year Avalon controllers. After repeated power events, the ext4/JFFS2 partition develops bad blocks, the USB host stack starts mis-firing, and you get chronic AVALON_AUC_USB_LOST that cable swaps don't fix. Pull the SD-card, image a fresh factory build (model-specific), reinstall, re-flash MM, re-test.

Swap to a known-good Canaan PSU from the same family. A1056..A1266 share comm protocol within their generation; A11/A12-series variants for 1346/1366/1446/1466/1566 share their own family. Do NOT substitute a Bitmain APW9 / APW12 — pinout and protocol differ; even if the 12V rail comes up, the comm surface stays dark. Re-test PS[0..2] via API after swap.

Stop DIY when three known-good components (cable, AUC dongle, PSU) plus a clean controller still don't restore comm. At that point the fault is in the chassis-internal harness, the controller's USB host silicon, or there's combined multi-component damage from a surge event. None of those are home-bench fixable without a programmable load, a logic analyzer, and bench fixtures for comm replay. Book a D-Central ASIC Repair slot.

Stop DIY when you see burnt silicon, cracked packages, or scorched silkscreen on the controller, AUC, or PSU. Surge damage almost never affects only the visibly-burnt component — adjacent input-protection silicon, regulators, and MCUs share the same surge path and accumulate latent damage that fails next. D-Central's bench recaps the whole input-protection chain, swaps any visibly-damaged silicon, and verifies survivors with a programmable surge-recurrence test.

Stop DIY when the fault correlates with a thermal or vibration condition you cannot reproduce on the bench at home. D-Central's bench has thermal chambers and vibration tables specifically for chasing intermittent comm faults. If your AUC drops only when ambient >30 C, only when the chassis fans are at full duty, or only after 4+ hours of continuous load, that's a bench-reproduction job — not a home-shop one.

Ship the full stack with context. Pack the chassis with the AUC dongle, the cable, and the PSU (we need your exact stack to reproduce the fault), a copy of your last PS[0..2] API response, the MM firmware version string, the AUC firmware version string, your service history (when opened, what was swapped, when the fault first appeared), and any dmesg or /tmp/log excerpts you captured. Every minute of context is a minute of bench time saved and a dollar of repair cost off your invoice.