Avalon 1566 – BOOTBY Overheat Reboot

Pull the power cord at the PDU, wait 60 seconds for bulk capacitors to drain, then restart. A full cold-boot clears any wedged MM3v2 state around the OVER_TEMP trip flag - Canaan's firmware occasionally holds the fault byte across a soft reboot. Count to 60; do not just hit the dashboard restart. This alone clears roughly one in five A1566 events that saw a transient thermal spike (warm intake air, an appliance on a shared HVAC circuit, an afternoon heat soak). If the miner runs an hour without re-tripping BOOTBY[0x02], you caught a transient and you are done. If it re-trips within minutes, escalate to Tier 2 - the 1566 will not tolerate a marginal cause for long.

Vacuum the front intake grille and rear exhaust vent with a shop-vac using the soft-brush attachment. Pay attention to the four fan blades and heatsink fin packs visible through the grille. The 1566's denser fin spacing traps dust faster than the 1466's - and dust-packed fins can raise heatsink-to-ambient delta by 8-15 C, which is the entire margin between running fine and OT on a warm day. No hard nozzle - you are moving dust, not polishing chassis steel. Restart and run for one hour. Clean intake alone resolves a large fraction of BOOTBY[0x02] events on residential 1566 installs.

Measure intake-air temperature with an IR thermometer held 5 cm from the front grille during hashing. Target 30 C or below for a Canadian basement or garage; 35 C is Canaan's absolute maximum per spec. The 1566 has less thermal headroom than its predecessors - 30 C is comfortable, 35 C is the cliff edge. If intake reads above 30 C, open a window, crack the garage door, or move the miner's intake to a cooler corner before doing anything more invasive. You cannot fix an ambient-envelope problem at the miner - the miner is just reporting what the room is doing to it.

Confirm physical clearance: at least 30 cm in front of the intake, at least 15 cm behind the exhaust. An A1566 piled on a shelf with no breathing room recirculates its own exhaust - and at ~3500 W of waste heat that is a faster cook than any previous Avalon. Pull everything back from the miner. Restart and confirm the fault does not return within an hour. In a multi-miner shed, reconfirm airflow direction - 1566s pointed at each other's intakes cook each other within a single afternoon.

From the dashboard or telnet to port 4028, run {"command":"ascset","parameter":"0,fan-spd,90"} to force fans to 90% PID. Reboot interval should lengthen significantly - sometimes the fault disappears entirely. This is diagnostic, not a permanent fix: 1566 fans wear out within months at sustained max RPM, and they wear faster than the 1466's. If the fault clears on forced 90%, you have isolated the thermal component and the underlying cause is dust, paste, or a marginal fan. Restore fan PID to default after diagnosis and proceed to Tier 2.

Open the chassis, remove each of the four A1566 fans in turn, and spin each by hand. A healthy dual-ball-bearing fan spins freely for 2-3 seconds after a flick. A failing fan grinds, buzzes, or stops immediately. Replace any fan that fails this test with a DF1205012B2 (current Martech revision used across A1326/A1346/A1366/A1446/A1466/A1566) - cross-compatible with the older HA1250H12SB-Z on mounting and electrical. One spare SKU covers the entire A13/A14/A15 generation. Stock at least two spares per 1566 in production - on flagship A15 hardware, fans fail more often than any other component.

Measure the 12 V fan rail at the PSU-to-MM3v2 connector under load. Multimeter on DC, probe at the connector while the miner is hashing at full power. Expect 11.8 V to 12.2 V sustained. Below 11.6 V means a tired PSU sagging the fan rail - the fans slow, chips heat, the miner trips BOOTBY[0x02], and you chase a thermal fault that is actually a power fault. Swap to a known-good PSU from the 1346/1366/1446/1466/1566 PSU family. Do NOT swap in a 1166 Pro or 1246 PSU - different generation, not cross-compatible with A14/A15 control signaling. The 1566 is the highest-draw load in this PSU family.

Re-torque the heatsink mounting clips on each of the three hashboards. A1566 heatsink clips loosen over 9-15 months of thermal cycling - faster than the 1466 because the 1566 runs hotter at stock. A heatsink with even 0.1 mm of lift loses its paste contact patch and the chip beneath cooks while neighbours are fine. Remove heatsink, wipe old paste with 99% IPA, apply a thin uniform layer of Arctic MX-6 or Thermal Grizzly Kryonaut, reseat with even clip pressure. One hashboard at a time - do not mix clips between boards. Highest-leverage Tier 2 step on a 1566 with one chain dominating PVT_T[].

Install a foam pre-filter on the intake if your install does not already have one. D-Central strongly recommends a simple foam pre-filter on every A1566 install - catches dust before it hits the heatsinks and can be vacuumed or washed in seconds instead of opening the chassis. Without a pre-filter you rely on the heatsink fins themselves to catch debris, which is the exact failure mode Step 2 fixes - and on a 1566's denser fin pack you will be fixing it more often than on a 1466. 30 PPI open-cell foam, cut to fit, replaced or washed every 21 days in dusty installs. Pre-filtration on a flagship 1566 is not optional past year one.

