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

HASH_LOW Warning

Avalon 1566 – Low Hashrate vs Nameplate

Warning — escalates to Critical when realized hashrate drops below 60% of nameplate for >1 hour, or when paired with any ECHU != 0, PS[0] != 0, or SYSTEMSTATU != 3

Warning — Should be addressed soon

Affected Models: Avalon A1566 (all production batches — nominal 185 TH/s SKU and batch-binned 170 / 175 / 180 / 185 / 195 TH/s variants) · any A15-class chassis running Canaan's A3206-successor silicon across three hashboards

Symptoms

  • CGMiner API `GHSmm` vs `GHSavg` divergence **greater than 5-8%** sustained 30+ minutes (theoretical vs actual hashrate, per Canaan `avalon10-docs` API reference — same API surface carries forward to A1566)
  • Pool-reported 24-hour hashrate is **`10-40%` below nameplate** (`185 TH/s` nominal, `170-195 TH/s` across batch bins) despite the miner's own UI reporting near-nameplate locally
  • One of three `MW0` / `MW1` / `MW2` arrays shows **fewer than 26 entries** or median count below `3000` — that board is underperforming
  • `ECHU[0 0 0]` reads all zero (no hashboard comms failure) but realized hashrate is still low — rules out comm fault, points at thermal, power, chip-drift, or firmware
  • `PVT_T` (per-chip temperature array) shows one or more chips **≥ `95 °C`** while the rest of the board median sits `78-88 °C`
  • `PVT_V` (per-chip voltage array) shows scatter greater than **±`30 mV`** across a board — drift in the voltage domain
  • `GHSmm` holds steady but `GHSavg` slowly bleeds over hours — thermal saturation pattern on A15 silicon
  • AUC LED is **solid green** (no comm errors), `SYSTEMSTATU = 3` (all three MMs present), but realized TH/s is flat and low
  • Chassis inlet air measured at the front mesh reads `> 30 °C` even with room A/C running — dust, restricted duct, or hot-aisle recirculation
  • Controller log shows intermittent `CODE_MMCRCFAILED` warnings without a full AUC dropout — marginal AUC IIC bus
  • Controller log shows `mm_work_send_timeout` or `asic_freq_set_fail` on one specific MM slot
  • Hashrate degrades **gradually over weeks** (thermal paste dry-out, cap aging) rather than dropping suddenly after a firmware flash or OC change
  • Stock Canaan PSU fan duty is above 80% at steady state even though ambient is normal — PSU working harder than it should because AC input is sagging
  • Hashrate drops every evening at the same time (neighbourhood peak `6-10 PM` local) and recovers overnight — line voltage sag, not a chip fault
  • Rig has been running 6-12 months at full load in a `>28 °C` ambient without thermal paste refresh (A15 silicon paste cycles are the shortest in the Avalon family)

Step-by-Step Fix

1

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 transient, and is a 2-minute diagnostic that closes a surprising percentage of overnight-drop tickets before any tool comes out of the drawer. A1566 units running 24/7 with no reboot can accumulate days of minor wedge state the firmware never clears on its own.

2

Shop-vac the intake mesh, front grille, and fan blades. The A1566's HA1250H12SB-Z fans pull hard and drag in dust at industrial rate. 30 days of dust = 5-12% hashrate drop on A15 silicon because the chips run closer to their thermal ceiling than earlier Avalons — more dust, more derating. Make this monthly — it is the highest-ROI maintenance action on the entire rig, and it is not listed anywhere in Canaan's A1566 documentation.

3

Measure intake air temperature with an IR thermometer at the front mesh itself, not room-middle, not the hallway. Target `≤ 28 °C` for full A1566 nameplate performance. A15 silicon visibly derates above `28-30 °C` intake before any `OVER_TEMP` alarm fires. Canadian garage deployments in July push `35 °C` at the intake even with the door open; if inlet is `> 28 °C`, improve ventilation before chasing any other cause — you will fix half of "summer A1566 hashrate" tickets here.

4

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 A1566 UI alone does not expose `MW0`/`MW1`/`MW2`, `PVT_T`, `PVT_V`, or `ECHU` in actionable form — the API does.

5

Verify firmware matches your A1566 hardware revision. Look at the sticker on the control board, cross-reference `avalonminer.org/firmware-document/`, and confirm you are not running firmware intended for a sibling A15 revision. Mismatched firmware silently caps hashrate and cannot be cleanly rolled back because Canaan's bootloader is signature-locked on every A1566 batch observed so far. A1566 firmware misflashes are ship-to-bench events — verify before you flash.

6

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 A1566 materials — entirely community knowledge via Zeus Mining and BitcoinTalk.

7

