AvalonMiner Technical Documentation: Miner Log Technical Guidance Explained

The “log” an AvalonMiner ticket asks for is not a syslog file. It is the estats response from the CGMiner API the MM controller exposes on TCP port 4028: one flat frame of bracketed fields that already holds everything needed to decide PSU or hashboard, chain or single chip, thermal or firmware. Skim only TMax and GHSavg and you will pull good boards while a dying PSU stays in the rack. Covers the A10, A11 and A12 generations.

How to pull a clean log

• TCP 4028, short-lived connections. One command per connection, and the API is single-threaded — poll from two tools at once and you get truncated frames.
• Two wire encodings. Pipe: estats, ascset|0,reboot,0. JSON: {"command":"estats","parameter":""}. Strip the trailing \x00 before parsing, or your loader throws on a good log.
• If estats returns nothing, fall back to summary and version before concluding the controller is dead.

1. Pull version first. HWTYPE/SWTYPE are what a firmware image is matched against — record them, with DNA and MAC, before any upgrade.
2. Pull estats. Note Elapsed (seconds since the controller booted) at the moment of capture.
3. Pull it again 10–15 minutes later. Almost every field below is a counter or an average: one snapshot proves nothing, the delta between two proves nearly everything.

Canaan also ships a Privileged API, and their own repository README states plainly that using it voids the warranty.

The fields that carry signal

• Identity and uptime — Ver (firmware version string), DNA (unique miner ID), Elapsed (s), MEMFREE (bytes), WORKMODE (operating-mode index — read it, do not set it blind).
• Work and errors — LW total local work, MH per-board hard errors, HW total hardware errors, DH error rate in percent. MW/MW0.. carry nonce values per hashboard, not a work count — do not diff them as if they were.
• Chain health — ECHU is the per-hashboard error code (one value per board index) and ECMM the MM controller’s error code; both are codes to look up, not numbers to average. CRC is the communication-error counter — that is the one whose rate of change between two pulls matters. CRC climbing on one board index is a comms fault on that chain: connector, ribbon, or a chip that stopped passing traffic.
• Thermal — Temp (ambient), TMax, TAvg, per-board MTmax/MTavg, Fan1/Fan2 in rpm, FanR as a percent.
• Hashrate — GHSmm theoretical, GHSavg 1-hour average, MGHS per hashboard, Freq average MHz, WU work utility.
• Frequency state — PLLn are bin counts (cores landing at each frequency point), SFn the frequency targets, one set per hashboard index present in the frame. Read the indices you are given; never assume a board count.

Vo is the average chip voltage, reported as a scaled integer. Sanity-check it against what the same firmware shows in its web UI before comparing it to a target — voltage is the one number you cannot afford to be an order of magnitude out on.

PS[ ] — the field that decides PSU vs hashboard

PS is the power-supply status tuple, POWS its parameter companion. Most operators skip both.

• PS[0] is a fault indicator, not telemetry. The remaining slots are supply voltage, current and power figures. Treat any non-zero PS[0] as a PSU-side finding and confirm it against the PSU’s own fault reporting before pulling a board. Boards get condemned over a supply that already confessed.
• POW_I2C_CONN[SUCCES|FAIL] — the I²C link between controller and PSU. FAIL means the controller cannot command the PSU. It may still come up at its default output, so lit boards are not proof the link is healthy. The fix is the cable, connector and controller path, not the hashboard.

Counting chips with PVT and TA

PVT_T0/PVT_T1 and PVT_V0/PVT_V1 are arrays of temperature (°C) and voltage (mV), one array per hashboard index present in the frame. TA is the count of active chips.

1. Count the entries in each PVT_T array. That length is how many chips the board enumerated; the boards the frame reports should match each other.
2. A short array means the chain stopped enumerating. Where it stops is where to scope: the last chip that answered and the link to the next.
3. Cross-check TA. Below nameplate with full-length arrays means the chips are present and the problem is upstream of enumeration.
4. Sort the PVT_T array. One chip far above its neighbours is a hot chip; adjacent chips reading identical values is usually a sensor path, not a thermal event.

Do not read PVT_V as evidence of per-chip voltage control. It is telemetry. Hashboard voltage is regulated per domain — a group of chips sharing a regulator — so a low reading is actionable only at the domain level.

BOOTBY — why it rebooted

BOOTBY records the last reboot reason. Each documented reason sends you somewhere different:

• Hard reboot / power removed — breaker, PDU, PSU shutdown, loose C19. Not a software event; stop debugging firmware and look at the feed.
• Overheating — the thermal watchdog took it down. Pair it with TMax, MTmax and the fan fields: ambient first, then a stalled fan, then a blocked intake.
• Network problem — it could not reach or submit to the pool. Fix the link, not the miner.
• API / web reboot — a human or a script did it (web UI, or ascset|0,reboot,0 over 4028). Check your fleet tooling before the hardware.

Pair it with Elapsed and MEMFREE: a small Elapsed on every pull is a machine looping; MEMFREE shrinking before each reboot is a controller fault, not a hashboard.

Common mistakes

• Confusing ECHU with CRC. ECHU is an error code to look up; CRC is the counter whose rate of change carries the signal.
• Treating lit boards as proof the I²C link is good. POW_I2C_CONN[FAIL] can coexist with a powered machine.

The low-voltage DC domains on a hashboard are not a shock hazard — they are a high-current hazard, so keep rings and metal watchbands off the bench. The PSU’s mains side is the shock hazard: its PFC capacitors can hold roughly 400 V for minutes after the cord is pulled. Discharge and verify before probing inside a PSU.

Related

• ASIC Fault Finder — symptom back to component.
• Troubleshooting Guide for Avalon Miner Power Supply Failures — where a non-zero PS[0] leads.
• Avalon A11 & A12 Series Miner Disassembly Guide — once the log says the fault is inside.
• Step-by-Step Guide to Upgrading AvalonMiner Firmware — match HWTYPE/SWTYPE first.
• Start a Repair — send us the estats frame with the board.