Avalon 1166 Pro – Fan Speed 0 RPM

Power down at the PDU and confirm the thermal state first. The A1166 Pro 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 power. Open the chassis within 2 minutes so residual heat dissipates before probing. A dead fan on a 3,400 W miner running even 10 extra minutes can cook thermal pads and shorten hashboard life by months. Non-negotiable first step.

Read the log, write down the fan number. On the miner's web UI or via `estats` over the API, record exactly which fan position reports `0`. Is it `Fan1`? All four? One per hashboard? Position dictates repair - intake and exhaust are the same log line but different physical parts. Screenshot or copy/paste the `estats` response. This artifact is the difference between a 20-minute fix and a 2-hour scavenger hunt.

Blow the 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. Dust dams on the hub are the most common cause of a fan that looks fine but reads zero RPM. Basement shop, garage, or any cat/dog within 50 metres? This step fixes about 15% of tickets.

Check ambient at the intake with an IR thermometer at the front grille, not mid-room. The A1166 Pro's thermal governor assumes <=35 C inlet. If intake is at 38 C in July, the fan controller runs survivors at 100% and you're hearing that, not a fault. Confirm the `Fan[0]` reading - if every fan reads real RPM but one is at `0`, it's not ambient, it's the fan.

Reseat the fan connector at the MM3-C board. Power off at the PDU, wait 60 seconds, pop the lid. Locate the 4-pin fan header matching the log's position. Unplug, inspect shell for bent pins or crushed latch, reseat firmly until the click. Fixes roughly 60% of Fan[0] tickets D-Central sees on shipped-in A1166 Pros. Before reassembling, dab dielectric grease on the pins - vibration backed it out once, will do it again without help.

Inspect the fan cable end-to-end. Look for: chafe points past sheet-metal edges, strain-relief damage at the fan terminal, discoloration from heat, or crush damage from the lid reinstalled over a pinched cable. Replace the harness if anything looks off. Convention on 4-pin PWM in this class is GND / +12 V / TACH / PWM - verify against MM3-C silkscreen before assuming.

Swap the suspect fan into a known-good position. Four fan headers on the MM3-C, four fans in the chassis. Move the suspect fan's harness to a known-working slot. Power on, re-read `estats`. If it now spins and reads correctly, the original slot is the problem - board-side fault, Tier 3/4. If it still reads `0` in a known-good slot, fan itself is dead, replace.

Measure +12 V rail at the dead fan header under load. Multimeter on DC, probe V+ to GND while powered on and fan controller is commanded to spin. Expect 11.8-12.2 V steady. Below 11 V or nothing = blown SMD fuse or supply-rail fault on the MM3-C (Tier 3). Healthy 12 V rail with a still-dead fan = fan or harness, replace.

Set manual fan speed via the API as a diagnostic. Bitcointalk community command: `echo '[{"command":"ascset","parameter":"0,fan-spd,90"}]' | nc <miner-ip> 4028`. Try 20, 50, 90. Healthy fan responds within a second; dead one won't. This is a diagnostic, not a fix - the setting doesn't persist across reboots. Don't use it to mask a real fault.

Check kernel log for `BOOTBY[0x10.*]` overheat reboots. If present, the fan failure already caused overheat events - hashboards went through thermal cycling they shouldn't have. Plan thermal paste refresh at the next opportunity, watch for elevated per-chip CRC errors over the next week.

Replace the fan with the correct part. Stock A1166 Pro: HA1250H12SB family, 12 V / 9 A, 120 x 120 x 50 mm, 4-pin PWM. The HA1250H12SB-Z revision drops in mechanically. Do NOT substitute 120x120x25 or 120x120x38 - A1166 Pro chassis is designed around 50 mm depth for static pressure through the dense fin pitch. Thinner fans cut airflow ~30% and you'll be back in two weeks. Verify polarity against MM3-C silkscreen before power-on.

Replace the SMD fuse on the MM3-C fan rail. If Step 8 showed dead +12 V on one header while others were healthy, a Canaan-side SMD fuse popped when a previous fan seized. Typically a 1206-package fast-blow in the 5-10 A range; identify by following the rail from the fan header back to the nearest SMD. Reflow replacement with hot air at 290 C. Verify rail voltage returns to 12 V under dummy load before reconnecting a real fan.

Firmware downgrade from a known-bad MM build. If Steps 1-12 didn't resolve and `estats` shows all four fans at `0` plus sensors at `-273 C`, you've hit a firmware bug. Bitcointalk documents `22061301_be77c30_ef5defc` as broken for the A1166 Pro - downgrade to `22033101_4ec6bb0_49ce84a` or the last-known-good for your MM hardware rev. Match silkscreen rev (e.g. `MM3-C_V1_2_200511`) to firmware target; wrong rev bricks the controller.

Replace the MM3-C control board. If the fan rail is dead and SMD fuse swap didn't restore it, damage is deeper - gate driver, voltage regulator, or board-level short. Replacing the full MM3-C is faster than board-level rework unless you have bench fixtures for the A1166 Pro. D-Central's Avalon repair bench handles both.

Refresh thermal paste on all hashboards if overheat events occurred. If the dead-fan state ran long enough to trigger `BOOTBY[0x10]` overheats, thermal pads on the three hashboards took abuse. Pull each hashboard, replace paste on the ASIC-to-heatsink interface with Arctic MX-6 or Thermal Grizzly Kryonaut, inspect pads between PMIC/PVT sensors and chassis. Preventative step that pays off for long-term miner life.

Stop DIY when any of these are true: +12 V rail dead across multiple fan positions (not just one), visible heat damage on the MM3-C, two fans failed in the same rig within 30 days, or fan failure coincided with a hashboard going dark or throwing ASICCRC errors. That's D-Central Avalon repair bench territory - not fan territory.

What D-Central does at the Avalon bench: diagnosis against a known-good A1166 Pro reference rig, MM3-C 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, 24-hour nameplate burn-in with all four fans monitored via continuous `estats` polling before ship-back. One of the few North American benches still servicing A1166 Pros.

Ship the whole miner, not just the MM3-C. The A1166 Pro's fan assembly is awkward to pack separately from the chassis safely. Double-box the full unit, remove 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.