Avalon Series – Chip BIN Mismatch Error
Warning — Should be addressed soon
Symptoms
- One or more chips on a single hashboard report a different `BIN` grade in `estats` than their neighbours (A vs B, B vs C, or numeric equivalents)
- Per-chain `DH%` reads above 2% sustained on the affected board while the other two boards in the rig sit under 1%
- Realized hashrate on the affected board is 8-20% below its expected nameplate share
- `PVT_T` on one or two specific chip positions reads 5-12 °C above the chain's median chip temperature
- `PVT_V` shows core voltage drift on the same chip positions — outlier chips driven outside their tolerance band
- The board was repaired recently — chips swapped, hashboard purchased used, parts pulled from a different generation ASIC
- `DH%` climbed immediately after a chip replacement or hashboard swap rather than gradually over time
- Pool side shows shares-per-board imbalance — affected chain submits 15-25% fewer shares than peers
- One or more chip positions flag `ECHU` thermal warnings while the rest of the chain stays cool
- After down-binning the entire board (-10% frequency, +50 mV voltage), `DH%` returns to under 1.5% — confirms diagnosis
- You bought 'loose chips' or a 'tested A3206 batch' online and reflowed them onto a working board
- `MM_STATUS` log shows `BIN_MISMATCH` or `BIN_DIFF` flags (only emitted by some MM firmware versions)
- A new chip replaced last quarter has died or degraded badly within 30-90 days of installation
Step-by-Step Fix
Pull the per-chip BIN map via `echo -n '{"command":"estats"}' | nc <miner-ip> 4028 > bin-map.txt` (or telnet 4028 and paste the command). Search the reply for `BIN`, `CHIPBIN`, `BLOCK`, or `MGN` blocks — the field name varies by MM firmware version. On a clean factory board, every chip on a single chain reports the same bin grade. Note the chain (0/1/2), chip position (0-119 typically), and bin value of any outliers vs neighbours. Save the snapshot — this is the diagnostic artefact the bench will ask for if you escalate.
On the same `estats` reply, read the `PVT_T` (per-chip junction temp) and `PVT_V` (per-chip core voltage) arrays. Cross-reference outlier chip positions from Step 1 with thermal/voltage data. Pattern A (dangerous): elevated `PVT_T` 5+°C above chain median + `PVT_V` near chain mean = an `A`-bin chip being over-driven on a `B`-bin board. Pattern B (wasteful): `PVT_T` near or below median + chain contributing disproportionately to `DH%` = a `C`-bin chip being under-driven. Confirm which pattern you have before acting.
If Step 1 returned `BIN: 0`, `BIN: 255`, or non-numeric garbage on any chip, you may have a counterfeit or wiped-OTP chip. Power off, remove the suspect chip, reflow it onto a known-good test board (sacrificial board or repair fixture). Boot, pull `estats`, observe behaviour standalone. Clean numbers at stock voltage = probably real chip with wiped fuse; chaotic numbers, fast thermal runaway, or refusal to enumerate = counterfeit, scrap. Real chip with wiped OTP can be used — treat as worst-bin (`C`) for safety.
Confirm the mismatch by down-binning the entire affected board. From the AvalonMiner UI: Configure → Frequency → -10% (e.g. 630 MHz to 567 MHz on a 1246), Voltage → +50 mV, save, reboot. Run 30 minutes. Pull fresh `estats`. If `DH%` drops below 1.5% per chain on the affected board and the outlier chip's `PVT_T` returns within 2-3°C of chain median, the diagnosis is confirmed. You can ride this configuration indefinitely (revenue penalty: -8-12% board hashrate) or proceed to bin-matched replacement.
Inventory check — pull every Avalon hashboard in your fleet through the same BIN-map probe. If you've been buying loose chips or used boards from the same supplier, you'll find this fault on multiple boards. Damage to over-driven A-bin chips is cumulative; their service life is reduced regardless of remediation. Triage which boards have outliers, which can be down-binned and ridden out, which need bin-matched chip replacement, which should be retired.
Source matched-bin replacement chips. Find chips of the bin grade matching the rest of the board — not the bin of the chip you removed. If the board is `B`-bin and someone replaced one chip with `A`-bin, pull the `A` and replace with `B`. Reputable parts suppliers (D-Central included) tag chips with bin grade where OTP was readable on harvest. Ask explicitly when ordering: 'Is the bin grade tagged?' If not available, the next-best option is replacement with the closest available bin and accepting the down-bin retune indefinitely.
Firmware version probe. Some older MM builds don't read the BIN field correctly on newer chip generations (e.g. early A1346 MM builds reading A3206H chips). Note the current MM version, then download the latest stable build for your hardware revision from canaan.io/support, flash, reboot, pull `estats` again. If the BIN map now reads cleanly with all chips matching, your 'mismatch' was a firmware reporting bug. Real fault: rare but eliminable before any hardware work.
Visual chip-mark inspection. Some Canaan chip generations laser-mark a bin code on the package top (single digit or letter near the date code). Power off, remove the fin stack, photograph chip positions under good lighting at 5-10x magnification. Compare the mark on the outlier chip vs neighbour chips. Visual mark is supplementary to OTP — if marks differ visibly, the OTP read was correct. If marks match but OTP differs, suspect either a remarked counterfeit or a Canaan generation that doesn't laser-mark consistently.
Document the board's chip-replacement history. Tape a 3x5 card to the inside of the chassis with: install date, which chip positions have been replaced, source of the replacement (vendor name, order number), bin grade if known, the firmware version active during install. When the board is sold, repaired, or fails again, the next person owning the problem has the data they need to diagnose it. The Mining Hacker move is treating each board like test equipment with a calibration log.
Down-bin operation as a long-term mitigation. If matched-bin replacement chips aren't available and the down-bin retune from Step 4 holds DH% under 1.5%, you can run the board indefinitely at -10% frequency / +50 mV voltage. Accept the 8-12% hashrate penalty. Monitor `PVT_T` on the over-driven chip (if Pattern A) — it should remain within 3°C of chain median under the down-bin profile. If `PVT_T` drifts back up over weeks, the chip is degrading despite the retune; escalate to Tier 4.
Set up monitoring for the BIN map. Five-line shell script: `nc <miner-ip> 4028 <<< '{"command":"estats"}'`, parse for the BIN array per chain, alert on any chip whose bin differs from its neighbours. Run on a 5-minute cron, push alerts to Discord/Slack/email. This catches future bin mismatches at the moment they're introduced — useful if you do regular chip replacements or if your repair workflow involves multiple operators.
Triage your supplier relationship. If the bin mismatch traces to a specific chip seller, they sold you ungraded inventory. Document: vendor, batch ID, harvest date, OTP read results across the chips you purchased. Most operators discover bin-mismatch after the warranty window has closed — the supplier-triage outcome is usually 'buy from someone better next time,' not 'get a refund.' Worth doing anyway: the data prevents repeating the mistake, and reputable repair shops will trade information about bin-blind sellers.
If a previously-replaced chip has died inside 30-90 days, do not just replace it again with another chip from the same source. The first replacement died because of bin-mismatch wear-out; the second will follow unless you change either the source (matched-bin replacement) or the configuration (full-board down-bin). Pulling another chip from the same drawer is the textbook definition of repeating the fault.
Stop DIY at this point — the actual fix (bin-matched chip replacement on the bench) is Tier 4. You are now in test-fixture territory. Pre-ship checklist: save the `estats` BIN-map snapshot from Step 1; record the down-bin retune results from Step 4; document chip replacement history per Step 9; package hashboard in anti-static bag, double-box with ≥5 cm foam on every side. Include a physical note inside the box with the diagnostic artefact summary. Book at d-central.tech/services/asic-repair/.
D-Central bench process: OTP read-back on every chip on the affected board to map current bin distribution; identify outlier chips; remove via hot-air rework with preheat (~150°C bottom, 310-330°C top-side ~30s); reflow bin-matched replacement chips from D-Central's tagged inventory; re-paste with Arctic MX-6 or Kryonaut; reassemble fin stack; 24-hour nameplate burn-in with continuous `estats` `DH%` and `PVT_T` monitoring before the board is signed off and shipped back.
If the bench audit reveals more than 3-4 mismatched chip positions on the same board, the economic break-even shifts from per-chip replacement to full-board swap. D-Central's salvaged-grade hashboards run $420-$920 CAD depending on model and grade — factory bin-matched. Where multi-chip rework on the existing board would run $195-485+, a board swap may be the right call. The bench will quote both options when an audit reveals multi-chip mismatch.
Post-repair verification. After the board returns from D-Central, pull `estats` again on first power-up and confirm: (a) BIN map reads consistent across all chips on each chain; (b) `DH%` per chain reads under 1% at stock voltage/frequency; (c) `PVT_T` outlier-spread across chips on each chain is within 3-5°C; (d) realized hashrate matches nameplate share. Save this baseline `estats` reply alongside any future ones — this is your reference point for the next time the board has trouble.
Long-term: only buy replacement Avalon chips from suppliers who explicitly tag bin grades on harvest. The $10-30 per-chip premium for a bin-tagged source is the cheapest insurance in mining repair work. Build a small inventory of bin-tagged spares per common bin grade (B-bin is most common in current Canaan stock; A and C are rarer and worth keeping in stock if you operate a fleet). Document every replacement in a per-board log so future repair work can match bins without an OTP read-back trip to 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.
