Skip to content
Small team, full backlog, zero orders dropped. Support replies are slower than we’d like. Read our status update → Zero orders dropped. Status → 📬 Check your spam folder — most of our replies land there. We do answer. Status update → 📬 Check your spam folder. Status →

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.toml that 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.

LED hardware map. Verified (in source)dcentrald-hal/src/gpio.rs:110-140
Name in the firmwareBoard designatorsysfs pathRole
GreenD5/sys/class/leds/Green LED/User-facing status — mining heartbeat, share flash, locate
RedD6/sys/class/leds/Red LED/User-facing alerts — errors, warnings, rejected shares
RedInternalD7/sys/class/leds/Red LED (inside)/Daemon-alive heartbeat, independent of everything else
D8D8noneSee 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.

Mining-heartbeat rate vs temperature. Verified (in source)dcentrald-hal/src/led.rs:411-438
Chip temperatureCycleRoughlyThe firmware's own word for it
55 °C or below1000 ms1 Hz"target" (led.rs:415)
65 °C~625 ms~1.6 Hz"hot" (led.rs:416)
75 °C or above250 ms4 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.

Background LED patterns. Verified (in source) — enum at led.rs:54-75, timing at led.rs:411-468, drive at led.rs:471-527
What you seeStateGreen (D5)Red (D6)Rate
Green, both, red, off — onceBootingone-shot wipe, 200 ms per stepplayed once at startup (led.rs:530-542)
Green blinking brisklyInitializing chainstogglingoff250 ms/phase — 2 Hz
Green pulsingMiningtogglingofftemperature-proportional — see above
Red solidErroroffon, steadystatic
Red blinking fastFan failureofftoggling167 ms/phase — ~3 Hz
Red blinking slowlyThermal warningofftoggling500 ms/phase — 1 Hz
Green and red alternating, slowlyPool disconnectedalternating1000 ms/phase — 0.5 Hz
Green and red alternating, brisklyFirmware updatealternating300 ms/phase
Green blinking very slowlySleeptogglingoff2500 ms/phase — 5 s cycle
Both darkShutdownoffoffstatic

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).

The complete pattern registry — exactly ten. Verified (in source)dcentrald-hal/src/led_patterns.rs:331-342
Pattern idNameFramesOne playthroughDefined at
imperial_marchImperial March204750 ms:42-74
zelda_secretZelda Secret Found141800 ms:80-102
mario_coinMario Coin6880 ms:108-115
morse_sosMorse SOS183300 ms:122-151
heartbeatHeartbeat81760 ms:157-173
cylonCylon Scanner121300 ms:179-199
matrixMatrix Rain201170 ms:205-233
bitcoin_minedBitcoin Mined!183080 ms:239-270
policePolice Siren16960 ms:276-300
close_encountersClose Encounters103100 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

Momentary LED events and their switches. Verified (in source) — handlers led.rs:344-377; defaults led.rs:136-151 and dcentrald.toml:131-142
EventWhat it looks likeConfig keyShipped default
Share acceptedbrief green flashflash_on_accepted_sharetrue
Share rejectedbrief red flashflash_on_rejected_sharetrue
New block from the poolbrief both-LED flashgoverned by enabled only
Lucky sharethree rapid double flashes (100 ms on / 80 ms off), then both LEDs held 400 ms (led.rs:659-679)celebration_on_lucky_sharetrue
A chain came online during initgreen flashes N times, 150 ms on / 100 ms off (led.rs:682-698)chain_status_blink_codestrue

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.