Avalon 1466 – Fan Speed Error

Power down at the PDU and confirm the thermal state first. The A1466 will keep trying to hash with one fan down - don't let it. At the PDU, not the web UI, not the power button, kill the breaker. Open the chassis within 2 minutes so residual heat dissipates before you probe. A dead fan on a 3,400+ W miner running an extra 10 minutes can cook thermal pads and shorten hashboard life by months. Higher nameplate wattage than the A1366 means thinner thermal headroom - don't run it with a known fan fault.

Read the log, write down the fan number. On the miner's web UI or via `estats` over the API (`echo '[{"command":"estats"}]' | nc <miner-ip> 4028`), record exactly which fan position reports `0`. Is it `Fan1`? All four? One per hashboard? Position dictates the repair. Screenshot or copy/paste the response. This artifact is the difference between a 20-minute fix and a 2-hour scavenger hunt, and it's what D-Central's bench asks for first if the miner ends up shipping.

Blow the suspect fan out with canned air. Upright can, short bursts. Hold the blade still with a plastic probe while blasting - spinning through airflow induces back-EMF that stresses a tired bearing and can finish off a marginal fan. Dust dams on the hub are the most common cause of a fan that looks fine but reads zero RPM. Basement shop, garage miner, or any pet within 50 metres of the rig? This step fixes the fault about 15% of the time and costs nothing. Blow out the intake and rear exhaust grilles while you're there.

Check ambient at the intake. Use an IR thermometer at the front grille, not in the middle of the room. The A1466's thermal governor is designed around `<=35 C` inlet. If your intake is already at 38 C because it's July in Ontario and the garage has no cross-ventilation, the fan controller may be running the survivors at 100% duty and you're hearing that, not a fault. If every fan reads real RPM but one is pegged at `0`, it's not ambient - it's the fan. If all fans are above 6500 RPM and the box is loud, it's ambient. Different problem, different fix.

Reseat the fan connector at the control board. Power off at the PDU. Wait 60 seconds. Pop the lid. Locate the 4-pin fan header matching the log's fan position against the silkscreen. Unplug, inspect the shell for bent pins or a crushed plastic latch, reseat firmly until you feel the click. This alone fixes roughly 60% of `Fan[0]` tickets on Canaan MM3-family boards. Before reassembling, put a tiny dab of dielectric grease on the pins - vibration is what backed the connector out the first time. Route the cable clear of the chassis lid before you close up.

Inspect the fan cable end-to-end. Look for: chafe points where the cable runs past sheet-metal edges (especially at the corner of the rear fan housing), strain-relief damage at the fan-side terminal, discoloration from heat, or obvious crush damage from the lid being reinstalled over a pinched cable. Replace the harness if anything looks off. The convention on 4-pin PWM fans in this class is GND / +12 V / TACH / PWM - verify against the silkscreen on your specific control-board revision before assuming. Generic PC 4-pin fan extensions do not meet the current rating.

Swap the suspect fan into a known-good position. Four fan headers on the control board, four fans in the chassis. Move the suspect fan's harness to a position you know is working. Power on, re-read `estats`. If the suspect fan now spins and reads correctly in the new slot, you've isolated the fault to the original slot - a board-side issue that is Tier 3/4 territory. If the suspect fan still reads `0` in a known-good slot, the fan itself is dead and needs replacement. Saves you from ordering a new fan when the real fault is a blown SMD fuse on the board.

Measure the +12 V rail at the dead fan header under load. Multimeter on DC, probe V+ to GND on the control-board fan header while the miner is powered on and the fan controller is commanded to spin (`ascset|0,fan-spd,90` via the API). Expect 11.8-12.2 V steady. Below 11 V or reading nothing = blown SMD fuse or supply-rail fault on the control board - Tier 3. Healthy 12 V rail with a still-dead fan = fan or harness, replace. This is the single most important measurement on a suspected board-side fan failure and it takes about 90 seconds once the lid is off.

Set manual fan speed via the API as a diagnostic. `echo '[{"command":"ascset","parameter":"0,fan-spd,90"}]' | nc <miner-ip> 4028` pushes the fan controller to 90% duty. Try 20, 50, 90. A healthy fan will respond within a second - tach value should climb proportional to duty. A dead one won't. This is a diagnostic, not a fix - the setting doesn't persist across reboots on stock MM firmware. Pairing this command with Step 8's voltage measurement tells you whether the controller is even driving the rail.

