Avalon 1446 – Low Hashrate
Warning — Should be addressed soon
Symptoms
- CGMiner API `GHSmm` vs `GHSavg` divergence **greater than 8%** sustained 30+ minutes (theoretical vs actual hashrate, per Canaan `avalon10-docs` Universal API reference — same API surface on A1446)
- Pool-reported 24-hour hashrate is **`10-40%` below nameplate** (`130-136 TH/s` depending on SKU) despite the miner's own UI showing near-nameplate numbers
- One of three `MW0` / `MW1` / `MW2` arrays shows **fewer than 38 entries** or median count below `2800` — 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 `A3210` chips **≥ `90 °C`** while the rest of the board median sits `72-82 °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
- 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 is `> 30 °C` even with room A/C running — dust, restricted duct, or recirculation
- Controller log shows intermittent `CODE_MMCRCFAILED` warnings without a full AUC dropout — marginal AUC3 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 `PSU3400-01 Plus` fan duty is above 80% at steady state even though ambient is normal — PSU working harder than it should because AC input is sagging below `220 V`
- Rig has been running 12+ months since last thermal paste refresh (A3210 on A1446 runs hotter-per-watt than earlier A3206 on A1246 at `24.5 J/TH` — paste cycles shorter than prior-gen)
- Hashrate drops every evening at the same time (neighbourhood peak `6-10 PM` local) and recovers overnight — line voltage sag, not a chip fault
Step-by-Step Fix
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 AUC3 / 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. Document what you observe on first power-up: full hashrate for a few minutes followed by decline, or low hashrate from the start — each points at a different root cause.
Shop-vac the intake mesh, front grille, and both `DF1205012B2FN` 12050 fan blades. The A1446's fans pull hard and drag in dust at industrial rate. 30 days of dust = 5-10% hashrate drop per Zeus Mining A14 maintenance notes and matches our own intake measurements. Make this monthly — it is the highest-ROI maintenance action on the entire rig, and it is not listed anywhere in Canaan's A14 user documentation. Keep a dust log on the side of the chassis so you know when you last did it.
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; A1446 silently caps frequency above `30 °C` before any `OVER_TEMP` alarm fires. If inlet is `> 30 °C`, improve ventilation before chasing any other cause — you will fix half of "summer hashrate" tickets here. Canaan's `-5 to 35 °C` operating range is an electrical-envelope spec, not a performance spec.
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 A1446 UI alone does not expose `MW0`/`MW1`/`MW2`, `PVT_T`, `PVT_V`, or `ECHU` in actionable form — the API does. Keep the text output; do not rely on a screenshot.
Verify firmware matches your A1446 hardware revision. Look at the sticker on the control board (should read `MM4_V1_1_20230216` or later for the A14 family per Hashrate Index's A14 review), cross-reference `avalonminer.org/firmware-document/`, and confirm you are not running firmware from a sibling A13-series revision. The A1446 shares a control-board platform with the A1466 but chip-frequency tables differ. Mismatched firmware silently caps hashrate and cannot be cleanly rolled back because Canaan's bootloader is signature-locked on all A14 batches we've seen.
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 A1446 manual — entirely community knowledge via Zeus Mining and BitcoinTalk. Applies to every AUC-based Avalon, not just the A1446.
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`. Real-world nameplate performance: `≥ 220 V AC` sustained. Anything below `220 V` drops hashrate silently because the chip frequency table derates. If you see `< 220 V`, fix the electrical feed (dedicated 240 V split-phase or commercial 208-240 V with balanced load) before replacing any miner hardware — the miner is not the problem, the electrical is. Log the sag profile across a 24-hour window before calling the electrician.
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 on the `4pin-C20` mating end: A1446 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 and reseat before concluding it is a dead PSU.
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. Never swap with the miner powered on — signal-chain hot-swaps on A3210 silicon kill chips.
Re-seat every cable with the system powered off at the PDU, with ESD precautions (wrist strap grounded to chassis — Zeus Mining flags `<100 V` static shocks as enough to permanently damage A3210 silicon, and every connector reseat is an opportunity to zap a chip if you skip the strap). 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 AUC3 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.
Run cgminer with conservative AUC3 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. The flag name is historical (`avalon7`) but the tuning applies cleanly to the A1446's AUC3 family.
Verify fan RPMs match nameplate under load via API `estats`. A1446 has two 12050 Martech intake fans rated `DC 12V 8A` per the bit2miner fan cross-reference. Under load, both should hold a consistent RPM per the API table (stock firmware reports per-fan RPM). Any fan reading materially below its peer, or audibly bearing-worn, needs replacement with the correct Martech `DF1205012B2FN` (part is shared across `A1326 / A1346 / A1366 / A1446 / A1466 / A15 / A15XP / A15Pro` — stock one spare per site). Dust-laden or worn fans push intake and chip temps up, triggering 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 Zeus Mining A11/A12 service pattern (same torque spec carries forward to A14). 12+ month old paste accounts for `2-5 °C` of junction-temp headroom — and on A3210 silicon which runs hotter-per-watt than A3206, the paste cycle is shorter than on the A1246. Full re-paste on an A1446 takes ~60 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 low-hashrate complaints.
Reflow the worst-performing A3210-family 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 a donor A3210-family chip sourced from Zeus Mining's Avalonminer ASIC chip catalog. ESD wrist strap mandatory — the chip is gate-oxide sensitive; a single careless touch will kill the replacement before it is soldered. Zeus Mining's A1446-compatible hashboard maintenance tool kit pairs with this procedure.
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 all A1446 batches we have seen; 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.
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 the PMIC is a replace-on-sight signal. Iron + hot-air rework + correct-value capacitor stock (Zeus Mining's A14 hashboard repair tool kit includes the common value set). Continuous `80 °C+` operation drifts stock capacitors in 18-30 months on the A1446 generation. 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.
Swap the AUC3 with a known-good unit. If you have cleared every other layer and bus tuning (Step 11) did not help, the AUC3 itself may be dying. FTDI USB-bridge silicon ages poorly in the Avalon chassis's fan-vibration + ESD-exposed environment. A replacement AUC3 is cheap insurance at `CAD $45-95` and is a 5-minute swap. If a fresh AUC restores hashrate, retire the old one — do not shelve it as "probably fine."
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, or a known-good AUC3 swap did not restore performance and `MW` arrays still show one board underperforming. [Book a D-Central ASIC Repair slot →](https://d-central.tech/services/asic-repair/). D-Central bench process on an A1446: programmable load + Canaan factory test binary to map each chip individually, chip replacement from graded A3210-family salvage or NOS stock, voltage-domain capacitor audit, full reflow and reseal, 24-hour full-load burn-in at `135 TH/s` nameplate with API logging to confirm the fix before ship-back. Canadian turnaround: 5-10 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.
