Passer au contenu

Nous améliorons nos opérations pour mieux vous servir. Les commandes sont expédiées normalement depuis Laval, QC. Questions? Contactez-nous

Bitcoin accepté au paiement  |  Expédié depuis Laval, QC, Canada  |  Soutien expert depuis 2016

FAN_FAULT Critical

Avalon 1246 – Fan Speed Error

Fan Speed Error — one of the four 12 V chassis fans (or the PSU internal fan, reported via PS[0] = 2048) has stopped reporting RPM or is outside the expected tachometer window. Critical: chip junction temp spikes past 85 C within 60 seconds on three-fan airflow.

Critical — Immediate action required

Affected Models: Avalon 1246 (all sub-revisions: 1246-83T, 1246-87T, 1246-90T)

Symptoms

  • Web UI at http://<miner-ip>/ shows Fan1/Fan2/Fan3/Fan4 reading 0 RPM or one fan 10%+ divergent from the others at the same duty cycle
  • CGMiner API on port 4028 returns a Fan[] array with a zero entry or non-zero ECMM module management error
  • Red chassis LED sustained (not blinking) — shared with six other faults on the 1246
  • Dashboard hashrate (GHSavg) drops to zero within 30-120 seconds of the fault
  • PVT_T0 / PVT_T1 / PVT_T2 chip temperature arrays climb past 85 C before the miner halts
  • Audible: one fan spins down to silence, or clicking/scraping sound just before the UI flags the fault
  • kern.log / MM log shows repeated `fan[N] rpm out of range` or `FAN_error` lines
  • PS[0] status bitmap reads 2048 (decimal) = bit 11 = PSU internal FAN_error — distinct from the four chassis fans
  • Miner reboots itself in a 2-5 minute cycle: boot, hash briefly, fault, halt, reboot
  • One fan running at 100% duty cycle permanently while the others modulate — MM controller compensating for a ghost reading

Step-by-Step Fix

1

Hard power cycle at the breaker. Wait 60 seconds for all 12 V rails to discharge, then power back up. Watch the UI for the first 3 minutes post-boot. Phantom FAN_FAULT events from an AUC3 I2C timing glitch often clear on a cold boot. If this clears the fault, log the ambient temperature at the moment of failure — you have a marginal thermal environment, not a hardware failure, and the real fix is better airflow or lower ambient.

2