Check the kernel log for `BOOTBY[0x10.*]` overheat reboots. If you find repeated entries alongside the `Fan[0]` state, the fan failure has already caused one or more overheat events and the hashboards have been through thermal cycling they shouldn't have. Plan for thermal paste refresh at the next reasonable opportunity, and watch for elevated per-chip CRC errors over the next week. Pull the full kernel log to a file and keep it - if the miner throws an `ASICCRC` fault within 30 days, the bench will want to see both logs to triage.

Replace the fan with the correct part. Confirm which stock fan your A1466 shipped with by reading the label on the housing before ordering. A1466 supply chain includes: Martech `DF1205012B2` (120 x 120 x 38 mm, 12 V / ~5.2 A) per Bit2Miner, OR `HA1250H12SB-Z` (120 x 120 x 50 mm, 12 V / 9 A dual-bearing axial) per Zeus Mining. These are NOT interchangeable - 12 mm chassis depth difference. Do not substitute a 120 x 120 x 25 mm generic PC fan - thinner fans cut airflow ~30% and you'll be back at the same diagnostic in two weeks. Confirm polarity against the silkscreen before power-on.

Replace the SMD fuse on the fan rail. If your voltage measurement in Step 8 showed the +12 V rail dead on one fan header while others were healthy, a Canaan-side SMD fuse likely popped when a previous fan seized and drew locked-rotor current. The fuse is typically a 1206-package fast-blow in the 5 A-10 A range; follow the rail from the dead fan header back to the nearest SMD component marked with the fuse code. Reflow the replacement with hot air at ~290 C and flux. Verify rail voltage returns to 12 V under a dummy load before reconnecting. If the replacement fuse blows again immediately, there's a downstream short and you're done with DIY.

Firmware check and rollback. If Steps 1-12 haven't resolved and `estats` shows all four fans at `0` plus temperature sensors at `-273 C`, you've hit a firmware bug - the I2C bus has lost its handle and the fan-tach polling died with it. Pull your current MM firmware version via `ascset|0,ver` or the web UI. Compare against the Avalon firmware portal for the latest A1466-targeted MM3v2 build. If you recently upgraded and the fault coincides with the upgrade, roll back to the previous known-good build. Match the control-board silkscreen rev to the firmware target - mismatched revisions brick the controller.

Replace the control board. If the fan rail is dead and the SMD fuse swap doesn't restore it, damage is deeper - gate driver, voltage regulator, or board-level short. Replacing the full control board is faster than board-level rework unless you have A1466 bench fixtures. D-Central's Avalon repair bench does both; the board itself is in the MM3v2 family and parts are available through multiple channels.

Refresh thermal paste on all hashboards if overheat events occurred. If the dead-fan state ran long enough to trigger any `BOOTBY[0x10]` overheats, the thermal pads on the A1466's three hashboards took abuse. Pull each hashboard, replace thermal paste on the ASIC-to-heatsink interface with Arctic MX-6 or Thermal Grizzly Kryonaut, inspect pads between PMIC/PVT sensors and the chassis for crumbling or dry-out. The A1466's higher wattage ages thermal pads faster than on the A1366 - preventative refresh pays off.

Stop DIY when any of these are true: +12 V rail is dead across multiple fan positions (not just one), you see visible heat damage or discoloration on the control board, two fans in the same rig have failed within 30 days (points to upstream PSU or ground issue), any fan failure coincided with a hashboard going dark or throwing `ASICCRC` errors, or your SMD fuse replacement blew immediately on re-power. That's no longer fan territory - that's D-Central Avalon repair bench territory.

What D-Central does at the Avalon bench. Diagnosis against a known-good A1466 reference rig, MM3v2-family component-level repair including SMD fuse and gate-driver replacement, fan harness remake with dielectric-greased connectors, full hashboard thermal service if overheat events occurred, and 24-hour nameplate burn-in with all four fans monitored via continuous `estats` polling before ship-back. We're one of the few North American benches still servicing A14-series Canaan miners - Canaan's official channel routes to Malaysia or Shenzhen with multi-week turnarounds.

Ship the whole miner, not just the control board. The A1466's fan assembly, power-splitter board, and hashboard-to-MM harnesses are awkward to pack safely separate from the chassis. Double-box the full unit, remove the hashboards and wrap separately in anti-static bags, include a note with the failing `estats` output, MM firmware version, and observed symptoms. Saves diagnostic hours, which saves repair dollars.