Verify line voltage at the outlet under load. On 240 V split-phase (correct feed for an A1566's 3420-3700 W draw) expect 235-245 V. On 208 V commercial expect 202-212 V. Low line voltage forces the PSU to draw more current, heats PSU internals, and can trip the PSU thermal sensor independently of hashboard sensors - which the firmware logs as BOOTBY[0x02] even though the chips are fine. Fix the feed before continuing - electrician or panel problem before miner problem. Never run an A1566 on 120 V. The 1566 is less tolerant of marginal feeds than any previous Avalon.

Snapshot cgminer-api estats output to a text file before any further changes. Run echo -n '{"command":"estats"}' | nc 127.0.0.1 4028 from the miner or a network-connected laptop. Save as a1566-pre-tier3.txt. Capture the BOOTBY history from the background log too. If the miner ships to D-Central, that pre-fix snapshot is exactly what the bench tech needs - and it saves diagnostic time, which saves you repair dollars. Take photos of every step in the disassembly. The 1566's hashboard layout differs from the 1466's - photograph cable routing carefully.

Remove the suspect hashboard, strip the heatsinks, and reapply thermal paste on every ASIC on the chain that dominated your PVT_T outlier list. Arctic MX-6 or Thermal Grizzly Kryonaut in a thin uniform layer - the grain-of-rice heuristic is for CPUs, not a multi-chip hashboard; you want a uniform film across each chip top. Replace any thermal pad under the PCH or voltage-domain ICs if pads are crumbled, discoloured, or compressed. Budget one hour per hashboard the first time, 30 minutes once practised. Where most BOOTBY[0x02] loops on 1566 miners 9+ months old finally break - the 1566 hits paste end-of-life sooner than predecessors.

If one specific chip position is the outlier and paste refresh did not resolve it, reflow that single chip. Preheat the hashboard from below at 150 C for 3 minutes, hot-air from above at 310-330 C for approximately 30 seconds with flux around the chip periphery, natural cool-down. The A15-generation BGA tolerates a single reflow cycle reliably. A second reflow on the same chip within 90 days rarely sticks - at that point the chip is dying and needs graded-replacement from salvaged A15-generation inventory (scarcer than A14). Practice on a junker A14 board first if this is your first BGA reflow.

Reseat the MM3v2 ribbon connectors on all three hashboards. The IDC-style ribbons used on the 1166 Pro and 1246 carry over on the A1566 and oxidize the same way in humid environments. Pull each ribbon fully, wipe contacts with 99% IPA on a lint-free wipe, reseat until the latch clicks. Oxidized ribbons can break the temperature telemetry path specifically, causing one chain to appear cool while running hot - tripping BOOTBY[0x02] from the PSU thermal sensor while the chip telemetry says everything is fine. This is the diagnostic head-fake that drives Tier 4 escalations on miners that did not need bench work.

Flash a known-good MM3v2 firmware build for the A1566 from Canaan's login-gated firmware portal at avalonminer.org/firmware-document/. Release notes are sparse, but it is the only official source. Verify your hardware revision against the firmware compatibility table before flashing - the wrong MM3v2 build for a late-rev A1566 can brick the control board. Flash via the dashboard's firmware page over a wired connection; never flash over wireless, never flash while hashing, never flash while an OT fault is active. Do NOT treat firmware refresh as the first move on BOOTBY[0x02] - on the 1566 it is even less likely to be the cause than on older Avalons.

Stop DIY and ship to D-Central when: every fan replaced, every heatsink cleaned, every chip repasted and the miner still trips BOOTBY[0x02] within 24 hours; reflowed a chip once and OT returned within 30 days; PVT_T[] returns impossible values (negative, above 200 C, or identical across all chip positions); same chip position trips on two different A1566 units in your rig; visible discoloration, burnt smell, or capacitor damage anywhere on the hashboard, MM3v2, or near the PSU. Book a slot at d-central.tech/services/asic-repair/. Turnaround 5-10 business days, Canada-wide, US and international welcomed.

What D-Central does at the bench: MM3v2 under a programmable load, per-chain isolation with Canaan diagnostic binaries, hashboard test fixture for the A15-generation BGA, chip-level replacement from salvaged-grade A15-generation inventory where available (lead times longer than for A14 inventory due to flagship scarcity), full reflow + reseal, MM3v2 thermal-sensor trace repair where applicable, post-repair 24-hour burn-in at nameplate. Immersion conversion is a Tier 4+ option for A1566 operators - on the 1566 the case for immersion is stronger than on any previous Avalon because the 1566 runs closer to its trip ceiling at stock.

Pack for shipping. Pack each hashboard in anti-static bags, pack the MM3v2 separately, double-box with at least 5 cm of foam on every side. Include a printed diagnostic note with: the kern.log excerpt (actual OT lines and BOOTBY[0x02] byte), MM3v2 firmware build, PSU model, measured line voltage, intake ambient at trip, fan tach readings before failure, every Tier 1-3 step you have already run with results. Better notes, faster and cheaper repair. Never ship A15-generation hashboards loose or in single-box packaging - replacement inventory is too scarce to risk a shipping write-off.