Open the top panel (four Phillips #2 screws). Shine a phone flashlight across each fan hub. Look for dust buildup on blades and around the hub magnet, objects lodged in the blades (wire ties, dropped washers, dust pillows), or discolouration indicating heat damage. Dust on the hub is the #1 cause on Canadian home-miner 1246s — heating season forces miners into furnace-adjacent environments where dust load is high.

3

Shop-vac the front intake grille, then blow out each fan with dry compressed air. Hold the fan blade with a toothpick so it does not over-spin — over-spinning damages the bearing worse than the dust ever did. Wipe each fan hub cap with 99% IPA on a lint-free wipe. Re-install and boot. Roughly 30% of FAN_FAULT reports to D-Central are actually heavily contaminated fan calls resolved at this step.

4

Verify inlet ambient temperature is at or below 35 C with an IR thermometer at the front grille (not room-middle). Ensure nothing sits within 15 cm of the intake. If the 1246 is in a closet or recirculating its own exhaust, the controller enters thermal protection in a way that reads almost identical to a fan-speed fault on the dashboard. Move the miner, duct the exhaust outside the living space, or ventilate the room.

5

Power off at the breaker. For each of the four fans, unplug the 4-pin PWM connector from the MM control board, inspect the pins for oxidation (greenish tint) or mechanical damage, plug back in firmly until you feel the retention click. Apply a drop of dielectric grease on re-seat. Vibration from 24/7 operation walks connectors loose after 6-12 months — this one step catches a surprising number of persistent faults.

6

Multimeter on DC, probe the 12 V PSU output while the 1246 is hashing at full power. Expect sustained 12.0-12.3 V. Below 11.6 V sustained indicates a sagging PSU — fan tach signals ride on rail stability, so a tired PSU produces erratic RPM readings that look identical to a dying fan. Swap PSU with a known-good AVA10-2200 to isolate. The AVA10-2200 uses a bus-bar output, so probe at the chassis input, not at a loose wire.

7

Swap the suspect chassis fan with a known-good unit. Spec: 12 V 4-pin PWM, 120 mm x 38 mm, ~6000 RPM max, ≥250 CFM, high static pressure. Delta AFC1212DE (OEM on most 1246 builds), Delta QFR1212GHE-PWM, or Sanyo Denki 9G1212H104 are direct fits. Avoid low-noise server fans — insufficient static pressure through three hashboards causes chasing thermal faults. Secure with all four Phillips screws; a missing screw causes vibration harmonics that walk the others loose.

8

Test each fan across all four MM board headers. Power off, move each fan through headers 1 through 4 one at a time, powering briefly to read RPM. If a specific header never reads RPM regardless of fan, the MM tach circuit for that channel is dead (Tier 3 repair). If a specific fan never reads RPM regardless of header, the fan is dead (direct swap). This isolation takes 10 minutes and distinguishes fan hardware from MM hardware faster than any other test.

9

Query the PSU status bitmap to confirm whether the fault is a chassis fan or the PSU internal fan. Command: `echo '{"command":"ascset","parameter":"0,ps,0"}' | nc <miner-ip> 4028`. If bit 11 of the returned PS[0] array is set (value 2048), the failure is inside the sealed PSU, not the chassis. Document the PS[0] value and ambient temp at fault — this is useful context if you ship to D-Central for PSU service.

10

Clean the AUC3 controller contacts. Power off, unplug the AUC3 USB cable and the 2x5 IDC ribbon to the MM board, clean contacts with 99% IPA and a dental pick, re-seat. A tired AUC3 header produces I2C bus errors that surface as phantom fan faults, especially at high ambient. This is a free, 5-minute check that resolves intermittent FAN_FAULT events on older 1246 deployments.

11

Flash a known-good Canaan MM firmware for the 1246. Download signed images from avalonminer.org/firmware-document/, flash via AUC3 with the miner idle. Observe 30 minutes for phantom faults. If the fault clears after rolling one version back or forward, log the buggy version string for the community. DCENT_OS does NOT run on Avalon hardware — it is D-Central's open-source Antminer firmware, wrong silicon family here. Stick with Canaan signed images.

12

Tune the AUC3 I2C bus timing if phantom FAN_FAULT events persist at high ambient. In cgminer set `--avalon7-aucspeed 400000 --avalon7-aucxdelay 24` (defaults are 400000 / 40). Lower aucxdelay tightens the bus sampling window and prevents tach-read misalignment with the fan controller's PWM update edge. This is undocumented in Canaan's public material but referenced in the ckolivas cgminer ASIC-README for the Avalon7/8/10 family.

13

Replace the MM board fan header MOSFET if a specific header is dead. Use a 3x loupe to identify the failed part (discolouration, cracked package, blackening around the PWM FET or tach pull-up). Desolder with hot air at 300-320 C, replace with same package and spec, verify continuity with a multimeter before re-powering. Expect 30-60 minutes of bench work per failed header. If you are not confident with SMD rework at this scale, skip to Tier 4.

14

Bearing-repack a Delta sleeve fan as a temporary measure while waiting on replacement stock. Peel the hub sticker, apply one drop of Teflon-based sewing machine oil to the bearing, re-seal with the sticker or a small square of Kapton tape. Adds 3-6 months to a dying sleeve-bearing fan. Does not work on sealed ball-bearing fans. Not a permanent fix — order the replacement.

15

Inspect MM board rail regulators. A damaged 12V-to-5V or 12V-to-3.3V buck converter causes the tach-reading MCU to read noise as RPM fluctuations. Measure at test points (refer to Canaan board silkscreen or community reverse-engineered pinouts). Any rail more than ±5% off nominal means the MM needs component-level repair or replacement. Voltage reference: 5V rail at 4.75-5.25 V, 3.3V rail at 3.13-3.47 V. Outside those windows, stop and ship.

16

Know when to stop DIY. Ship to D-Central when: PSU internal fan has failed (PS[0] = 2048) and you lack live-rail PSU experience; multiple MM fan headers are dead simultaneously; a replacement fan shows the same fault; MM board shows burnt components or bulging caps; the AUC3 is bricked after a flash attempt. Book a repair slot at d-central.tech/services/asic-repair/. Turnaround 5-10 business days, Canada-wide shipping, US and international welcomed.

17

D-Central bench process: test fixture with programmable load for sustained fault reproduction, per-channel fan header isolation using a known-good fan harness, AUC3 bus capture (logic analyzer) for I2C timing bugs, PSU recap or full replacement on sealed AVA10-2200 units, MM component-level repair covering the tach-MCU, I2C controller, and rail regulators. Every repair gets a post-repair 24-hour burn-in at nameplate hashrate before return ship, with hashrate and fan-RPM logs included in the ticket.

18

Ship safely. Pull the PSU and the three hashboards separately from the chassis. Pack each hashboard in an anti-static bag; wrap the chassis in 5 cm of foam on every side; double-box. Include a note with observed symptoms, whether the fault is intermittent or constant, MM firmware version, PS[0] value if you captured it, the ambient temperature at fault, and your contact info. Every piece of context you include at shipping saves diagnostic time at the bench — and diagnostic time is what the repair bill buys.

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.