Skip to content

We're upgrading our operations to serve you better. Orders ship as usual from Laval, QC. Questions? Contact us

Bitcoin accepted at checkout  |  Ships from Laval, QC, Canada  |  Expert support since 2016

BEEP_ERR Warning

Antminer – Control Board Beeping

Control Board Beeping — on-board piezo buzzer alarm indicating a firmware fault (ERROR_TEMP_TOO_HIGH, ERROR_FAN_LOST, ERROR_POWER_LOST, ERROR_SOC_INIT, or hashboard short) that demands operator attention.

Warning — Should be addressed soon

Affected Models: All Antminers with on-board buzzer: S9, S9j, S9k, S17, S17 Pro, S17+, S19, S19 Pro, S19j, S19j Pro, S19 XP, S19 XP Hydro, S19k Pro, S21, S21 Hydro, T17, T19, T21, L3+, L7, Z15, D9, KA3

Symptoms

  • Audible piezo-style beep from inside the chassis, not from a fan or the PSU
  • Continuous non-stop beep that started during mining (points at `ERROR_TEMP_TOO_HIGH` or `ERROR_FAN_LOST`)
  • Intermittent short-short-long or long-long-short coded pattern at boot (POST / self-test alarm)
  • Single long beep on power-up that never resolves (hashboard or PSU handshake failure during init)
  • Beep starts when the miner crosses `80 °C` PCB or `95 °C` chip temp, clears when ambient drops
  • Buzzer screams immediately after a firmware update or factory reset
  • Beep began after a relocation where airflow or ambient changed
  • Miner is still hashing and showing green LEDs but the alarm is active — warning while still working
  • Miner is NOT hashing and the alarm is active — protective shutoff already tripped
  • `kern.log` shows `ERROR_TEMP_TOO_HIGH`, `ERROR_FAN_LOST`, `ERROR_POWER_LOST`, `ERROR_SOC_INIT`, or `check_asic_number_with_power_on` around the beep onset
  • Fault LED on the control board is solid red or blinking red in time with the beep
  • Buzzer quiets if you pull one hashboard or one fan — isolating the alarming subsystem
  • Beep pattern changes after a firmware roll-forward or roll-back

Step-by-Step Fix

1

Pull the log before touching anything else. Web UI → Miner Status → Kernel Log, or SSH `tail -n 200 /var/log/kern.log | grep -iE 'ERROR|FATAL|fan|temp|power|soc|asic_number'`. Record every `ERROR_` line around the time the buzzer started. The buzzer is the alarm; the log has the real fault code. Every step below branches off what you find here — skipping this means you are guessing with a multimeter.

2

Hard power-cycle at the breaker. Not a soft reboot. Power off for 60 seconds, power on, watch the buzzer through boot and into steady-state mining. Bitmain's watchdog sometimes latches a fault after a transient event and does not re-check until a cold boot. If the buzzer clears and stays clear for 15 minutes of sustained mining, log the event and move on. If it returns, your log from Step 1 is the real signal.

3

Clean the intake filter and heatsink fins. Shop-vac the front grille, wipe down the intake with a dry microfiber, confirm nothing sits within 15 cm of the front of the miner. Dust-clogged filters are the single most common cause of `ERROR_TEMP_TOO_HIGH` in home-mining setups. A 5-minute cleaning stops the alarm, drops intake temp by 3–8 °C, and buys back nameplate hashrate you did not know you lost.

4

Verify intake ambient with an IR thermometer — at the front grille under load, not room-middle. Target ≤ 35 °C standard, ≤ 40 °C Hydro. A summer basement at 38 °C ambient will push an S19's intake past threshold on hot afternoons and trigger the thermal alarm daily. If ambient is too high, the fix is airflow engineering (intake ducts, exhaust fan, open a window) before any hardware swap.

5

Check firmware version for known buzzer-aggressive builds. On `support.bitmain.com/downloads`, compare your installed firmware against the latest release for your hardware revision. Some stock builds in the 2021-2022 range ship overly aggressive buzzer behaviour — beeping on minor temp fluctuations newer builds silence. Roll one version back or forward and watch for behaviour change; or flash DCENT_OS / Braiins OS+ / LuxOS / Vnish.

6

Re-seat every hashboard ribbon and power cable. Power off at the breaker. Disconnect each data ribbon and power cable; visually inspect connectors for blackening, oxidation, bent pins, or crimp damage before reconnecting firmly until you hear the click. A hashboard that cannot talk cleanly to the CB throws `ERROR_SOC_INIT` at boot and fires the buzzer before mining starts. Resolves a large fraction of post-relocation and post-shipping alarms.

7

Swap hashboards between slots to isolate. Label slots 0/1/2 with tape. Move the suspected-bad board to a known-good slot; move a known-good board to the suspect slot. Boot and observe the buzzer and per-chain UI reading. If the fault follows the board → bad board (hashboard repair territory). If the fault stays with the slot regardless of board → control-board cable or slot circuitry — Tier 3 or Tier 4.

8

