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 — each reload takes a new snapshot of the station’s readings. It is not a continuous recording. The Raw JSON data link at the top is the same content as one document: /api/status. Some rows appear only when they have something to say — a warning row that is missing means nothing has happened.
1. Station
| Row | What to look for |
|---|---|
| Station | The local 8xxx number, marked remote when it came from the configuration file and when it is the default 8000 (chapter 6). |
| Board | The PCB revision and PCB-Id, decoded from the board's own straps. |
| Firmware | Version and exact source revision, and whether the image is confirmed or on trial (chapter 5). |
| Processor ID | The registration key: quote this when linking the board to an account on the lightning network. Fixed in silicon; never changes. |
| MAC | Derived from the processor ID — the address you look for in the router's client list. |
| Detector | armed is normal; settling is the first moments after start or a retune. From firmware v450, the detector also stays disarmed for the startup delay check; no lightning reports are sent during it. |
| Lightning network | Shown when registration is enabled: station N once registered, otherwise not registered, with a note on where registration stands. The notes are decoded in chapter 7. |
| Uptime · Last reset | Uptime alone says little; the reset cause (power-on, reset pin, software, watchdog, brownout …) says whether the last start was planned. watchdog armed is what you want to see. |
| Boot journal | Which images ran, for how long, and why each stopped, newest first — the station's own history across restarts (chapter 7). |
| Verdict | The one-line health answer — in words from firmware v440 (healthy, not healthy, starting up, with any reasons), a short code before. Every state and reason, in both forms: chapter 7. |
| MCU | Processor temperature and supply voltage. |
2. GNSS
Fix state, satellites in use, position and height (with the reason when there is no height yet), and the 1PPS lock. Rows that deserve a second look:
- Antenna (on receivers that report it): ok, SHORT or OPEN, and whether the antenna supply is on. OPEN is normal with the standard passive antenna; only SHORT is a fault. If you use an external antenna with an amplifier (active antenna), then OPEN means it is not getting power: check its cable and connector. With open-circuit detection off (the default), the row adds that “ok” only means “not shorted” (chapter 3).
- Front end: the receiver’s AGC, noise and jamming figures. near maximum means very little received signal; it does not by itself identify interference. interference flags an elevated jamming reading. The GPS page also distinguishes a jamming measurement from not measured when the receiver supplies no reading.
- Timer, measured and Baud, discovered: the station's timer counted against 1PPS, and the speed at which the receiver was found.
- 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.)
- Receiver TX queue (when reported): queued bytes, current usage and peak usage of the receiver’s outgoing message queue.
- Sentences / errors and Stamped captures: how much the receiver has said, and how many captures got a satellite-disciplined timestamp.
3. Detector
From firmware v450, /api/status also includes chain_delay, the delay check's per-input results. Its state and input masks distinguish a measured correction, a fallback (a nominal correction before firmware v482; from v482 that input uses the bypass) and no working filter detected. It also reports automatic delay retry state, attempts remaining and the wait before another check (chapter 4). The remaining path delays are diagnostics, not timestamp corrections.
The measurement chain's live readings: whether the converter is running, the channel and total gain, per-input polarity, trigger counts and rates (per second and over 60 seconds), interference state, the threshold in counts and millivolts, gain code, noise and baseline, the window's minimum and maximum, the tone reject and tracker, and a family of counters that should stay at or near zero in healthy operation — ring laps, late windows, reader trims, timestamp drops, unusable windows, ADC restarts. Each warning is decoded in chapter 7.
Other readings are available in the JSON (/api/status): gain_writes — gain changes gain_auto has applied since start (chapter 6); gain_holds — increases it has parked after a step up came straight back down; band_rejects — parts of captured signals dropped by the band veto, which stays 0 while band_pct is off; hp_active — the detector high-pass corner actually in force, in Hz, 0 while the filter is off (hp_hz 0, or more than two inputs enabled; chapter 6); and, from firmware v482, clip_captures — for each of inputs 1–4, how many captures reached the converter's limit (clipped). A converged gain loop stops writing: a gain_writes that keeps climbing is the hunting sign, a steady one the healthy sign.
4. Network participation
Within the Detector section, the Lightning network row lets the station owner choose turn on or turn off. It shows off, on, or on · no collector yet when registration has not supplied a usable destination. From firmware v482 the Denko row reads always on and has no button: the station always reports to Denko. Both networks are selected by default; an existing choice to leave the optional network stays in force. The same selection is available on the Aurora station page and in the dashboard for the station owner or authorized administrator. Local choices are stored on the board; from firmware v482, a new owner save in the dashboard applies on the next configuration fetch, even when the selected value is unchanged, and an unchanged automatic check preserves a later local choice. The Denko row also shows its destination and packet count. Firmware before v482 also offers turn off on the Denko row and does not take the choice from the dashboard. Failure messages 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 section reads never surveyed 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 restores the defaults). Then every setting, its current value, and its provenance — remote or — the same list as chapter 6, section 3.
7. Firmware update
What the automatic update checks have found (chapter 5): Manifest checks counts the checks, how many succeeded or failed and how long ago the last one ran; Last outcome and Earlier outcomes say in words why each check did or did not start an update — kept across restarts, so a board that rebooted still tells you what happened before. Every outcome is listed in chapter 7. On a board with self-updating switched off, the outcome reads not enabled (fw_seq is 0).
8. Network
Link state, the address and prefix with the gateway, the DHCP state and leases taken (decoded in chapter 7), the Ethernet controller's revision, the collectors the station has learned with the packet counters for each, and low-level traffic counts (frames, ARP and ping replies, pages served). From firmware v482, Ethernet RX resets counts how often the station restarted its Ethernet receiver after a receive error or damaged incoming data; it recovers by itself, and only a fast-growing count is worth reporting. Packets sent climbing steadily during weather shows the station is sending packets. It does not prove the receiving service accepted them or located lightning. The row also reports packets held by send_gap and any that failed.
9. 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. The table distinguishes readings (GET) from actions (POST). Check the station’s reply and current state after an action.
| Endpoint | Method | What it returns / does |
|---|---|---|
/api/status | GET | Everything on the Diagnostics page, plus the full configuration with per-key provenance. |
/api/gnss | GET | Satellites, DOP, PPS, receiver identity and capability — everything on the GPS page. |
/chain.json | GET | The signal chain's stage list, each value with how it is known (chapter 2). |
/api/scope | GET | A free-running snapshot of the inputs (the Live view's frame). |
/api/channels | GET | One aligned snapshot of all four channels; disabled inputs carry no samples. |
/api/trig · /api/event | GET | The last window the detector captured and sent, with its pre-trigger history. |
/api/captures · /api/capture/N | GET | The capture history list (the last 32 captures), and one capture's full waveform. |
/api/resp | GET | Results of the last response sweep and gain check, and from firmware v482 the gain timing (chapter 4). |
/api/alias | GET | Result of the last alias survey. |
/api/delay | GET | Per-input results of the delay check: filter detection, measured path delays and whether a nominal fallback supplies the correction. From firmware v450 (chapter 4). |
/api/sweep | POST | Requests a common four-input diagnostic capture. m= selects which enabled inputs to display; a zero or omitted mask uses the enabled inputs. |
/api/scan | POST | Starts the four-channel input survey; results land in /api/status. A survey pauses detection. |
/api/resp · /api/gaincheck · /api/alias | POST | Start the sweep, the gain check and the alias survey. The Tests page's buttons use these. From firmware v482, /api/resp also accepts clear=… to remove stored results without starting a test; this needs a login (chapter 4). |
/api/delay | POST | Queue a new delay check on all four inputs. Detection pauses for the check and resumes after settling. Poll GET for completion; an accepted request is not a completed measurement. From firmware v450. |
/api/cfg | POST | A runtime configuration patch (chapter 6). |
/api/channels · /api/polarity | POST | Store the local enabled-input mask (mask 0..15, 0 follows the fleet) and the per-input polarity mask. |
/api/networks | POST | Switch network participation: lines of bo 0|1 (the lightning network). From firmware v482 Denko is always on, and a denko 0 line does not switch it off; earlier firmware also takes denko 0|1. |
/api/ota | POST | Check for a firmware update now instead of waiting for the next scheduled check. It changes nothing about what may be installed, and is refused while self-updating is off (fw_seq 0), while the image is on trial, while a check is pending, while the recovery updater is busy, or within 60 seconds of the last accepted request. |
/api/reboot | POST | Requests a restart. During an update trial the restart waits for confirmation or the trial deadline. |
The login controls also use GET /auth/state and POST /auth/login, /auth/session and /auth/logout. Use the station’s login window as described in chapter 6. Firmware conversion uses POST /api/stockprepare, GET /api/stockready, POST /api/stock and POST /api/stockcommit; follow the Firmware page procedure for these actions.
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.