Avalon 1166 – Low Hashrate

Hard power-cycle at the PDU for 5 minutes. Not a soft reboot — full power-off long enough that the hashboard capacitors discharge and the AUC3/MM re-initialize cleanly. Clears wedged driver or comm state that survives a warm reboot and is often enough on its own to restore nameplate after a firmware update or a stratum glitch. Record the API stats baseline before and after so you know whether this step alone fixed it.

Shop-vac the intake mesh, front grille, and fan blades. Dust build-up on the 1166 intake is the single most common 'mystery low hashrate' cause — CryptoMinerBros field data shows 5-10% hashrate loss from 30 days of neglect. Use a soft-bristle brush for stubborn build-up. Do not use canned air near the hashboards (pushes dust into chip sockets). Make this a monthly recurring task.

Verify ambient at the miner intake is at or below 30 °C using an IR thermometer aimed at the front mesh (not room-middle, not the hallway). A Canadian garage in July can easily hit 35 °C at the intake even with the door open. Above 30 °C the 1166 firmware silently caps chip frequency to maintain thermal stability — you lose hashrate and see no named fault.

Confirm firmware matches hardware revision. Read the sticker on the MM control board, cross-reference Canaan's firmware portal at avalonminer.org/firmware-document, and confirm you are not running a 1166 Pro firmware on a base 1166 board (or vice versa). Mismatched firmware advertises hashrate the chassis cannot deliver and is a silent hashrate killer. Roll to the stock firmware matching your hardware revision and re-baseline.

Pull API `stats` and record a baseline. From the controller or any host on the LAN: `echo -n '{"command":"stats"}' | nc <miner-ip> 4028`. Save the output to a file. Record `GHSmm` (theoretical), `GHSavg` (actual), `MW0`/`MW1`/`MW2` (per-board work counts, should have 26 entries each >= `3000`), `PVT_T`/`PVT_V` (per-chip temps and voltages), `ECHU` (should be all zero), and `ECMM`. Compare against this baseline after every subsequent fix step.

Measure AC input voltage at the PSU under full load. Multimeter on AC, probe at the PSU input while the miner is hashing at steady-state. Canaan spec says 180-264 V; real-world nameplate hashrate requires >= 220 V sustained. Anything below 220 V drops hashrate silently because the PSU works harder, voltage droops, and the chips down-clock to stay stable. If AC is low, you have a circuit problem, not a miner problem — call an electrician before doing anything else.

Measure DC rail at the PSU-to-hashboard connector under full load. Probe all three hashboard connectors in turn with the miner hashing. Rail voltages should match each other within a few mV — one rail materially below the others points at a tired PSU, a damaged cable, or a fault on that specific board. If all three rails sag together under load, the PSU is tired; swap with a known-good unit before suspecting the hashboards.

Swap hashboards between MM slots to isolate the fault. Label the three slots 0/1/2 with tape first. Power off at the PDU, move the suspect board to a known-good slot, power back up, re-pull API stats after 15 minutes. If the thin `MW` array follows the board, the board is at fault (go to Tier 3). If the fault stays in the slot, the MM / AUC3 / cable path is at fault. This is the cleanest hardware-vs-control-path isolation available without a bench setup.

Clean or replace any aftermarket intake filter. Some commercial 1166 deployments run with a filter in front of the intake. A clogged filter adds 3-5 °C to inlet temp even when the room is cold. If you're running one, clean or replace it on the same 30-day cadence as the dust vacuum. No filter at all is fine for most home setups — focus on the 15 cm intake clearance and room air quality instead.

Reseat every cable in the chassis. Power off at the PDU. Pull each hashboard data cable and power cable in turn, visually inspect pins for oxidation or blackening, reconnect firmly with a click. Reseat the AUC3 USB cable at both ends. A poorly-seated connector adds resistance, drops voltage, and caps hashrate without tripping a named fault. Zip-tie any loose USB cable to the chassis frame so fan vibration can't loosen it again.

Run cgminer with conservative AUC3 bus settings. Add `--avalon7-aucspeed 200000 --avalon7-aucxdelay 24000` to the cgminer launch command (substitute `avalon8`/`avalon10` for matching chassis generation if relevant — the 1166 uses the `avalon7` family in cgminer). Undocumented by Canaan, documented in the cgminer `ASIC-README`. Conservative values double IIC bus headroom and eliminate intermittent `CODE_MMCRCFAILED` retries that silently reduce effective hashrate on marginal bridges.

Override the default DNS in miner network config. Stock Canaan firmware defaults to `114.114.114.114`, a Chinese public DNS that resolves unreliably outside China. Set DNS to `1.1.1.1` or `8.8.8.8` to eliminate stratum-side flapping that looks like hashrate loss on the pool dashboard. This is one of the most under-documented Canaan defaults and has a literal one-field fix; documented nowhere in the English manual.

Refresh thermal paste on all three hashboards. Use Arctic MX-6 or Thermal Grizzly Kryonaut. Remove heatsinks, clean old paste with 99% IPA and lint-free wipes, apply a uniform thin layer (don't glop it on), reassemble with correct heatsink torque. 18+ month old paste accounts for 2-5 °C of junction-temp headroom; expect hashrate recovery of 3-8% on a miner that had drifted thermally. Plan the paste refresh cycle every 18-24 months as preventive maintenance.

Reflow the worst chip identified by `PVT_T`/`PVT_V` outliers. Remove heatsink, flux the BGA, preheat the bottom of the board to 150 °C, top-side hot air at 310-330 °C for 30 seconds, let it cool naturally, re-apply paste, reassemble. A3205 BGA packages tolerate a single reflow cycle well. If HW% or `PVT` numbers return to median after 20 minutes of run-time, the reflow took; if the chip drifts again within 30 days, the chip itself is failing silicon and must be replaced.

Roll firmware one version back or forward from the Canaan firmware portal at avalonminer.org/firmware-document. Cross-reference the BitcoinTalk A1166 thread for community A/B reports — Canaan publishes no changelog, so tribal knowledge is your changelog. A firmware release that shipped with a conservative chip-frequency table costs real hashrate without any named fault; rolling one version either direction is a legitimate Tier-3 diagnostic.

Inspect and replace voltage-domain capacitors. Bulging electrolytics or cracked MLCCs near the PMIC on any hashboard = replacement job. Soldering iron + hot-air rework + correct-value caps, working from the board schematic. Continuous 80 °C operation drifts stock electrolytics in 2-3 years. Not a reflow job. If you're not comfortable with fine-pitch SMD rework, stop here and ship the board — a botched cap replacement can damage adjacent components and increase the final repair bill.

Swap the AUC3 with a known-good unit. If every other layer has been cleared and conservative bus tuning did not help, the AUC3 itself may be dying. FTDI bridges age poorly in the Avalon's fan-vibration, ESD-exposed environment — D-Central's repair-queue data shows a seasonal spike in AUC3 replacements every Canadian winter from dry-air static discharge. A fresh AUC3 is cheap insurance. If a known-good AUC3 also drops or caps hashrate, pivot back to Step 8's board-vs-slot isolation.

Stop DIY when `PVT_T`/`PVT_V` isolates three or more failing chips on the same board, a reflow on a suspect chip returned within 30 days, a PMIC/voltage-domain IC is suspected, you see visible capacitor bulging or burnt-component damage you are not equipped to rework, or a known-good AUC3 swap and conservative bus tuning still leave `GHSmm`-vs-`GHSavg` divergence above 15%. You are now in test-fixture territory. Book a D-Central ASIC Repair slot at https://d-central.tech/services/asic-repair/ and include your `stats` dump plus observed symptoms in the shipment note.