Avalon 1466 – Low Hashrate vs Nameplate

Hard power-cycle at the PDU for 5 minutes. Not a soft reboot from the UI — a full power-off so the hashboard capacitors fully discharge and the AUC / MM controllers re-initialize cleanly. Clears wedged driver state that survives a warm reboot, resets any firmware-side frequency throttle that latched during an earlier thermal event, and on the A1466 specifically forces the firmware out of any `normal` mode it silently fell back into after an overheat — in `high-performance` mode operators usually need a cold boot to re-enter.

Shop-vac the intake mesh, front grille, and both 12050 Martech front fans. The A1466's two front fans pull `8 A @ 12 VDC` each and drag in dust at industrial rate. 30 days of dust = 5-10% hashrate drop, because dust pushes chip junction temps closer to the firmware auto-derate trigger near `40 °C`. Monthly maintenance is the highest-ROI action on the entire rig, and it is not listed anywhere in Canaan's A1466 user manual.

Measure intake air temperature with an IR thermometer at the front mesh itself, not room-middle, not the hallway. Target `≤ 30 °C`. Canadian garage deployments in July push `35 °C` at the intake even with the door open; A1466 firmware auto-underclocks as chip temp approaches `40 °C`, which arrives before your room feels hot. If inlet is above `30 °C`, improve ventilation before chasing any other cause — you will fix half of 'summer hashrate' tickets here. Canaan's operating range is `-5 °C to 35 °C` but the firmware visibly derates before `35 °C`.

Pull the CGMiner API `stats` on port 4028 and record a baseline. `echo -n '{"command":"stats"}' | nc <miner-ip> 4028`. Save the output. You will compare against this after each subsequent fix step to know whether you are making progress. Without the API baseline, every later step becomes a guess. The A1466 UI alone does not expose `MW0`/`MW1`/`MW2`, `PVT_T`, `PVT_V`, or `ECHU` in actionable form — the API does.

Verify firmware matches your A1466 hardware revision (`MM4_V1_1_20230216` or later). Look at the sticker on the control board, cross-reference `avalonminer.org/firmware-document/`, and confirm you are not running firmware from a sibling A14-series revision (the A1466 shares a control-board platform with the A1446 but chip-frequency tables differ). Mismatched firmware silently caps hashrate and cannot be cleanly rolled back because Canaan's bootloader is signature-locked on most batches.

Change miner DNS to `1.1.1.1` or `8.8.8.8`. Stock Canaan firmware defaults to `114.114.114.114` — a Chinese public DNS that resolves unreliably outside China. Symptom: stratum flapping, jagged pool-side dashboards, hashrate that looks fine on the miner but bad at the pool. One-field fix, documented nowhere in the English-language A1466 manual — entirely community knowledge via Zeus Mining and BitcoinTalk.

Confirm the miner is actually in `high-performance` power mode via the UI. The A1466 firmware can silently drop back to `normal` after a thermal event and does not auto-promote back. `normal` mode sits below `150 TH/s` nameplate. If the UI shows `normal` or `power`, switch to `high-performance`, hard-reboot once, and re-baseline the API stats. This is a documented A1466 firmware behaviour confirmed by HashrateIndex's review.

Measure AC input voltage at the `PSU3400-01 Plus` under full load with a multimeter on AC, probing at the PSU input while the miner is hashing at nameplate. Canaan spec: `220-277 V AC`. The A1466 does not accept 110 V at all. Anything below `220 V` drops hashrate silently because the chip frequency table derates. Fix the electrical feed (dedicated 240 V split-phase or commercial 208 V+ with balanced load, 240 V preferred for full high-performance mode) before replacing any miner hardware.

Measure DC rail at each PSU-to-hashboard connector under load. Record all three rails and compare. One rail materially below the others (drift greater than ~`50 mV` at the connector) = PSU or cable fault on that specific board. Pay attention to connector oxidation: A1466 power connectors in humid environments (coastal BC, Maritimes, any basement) oxidize within 12-18 months and add resistance that looks exactly like PSU sag.

Swap hashboards between the three MM slots. Label slots 0/1/2 with tape. Move the underperforming board (identified from the `MW` arrays in Step 4) to a known-good slot. Power up, stabilize 10 minutes, re-pull API stats. Fault follows the board = board-level problem, proceed to Tier 3. Fault stays in the slot = control board / AUC / cable path problem; inspect that slot's cable harness and ribbon, proceed to Tier 3 for bus tuning.

