On an Antminer Z15 the miner spells the fault out for you: a healthy board shows ooo in ASIC status, and every x is a dead chip. Three chips sit on one board, so oxx is a board running on a third of its output. Boards marked with an x and boards that vanish entirely are both repairable.
Antminer Z15 hashboard repair is a small-board job with an unusually low tolerance for error: three chips to a board, three separate power domains, and no spare capacity anywhere on it. We work at component level — diagnostics, power-domain and chip repair, cleaning and thermal work, then validation under load inside a running miner. If you cannot open the machine, or cannot tell which of the three boards is at fault, that is not something you need to solve before contacting us.
Technical Diagnostics and Common Issues with Antminer Z15
Quick Symptom Checklist
These are the readings and log lines Z15 owners send us most often, taken from real machines. The hex values and counters differ from machine to machine — match the shape of the line, not the digits. And note that hashrate on this model swings widely between refreshes: a single low number is noise, the letters and the counters are signal.
- ASIC status on one chain reads
oxo,oxxorxxoinstead ofooo - A chain is gone from the Chain# table altogether — not zero, absent — and the machine settles near 280 KSol/s instead of 420
bm1740_verify_nonce_integrality CRC error. cal-crc=9e6b, chip-crc=6bea-
nonceID is different cf != d0 chipid=1, naming the chip that is misbehaving -
receive a error nonce. total = 13, with the total climbing over days rather than jumping -
low freq[2-1]: cur freq 815, [775, 815], invalid nonce 0, ox status 1, and the frequency walking down step by step - Accepted work falling away over weeks while nothing in the interface turns red
One thing worth ruling out before shipping anything: pools 1 and 2 showing Dead with Failed to resolve (?wrong URL) in the log is an empty pool configuration, not a board fault. A Z15 runs perfectly well on pool 0 alone.
Model-Specific Patterns We See on Antminer Z15
A chip dies in one of two ways, and they look nothing alike. Usually the cores fail while the chip keeps passing the chain signal along: the board stays in the list, the status turns to oxo or oxx, and it goes on hashing on whatever is left. Less often the chip stops passing signal at all, and then the chain disappears from the table completely. The first case is often mistaken for a pool problem, the second for a dead board. Neither is.
oxx and still produces, at roughly a third of the chain beside it. Below: a different machine where the chip stopped passing signal, and the chain is simply not in the table any more.One reading proves nothing. Hashrate on the Z15 fluctuates hard. The same healthy chain reads very differently from one refresh to the next, and two chains compared at a single moment tell you almost nothing. What indicates a fault is the status letters, an error counter that keeps climbing, and a trend across days. This is why boards get shipped that did not need to be — and why genuinely failing ones sit in a rack for months.
The error counter climbs for weeks before anything looks broken. receive a error nonce reached 13 over three days on one machine, alongside CRC errors naming a specific chip. Nothing in the interface goes red; accepted work just quietly thins out. Owners usually notice a month after it started.
The miner throttles a chain trying to save it. When a chain misbehaves the firmware steps its frequency down inside the allowed range — 815, then 810, 805, 800, 793, 787, 781 within a quarter of an hour on one unit. It is the machine compensating for hardware, not a setting to be tuned back up.
Hardware Notes
| Specification | Details |
|---|---|
| Algorithm and cooling | Equihash — Zcash and Horizen. Air-cooled. |
| Miner hashrate | 420 KSol/s from three hashboards, about 140 per board. Individual readings swing widely, so judge a board by its status letters and error counters rather than by one number. |
| Hashboards per miner | 3 |
| Chips per board | 3. The log numbers them chipid=0 to chipid=2, and a healthy board reports ooo in ASIC status. |
| How the chips are grouped | Three power domains, one chip each. A power fault therefore takes out a single chip rather than a group, which is why the status usually loses one letter at a time. |
| Chip family |
BM1746AA. The letters at the end are a production batch marking rather than a different part. |
| Board base | Standard PCB, no aluminium backing. |
| Hashboard marking | Printed on the board as BEZ36601_V1.0 or BEZ36601_V2.0. You can also tell them apart by eye — see the photographs below. Both revisions fail the same way, take the same repair, and mix freely in one miner. |
| Power | 1510 W for the machine, fed from an external power supply — most often an APW3++, though plenty of units arrive on other or custom supplies. |
What the Log Is Telling You
None of this needs action from you. It is here so you know what state your board is in before deciding to ship it.
| What you see | What it usually means | What we do with it |
|---|---|---|
oxo or oxx in ASIC status |
One or two chips are dead but still passing signal, so the board keeps hashing on what is left. | We establish whether the chip itself failed or its power domain starved it, then repair or replace accordingly. |
| A chain missing from the table entirely | A chip has stopped passing signal, so nothing on that board answers the controller. | We bring the board up on the bench and find where the chain stops responding. |
bm1740_verify_nonce_integrality CRC error |
Work coming back from a chip is arriving corrupted. The chip is alive and unreliable, which is worse than dead for your accepted share count. | We test each chip separately, since a chip that answers is not necessarily a chip that works. |
nonceID is different ... chipid=N |
The firmware is naming the chip that returned the bad result. N is its position on that board. | We start from the named chip, then check the rest rather than assuming it is alone. |
receive a error nonce. total climbing |
Slow degradation. A board in this state usually has weeks left, not hours. | We treat it as a repair booked in advance rather than an emergency, and say so honestly. |
low freq[...] with the frequency stepping down |
The miner is lowering that chain's frequency to keep it running. Compensation, not configuration. | We look for what the firmware is compensating for, because raising the frequency back only hides it. |
| One chain reading lower than the others right now | On its own, usually nothing. Readings on this model scatter widely, and a single snapshot is not a diagnosis. | We ask for the status letters and the log instead, and tell you when there is nothing to fix. |
Pools 1 and 2 Dead, Failed to resolve (?wrong URL)
|
Empty backup pool slots. Nothing to do with the hashboards. | Nothing — we tell you so and save you the shipping. |
Diagnostics Focus
The x says where, not why. The status marks which chip stopped producing, but a chip goes quiet both when it has failed and when the domain feeding it has. On a three-chip board those are one-to-one, so the first job is separating a dead chip from a starved one before anything is removed.
Every chip measured, not counted. A full ooo and a full chip count tell us the board enumerates, nothing more. Each of the three is tested on its own, which is the only way a chip that answers but underperforms is caught — and the only way to tell that apart from ordinary scatter in the numbers.
Our Professional Repair Process
What to Ship Us
The choice above sets what arrives here, not what it costs — the price is the same either way, and only the size of the return parcel changes. Hashboard only works if you already know which board is at fault and are comfortable pulling it. Complete miner works if the machine is sealed to you or the status line is ambiguous. Nobody is expected to diagnose their own miner before shipping it.
Gotchas
A board that still hashes is not a board to leave alone. An oxx chain earning something feels like a machine you can put off repairing, and the error counter says otherwise — it climbs, and the surviving chips carry the load meanwhile. The boards that arrive here as scrap are usually the ones that ran for months in that state.
Heat damage does not clean out. Dried thermal compound is the cause; what it leaves behind — tired solder under a chip, a sensor path that has cooked — stays after the cleaning. Fresh paste on a board that has already been overheated buys weeks, not a fix, and we say which of the two we are looking at before quoting.
Typical Service Scenario
Six years in and switched back on. The Z15 shipped in 2020 and a lot of them sat idle through the quiet years. Dried compound, a season of dust and the first sustained load in months tend to arrive together, and the weakest chip goes first.
Dust and a warm room. Reduced airflow raises chip temperature quietly until error counts start rising. Nothing in the interface turns red, so this is usually found by looking at the trend rather than at an alarm.
Something happened on the line. Storms, brownouts and a supply that sags under load leave a recognisable signature on these boards — and with an external power supply the Z15 has one more link in that chain than machines with the supply built in.
What Happens After Intake
Every board takes the same route through our USA-based lab: intake and incoming inspection, diagnostics, component-level repair, then cleaning and replacement of the thermal interface, then testing — on STASIC and ASIC REPAIR fixtures first, and for at least an hour inside a live miner under load afterwards. Extended burn-in beyond that hour is a separate add-on. Chips that turn out to be genuinely dead are billed separately, because how many need replacing is only known once the board is powered on a bench.
Diagnostics and Validation Equipment
Bench measurement, STASIC and ASIC REPAIR fixtures for chip count and work verification, a per-chip test that scores all three separately, and final validation inside a working Z15 under real load. The fixture proves the chain; the per-chip test finds the chip that answers but does not work; only the miner proves the board.
All repairs are performed personally by Alex, who has been servicing ASIC miners since 2019. See credentials →
Contact our repair team today and get your miner back to full power.