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 1346 – Low Hashrate

Warning — escalates to Critical when realized hashrate falls 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 A1346 (all production batches, including 104 / 107 / 110 / 113 / 120 TH/s SKUs) · any A13-class chassis running the Canaan A3200CFA / A3200CMA / A3200CMCV3 ASIC silicon across three hashboards

Symptoms

  • CGMiner API `GHSmm` vs `GHSavg` divergence **greater than 8%** sustained 30+ minutes (theoretical vs actual hashrate, per Canaan `avalon10-docs` API reference — same API surface on A1346)
  • Pool-reported 24-hour hashrate is **`10-40%` below nameplate** (`104-113 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 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 `A3200` 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 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 PSU (`PSU3400`) fan duty is above 80% at steady state even though ambient is normal — PSU working harder than it should because AC input is sagging
  • Rig has been running 12+ months since last thermal paste refresh (A3200 silicon runs hotter-per-watt than the A3206 on A1246 — paste cycles shorter)
  • 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

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.

2

Shop-vac the intake mesh, front grille, and fan blades. The A1346's four 12038 intake fans pull hard and drag in dust at industrial rate. 30 days of dust = 5-10% hashrate drop per CryptoMinerBros field data 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 user manual.

3

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; A1346 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 manual lists `5-35 °C` operating range but the firmware visibly derates before `35 °C`.

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 A1346 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 A1346 hardware revision. Look at the sticker on the control board, cross-reference `avalonminer.org/firmware-document/`, and confirm you are not running firmware from a sibling A13-series revision (the A1346 shares a control-board platform with the A1366 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.

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

7

Measure AC input voltage at the `PSU3400` 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: `≥ 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 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. Pay attention to connector oxidation: A1346 power connectors in humid environments (coastal BC, Maritimes, any basement) oxidize within 12-18 months and add resistance that looks exactly like PSU sag.

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.

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.

12

Verify fan RPMs match nameplate under load via API `estats`. A1346 has four 12038 intake fans and two 12050 exhausts — mixed bay. Under load, each should hold a consistent RPM per the API table (stock firmware reports per-fan RPM). 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.

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 per the Canaan A1346/1366 service guide. 12+ month old paste accounts for `2-5 °C` of junction-temp headroom — and on A3200 silicon which runs hotter-per-watt than A3206, the paste cycle is shorter than on the A1246. Full re-paste on an A1346 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.

14

Reflow the worst-performing A3200 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 `A3200CFA` (or `A3200CMA` / `A3200CMCV3` per the chip revision on your board) from Zeus Mining's parts inventory — replacement chips run `$9.50 USD` per unit at 20-chip minimum order. Zeus Mining publishes a step-by-step A3200CFA replacement tutorial.

15

Roll firmware one version back or forward from `avalonminer.org/firmware-document/`, using a build confirmed by the BitcoinTalk Avalon A13 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 A1346 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 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 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. Continuous `80 °C+` operation drifts stock capacitors in 18-30 months on the A1346 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.

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. 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, or a known-good AUC 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 A1346: programmable load + Canaan factory test binary to map each chip individually, chip replacement from graded A3200-series salvage or NOS stock, 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: 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.