DCENT_OS LED Reference: What the Lights on the Control Board Mean
Home » DCENT_OS — Open-Source Antminer Firmware » DCENT_OS LED Reference: What the Lights on the Control Board Mean
There are four LEDs on the control board. DCENT_OS drives them deliberately — a blink rate is a measurement, not decoration. This page is the complete list of states the firmware can put them in, taken from the LED engine's source. It is a reference: there is nothing to do here, only something to read off a miner you are standing in front of.
How to read this page
Nothing on this page has been verified against a miner on a bench. Every statement here is a statement about the published GPL-3.0 source, or about the configuration file that ships with it. Each claim carries one of four grades:
- Verified (in source) — read in the public release tree; the file and line are printed beside it.
- Verified (shipped config) — a real key and value in the
dcentrald.tomlthat ships in the repository. - Inferred — arithmetic, or a consequence that follows from Verified facts. Labelled, never dressed as an observation.
- Unknown — the source does not say, or two files say different things. We box it rather than pick one.
There is deliberately no Supported grade on this page. That grade would mean tested on hardware, and we have not done that for anything described here. When we have, this page changes.
The four LEDs
The firmware addresses four LEDs by name. Three are real sysfs devices; the fourth is not, and that is worth knowing before you go looking for it.
| Name in the firmware | Board designator | sysfs path | Role |
|---|---|---|---|
Green | D5 | /sys/class/leds/Green LED/ | User-facing status — mining heartbeat, share flash, locate |
Red | D6 | /sys/class/leds/Red LED/ | User-facing alerts — errors, warnings, rejected shares |
RedInternal | D7 | /sys/class/leds/Red LED (inside)/ | Daemon-alive heartbeat, independent of everything else |
D8 | D8 | none | See the box below |
Unknown — two files in the same crate disagree
The LED engine's own header comment says "D8: Mining pipeline heartbeat (toggles on work
dispatch)" (led.rs:7), and the code really does call toggle_led(Led::D8)
from the work-dispatch path (led.rs:404-406). But the GPIO layer says D8 has
"no sysfs entry, writes are no-ops" (gpio.rs:117-118) and routes its
brightness path to D7's, commented // fallback, D8 not wired
(gpio.rs:128).
So: the command path is Verified. Whether anything lights up on a board is Unknown. We would rather tell you two files disagree than pick the reading that sounds better. If you have a board in front of you and can settle it, that is a contribution we would take.
The green heartbeat is a thermometer
This is the single most useful thing on the page. While mining, the green LED's blink rate is computed from chip temperature — a faster heartbeat means a hotter miner. You can read the approximate thermal state of a machine from across a room, with no screen.
| Chip temperature | Cycle | Roughly | The firmware's own word for it |
|---|---|---|---|
| 55 °C or below | 1000 ms | 1 Hz | "target" (led.rs:415) |
| 65 °C | ~625 ms | ~1.6 Hz | "hot" (led.rs:416) |
| 75 °C or above | 250 ms | 4 Hz | "dangerous" (led.rs:417) |
Between 55 °C and 75 °C the scale is linear:
scale = 1.0 − (T − 55.0) / 20.0 × 0.75 (led.rs:426),
applied to a base cycle of heartbeat_on_ms + heartbeat_off_ms — 100 + 900 = 1000 ms
on the shipped configuration. The cycle floors at 100 ms, the on-phase at 30 ms and the
off-phase at 50 ms (led.rs:428-436).
The source disagrees with itself on the 65 °C row — we print what the code computes
The comment on led.rs:416 reads "At 65C (hot): ~2Hz (500ms cycle)". The
formula two lines below it, at led.rs:426, gives
1.0 − (65 − 55) / 20 × 0.75 = 0.625, so a 625 ms cycle and
about 1.6 Hz. Executed code beats a comment, so the table above prints 625 ms — but we
are citing that line for the word "hot" while overriding its number, and you are entitled to know
that. The 55 °C and 75 °C endpoints are stated by the source and agree with the formula;
only the middle row is ours. Inferred (our arithmetic).
Status patterns
Ten background states. The firmware holds exactly one at a time, and it resumes after any interruption.
| What you see | State | Green (D5) | Red (D6) | Rate |
|---|---|---|---|---|
| Green, both, red, off — once | Booting | one-shot wipe, 200 ms per step | played once at startup (led.rs:530-542) | |
| Green blinking briskly | Initializing chains | toggling | off | 250 ms/phase — 2 Hz |
| Green pulsing | Mining | toggling | off | temperature-proportional — see above |
| Red solid | Error | off | on, steady | static |
| Red blinking fast | Fan failure | off | toggling | 167 ms/phase — ~3 Hz |
| Red blinking slowly | Thermal warning | off | toggling | 500 ms/phase — 1 Hz |
| Green and red alternating, slowly | Pool disconnected | alternating | 1000 ms/phase — 0.5 Hz | |
| Green and red alternating, briskly | Firmware update | alternating | 300 ms/phase | |
| Green blinking very slowly | Sleep | toggling | off | 2500 ms/phase — 5 s cycle |
| Both dark | Shutdown | off | off | static |
Two pairs you can confuse — count the rate
Fan failure and thermal warning are both a blinking red LED. The only difference is speed: roughly three blinks a second for a fan, one a second for temperature. If you cannot tell, treat it as the fan — a stopped fan becomes a thermal event within minutes, and the reverse is not true.
Pool disconnected and firmware update are both green/red alternation. Again only the rate separates them: one alternation every two seconds for a lost pool, roughly three a second during an update. If you did not start an update, it is the pool.
These are our readings of the timings in the table above, not warnings the firmware itself emits. Inferred.
D7 is a separate question: is the daemon alive?
The internal red LED runs its own rhythm, on its own timer, and is not silenced by the
LED master switch, by night mode, or by a locate sequence (led.rs:269-280). It is a
double-pulse, like a heartbeat: on 100 ms, off 100 ms, on 150 ms, off 650 ms —
a 1-second cycle (led.rs:246-251). Verified (in source).
Read the two together:
- D7 beating, D5/D6 dark — the daemon is running and the user-facing LEDs are off
(night mode, or
[led] enabled = false). - D7 dark — either the daemon has stopped, or it shut down cleanly
(
all_off()clears every LED on shutdown,led.rs:701-706).
Find My Miner: the ten locate patterns
Locate plays a named rhythm on the front LEDs so you can pick one machine out of a rack. The
firmware's own convention: green reads as the high notes, red as the low notes, both together as
an accent (led_patterns.rs:3-4).
| Pattern id | Name | Frames | One playthrough | Defined at |
|---|---|---|---|---|
imperial_march | Imperial March | 20 | 4750 ms | :42-74 |
zelda_secret | Zelda Secret Found | 14 | 1800 ms | :80-102 |
mario_coin | Mario Coin | 6 | 880 ms | :108-115 |
morse_sos | Morse SOS | 18 | 3300 ms | :122-151 |
heartbeat | Heartbeat | 8 | 1760 ms | :157-173 |
cylon | Cylon Scanner | 12 | 1300 ms | :179-199 |
matrix | Matrix Rain | 20 | 1170 ms | :205-233 |
bitcoin_mined | Bitcoin Mined! | 18 | 3080 ms | :239-270 |
police | Police Siren | 16 | 960 ms | :276-300 |
close_encounters | Close Encounters | 10 | 3100 ms | :306-324 |
Inferred (arithmetic), and machine-derived: a playthrough is the sum of that
pattern's frame durations, which is exactly what the firmware itself computes
(BlinkSequence::duration_ms(), led.rs:46-49, summing
LedFrame.duration_ms declared at led.rs:33). We do not add these by hand.
The ten figures above are emitted by a script that parses every *_FRAMES array in
led_patterns.rs and refuses to print anything unless three controls pass — that the
summation formula is what we think it is, that every frame helper passes its argument straight
through, and that each array's declared [LedFrame; N] length equals the number of
frames actually parsed. Check them against the repository; that is the point of printing them.
Behaviour worth knowing before you use it, all Verified (in source):
- The pattern loops until the locate duration expires or a stop arrives
(
led.rs:566-616). The shipped duration is 30 s (dcentrald.toml:137). - A stop is honoured within 50 ms, even mid-frame (
led.rs:581-582). - An unrecognised pattern id does not fail — it logs a warning and falls back to
imperial_march(led.rs:546-552). If you asked for something exotic and got Star Wars, you mistyped it. - Share flashes and celebrations are suppressed while locate is running
(
led.rs:345,:352,:359,:367), so the rhythm stays readable. - When locate ends, the background pattern resumes (
led.rs:618-623).
Event flashes
| Event | What it looks like | Config key | Shipped default |
|---|---|---|---|
| Share accepted | brief green flash | flash_on_accepted_share | true |
| Share rejected | brief red flash | flash_on_rejected_share | true |
| New block from the pool | brief both-LED flash | governed by enabled only | — |
| Lucky share | three rapid double flashes (100 ms on / 80 ms off), then both LEDs held 400 ms (led.rs:659-679) | celebration_on_lucky_share | true |
| A chain came online during init | green flashes N times, 150 ms on / 100 ms off (led.rs:682-698) | chain_status_blink_codes | true |
The chain-online code is a genuine init diagnostic worth memorising: chain 6 flashes
once, chain 7 twice, chain 8 three times (led.rs:684-689). On a three-board S9
you should see one, then two, then three green flashes as the chains come up. A missing group tells
you which board did not enumerate before any log does.
A flash restores whatever the LED was doing before it, rather than forcing it off
(led.rs:632-639) — so a share flash never disturbs the heartbeat you were reading.
Night mode has a trap in it
Verified (in source) — and it will surprise you
Turning night mode on at runtime does nothing unless you also enabled it in the
configuration first. The handler computes
night_mode = enabled && config.night_mode_disable
(led.rs:386), and night_mode_disable ships as false
(dcentrald.toml:140). On a stock configuration the runtime switch is inert — it is a
two-key feature, and the config key is the master.
When it is active it blanks D5 and D6 only. It does not touch D7, so the daemon
heartbeat keeps blinking in the dark (led.rs:473-474). Flashes and celebrations are
suppressed while it is on (led.rs:628, :644, :660).
The shipped configuration block
This is the [led] section exactly as it ships in the repository's
dcentrald.toml. Verified (shipped config) —
DCENT_OS_Antminer/dcentrald/dcentrald.toml:131-142.
[led]
# LED status indicators on front panel
enabled = true
heartbeat_on_ms = 100 # green LED on-time during mining heartbeat
heartbeat_off_ms = 900 # green LED off-time (1Hz cycle = 100+900)
locate_pattern = "imperial_march" # default "Find My Miner" blink pattern
locate_duration_s = 30 # how long locate plays before auto-stop
flash_on_accepted_share = true # brief green flash on accepted share
flash_on_rejected_share = true # brief red flash on rejected share
night_mode_disable = false # turn off LEDs during thermal night mode hours
celebration_on_lucky_share = true # celebrate shares 10x+ above target difficulty
chain_status_blink_codes = true # flash green N times when chain N comes online
On a running miner the live configuration is /data/dcentrald.toml, which overrides
the read-only copy baked into the image and survives reboots and A/B upgrades
(DCENT_OS_Antminer/docs/CONFIGURATION.md:3-6).
Read this as source, not as a datasheet. These values are what the firmware is written to do. We have not confirmed them on a miner.
What this page does not tell you
- Whether any of it is true on your miner. We have not put a bench S9 in front of this table and checked it off. Until we do, this is a reading of source code.
- What the stock Bitmain firmware's LEDs mean. Different firmware, different meanings. This page describes DCENT_OS only.
- Whether D8 does anything. See the box at the top.
Which control boards this has evidence on is a separate question from what the firmware is written to do; see hardware status for the per-lane picture. Nearby: all documentation.
Source of record: the public GPL-3.0 release tree at
github.com/DCentralTech/DCENT_OS,
commit 6f61603 (2026-08-16). Line references are to that commit. Code moves; if a line
number has drifted, the file and the symbol name still find it. Reviewed 2026-08-19.
Companion tool — DCENT_Toolbox: Read LED and board state with a read-only DCENT_Toolbox pass.
Related products, repair, and setup paths
- how D-Central diagnoses ASIC repairs
- ASIC troubleshooting library
- ASIC manuals and repair guides
- replacement hashboards
- ASIC control boards
- ASIC power supplies
- S19 family replacement hashboard
- C52 replacement control board
- APW12 S19 power supply
- compare specs in the ASIC miner database
- compare ASIC miner specs
- ASIC miner database
- ASIC repair services
- Antminer S19 specs and profitability
- buy a tested Antminer S19
- Antminer S19 maintenance guide
- Antminer S19 repair service
- Antminer S21 specs
- Bitmain Antminer S21
- Antminer S21 maintenance guide
- BM1370BC S21 Pro chip
- Antminer S9 specs
- Bitmain Antminer S9
- Antminer S9 maintenance guide
- S9 hashboard repair parts bundle
Last reviewed August 19, 2026.