Replace the suspect fan on `ERROR_FAN_LOST`. Pull the fan with 0 RPM reading. Inspect the bearing for grinding or wobble (dead). Confirm the 4-wire connector pins are clean. Swap with a known-good fan of the exact same PN (Antminer stock: 120 mm or 140 mm 4-wire PWM fans; S9 / S17 / S19 use 6000 RPM class; Hydro and S21 use variant-specific fans). Power on and verify every configured fan reports ≥ 1500 RPM within 30 seconds.

9

Fix a working fan with a dead tach wire. If a fan physically spins but the UI reads 0 RPM, the 4-wire connector's tach line (`FG`, usually yellow) is cut or the pin is oxidized. Ohm-out the yellow wire from connector to fan hub; replace the cable or splice with solid-core copper if cut. If the fan itself has a failed Hall sensor, the tach line reads open even with the cable intact — swap the fan. This is how you save a rig that is physically healthy but whose alarm is false.

10

Measure PSU output and verify model compatibility. Multimeter on DC, probe at the PSU-to-board connector while the miner attempts to boot. Expect ≥ 13.8 V sustained on a standard S19-class miner. Verify the PSU model matches your miner per Bitmain's compatibility list — running APW3++ on an S19 XP that wants APW12 throws `ERROR_POWER_LOST` and buzzes at boot. Verify the voltage-sense wire between PSU and CB has end-to-end continuity. Swap with a known-good PSU of the correct model.

11

Flash DCENT_OS for sane buzzer behaviour and real log visibility. DCENT_OS is D-Central's own open-source Antminer firmware — configurable buzzer behaviour (silent-with-webhook-alert, silent-with-email-alert, audible-plus-webhook, or traditional audible), per-chip HW%, tuning, autotuning, Stratum V2. Open-source on GitHub, no licensing BS. Alternatives: Braiins OS+, LuxOS, Vnish. All four turn the buzzer from a black box into a configurable, log-correlated alert pipeline.

12

Re-apply thermal paste on the hashboards. If `ERROR_TEMP_TOO_HIGH` keeps firing despite clean filters and low ambient, the thermal interface between ASICs and heatsinks has likely dried out — common after 18–24 months on standard Antminers and 12 months on Hydro. Disassemble the hashboard, clean old paste with 99% IPA and lint-free wipes, apply a uniform thin layer of Arctic MX-6 or Thermal Grizzly Kryonaut. Pay attention to PCH and voltage-domain ICs — dried pads are a sneaky false-over-temp cause.

13

Reflash the hashboard PIC / EEPROM. `fail to read pic temp for chain X` or `ERROR_EEPROM_INFO` in the log means the board's PIC16F1704 is not responding or its EEPROM is corrupt. With Bitmain's hash board code editor tool you can reflash the PIC and EEPROM directly over the CB's I²C bus. Niche skill — if you are not set up for it, ship the hashboard to D-Central and the bench will handle it.

14

Probe the buzzer circuit if the alarm fires with a clean log. Pull the board to the bench. Locate the piezo and driver transistor (SOT-23 near the buzzer). With a multimeter, check the GPIO line driving the transistor base — should sit at 0 V with no fault. If stuck at 3.3 V, either the firmware is commanding it (re-check log, fault might be logging outside kern.log) or the SoC GPIO is damaged. Replace the buzzer (CAD $2 passive piezo, 3–5 V) or the driver (2N2222 / MMBT3904 class, CAD $0.50).

15

Replace the temperature sensor or PIC chip if the log shows `fail to read pic temp` after reflashing the PIC and paste is fresh. Rare but real on boards with multiple lifetime ESD events. Hot-air rework, lift the old PIC, clean pads, place new PIC, reflow 260–290 °C. After reassembly boot and verify the UI reads real per-chain temps (55–75 °C on a healthy active chain) rather than `-` or `255`.

16

Know when to stop DIY. Three scenarios push to Tier 4: (a) a hashboard fault (`ERROR_SOC_INIT` follows the board, or shorted voltage domain) you are not equipped to repair at chip level, (b) buzzer fires with a clean log AND a confirmed-healthy buzzer circuit (SoC GPIO / CB fabric issue), (c) repeated PIC / EEPROM failures across reboots despite reflashing. Photograph the board, note Tier 1–3 steps you ran and their outcomes, book a D-Central ASIC Repair slot at https://d-central.tech/services/asic-repair/.

17

D-Central bench process: log pull, buzzer-pattern-to-fault-code correlation, per-chain SoC init test on a dedicated test fixture, PIC / EEPROM reprogramming with official Bitmain binaries, voltage-domain diagnostics on hashboards (short detection, MOS-tube and boost-circuit check, Fluke 15B+ rail probing), replacement of shorted components or reflow of suspect chips, buzzer-circuit repair or replacement if warranted, 24-hour burn-in at nameplate to confirm the alarm stays silent under real load. If the board is unrecoverable we quote a graded replacement from D-Central inventory and migrate firmware/config.

18

Ship safely. Whatever component you send — hashboard, control board, or full miner — anti-static bag, foam wrap, double-boxed with ≥ 5 cm foam on every side. Include a note with: the buzzer pattern (record on your phone), firmware version, kernel log excerpt around the alarm, what Tier 1–3 steps you ran, and your contact. Clear notes save diagnostic time and your repair cost. Canadian shipping is fast from anywhere in Canada; US and international welcomed.

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.