Avalon 1446 – PSU Incompatible Model
Critical — Immediate action required
Symptoms
- Controller boots clean to the dashboard, `SYSTEMSTATU = 3`, AUC LED solid green, network reachable — but hashrate is **flat zero** or sits at idle baseline
- CGMiner API `stats` on port 4028 returns `GHSmm = 0` and `GHSavg = 0` despite no `ECHU` or `ECMM` faults
- `PS[0]` reads non-zero — typical pattern is `0x0001` (insufficient PSU rating) or a documented bit indicating power-class mismatch in the `MM4` firmware
- Controller log contains `power supply insufficient`, `PSU rating mismatch`, `power class abort`, or a vendor-internal variant referencing wattage / current rating
- PSU sticker reads `PSU3300 Plus`, `PSU3300-01`, `PSU3300-02`, or any wattage rating **below `3500 W` continuous**
- You moved the PSU from a working A1166, A1246, A1266, or A1346 chassis and the original A1446 PSU is missing or in another rig
- PSU is third-party (server PSU breakout, Dell / HP / Delta refurb) wired to a `4pin-C20` adapter cable bought off a marketplace
- Wall AC at the PDU under load reads `< 220 V` despite the PSU being a correct `PSU3400-01 Plus`
- Hashboards never reach steady-state temperature — chips remain at room ambient because they were never enabled
- PSU fan stays at idle / minimal duty (`< 30%`) because the load it expects is never drawn — telltale of a hashboard hold-off, not a PSU fault
- Rig was stable on the bench at the previous owner / shop, then transferred to your site with a PSU swap and has not hashed since
- Multiple A1446 units on the same site exhibit the same symptom because a batch of mismatched PSUs was wired across the rack
- PMBus / cable connector is `4pin-C20` on both ends but the wattage rating sticker doesn't match the chassis class
Step-by-Step Fix
Power off at the PDU and let the chassis sit 5 minutes for capacitor discharge. Then pull the PSU out of the bay and read the manufacturer label. Document the model number and the continuous wattage rating in writing — not just the marketing wattage. A1446 requires a Canaan `PSU3400-01 Plus` or equivalent A14-rated unit, rated for the ~3310 W nominal / ~3640 W high-performance envelope. Anything labelled `PSU3300`-family (A11/A12 generation), or any unit rated `< 3500 W` continuous on its sticker, is the wrong SKU. If the sticker confirms a wrong-class PSU, you have your fix: source the right one and retire the legacy unit to its correct chassis (A1166, A1246, or A1266 — it is fine on those, just under-rated for A14).
Verify the chassis SKU and confirm the firmware-expected PSU. Stick a label inside each rack rig identifying the matched PSU model so the next operator (you, in six months, with no memory of this debugging session) doesn't repeat the swap. A 30-second label saves a 4-hour ticket. This is the single highest-leverage operational habit on a multi-rig site, and the cheap, durable fix for the multi-rig pairing class of fault.
Multimeter on AC, probe at the wall outlet or PDU under no-load. Target `≥ 220 V`. Canadian residential 240 V split-phase reads `235-245 V`; commercial 208 V reads `202-212 V`. If you see `< 220 V` on a 240 V circuit, you have an electrical problem before you have a miner problem — call an electrician for residential, check phase balance for commercial. Document the reading; this becomes evidence later when you compare the historical baseline against any future fault.
Re-measure AC input under load, this time at the PSU input while the controller is powered (PSU plugged in, miner on, hashboards held off). The PSU primary side draws idle current even with hashboards held off; you should see steady AC. Sag of more than `10 V` between no-load and idle-load is a circuit-undersized signal independent of the PSU SKU. Move the rig to a dedicated circuit before continuing.
Pull the CGMiner API `stats` and `summary` on port 4028. `echo -n '{"command":"stats"}' | nc <miner-ip> 4028`. Save the full text output. Inspect `PS[0]`, `SYSTEMSTATU`, `GHSmm`, `GHSavg`, and the controller log strings if exposed. `PS[0] = 0x0001`-class with `SYSTEMSTATU = 3` is the textbook PSU-incompatible signature. Without this baseline, every later step is a guess. Keep the text output; do not rely on a screenshot.
Substitute a known-good `PSU3400-01 Plus` from your spares, or pulled off a working A1446 / A1466 (platform shares the PSU). Power off at the PDU first. Disconnect AC, disconnect the `4pin-C20` to-board cable, slide the suspect PSU out, slide the known-good in, reconnect. Power on, wait 60 seconds, re-pull `stats`. If `PS[0]` clears and `GHSmm` climbs, the original PSU was the cause. Document, retire the original to a correct A11/A12-era chassis if its rating matches; otherwise scrap.
If you do not have a known-good A14-rated PSU on hand, do not improvise with a server PSU breakout for an A1446. The MM4 controller's PSU-rating handshake will refuse non-Canaan IDs even when the rail is electrically capable. The fix is the right SKU, not a clever cable. Order the matched `PSU3400-01 Plus` from a Canaan-authorised reseller; verify the part number and serial format on receipt before installation.
Inspect the `4pin-C20` connector contacts on both the PSU side and the chassis side. Coastal BC, Maritimes, and any humid basement deployment will oxidise these contacts within 12-18 months and add resistance that mimics a PSU sag. Clean with `99%` isopropyl alcohol on a lint-free wipe, let dry, reseat firmly. Listen for the click. If contacts show pitting, blackening, or pin damage, replace the cable rather than continue to use it.
Verify the wall circuit is dedicated and correctly sized. A1446 nominal is `~15 A @ 240 V` or `~17 A @ 208 V` continuous. NEC 80% derate puts the dedicated breaker at `20 A` minimum. Sharing a circuit with a fridge, microwave, or another miner virtually guarantees AC sag during peak draw, which can present as PSU-incompatible even with the right SKU. Move to a dedicated circuit; this is a one-time electrical fix that prevents a class of long-running ghost faults.
Set miner DNS to `1.1.1.1` or `8.8.8.8`. Stock Canaan firmware default is `114.114.114.114` — Chinese public DNS that resolves unreliably outside China. Symptom: stratum flapping that masquerades as low effective hashrate post-fix. One field change, documented nowhere in the English A1446 manual, applies to every AUC-based Avalon. After a PSU swap brings the rig back online, this prevents the next confusing ticket.
Verify firmware. Confirm `MM4_V1_1_20230216` or later via the dashboard or API. Early A14 production batches shipped with conservative PSU rating tables that occasionally rejected valid PSUs. If your firmware is older, document the build, plan the upgrade before assuming the PSU is at fault. Note that Canaan's bootloader is signature-locked on all A14 batches D-Central has handled — you can roll forward, but you cannot cleanly downgrade. Flash from `avalonminer.org/firmware-document/` against the build matched to your control-board sticker. Wrong-revision flash is a ship-to-bench event.
If the chassis is a recent secondary-market purchase, inspect for evidence of a non-Canaan PSU swap during prior ownership: re-crimped connectors, third-party labels covering Canaan stickers, drilled mounting holes, splice tape. Operators selling A1446s onward sometimes swap the matched PSU to retain it for another rig and ship the chassis with a generic. Confirm against original Canaan part numbers; if the PSU is not original-spec, treat the unit as a wrong-SKU case from delivery.
Audit the entire site for PSU-rig pairing. Walk the rack with a clipboard. Match every PSU sticker to its chassis class. Any A14 chassis (A1326, A1346, A1366, A1446, A1466) requires a `PSU3400-01 Plus` or equivalent A14-rated unit. Any A11/A12 chassis (A1166, A1246, A1266) takes the older `PSU3300` family. Cross-deployment is an operational error that compounds across rack moves; one audit pass catches the case you don't know you have.
Replace the PSU-to-PDU cable if the existing cable is a generic IEC C19/C20 rated below `20 A`. Underrated cables pass small loads invisibly and bottleneck high-current loads exactly when the firmware checks rated capacity. Use a properly rated and labelled `C19-to-C20 20 A` cable, or move to PDU outputs that supply integrated cables of the right gauge. This rarely fixes a true SKU-mismatch case — but it eliminates a confounding variable for the audit log.
Document the rig's full power chain post-fix: PDU make / model, breaker rating, dedicated circuit confirmation, AC input under load, PSU model and continuous rating, DC rail readings at each hashboard connector under enabled load. This documentation block lives on the chassis or in your ops sheet. Two months from now, when the rig drops `PS[0] != 0` again, you will know in 30 seconds whether anything changed.
Stop DIY when any of these are true: the correct `PSU3400-01 Plus` is in the bay, AC input is `≥ 220 V` confirmed under load, firmware is current, and `PS[0]` still reads non-zero — at this point the variable is the controller board, the AUC3 sideband, or the hashboard rail circuitry, and you are in test-fixture territory. Do not chase it further on the rack. Book a D-Central ASIC Repair slot. Continued attempts in the field with a PSU-handshake fault risk damaging the controller board, and bench triage is materially cheaper than a controller-board replacement.
D-Central bench process for a stuck-`PS[0]` A1446: programmable AC source clamped to `230 V` for repeatable input; calibrated `PSU3400-01 Plus` on the bench rail; oscilloscope on the PSU sideband to confirm Canaan-correct identification handshake; controller-board test binary to read raw rated-capacity bytes the firmware sees; hashboard rail measurement at full enable; cap audit on hashboard PMIC sections; full reflash to known-good `MM4` revision; 24-hour burn-in at `135 TH/s` nameplate before ship-back. Canadian turnaround 5-10 business days. US and international accepted.
Ship safely. Pull the PSU separately from the chassis if both are coming to bench — they double-box differently, and a loose PSU rattling against a hashboard is its own ticket. Anti-static bags on any board you remove. Include: PSU sticker photo, controller log dump, API `stats` snapshot, AC input reading under load, and a short note describing what you swapped before shipping. We charge by triage time; complete documentation pays for itself inside the first hour at the bench.
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.
