DENKOSettings and station identity
Where each setting's value comes from, what lasts across a restart and what does not, every setting the station has, and how the station's two numbers — its local one and its Blitzortung one — 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. Compiled defaults | Built into the firmware; used from power-on. Fail-safe: a failed config fetch, an unreadable file or an unknown key all mean “keep the defaults”, never a zero. | 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). 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. A patch held in memory, applied 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 written to the board's flash as append-only records, so a fleet refresh cannot quietly reverse them. | Kept, until you change them again. |
Some keys cannot be set from the web interface at all: register, station and send_gap 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.
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 echo the station's assigned public number so a packet can be traced back to hardware. Shown as Station on the Diagnostics page, marked remote when it came from the configuration file and when it did not. |
| Blitzortung number | Assigned by the Blitzortung 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 as Blitzortung station N. |
Registration runs only while all three of these are true:
registeris enabled (it is on in the compiled defaults; the fleet file decides per board),- the processor ID is linked to a Blitzortung account server-side, and
- the GPS receiver has a 3D fix.
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 compiled values; the remote configuration replaces them per fleet or per board. Ranges are clamped, never rejected — a value outside the range becomes the nearest value inside it. The current value of every key, and whether it came from the remote file, is 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. | 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. | 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 | How many gain chips are actually fitted. The chain is write-only and cannot be counted by the firmware, so this is told to it; a wrong value puts every gain in the wrong chip. | 8 | 2–8 |
station | The local station number (section 2). Fleet-only. | 8000 | 8000–8999 |
buzzer | Sound the piezo once per capture. Off by default; it is the only feedback a board gives with no network and no LED in view. | 0 | 0/1 |
rate_max | Captures per second above which the detector is throttled. The cap that keeps a dead or flooded input serviceable. | 200 | 1–2000 |
send_gap | Minimum seconds between transmitted packets; held-back packets are counted as throttled. When register is on, at least 10 is enforced regardless of this value. Fleet-only. | 10 | 0–3600 |
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 | The declared gain of the amplifier head (×10 stock PCB 16.2, ×45 PCB 23.1). Declared, not measured — 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. | 1 | 0/1 |
filter_hz | Cutoff of the LTC1569-7 low-pass, in Hz, on boards that have the chip. Ignored where it is not fitted. | 25200 | 1000–200000 |
gain_auto | Let the firmware steer the gains toward noise_target. Off by default, so the configuration file is the single source of truth for gain. | 0 | 0/1 |
noise_target | Where gain_auto aims the quiet noise, in RMS counts at the converter (32 ≈ 25 mV). | 32 | 20–2000 |
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 Blitzortung registration service (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. Forced to 1 on boards with no filter fitted. | 0 | 0/1 |
protocol | Stock-compatibility profile on the wire: 94 or 101. The protocol selector on the Live page. | 101 | 94/101 |
fw_seq | Self-update switch: 0 (the default) disables it; any nonzero value allows the latest published update (chapter 5). | 0 | 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: the frequency in Hz; 0 disables it. For an input carrying a continuous interference tone that would otherwise trigger on every cycle. | 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 |
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, in memory only — the next remote fetch wins, and nothing survives a restart.
register,station,send_gapandchannel_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's API has no authentication. Anything on the network can read it and post to it. Keep the station on a trusted network.
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.