Potential Problems and Solutions for ANTMINER Z11

The Antminer Z11 is an Equihash miner (Zcash, Horizen, and other Equihash coins), rated at roughly 135 KSol/s from three hashboards drawing around 1,400W at the wall. Most Z11 faults fall into four buckets: a firmware/pool mismatch, network-induced rejects, a dead ASIC in one of the chains, or a board that dropped below its target frequency. This guide walks each failure, the tool you need, the fix, and how to confirm the miner is healthy again before you rack it.

First, isolate the layer. A Z11 has three independent systems that can each fail: the PSU, the control board (running the web UI and driving the chains), and the three hashboards. Every diagnosis below is about proving which of the three is at fault before you swap anything.

Tools you’ll want on the bench

• A laptop on the same subnet, plus the Bitmain IP Reporter or a network scanner to find the miner’s IP
• A known-good APW7 PSU (or another verified Z11-compatible PSU) for swap-testing
• A multimeter for continuity and DC-rail checks
• A clip-on IR thermometer or thermal camera for heatsink hot-spots
• Compressed air and a soft brush — most “random” faults on a used Z11 are dust
• The kernel log from the miner UI (Status > Kernel Log), which names the failing chain and chip position

Safety. The low-voltage DC rails feeding the boards will not shock you, but they can push enormous current — a slipped screwdriver across a rail will arc and vaporize metal. Power down and unplug before touching connectors. The genuine electrical hazard lives inside the sealed PSU shell, where the mains-side bulk capacitors hold a charge. Never open the PSU — if one is suspect, swap it, don’t crack it.

Problem: Local hashrate looks normal, but the pool shows low hashrate

This is the classic Z11 symptom: the miner’s own status page reports a healthy KSol/s figure, yet your pool credits far less. It almost always means shares are being generated but rejected or lost in transit — a stale-firmware or connectivity issue, not a dead board.

1. Confirm you’re on the latest official Bitmain firmware for the Z11. Outdated firmware is the single most common cause of a good local rate producing a poor pool rate. Download from the Bitmain support portal: service.bitmain.com Z11 downloads.
2. Check the pool page in the miner UI for a climbing Rejected counter. A few tenths of a percent is normal; several percent points to firmware, latency, or a bad pool endpoint.
3. Verify the pool’s stratum URL, port, and worker name are exact. A misconfigured difficulty or a distant pool region inflates rejects.
4. Give the pool a full measurement window — pool-side hashrate is a rolling average and needs ~30–60 minutes to converge with the local reading.

Problem: High rejected-share rate

A rising reject percentage means the pool is throwing out otherwise-valid work — usually a network or timing problem between the miner and the pool.

1. Update to the latest firmware first; it clears a surprising share of reject issues on its own.
2. Check bandwidth and latency. A saturated uplink or a flaky powerline/Wi-Fi bridge causes shares to arrive stale. Put the miner on wired Ethernet straight to the switch.
3. Test the LAN switch and cable. A marginal switch port or a damaged RJ45 run will silently drop packets — swap the cable and try a different port before blaming the miner.
4. If rejects persist on clean firmware and a clean network, try a geographically closer pool region to cut round-trip time.

Problem: ASIC status shows “X” (chip failure in a chain)

An X on the status page marks a chip position that stopped responding in the ASIC chain. Because the chips on a Z11 hashboard are wired in series, one failure often drops the whole board’s reported chip count. Before condemning a board, rule out the power feeding it.

1. Swap-test the PSU. Substitute a known-good PSU (Bitmain recommends the APW7 for the Z11) and re-check. A sagging or failing PSU rail produces phantom chip dropouts across boards that look exactly like hardware death.
2. Note the pattern: an X at the same chip position every boot is a real board-level fault; an X that moves or clears after a PSU swap or reseat was a power/connection problem.
3. Reseat the hashboard power and data connectors. The Z11 feeds each board through its own connector rather than the bolted copper bus-bar of the later S17/S19/S21 generation, so a loose or oxidized board connector is a common and fixable cause. Power down, unseat, clean, and firmly re-seat.
4. If one specific board still fails on a known-good PSU with reseated connectors, that board needs component-level diagnosis or repair — a dead ASIC, a failed domain, or a heat-damaged solder joint.

On voltage: the Z11’s hashboards are organized into power domains, each feeding a group of chips in series. Voltage is regulated per domain, never per individual chip — so a single sagging domain, not one lone chip, is usually what takes a chain down.

Problem: Frequency is lower than normal

The Z11 is an auto-frequency miner: it tunes its own operating frequency at runtime, and a healthy board settles above 700. A board stuck below that is throttling because it detected instability — heat, weak power, or a marginal chip.

1. Reset to factory settings from the miner UI (or the reset button) and let it re-tune. Wait ~20 minutes for the auto-frequency routine to stabilize before judging the result.
2. If it re-throttles, check cooling: confirm both fans spin at full RPM, clear dust from the heatsinks, and verify intake/exhaust aren’t obstructed. A hot board deliberately lowers frequency to protect itself.
3. Confirm clean, adequate power. The APW7 delivers its full rated output only on a 200–240V feed; it will run on 110/120V but at reduced output, and a Z11’s ~1,400W draw sits near the ceiling of a single 15A/120V circuit. Undervoltage or an overloaded circuit shows up first as frequency throttling. Run the miner on 240V where you can.
4. Persistent low frequency on one board after cooling and power are ruled out points to a weak chip or domain on that board.

Reloading or upgrading firmware

1. Download the correct Z11 firmware image from the Bitmain portal linked above — never flash an image from another model.
2. In the miner UI, open System > Upgrade, select the file, and leave “Keep Settings” unchecked when you want a clean baseline for troubleshooting.
3. Do not cut power mid-flash — an interrupted write can brick the control board and force an SD-card recovery.
4. After it reboots, reset to factory settings and let it re-tune for ~20 minutes before re-reading hashrate.

How to confirm the fix worked

• Chip count is full: the status page shows every chip present with no X markers across all three chains.
• Frequency is above 700 on every board and holds steady after the 20-minute re-tune.
• Local and pool hashrate converge to the expected ~135 KSol/s once the pool’s rolling average catches up.
• Reject rate is a fraction of a percent and flat, not climbing.
• Temperatures are stable and fans hold a steady RPM — no thermal-driven frequency drops over a 30-minute soak.

When to escalate

If a board still shows dead chips after a known-good PSU, reseated connectors, clean firmware, and confirmed cooling, the fault is component-level and needs a repair bench — heat-gun rework, domain testing, and chip-level probing. That’s board surgery, not a settings change. Source the parts through ASIC repair parts or hand the board to a technician.

Related: Walk symptoms methodically with the ASIC fault finder, pull the original documentation from the miner manuals library, and if the fix is beyond a swap-and-reseat, start a repair with D-Central.