What this system relies on, and how good each source actually is. This matters because the whole trigger design has to be built around the weakest link, not the strongest.
The location-db locations table (PostgreSQL + PostGIS on gravlax), fed by the phone's OwnTracks app via the loc HTTP endpoint. Columns of interest: tst/received_at, lat/lon, acc (horizontal accuracy, metres), conn/ssid (network state).
Quality: GPS fix accuracy (acc) is typically single-digit metres in good conditions, but was seen spiking to 1000+ metres briefly during a tunnel/poor-signal stretch on the 2026-07-13 trip — those fixes should be filtered out (e.g. acc > 200) before being used for anything precision-sensitive.
Reporting cadence — the key limitation: logs every few minutes when the phone is stationary/idle, but densifies to ~4-8 second intervals once in motion. Confirmed consistently across the whole 2026-07-13 return journey, not just near the neutral sections. This is good enough on its own for the hibernate trigger while genuinely moving (worst case ~8s × 55 m/s ≈ 440m staleness, small next to the position uncertainty below) — but the idle→moving transition (e.g. just after leaving a station) is a blind spot: the most recent fix could still be several minutes old at exactly the moment cadence needs to tighten up.
A 5-row table in the same PostGIS database (gazetteer, source='gwml-neutral-sections'), populated from web research rather than a surveyed/official source. Covers Airport Junction, Ruscombe/Twyford, Steventon/Milton, Royal Wootton Bassett, and Chipping Sodbury Tunnel.
Quality: approximate. See Findings for the direct comparison against observed router power-loss — the two points that could be cross-checked were both off by roughly 2-3 km from the documented coordinates. That's the single biggest source of trigger-timing uncertainty in the whole system right now, bigger than polling lag or hibernate write time.
The train-router's wifi network (SSID c13) appears in the same locations table via the phone's conn/ssid columns, since the phone connects to it. A drop from ssid='c13' to conn='m' (mobile) or null is used as a proxy for "the router lost power", which is itself a proxy for "we are crossing a phase break".
Quality — several layers of indirection, each adding uncertainty:
• A router power drop only reliably indicates a neutral section if it's a genuine, complete power loss — short blips (confirmed present in the 2026-07-13 data, e.g. the Iver/Slough gap and a 4-second reconnection blip) can look similar but have other causes and should not be treated as phase-break evidence.
• The observed outage duration conflates three different things: the true electrical dead-time, router reboot/cold-boot time, and wifi reassociation time. These need to be disentangled (see Considerations) before outage duration can be trusted as a distance-along-track measurement.
• No stationary/zero-speed baseline exists yet for this specific router, so there's currently no calibrated boot-time constant to subtract from observed outage durations.
Used to identify station stops and exclude zero-speed events from candidate phase-break analysis — phase breaks are never sited at stations (a stopped train couldn't restart with no power), so any wifi/power drop at zero speed is definitionally not a phase break. Also a candidate source of stationary power-cycle events for future boot-time calibration, if any coincide with router power cycling.
From most to least trustworthy for this purpose: (1) GPS position/speed while moving — good; (2) the fact that a router power-loss event occurred — good, directly observed; (3) the geographic location implied by a power-loss event's start point — fair, but conflated with reconnection dynamics; (4) the documented gazetteer coordinates for neutral sections — approximate, needs tightening against (2)/(3) over more trips.