The Tests page
The response sweep, gain check and alias survey at /test measure the station's own signal paths. From firmware v450, an automatic delay check also measures all four inputs at startup and can be requested through the API. These measurements describe your board rather than a circuit model.
Detection is paused while a diagnostic runs. The station cannot listen for lightning and inject test tones at the same time, so run these when a few seconds of quiet do not matter — not in the middle of a storm you care about.
One diagnostic at a time. Starting a second one while another is running is refused (another diagnostic is running); wait for the progress bar to finish.
1. Run sweep: the frequency response
Choose a channel with the channel selector at the top of the page (it starts on channel 2) and press Run sweep. The station injects a tone ahead of the whole signal chain (the DAC block on the Signal chain diagram), steps it through 28 frequencies, and measures the amplitude that comes back — once through the filter path and once through the bypass. It takes about 22 seconds; the page first says requesting sweep on both paths. The later request outcome does not prove a fresh measurement (see below).
The result is drawn as a response (Bode) plot, with a dashed computed curve of the passive LC ladder from the circuit for comparison — a model of the board family, not a measurement of your board. For each path the table reports the peak, the −3 dB crossings, and the noise floor:
- Hollow rings mark points at or near the noise floor: there the dB figure is a limit, not a value — the true response is at least that low.
- CLIPPED means a sample hit the converter's rail, so attenuation below that point is compression, not filtering.
- Both paths are measured together because the comparison is the test: on a board with no filter chip fitted, the filtered path shows nothing while the bypass shows the tone — one path alone cannot tell “not fitted” from “fitted and attenuating”.
Request outcomes are not completed measurements
On firmware v475, before measurement times and run numbers were added, a request and an available result are reported separately. The progress bar is a wait, not proof of fresh measured data. There is no automatic retry; check the station state before requesting another test. From firmware v482, results carry run numbers and capture times, and a result that matches this page's request is reported as request accepted; fresh measurement (section 5).
| Message | Meaning and next step |
|---|---|
| request accepted; showing available results; freshness unproved | Available results are displayed, but they may be from an earlier run. Acceptance is not proof of a fresh completed measurement. |
| request accepted; no usable measurement; freshness unproved | The request was accepted, but there is no usable measurement and freshness is unproved. Check the station and results before another attempt. |
| request accepted; results unavailable; freshness unproved | The request was accepted, but results could not be read. Completion and freshness remain unproved; check the station before retrying. |
| request refused; not retried | The station refused the request. Nothing was retried. Check the reason and current station state. |
| acknowledgement did not match; not retried | The acknowledgement does not prove that this request was accepted. Nothing was retried; check the station state. |
| request outcome unknown; not retried | The answer was lost or could not be verified. The test may have started. Nothing was retried; inspect the station state before another attempt. |
| requesting sweep on both paths | The sweep request is being sent. Wait; this is not proof of a fresh completed measurement. |
| requesting gain check | The gain-check request is being sent. Wait for its request outcome, then inspect results. |
| request accepted; fresh measurement | Firmware v482 and later: the result shown carries the run number the station gave this page's request, so it is a new measurement. |
| results cleared | Firmware v482 and later: the stored results you chose were removed (section 5). |
2. Check gains: the PGA ladder
The gain stages are write-only: nothing in the hardware reads a gain back, so every gain figure the station displays is what it believes it sent. Check gains is the evidence. It steps the stages through all 64 combinations of the two 8-step ladders (×1, ×2, ×4, ×5, ×8, ×10, ×16, ×32) at the strongest frequency in the passband, injecting at whatever level keeps each combination between the noise floor and the rails. The page labels this Check gains about 14 s, but waits 18 seconds before reading the result. Wait for the request outcome and check the run number; the progress estimate alone does not establish completion.
The result is an 8 × 8 table of measured gains against the ladder. Cells 15 % or more off are flagged; a dash means no injection level could put that combination in range. A healthy board ends with all N measurable combinations follow the ladder, with the worst error in brackets; otherwise the line counts the flagged combinations. A cell that is consistently wrong points at that gain stage; a board where nothing follows the ladder points at the injection path or the converter.
Pressing Check gains first shows requesting gain check. The same request outcomes and freshness limits above apply.
Gain timing
From firmware v482, Check gains also measures how the delay through the two gain stages changes with their setting, on the selected channel. The Gain timing table lists combinations of the stages with total gains ×8, ×16 and ×32, including different ways of reaching the same total. For each it gives a Phase slope estimate in nanoseconds, relative to ×4 · ×4 on the same channel and path, with its Fit residual and Signal / noise. Every estimate is marked (branch ambiguous): the measurement uses steady test tones, so it cannot tell which of several possible delays is the real one. A row that could not be measured reads unavailable, with the reason and how many of the 7 test tones were usable. No timing run yet. means no gain check has run since the last restart or clear.
This is a diagnostic reading only. It does not measure a lightning timestamp, and the station does not use it to correct event times. The same data, with the raw per-tone values, is in /api/resp as gain_timing.
3. Alias survey
Alias survey captures the selected channel through the filter and the bypass at three slightly different sample rates (480, 500 and 525 kSPS). A real in-band tone stays at one frequency; an out-of-band tone that is only aliasing into the measurement band moves when the sample rate changes. It takes a few seconds (capturing six multi-rate windows), and the result names either peaks that stay put or the out-of-band frequencies that could explain moving ones. Use it when the spectrum view shows a suspicious steady line: this is alias evidence, not source identification, but it tells you whether the tone is really in the band your filters claim to pass.
| Alias-survey message | Meaning |
|---|---|
| alias survey complete | A new survey completed. Inspect its result; completion alone does not identify an interference source. |
| alias survey failed · alias survey timed out · connection lost while waiting | The survey failed or its final result was not obtained. Check the station and available results before requesting another survey. |
| Hardware restoration failed; detection remains disarmed. | The station could not restore its normal signal path. Detection remains stopped. Restart the station and contact Denko if it recurs. |
| Inconclusive: no significant spectral peak was found at all three achieved sample rates. Alias evidence only; not source identification. | There was too little usable signal to compare the rates. |
| Inconclusive: no common source candidate fits the three achieved sample rates. Alias evidence only; not source identification. | The available peaks do not support one common source candidate. |
4. Signal-path delay check
From firmware v450, the station injects a known test signal and compares the filtered and bypass paths of every input, on both the amplified and direct input paths. It checks whether each input has a working filter and measures the added delay at the current filter cutoff. This check runs automatically at every startup, before detection begins, and repeats automatically after a programmed cutoff changes. Calibration has a five-second deadline; the inputs settle afterward before detection resumes.
To repeat it, send POST /api/delay to the station, then poll GET /api/delay. Wait for a new generation with busy false, then inspect the results. A complete four-input capture has steps 28 and error none; each input must also have valid measurements. An accepted request is not a completed measurement, and a completed attempt can still need fallback. Detection pauses for the check and resumes after the signal path settles. Keep the default filtered path on inputs with fitted filters: bypassing it can greatly increase noise triggers.
The result identifies the filter on each input and distinguishes a measured delay from a nominal fallback. For a report triggered on a filtered input, the station subtracts that input's measured filter delay relative to its bypass, using the same amplified or direct input path. From firmware v482, an input whose filter the check could not confirm (state fallback or unknown) is switched to the bypass and gets no filter-delay correction; a confirmed filter whose current input path or cutoff has no valid measurement uses the nominal delay for the programmed cutoff, and the status says so. Before v482, an unconfirmed filter stayed in the path and was corrected with the nominal delay. A bypassed input receives no filter-delay correction.
The released firmware provides automatic delay retries: an input left unknown or fallback after startup can be checked again without restarting the station. There are at most three automatic attempts for the current input-chain and cutoff configuration. The minimum waits after the preceding completed attempt are 30, 120 and 600 seconds, in that order. A busy station postpones the check without using an attempt or starting several overdue checks together. Inputs already measured or found to have no working filter keep their results while the remaining inputs are retried; unavailable inputs are not retried. Once every input has a conclusive result, no further automatic delay check is started. A manual check or a changed input-chain or cutoff configuration starts a new retry sequence.
These retries introduce short gaps in lightning detection: each attempt has the existing five-second measurement deadline, followed by bounded restoration of the normal signal path and recovery of capture history. Five seconds is the measurement limit, not a guaranteed total gap. Detection resumes only after restoration and history recovery succeed; a failed restoration keeps detection stopped. The delay result reports retry_enabled, retry_state, retry_attempts, retry_remaining and retry_due_in_s, so you can check the state: disabled, unavailable, pending, waiting, complete or exhausted.
The other path delays are diagnostic readings. They include the test-signal source and do not measure the antenna or amplifier head, so they are not subtracted from event timestamps.
Delay measurement is qualified only for cutoffs from 10 to 100 kHz, inclusive. From firmware v482, a cutoff outside that band is not measured: the inputs use the bypass with zero filter-delay correction, not a nominal filter correction. Earlier firmware keeps the filter and applies the nominal correction. A silent filter path with a strong bypass means no working filter was detected; the test cannot distinguish an omitted filter from a failed one.
| Result field | Meaning |
|---|---|
busy · generation · duration_ms | Whether the check is running, which measurement this is, and how long it took in milliseconds. |
steps · error | Captured test points out of 28, and why a capture stopped: none means no capture error; cutoff_range, hardware, timeout, adc_phase, dac_phase, snapshot or copy_timeout identify an incomplete or unsupported capture. timer_unavailable means the diagnostic timebase was unavailable. Check each input's validity even with all 28 points. |
retry_enabled · retry_state · retry_attempts · retry_remaining · retry_due_in_s | Whether automatic retries are enabled, their state, the attempts used and remaining, and the minimum wait before another attempt. A zero wait can mean due but deferred; it does not mean a measurement is running. unavailable is not a conclusion about the filter. |
measured_mask · absent_mask · fallback_mask | Input masks: bits 0–3 identify inputs 1–4 with a valid measured filter delay, no working filter detected, or at least one filter path requiring nominal fallback. A measured input can also have a fallback bit; check its selected source. |
channels · pre_valid | Four per-input records. state distinguishes measured, absent, fallback, unknown and unavailable. A failed or unavailable check is not proof that a filter is absent. pre_valid bits 0 and 1 identify valid measurements for the amplified and direct paths; one can be valid while the other needs fallback. |
cutoff_hz · filter_ns | Cutoff used for this measurement in Hz, and the additional filter delay in nanoseconds for the amplified and direct paths, in that order. The delays can be measured or nominal; check pre_valid. |
correction_ns · source | Correction for this input's current path and cutoff, in nanoseconds. source is measured, fallback or bypass; bypass has zero filter correction. |
bypass_ns · bypass_valid · pre_delta_ns | Diagnostic delay through the bypass for each input path, and the difference between the amplified and direct input paths, in nanoseconds. bypass_valid bits 0 and 1 qualify the amplified and direct readings; zero delay without its valid bit does not establish a zero-delay path. These are not timestamp corrections. |
residual_ns · bypass_residual_ns | Fit errors, in nanoseconds, for the differential filter delay and the raw bypass delay respectively. A valid bypass fit can still have a large residual because delay varies across the test band. |
pre_delta_valid · pre_residual_ns | Whether the direct-minus-amplified input-path delay is qualified, and its fit error in nanoseconds. This delay is fitted from the phase difference so shared path curvature can cancel. It is valid only when both bypass paths were measurable and the differential residual is at most 2,000 ns. It remains diagnostic. |
5. Reading and re-reading results
From firmware v482, each sweep result and gain-check table shows its run number and the station's uptime at the start of capture. Uptime is time since the station started, not the age of the result or your computer's time. Run numbers identify runs within the current boot. UTC is shown only if it was available at capture; otherwise UTC is unavailable. A result is marked request accepted; fresh measurement only when it matches the run accepted for this page's request. Check the run number and capture time when comparing a new measurement with stored results; accepting a request alone does not mean the measurement completed.
To remove a stored result, choose the sweep's channel and path, or Gain ladder for the gain-check result, in the result selector and press Clear result. Clear channel clears both sweep paths for the selected channel, plus the gain check and timing only when they belong to that channel. Press Clear all results to clear every stored sweep and gain-check result. Clearing the gain check also clears its associated gain timing. These buttons remove the station's stored records, so reloading the page does not bring them back. They do not change the selected channel, programmed gains or other settings, and do not start a measurement. A clear request is refused while a diagnostic is running; wait for it to finish, then clear again. Clearing needs a login with a token that allows settings (chapter 6, section 5), even on a station that does not otherwise require a login: without one, the login box opens and the page reports request refused; not retried. A successful clear reports results cleared.
From firmware v482, the same clearing operations use POST /api/resp with a body of clear=all, clear=channel1 through clear=channel4, clear=c1l0 through clear=c4l1, or clear=gaincheck. A sweep key identifies channel 1–4 and the filter path l0 or bypass l1. GET /api/resp only reads results; it does not clear them.
- Sweep results are stored separately for each channel and path. The gain-check result identifies the channel it measured. Records remain until replaced, cleared or the station restarts. Repeating a sweep on one channel does not replace the other channels' sweeps. The page reads the stored results when it opens.
- The same results are available as JSON at
/api/resp(sweep and gain check),/api/alias(alias survey) and/api/delay(delay check) — see the endpoint list. Delay results are measured again automatically after a restart. - These tests measure the board, not the sky. Run the sweep and gain check after building or repairing a station, after changing the amplifier head, and whenever the Diagnostics page disagrees with what you expect.