Chapter 8 · Applies to firmware v408 and later · Updated 2026-09-21

The Diagnostics page and the JSON API

Everything the station knows about itself, on one self-refreshing page at /diagnostics — and the machine-readable endpoints behind it and the other pages, for your own scripts and monitoring.

The page reloads itself every two seconds — every number on it is live, rendered from the same status structure the firmware itself uses. The Raw JSON data link at the top is the same content as one document: /api/status.

1. Station

2. GNSS

Fix state, satellites in use, position and height (with the reason when there is no height yet), and the 1PPS lock. Two rows deserve a second look:

• Antenna: the receiver's own supervisor — ok, SHORT or OPEN — with the caveat, when it applies, that “ok” only means “not shorted” (chapter 3).
• Ring resyncs / UART resyncs: intervals the reader could not account for. Not data loss — merely serving this page can cause one. (The counter that does mean lost samples is Ring laps, in the Detector section, and it should read zero.)

3. Detector

The measurement chain's live readings: whether the converter is running, the channel and total gain, per-input polarity, trigger counts and rates, interference state, the threshold, noise and baseline, and a family of counters that should all read zero in healthy operation — ring laps, late windows, timestamp drops, unusable windows. Each warning is decoded in chapter 7.

4. Network participation

The station belongs to two networks at once — Blitzortung and Denko — and each row shows the state and a button to change it: off, on, or on · no collector yet (enabled, but no usable destination learned so far; the page does not call that participation). The choice is stored on the board and survives restarts and configuration refreshes — a fleet update cannot quietly put a station back into a network its owner left. Failure messages on these rows are decoded in chapter 7.

5. Amplifier inputs

The results of the last input survey (started from the Live page): each input's offset in mV and noise in counts, with disabled inputs marked and the active channel flagged. This is the diagnostic that separates a quiet sky from an unpopulated input — identical symptoms, completely different fix. Until the first survey, the row says so and points at the Live page's Survey inputs button.

6. Remote config

Whether the remote configuration is working: fetches and failures, how many keys the file applied, and whether a copy is held in flash (without one, a restart falls back to the compiled defaults). Then every setting, its current value, and its provenance — remote or default — the same list as chapter 6, section 3.

7. Network

Link state, the address and prefix with the gateway, the DHCP state (decoded in chapter 7), the Ethernet chip revision, the collectors the station has learned and the packet counters for each, and low-level traffic counts. Packets sent climbing steadily during weather is the simplest end-to-end proof the station is reporting.

8. The JSON endpoints

Every page is built on a small JSON API, and you can use the same endpoints from your own scripts. Put the station's address in front of each, for example http://192.168.1.57/api/status. Responses to GETs are safe to poll; every endpoint that changes something is POST-only, so a link checker or browser prefetch cannot retune, survey or restart the station.

Sample windows are hex strings, three characters per 12-bit sample. One count is about 0.79 mV at the converter; divide by the gain to refer a value to the antenna.