Re-seat every cable with the system powered off at the PDU. Pull each hashboard data and power cable, visually inspect pins for oxidation, blackening, or bent pins. Clean contacts with 99% isopropyl alcohol on a lint-free wipe. Reseat the AUC USB cable at both ends and replace it with a short shielded cable if the run exceeds `1 m` — long USB runs in a fan-vibration environment are a documented cause of marginal AUC bus behaviour. A poorly-seated connector adds resistance, drops rail voltage under load, and caps hashrate with no named fault.

Run cgminer with conservative AUC bus settings: add `--avalon7-aucspeed 200000 --avalon7-aucxdelay 24000` to the cgminer launch command. Undocumented by Canaan, canonical in cgminer `ASIC-README`. Conservative values double the IIC bus headroom, eliminate intermittent `CODE_MMCRCFAILED` retries, and in D-Central's Avalon repair queue recover 2-4% of effective hashrate on units with marginal AUC hardware without any physical repair.

Verify fan RPMs match nameplate under load via API `estats`. A1466 has two 12050 Martech front fans, each pulling `8 A @ 12 VDC`. Under load, both should hold a consistent RPM per the API table. Any fan reading materially below its peer, or audibly bearing-worn, needs replacement (`DF1205012B2` is the Martech part family for the A1466 fan slot per bit2miner's cross-reference). Dust-laden or worn fans push intake and chip temps up, triggering firmware frequency rollback that presents as low hashrate.

Refresh thermal paste on all three hashboards with Arctic MX-6 or Thermal Grizzly Kryonaut. Remove each heatsink, clean old paste with 99% IPA and lint-free wipes, apply a uniform thin layer (do not glop), reassemble with correct heatsink torque per the Avalon A11/A12-series hash board repair guide. 12+ month old paste accounts for `2-5 °C` of junction-temp headroom — and on A3198 silicon which sits closer to the `40 °C` firmware auto-derate trigger, every °C matters. Full re-paste on an A1466 takes ~60 minutes and frequently recovers 3-8% hashrate on a unit in service without thermal service.

Reflow the worst-performing A3198 chip identified from PVT_T / PVT_V outliers. Remove heatsink, flux the target BGA, preheat the bottom of the board to `~150 °C`, apply top-side hot air at `~310-330 °C` for `~30 s`, let cool naturally, re-apply thermal paste, reassemble. If reflow fails to recover the chip, replace with an A3198 from Zeus Mining's parts inventory — replacement chips run `$11.90 USD` per unit. Critical: when replacing an A3198, the BIN number of the new chip must match the BIN number marked on the hash board. Mismatched BINs cause immediate hashrate loss on that group.

Roll firmware one version back or forward from `avalonminer.org/firmware-document/`, using a build confirmed by the BitcoinTalk Avalon A14 thread as good for your specific hardware revision. Canaan publishes no changelog, so community A/B testing is your de facto reference. Canaan's signed bootloader blocks firmware downgrade on many A1466 batches; if the current build is a regression and rollback is blocked, document the build version, flag the unit for bench recovery, and proceed to Step 18. Do not attempt unsigned firmware flashes — bricking via signature mismatch is a ship-to-bench event.

Inspect and replace voltage-domain capacitors on any hashboard showing even `PVT_V` drift or `> 30 mV` spread across chips. Bulging electrolytics, cracked MLCCs, or discolouration near a group's PMIC is a replace-on-sight signal. Remember the A1466's 40-series-of-3 layout — a bad group-level cap can drag three chips down at once. Iron + hot-air rework + correct-value capacitor stock. Continuous 80 °C+ operation drifts stock capacitors in 18-30 months on the A1466 generation. This is SMD rework, not a reflow job — if you are not comfortable with component-level replacement, stop here and ship to D-Central.

Stop DIY and ship to bench when any of these are true: three or more failing chips on one board outside a single group, PMIC or voltage-domain IC suspected, a second reflow on the same chip failed within 30 days, capacitor bulging or burnt-component smell present, Canaan's signed firmware blocks a rollback, or a known-good AUC swap did not restore performance. Book a D-Central ASIC Repair slot at https://d-central.tech/services/asic-repair/. Bench process: Avalon universal test file on a programmable load, BIN-matched A3198 replacement from graded stock, voltage-domain capacitor audit, full reflow and reseal, 24-hour burn-in at 150 TH/s with API logging. Canadian turnaround 5-10 business days; include your API stats dump in the shipment note.