Measure AC input voltage at the PSU under full load with a multimeter on AC, probing at the PSU input while the miner is hashing at nameplate. Canaan spec: `200-300 V AC`. Real-world nameplate performance on the A1566: `≥ 220 V AC` sustained. Anything below `220 V` drops hashrate silently because the chip frequency table derates, and the A1566 is more sensitive to sag than earlier Avalons because it draws more current. If you see `< 220 V`, fix the electrical feed (dedicated 240 V split-phase or commercial 208 V+ with balanced load) before replacing any miner hardware — the miner is not the problem, the electrical is.

8

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. A1566 power connectors in humid environments (coastal BC, Maritimes, any basement) oxidize within 12-18 months and add resistance that looks exactly like PSU sag — clean contacts with 99% IPA as part of the measurement procedure.

9

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 JAMLINK harness and ribbon, proceed to Tier 3 for bus tuning. On an A1566 with scarce replacement parts in the open market, per-board isolation matters more than on older generations.

10

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.

11

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. Applies to every Avalon from A1066 forward including A1566.

12

Verify fan RPMs match nameplate under load via API `estats`. A1566 uses the HA1250H12SB-Z fan family per Zeus Mining's fan documentation. Under load, each fan should hold a consistent RPM per the API table. Any fan reading materially below its peers, or audibly bearing-worn, needs replacement — dust-laden or worn fans push intake and chip temps up, triggering frequency rollback that presents as low hashrate. HA1250H12SB-Z is the designated A15-gen fan and is available through Zeus Mining's parts catalog.

13

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. 9-12 month old paste on A15 silicon accounts for `2-5 °C` of junction-temp headroom lost — and A1566 silicon runs closer to its thermal ceiling than A1346 did, so the paste cycle is shorter. Full re-paste on an A1566 takes ~90 minutes and frequently recovers 3-8% hashrate on a unit that has been in service without thermal service. Single highest-impact Tier 3 action for drift-style A1566 low-hashrate complaints.

14

Reflow the worst-performing A15 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. A15 replacement chip supply in the open market is thin as of 2026-Q2 — if reflow fails, most operators will need to ship the board to D-Central for chip sourcing rather than DIY-replacing. Attempting chip-level repair without stock replacement chips on hand wastes a reflow cycle.

15

Roll firmware one version back or forward from `avalonminer.org/firmware-document/`, using a build confirmed by the BitcoinTalk Avalon A15 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 every A1566 batch observed so far; 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 17. Do not attempt unsigned firmware flashes — bricking via signature mismatch is a ship-to-bench event.

16

Inspect and replace voltage-domain capacitors on any hashboard showing `PVT_V` drift or `> 30 mV` spread across chips. Bulging electrolytics, cracked MLCCs, or discolouration near the PMIC is a replace-on-sight signal. Iron + hot-air rework + correct-value capacitor stock. The A1566 hasn't been in the field long enough for the full cap-aging pattern to emerge, but the design inherits from A1346/A1466 topology and we expect a similar 18-30 month capacitor drift window at continuous `80 °C+` operation. This is not a reflow job — it is SMD rework — and if you are not comfortable with component-level replacement, stop here and ship to D-Central.

17

Swap the AUC with a known-good unit. If you have cleared every other layer and bus tuning (Step 11) did not help, the AUC itself may be dying. FTDI USB-bridge silicon ages poorly in the Avalon chassis's fan-vibration + ESD-exposed environment. A replacement AUC is cheap insurance at `CAD $40-90` and is a 5-minute swap. The same AUC carries across the entire modern Avalon line — A1166 / A1246 / A1346 / A1466 / A1566 all accept the same replacement part. If a fresh AUC restores hashrate, retire the old one — do not shelve it as "probably fine."

18

Stop DIY and ship to bench when any of these are true: `PVT_T` / `PVT_V` isolates three or more failing chips on the same board (beyond single-chip reflow), a PMIC or voltage-domain IC is suspected (measurable short, visible discolouration, rail refusing to come up to spec), a second reflow on the same chip fails within 30 days, capacitor bulging or a burnt-component smell is present, Canaan's signed firmware blocks a rollback you need for recovery, a known-good AUC swap did not restore performance and `MW` arrays still show one board underperforming, or you simply cannot source A15 replacement chips in the open market. [Book a D-Central ASIC Repair slot →](https://d-central.tech/services/asic-repair/). D-Central bench process on an A1566: programmable load + Canaan factory test binary to map each chip individually, chip sourcing through repair-channel supply, voltage-domain capacitor audit, full reflow and reseal, 24-hour full-load burn-in at nameplate with API logging to confirm the fix before ship-back. Canadian turnaround on A1566 current-gen repairs: 7-14 business days. US and international accepted. Include your API `stats` dump in the shipment note — it saves us diagnostic time, which saves you money at the hourly past-triage rate.

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.