Avalon 1246 – LED Error Pattern
Warning — Should be addressed soon
Symptoms
- Chassis LED on the A1246 lid shows sustained red for 60+ seconds after initial boot completes
- AUC3 USB controller LED shows sustained red while chassis LED is green, or vice-versa
- Chassis LED stuck on yellow past the 5-minute boot window, never transitions to green
- Chassis LED on white with rapid flash (bootloader active, main control not handed off)
- AUC3 LED alternates blue/red without ever stabilizing
- LED reads green but `SYSTEMSTATU` in `cgminer-api stats` reports fewer than 3 active hashboards
- LED reads green but dashboard hashrate sits at 0 GH/s or drifts 20%+ below nameplate 90 TH/s
- AUC3 LED flickers red every 10-60 seconds synchronized with pool share submissions
- Red LED correlates with `CODE_MMCRCFAILED`, `E: no asics!!!`, or `ascset` errors in `cgminer.log`
- `cgminer-api stats` shows non-zero `ECHU` array, non-zero `ECMM`, or any `PS[0]` bit set
- LED state changes under thermal load (green at idle, red after 5-10 min of full hashrate)
- Fans never ramp past idle RPM despite red LED suggesting thermal fault (tach loss misread)
Step-by-Step Fix
Hard power-cycle the rig at the PDU for a full 60 seconds. Wait for complete reboot and LED re-sequence before touching anything else. Many sustained-LED events are cgminer session wedges that clear with a cold boot — the 60-second off cycle clears driver state that a soft reboot or web-UI restart will not. This single step resolves roughly a third of inbound LED tickets at the D-Central bench.
SSH to the controller and capture the full diagnostic snapshot *before* touching hardware: `cgminer-api -o estats`, `cgminer-api -o pools`, `dmesg | tail -100`, and `cat /var/log/cgminer.log | tail -200`. Save the output to a file. This snapshot is the single most valuable artifact for later diagnosis and it evaporates the moment you reboot — without it, you are back to guessing from a one-colour LED.
Compare chassis LED and AUC3 LED states side by side. Photograph both. Confirm which LED is showing the fault; do not troubleshoot the wrong one. The chassis LED is driven by MM firmware and reports hashboard / thermal / PSU health. The AUC3 LED is driven by the USB bridge and reports IIC bus / pool communication health. These are different fault domains with different fix paths.
Verify ambient inlet air temperature at the front grille with an IR thermometer or thermocouple. Target ≤ 35 °C on the A1246 (inherits A1066 chip thermal limits — max chip 85 °C, average 68 °C). If ambient is over 35 °C, chassis LED red may be a legitimate thermal protection trip — improve airflow, reduce room temp, add ducting, and retest before assuming a hardware fault.
Check upstream network connectivity from the controller: `ping 1.1.1.1` for general Internet, `ping <pool-hostname>` for pool reachability. If DNS resolves but pool TCP connect fails, this is a network issue, not a miner hardware issue — AUC3 LED red can mislead you toward hardware when the fault is actually upstream. Verify pool credentials and stratum endpoint while you're in the config.
Measure AC input voltage at the PSU under full load. Multimeter on AC, probe the inlet while miner is hashing at stock 90 TH/s. Expect 235-245 V on 240 V split-phase or 202-212 V on 208 V commercial. Low line voltage trips `PS[0] = 1` (`Input_UV`) or `PS[0] = 16` (`OC_Pri`). Canadian residential miners commonly see this during evening peak load — the fix is a dedicated 240 V circuit or a line-interactive UPS.
Measure DC output at PSU-to-board connectors under load. Multimeter on DC, probe the 12 V rails while miner is hashing at stock. Expect 12.0 V nominal, 11.8-12.2 V acceptable. Below 11.5 V sustained = PSU tired or circuit undersized. Canaan's A1246 manual specifies 3100-3300 W as the normal power-output range; any consistent deviation is a PSU health flag. Swap with a known-good unit to confirm before ordering replacement.
Reseat the AUC3 USB cable between the controller board and the AUC3 module. Power off at the PDU first. Inspect connectors for corrosion, bent pins, or cracked strain relief. Use a proper shielded USB-A-to-USB-B data cable (a charging-only cable enumerates but drops packets on the IIC bus). Zip-tie the cable to the chassis afterward to prevent vibration-induced disconnects — Zeus Mining documents this as the #1 cause of intermittent A1246 AUC red-LED events.
Reseat the three MM ribbon cables between the controller and each hashboard. Power off at the PDU. Inspect pins for bent contacts, oxidation, blackening, or mechanical damage. Listen for the click when reconnecting each cable. If the chassis LED returns to green after reseating, the fault was a mechanical contact issue — zip-tie the ribbons to prevent recurrence. Do one board at a time so you can retrace if the fault moves.
Swap hashboards between slots 0/1/2 to isolate a bad board. Label each slot with tape before swapping. Power up, observe chassis LED and `SYSTEMSTATU` value in `cgminer-api stats`. If the fault follows the board, the board is bad and you move to Tier 3 repair. If the fault stays in the slot, the control board or AUC bus is bad and you move to Step 13 / Tier 4.
SSH in and dump the full `cgminer-api estats` output, then decode `PS[0]` against the 12-bit table: bit 0 = `Input_UV`, 1 = `OT1`, 2 = `OT2`, 3 = `OT3`, 4 = `OC_Pri`, 5 = `UV_out`, 6 = `OC_out`, 7 = `CS_error`, 8 = `OC_IOSA`, 9 = `OC_IOSB`, 10 = `OC_IOSC`, 11 = `FAN_error`. Each set bit is a targeted remediation. This step transforms the chassis LED from a one-bit signal into an actionable diagnostic — the single highest-leverage Tier 3 move.
Flash a known-good A1246 firmware image matching your hardware revision. Source the image from `avalonminer.org/firmware-document/`. Use a wired Ethernet connection during flash — controller Wi-Fi drops mid-flash cause half-written images Canaan's signed-firmware model cannot rollback from. Never mix controller and MM firmware versions across hardware revisions; Canaan's bundles must be flashed together for the signature check to pass.
Tune the AUC3 IIC bus back to stock speed. If you've experimented with `--avalon7-aucspeed` or `--avalon7-aucxdelay` in the cgminer config, revert to default. Non-default IIC speed is a frequent cause of intermittent AUC3 red LED that clears on reboot and returns under thermal load. Default-stock is the correct setting for 99% of operators; the tuning flags exist for edge cases that are not your rig.
Re-apply thermal paste on the worst hashboard if `PVT_T` shows a consistent per-chip hot spot above 85 °C. Use Arctic MX-6 or Thermal Grizzly Kryonaut. Thin uniform layer; clean existing paste with 99% isopropyl alcohol and lint-free wipes first. Pay attention to thermal pads on the power regulation ICs — dried pads are a common drift cause that presents as LED red on thermal-trip without any single chip being bad.
Visually inspect caps and MLCCs around the MM power regulation stage. Bulged electrolytics, cracked MLCCs near PMIC or voltage domain ICs, or dark spots on the PCB require soldering-iron work. Replace with matching footprint and voltage-rating parts. This is Tier 3 for a confident solder-station operator with hot air; it's Tier 4 for anyone without. Do not guess on cap values — match existing parts.
Stop DIY when: chassis LED stays red across two different hashboards swapped into the same slot (PCB-level or control-board fault); `PS[0]` bits 128/256/512/1024 stay set (PSU channel-level fault requires bench parts); `ECHU` stays non-zero after reflow + paste + caps (chip-level repair needs test fixture); or you see cap bulging / burnt smell (stop before adjacent components take damage). Book a D-Central ASIC Repair slot at this point.
D-Central bench process for Avalon A3206-silicon rigs: A3206 test fixture with programmable AUC3 load, per-MM isolation using Canaan MM firmware debug hooks not exposed in stock firmware, chip-level reflow with calibrated hot air, capacitor and PMIC replacement from salvaged-grade A1246 inventory, post-repair 24-hour nameplate burn-in, and full `cgminer-api` healthchecks before return shipping.
Ship safely. Pack hashboards in anti-static bags, double-box with ≥5 cm foam on every side. Include a printed note with the `cgminer-api estats` snapshot from Tier 1 Step 2, your firmware version, chassis + AUC3 LED states observed, and your contact info. This one page of context typically shaves 30-60 minutes of diagnostic time at the bench, which directly reduces your repair cost.
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.
