The target device is a small SBC ("vibe computer") with no internal battery, powered from the same train inverter/socket circuit as the wifi router. There is no graceful low-power warning path — it dies the instant power drops, exactly like the router. This means the hibernate-to-disk write must be fully complete, not just started, before the train reaches the real electrical dead zone. A partial hibernate write risks worse corruption than simply letting the device die uncleanly with no hibernate attempt at all, so “trigger a bit early and finish comfortably” strictly dominates “trigger late and risk an incomplete write”.
• Position uncertainty: ~1.7–2.7 km, from comparing observed router-drop locations against documented gazetteer coordinates (see Findings). This is currently the dominant source of error — bigger than polling lag or (probably) hibernate write time.
• Speed: up to ~200 km/h (~55 m/s) observed through the relevant stretches. Higher speed directly shrinks the safety margin in time for any given distance uncertainty.
• Polling lag: ~4-8s while genuinely in motion (see Data Sources) — small relative to position uncertainty (worst case ~440m), but not zero, and materially worse during the idle→moving transition where the most recent fix could be minutes old.
• Hibernate write time: unknown for this specific device/storage combination — the single biggest unmeasured unknown right now. SD card storage could be meaningfully slower than SSD for a RAM-to-disk write, and this hasn't been tested at all yet.
All of these compound in the same direction — every source of error argues for triggering earlier, never later. Current recommendation given the above: treat the two confirmed points with a wide ~5 km trigger radius until real multi-trip data narrows the position estimate and a real hibernate-write measurement replaces the current unknown.
An observed router outage duration is not simply “how long the power was off”. It's a mix of: (a) true electrical dead-time crossing the phase break, (b) router reboot/cold-boot time if power was fully lost, and (c) wifi reassociation time once power/signal is back. A single 4-second blip observed right after a reconnection (see Findings) suggests warm reassociation alone can be very fast — which argues that the 40-50+ second durations at the two confirmed neutral sections are not simply reconnection overhead, and more likely include genuine dead-time. But this is inference from one data point, not a calibrated constant, and a proper cold-boot baseline is still needed (see Todo).
By design, neutral sections have to be on plain running line where a train can coast through under momentum with power cut and the pantograph typically still up, then re-power beyond it. One sited at a platform would strand any stopping train with no power to restart. Practical implication: any router/power drop observed while the train is stationary is definitionally not a phase break — useful as an automatic filter for candidate events, and potentially useful as an incidental stationary calibration point (though not yet observed in the data).
The current design uses a fixed ~5 km trigger radius. This is simple but not ideal — the actual requirement is really a time margin (enough time for the hibernate write to complete), and time-to-reach-a-point depends on current speed, which varies by train, schedule, and possibly weather/signalling delays. Once real hibernate-write timing is known, the trigger condition should move to “estimated time to section, at current speed, is less than write-time-plus-safety-margin” rather than a fixed distance. This is more robust across different journeys.
The trigger only cares whether the router loses power at a given point, not why. A genuine electrical phase break and the Maidenhead-area drop (see Findings) have the same practical consequence for the SBC — power gone, hibernate needed — regardless of whether the underlying cause is a documented neutral section, an undocumented one, or something else systematic (e.g. trackside infrastructure, signalling-related switching). This means the target list for the trigger shouldn't be constrained to the five-entry gwml-neutral-sections gazetteer: it should be — or eventually become — a list of observed recurring power-loss points, built empirically from repeated router-drop locations, with the neutral-section gazetteer as one useful prior rather than the definition of the target set. A recurring drop that fails to match any documented section (Maidenhead) is still operationally exactly as important as one that does.