Settings and station identity
Where each setting's value comes from, what lasts across a restart and what does not, the station settings, and how the station's two numbers — its local one and the one the lightning network assigns — relate.
1. Where a value comes from
A setting can be given a value in four places:
| Source | When it is applied | After a restart |
|---|---|---|
| 1. Defaults | Used from power-on. Used until a stored or downloaded configuration supplies a value. A failed download leaves the previous settings in use; unknown keys are ignored. | Restored. Change only with a firmware update. |
| 2. Remote (fleet) configuration | A file the station downloads on a schedule (the interval setting, default every 5 minutes; the current fleet file requests every 60 seconds). It holds fleet-wide lines plus a per-board block keyed on the processor ID; the board's block wins for the keys it names. Stored on the board, so it also applies while the server is unreachable. | Kept, and refreshed on the schedule. |
| 3. Your runtime changes | The controls on the Live and Signal chain pages, and POST /api/cfg. Changes apply immediately. | Lost — and usually sooner: the next successful remote fetch wins. |
| 4. Your stored local choices | Three choices are deliberately different: the enabled-input mask, the per-input polarity, and network participation. They are stored on the board. A new network choice saved by the owner in the dashboard applies on the next configuration download; otherwise later local choices stay in force. | Kept, until you change them again. |
Some keys cannot be set from the web interface at all: register, station, send_gap, verified, pick and gnss_mtk_plan are fleet decisions, and channel_mask belongs to the stored local choice in row 4. Runtime posts that name them are ignored, and a post containing nothing else is refused outright (no editable config keys).
2. Station identity: the two numbers
A DENKO Blue station has two numbers, and the Diagnostics page shows both:
| Number | Where it comes from |
|---|---|
| Local number, 8000–8999 | The station setting: 8000 unless the remote configuration assigns one. The 8xxx range is reserved for DENKO Blue stations, and by convention the last digits can echo the station's assigned public number. Shown as Station on the Diagnostics page, marked remote when it came from the configuration file and when it did not. |
| Lightning network number | Assigned by the lightning network's server during registration, from the board's processor ID — the long hex string on the Diagnostics page, which is the registration key you quote when linking the board to an account. Once assigned, the server number is the station's public identity and is shown in the Lightning network row as station N. |
Registration runs only while all three of these are true:
registeris enabled (it is on by default; the fleet file decides per board),- the processor ID is linked to an account on the lightning network, and
- the GPS receiver has a 3D fix (once the station has had one, a later loss of fix does not hold registration back).
Why a board without a satellite fix keeps its local number. Registration declares the station's coordinates, and every station's declared coordinates feed everyone's multilateration. The firmware therefore refuses to register a position it does not have: no fix means “will not declare 0°N 0°E”, and a 2D fix means “will not declare a sea-level altitude”. Until a real 3D fix exists, registration simply waits — and the station goes on measuring and reporting under its local 8xxx number. That is normal, not a fault.
3. Every setting
Defaults are the initial values; the remote configuration replaces them per fleet or per board. Most numeric ranges are clamped: a value outside the range becomes the nearest value inside it. Unknown protocol values are ignored; an out-of-range led_mode falls back to classic (0). Collector addresses and ports are validated instead. An incomplete or invalid pair of owner login settings leaves the previous configuration in use. If channel_mask leaves out the primary channel, that input is enabled anyway. The ordinary settings and whether they came from the remote file are on the Diagnostics page.
| Setting | What it does | Default | Range |
|---|---|---|---|
trigger | Detection threshold, in ADC counts either side of the baseline (1 count ≈ 0.79 mV). The trigger selector on the Live page. From firmware v482, with trig_auto on, the value applies at the default total gain of the two gain stages (×16) and is scaled with the gains actually programmed; with trig_auto off it is used as set. | 99 | 20–2000 |
gain_pre, gain_post | The two programmable gain stages, as ladder codes 0–7 meaning ×1, ×2, ×4, ×5, ×8, ×10, ×16, ×32. The gain selectors on the Live page and the diagram. These defaults apply from firmware v451; remote configuration can replace them. | 4 (×8), 1 (×2) | 0–7 |
channel | The primary (viewed/diagnostic) input, 1–4. | 1 | 1–4 |
interval | Seconds between remote configuration fetches. | 300 | 30–86400 |
pga_count | Number of programmable gain stages fitted to this controller. A service setting; leave it at the value supplied for your board. | 8 | 2–8 |
station | The local station number (section 2). Fleet-only. | 8000 | 8000–8999 |
buzzer | From firmware v482, beeps for the same lightning events as the lightning indicators (ledmode), once per magnitude-meter step, up to seven beeps. 0 = off (default), 1 = on. Switch it on or off on the Live page. Earlier firmware clicks once per captured signal while it is on. | 0 | 0/1 |
ledmode | From firmware v482, selects the lightning events: 0 = our timestamp was used by the locator (default); 1 = network lightning within 250 km, even if this station did not contribute. Separate from the appearance setting led_mode. Used events show the magnitude of the station’s reported signal. Nearby events use the magnitude supplied by the Denko service. Without a current position, nearby indications pause. | 0 | 0/1 |
rate_max | Capture rate, in captures per second, at or above which the detector is throttled. The cap that keeps a dead or flooded input serviceable. | 200 | 1–2000 |
caprank | When more captures arrive in one second than rate_max allows, keep the strongest ones instead of the first ones. 0 = keep the first ones (default), 1 = keep the strongest. Experimental: leave it at 0 unless Denko asks you to change it. While it is 1 the station examines more captures each second, so it has less time for its other work when the input is very noisy. | 0 | 0/1 |
send_gap | Minimum seconds between packets that carry no input named in verified, timed from the previous such packet — packets from verified inputs neither wait for it nor delay it. Packets it holds back are counted as held by send_gap. When register is on, at least 10 is enforced regardless of this value. Fleet-only. | 10 | 0–3600 |
verified | Inputs whose packets have been checked against located lightning and found to carry it, bits 0–3 for inputs 1–4. A packet carrying such an input is not held by send_gap; it is paced like a standard station instead: at least 0.604 ms after the previous packet, and never more than 240 packets in any 3 seconds or 3,660 in any 60 seconds. Every other packet keeps send_gap, and every packet obeys the same limits; packets these limits hold back are counted as paced in /api/status. 0 (the default) names no input, so every packet keeps the probation gap. Fleet-only. | 0 | 0–15 |
pick | Which packet send_gap lets through. 0 (the default): the first one after the gap, as before. 1: the first one after the gap whose own signal-to-noise ratio clears the station's threshold, which adapts so that a few per gap qualify. Packets it passes over are counted as held by send_gap. Packets from verified inputs are never affected. Fleet-only. | 0 | 0/1 |
encrypt | Seal packets when an encryption key is in force. On by default; exists so the encryption can be taken out of the chain when diagnosing. | 1 | 0/1 |
preamp_gain | Declared gain of the amplifier head, rather than a measured value — see the Signal chain page. | 10 | 1–1000 |
trig_auto | Let the measured noise floor raise the trigger threshold, so a channel that gets noisy goes quiet instead of flooding. Off pins the threshold — what you want on a bench. From firmware v482, while it is on, trigger is also scaled with the programmed gains (see trigger). | 1 | 0/1 |
filter_hz | Requested low-pass filter cutoff, in Hz. The accepted configuration range is 1,000–200,000 Hz; the delay check is qualified only from 10,000 to 100,000 Hz, inclusive. A valid measurement supplies the input's filter-delay correction; an inconclusive measurement within that band is identified as fallback. From firmware v482, such an input uses the bypass, and so does every input while the requested cutoff lies outside that measurement band: zero filter-delay correction, rather than a nominal filter correction. Earlier firmware keeps the filter in those cases and applies the nominal correction. Inputs with no working filter detected also use bypass. | 25200 | 1000–200000 |
gain_auto | Let the firmware steer the gains toward noise_target. The loop is built to converge: it steps an input up only when the level that step would land at would not rise above the target band — a step that would overshoot holds on the lower rung, the quieter side — and only after 10 seconds of quieter readings asking for it. A step up that is followed by a step back down parks the input on the lower rung, and that step is not tried again for five minutes at first, doubling after each further round trip up to an hour. The first hold caused by a rising noise floor can end early if the noise then falls far enough; later doubled holds, or holds caused by clipping, run to their end. The 10-second wait also does not apply to the climb back after a clipping step-down, which goes one rung per decision. Decreases are immediate: clipping or a rising noise floor still steps down at once. From firmware v451, automatic gain is on by default. The legacy fleet defaults gain_auto 0, gain_pre 6, gain_post 5 migrate to automatic gain with initial gain settings of 4/1. A board-level gain_auto 0 opts out; with that legacy fleet tuple, it preserves the initial manual gain settings of 6/5. Runtime changes last until the next successful configuration download or restart. | 1 | 0/1 |
noise_target | Where gain_auto aims the quiet noise, in RMS counts at the converter (32 ≈ 25 mV). | 32 | 20–2000 |
noise_target_a, noise_target_b, noise_target_c, noise_target_d | A separate noise_target for inputs 1–4, in the same RMS counts at the converter, for a board whose inputs have different noise floors. 0 (the default) lets an input follow noise_target; a nonzero value below 20 is raised to 20. | 0 | 0 or 20–2000 |
gain_ceiling | With gain_auto, how much of the converter's half-scale swing a signal may use before its input's gain steps down one rung, in percent. Most of a second's windows must exceed it, so a single strike does not trigger it. While the ceiling is on, a step down for the ceiling or for clipping holds the input's gain: it is not raised again for 300 seconds (five minutes). 0 (the default) turns it off; a nonzero value below 50 is raised to 50. | 0 | 0 or 50–95 |
gnss_sys | Requested constellations as a bit mask: 1 GPS, 2 GLONASS, 4 Galileo, 8 BeiDou. A request, clamped to what the receiver can do (chapter 3). | 5 | 1–15 |
ant_ocd | Ask the receiver to detect an open GPS antenna as well as a short. Off by default; with it off, “ok” only means “not shorted”. | 0 | 0/1 |
register | Register with the lightning network (section 2). Fleet-only. | 1 | 0/1 |
mux_pre | Input path of the first gain stage: 0 = amplified (×4), 1 = direct tap (×1). | 0 | 0/1 |
mux_post | Input path of the second gain stage: 0 = through the filter, 1 = bypass. The default keeps fitted filters in the path for noise rejection. From firmware v450, the startup check tests filters per input and automatically bypasses an input with no working filter detected; from firmware v482, also an input whose filter the check could not confirm. Other inputs keep their own paths. The timestamp correction follows the path of the triggering input. | 0 | 0/1 |
protocol | Stock-compatibility profile on the wire: 94, 101 or 110 (stock 9.4, 10.1 or 11.x). 101 and 110 send only once registration has given the station a valid key (see nokey in chapter 7). The protocol selector on the Live page. | 94 | 94/101/110 |
fw_seq | Self-update switch: any nonzero value (the default is 1) allows newer updates offered to this station in the staged rollout; 0 switches it off for this board (chapter 5). | 1 | 0–65535 |
channel_mask | The fleet's enabled-input mask, bits 0–3 for inputs 1–4. Your stored local mask replaces it when set (chapter 2). | 15 | 1–15 |
reject_hz | Single-frequency tone reject, for an input carrying a continuous interference tone that would otherwise trigger on every cycle. 0 (the default) leaves it to the station: it watches the live signal and locks on to up to four steady tones by itself (the Tone track row reads learning, then active). A nonzero value fixes the reject on that frequency in Hz and stops the automatic tracking (manual). | 0 | 0–240000 |
reject_pct | How much of a window's peak the tone must explain for the window to be dropped, in percent. | 75 | 1–99 |
reject_lo | Let the automatic tone tracker (see reject_hz) also watch for steady tones below 3 kHz, down to about 1.9 kHz. 0 (the default) watches from 3 kHz upward. | 0 | 0/1 |
band_lo | Lower edge of the band veto, in Hz: parts of a captured signal whose energy is concentrated between band_lo and band_hi are dropped before the signal is reported (chapter 8 counts them). Built for broad low-frequency bursts that have no single tone for reject_hz to name. | 1500 | 0–60000 |
band_hi | Upper edge of the band veto, in Hz. The defaults 1500 and 4000 name the band of the burst interference this veto exists for. | 4000 | 0–60000 |
band_pct | The veto's threshold, in percent: a part of a captured signal is dropped when at least this much of its energy lies inside the band. 0 (the default) is off — this veto leaves detection unchanged. A band no measurable frequency falls into vetoes nothing. The trade-off is deliberate: a lightning signal riding on a burst whose energy dominates the window is dropped with it. | 0 | 0–99 |
hp_hz | Detector high-pass corner, in Hz — a per-board remedy for an input that carries a steady low-frequency tone (a carrier that is always there), so the trigger threshold no longer rides on the tone. From firmware v442. It removes the tone from the trigger decision only: the captured signal, the Live page and every packet stay raw, and only the trigger test and the noise floor its threshold is set from use the filtered stream. On the Live page each channel is then drawn twice — solid for the raw signal as sent, dashed for what the trigger tested (chapter 1). 0 (the default) is off: the detector is exactly the one it was. A nonzero value is raised to 3000 or lowered to 20000 to sit inside the filter's usable range, and the filter runs only while at most two inputs are enabled — with more enabled it stays off. At a clean site it costs a strike's first cycles part of their size, which is why it ships off and is set per board. | 0 | 0 or 3000–20000 |
led_mode | What the status LEDs show: 0 classic (each LED its own meaning), 1 magnitude meter, 2 blind (all controllable LEDs off). The LEDs selector on the Live page; the modes are described in chapter 7. | 1 | 0–2 |
auth_req | The station owner’s login setting: 1 = on, 0 = off. Set from the Denko dashboard. Use the login steps in section 5; leave these configuration values to the owner. | 0 | 0–1 |
auth_nb | The owner’s login reset time, in Unix seconds. Managed together with auth_req from the dashboard; leave it to the owner. | 0 | 0–4294967295 |
netenable | The station owner's network choice from the Denko dashboard (chapter 8): 1 adds the lightning network, 2 is Denko. Denko is always included, so 0 and 2 both mean Denko only, and 1 and 3 both networks. Read only from this station's own section of the remote configuration. A new save in the dashboard applies on the next configuration fetch; otherwise the choice stored on the board stays. From firmware v482. | — | 0–3 |
gnss_mtk_plan | Optional satellite-receiver constellation planning for receivers that support it. 0 = existing plan, 1 = try the requested constellations in preference order. Set per board by Denko; ignored on other receiver types. Fleet-only. | 0 | 0/1 |
collector_ip | Denko collection destination supplied for this station. 0 uses the normal destination. Fleet-only; leave this to Denko. | 0 | 0 or valid unicast IPv4 value |
collector_port | Port for collector_ip. Both address and port must be present to use an override. 0 cancels the override. Fleet-only. | 0 | 0–65535 |
collector2_ip | Optional additional collection destination. It receives a copy and does not replace Denko’s destination. 0 = off. Fleet-only; leave this to Denko. | 0 | 0 or valid unicast IPv4 value |
collector2_port | Port for collector2_ip. Both address and port must be present to use the additional destination. 0 = off. Fleet-only. | 0 | 0–65535 |
network_revision | Identifies a new network choice saved in the dashboard, so a later local choice is not undone by an unchanged download. Managed by the dashboard; do not edit it. | 0 | 0–4294967295 |
4. Changing a setting yourself
The same patch the pages send can be sent by hand — lines of key value in a POST:
curl -X POST --data-binary $'trigger 130\ngain_pre 5\n' http://<IP address>/api/cfg
- The patch is partial: keys you omit keep their current values. It applies immediately — the next remote fetch wins, and nothing survives a restart.
register,station,send_gap,verified,pick,gnss_mtk_planandchannel_maskare ignored in these posts, even echoed back from the station's own configuration.- The stored local choices have their own endpoints:
POST /api/channelswithmask 0..15(0 follows the fleet again) andPOST /api/polaritywith the same form. They survive restarts.
The station works best on its configured settings. Change a setting only if you know what it does — and remember that restarting the board, or simply waiting for the next fetch, undoes any runtime change that made things worse.
5. Logging in with a token
If the page asks you to log in, use a login token supplied by the station owner from the Denko dashboard. It is a long piece of text beginning with dk1..
Open the Live, Signal chain or Tests page. In the box at the bottom right, press Log in, paste the whole token and press Log in again. After Checking the token…, the box shows Logged in until and the expiry time. Review your settings and apply the change again. Press Log out when finished. The Firmware page has no login box: log in on one of those pages first, then open Firmware in the same browser tab.
After a restart or an expired login, log in again. For an operation the token does not allow, ask the owner for the appropriate token. When using the console from the dashboard, follow any console message before retrying; a console interruption does not by itself tell you whether a change happened.
At startup the station waits for its configuration. The first download is scheduled about 20 seconds after start, but the connection may take longer. If the waiting message continues, check the station’s internet connection and ask the owner to check its login settings.
| Message | What it means and what to do |
|---|---|
| Waiting for station configuration. If this continues, ask the owner to check this station’s login settings. Readings and automatic updates continue. | The station is waiting for its configuration. The first download is scheduled about 20 seconds after start. If the message stays, check the station's internet connection and ask the owner to check this station's login settings. |
| The station clock is not set yet. Try again when GNSS has a fix. | The station needs the time from its GPS receiver before it can check a token. Wait until the GPS page shows a fix, then try again. |
| This token has expired. Ask the station owner for a new one. | The token is past its time limit. Ask the owner for a new one. |
| This token was revoked. Ask the station owner for a new one. | The owner withdrew this token and every earlier one. Ask the owner for a new one. |
| This token is not valid yet. Check the station clock. | Wait a few minutes and try again; if it keeps happening, check the station clock and ask the owner for a new token. |
| Too many attempts. Wait a minute and try again. | Several logins were tried in a short time. Wait a minute, then try again. |
| The station is busy. Try again in a moment. | The station could not take the login just now. Try again in a moment. |
| This token is not valid for this station. | The token was made for a different station, or it was not pasted whole. Check that you are on the right station and paste the whole token. |
| The change may have happened. Check the current station state before making another change. | Read back the current setting or result before you retry, to avoid repeating an operation that already happened. |
| Your console session expired or is no longer available. Reopen the console from the dashboard. Your station login token may still be valid. | Open the station console again from the dashboard, then check the current state. |
| Console access was refused for this request. Return through the dashboard to check access. Your station login token may still be valid. | Return to the dashboard and check access before trying again. |