Evidence gathered so far, and how it was derived. Two trips now agree on the Steventon/Milton crossing (see Combined estimate below); other candidates remain provisional until repeated (see Todo).
Method: pulled the full router (SSID c13) connection-state transition history for the journey from location-db, identified every drop from c13 to mobile/null and back, and compared the drop locations against the gwml-neutral-sections gazetteer.
• Steventon / Milton — gazetteer: 51.6212, -1.3093. Observed outage 18:55:20–18:56:06 (46s). Start-of-outage point 51.617949, -1.271165; end-of-outage point 51.620804, -1.298286; midpoint estimate 51.6194, -1.2847. Offset from documented point ≈ 1.7 km. This is the crossing informally referred to as “near Didcot Parkway” earlier in analysis — geographically adjacent but the properly named gazetteer entry is Steventon/Milton, roughly 2-3 km west of Didcot Parkway station itself. This trip travelled westbound (Paddington→Bristol).
• Royal Wootton Bassett — gazetteer: 51.5416, -1.9045. Observed outage 19:14:09–19:15:01 (52s). Start-of-outage point 51.537248, -1.923087; end-of-outage point 51.529985, -1.963546; midpoint estimate 51.5336, -1.9433. Offset from documented point ≈ 2.7 km.
• Iver/Slough gap (18:31:43–18:32:19, plus a follow-on blip 18:32:27–18:32:31) — approx. 24.1–24.8 miles from Paddington by straight-line distance, which sits between the documented Airport Junction (≈10.6 mi) and Ruscombe/Twyford (≈29.8 mi) entries without matching either well. Per John's own assessment, this outage was too short in underlying cause to be a genuine phase break — the apparent duration was inflated by router reconnection time, not real dead-time. Excluded from gazetteer-tweak candidates.
• 4-second blip at 18:32:27–18:32:31, occurring immediately after a reconnection — useful as a rough indication that warm reassociation can be very fast (~4s), which is much shorter than the 40-50s+ durations seen at the two confirmed points. This cuts against treating those longer durations as pure reconnection/boot overhead — they more likely include genuine dead-time. See Considerations for the full reasoning and the remaining need for a proper cold-boot baseline.
• Box Tunnel (19:27:35–19:28:58, ~83s) — a complete signal blackout with no mobile fallback either, unlike every other candidate which showed wifi-drop-with-mobile-fallback. This pattern (both wifi and mobile dead) is consistent with a genuine tunnel, not a phase break, and was excluded on that basis.
• Early gap near Ealing/Acton (18:16:07–18:16:48, ~41s) — too close to departure to distinguish from initial wifi settling; not treated as evidence either way.
This trip used the Bath/Chippenham diversion, so Chipping Sodbury Tunnel (the fifth gazetteer entry) was not on the route and generated no data point. The Paddington→Swindon portion of the route is shared with the direct/non-diverted route; findings there should generalise, but the Bath diversion section is diversion-specific until compared against a direct-route trip.
Same method as 2026-07-13, applied to the Swindon→Reading→Paddington portion of the outbound leg (the segment upstream of Swindon wasn't checked for this pass). This trip travelled eastbound (Bristol→Paddington) — the opposite direction to the 2026-07-13 trip.
• Steventon / Milton — second independent observation. Observed outage 07:05:19–07:06:12 (53s). Start-of-outage point 51.617204, -1.266741; end-of-outage point 51.612509, -1.248089; midpoint estimate 51.6149, -1.2574. Offset from documented point ≈ 3.65 km. 1.8 km clear of the nearest station (Didcot Parkway), and the train was moving fast through the area, not stopped — consistent with a genuine phase break rather than a station-related wifi event.
| Candidate | Gazetteer coords | Observed outage | Verdict |
|---|---|---|---|
| Steventon/Milton (2026-07-13, westbound) | 51.6212, -1.3093 | 18:55:20–18:56:06 (46s) | Confirmed match, ~1.7km offset |
| Steventon/Milton (2026-07-22, eastbound) | 51.6212, -1.3093 | 07:05:19–07:06:12 (53s) | Confirmed match, ~3.65km offset |
| Steventon/Milton (combined midpoint, both directions) | 51.6212, -1.3093 | n/a | Combined estimate 51.6171,-1.2711 (~2.68km offset, 2 trips agree ±1.95km) |
| Steventon/Milton (entry boundary, eastbound only) | 51.6212, -1.3093 | 07:05:13–07:05:26 | Direction-aware bracket: 51.6169,-1.2652 (≈700m stretch) — tighter, awaits more same-direction data |
| Royal Wootton Bassett | 51.5416, -1.9045 | 19:14:09–19:15:01 (52s) | Confirmed match, ~2.7km offset |
| Iver/Slough | n/a (near two entries) | 18:31:43–18:32:19 (~36s) + 4s blip | Rejected — too short to be genuine |
| Box Tunnel | n/a | 19:27:35–19:28:58 (83s) | Rejected — tunnel, not phase break |
| Ealing/Acton | n/a | 18:16:07–18:16:48 (41s) | Inconclusive — too close to departure |
| Steventon/Milton (westbound entry, 2 trips) | 51.6212, -1.3093 | n/a | Direction-aware bracket: 51.6182,-1.2729 (~50m agreement, east-side boundary) |
| Royal Wootton Bassett (westbound entry, 2 trips) | 51.5416, -1.9045 | n/a | Direction-aware bracket: 51.5373,-1.9242 (~40m agreement, east-side boundary); no eastbound observation yet |
| Maidenhead (not in gazetteer, 4 trips, all eastbound) | n/a (nearest doc. section 10.8–12.1km away) | 07:27:54–07:28:42 (48s); 08:34:09–08:35:21 (72s); 08:45:17–08:45:57 (44s); 07:58:18–07:59:03 (45s) | 4/4 eastbound hit rate — likely genuine undocumented section, not yet confirmed; no westbound data |
Approaching this crossing eastbound gives a tighter bound on the true “wifi-off” point than the outage midpoint does, because the entry boundary doesn't need averaging over a direction-dependent detection lag — it's bracketed directly between the last fully-connected fix and the first fully-dropped fix, both from the same approach direction:
• 07:05:13 — 51.617672, -1.269558 (conn=w, ssid=c13, still fully connected)
• 07:05:19 — 51.617204, -1.266741 (conn=w but ssid goes null — reassociation starting)
• 07:05:26 — 51.616608, -1.263648 (conn=m — wifi fully gone)
This brackets the true crossing point to roughly 51.6169, -1.2652 (≈700 m stretch), notably tighter and further east than the round-trip midpoint estimate (51.6149, -1.2574) used elsewhere in this note. The midpoint approach implicitly averages over both a westbound and an eastbound detection lag, which isn't valid unless both lags are equal — direction-aware bracketing avoids that assumption. Once several same-direction crossings are logged, the entry/exit boundaries should be tightened using only same-direction brackets rather than round-trip midpoints — see Todo.
• Maidenhead-adjacent blip (07:27:54–07:28:42, 48s) — only 172 m from Maidenhead station, but the train was moving through (not stopped) so this isn't excluded on the “no phase break at a station” rule alone. The decisive factor: nearest documented neutral section (Ruscombe/Twyford) is 10.8–12.1 km away — far outside the ≈2-3 km gazetteer error margin established by the confirmed matches. No documented neutral section explains this outage; more likely a wifi/mobile handover tied to station-adjacent trackside infrastructure. Excluded from gazetteer-tweak candidates.
The two independent observations (2026-07-13 midpoint 51.6194, -1.2847; 2026-07-22 midpoint 51.6149, -1.2574) sit 1.95 km apart from each other — reasonable agreement for this method, and both land well clear of any station. Averaging the two midpoints gives a combined estimate of 51.6171, -1.2711, which is 2.68 km from the documented gazetteer coordinate (51.6212, -1.3093).
This is the first candidate to reach the “multiple trips agree” bar noted in Todo for proposing a tightened gazetteer coordinate. Note the direction-aware bracket above (51.6169, -1.2652) already sits noticeably east of this midpoint — once more same-direction data exists, that method should supersede the cross-direction average here. Writing any correction to location-db/gazetteer needs direct DB write access (the pg_query MCP tool is read-only) — flagged as an action in Todo rather than applied here.
As of 2026-08-03, two same-direction brackets exist for each approach direction (see 2026-08-03 return journey, above): eastbound entry (west-side boundary) ≈ 51.6169, -1.2654 (2 trips, ~50m agreement); westbound entry (east-side boundary) ≈ 51.6182, -1.2729 (2 trips, ~50m agreement). Per the todo item on same-direction bracketing, these should now be used in place of the single cross-direction combined midpoint (51.6171, -1.2711) above — that figure mixed east- and west-side boundary crossings and is not a meaningful physical location. Still needs direct DB write access to apply to location-db/gazetteer.
| Candidate | Gazetteer coords | Observed outage | Verdict |
|---|---|---|---|
| Steventon/Milton (2026-07-13, westbound) | 51.6212, -1.3093 | 18:55:20–18:56:06 (46s) | Confirmed match, ~1.7km offset |
| Steventon/Milton (2026-07-22, eastbound) | 51.6212, -1.3093 | 07:05:19–07:06:12 (53s) | Confirmed match, ~3.65km offset |
| Steventon/Milton (combined midpoint, both directions) | 51.6212, -1.3093 | n/a | Combined estimate 51.6171,-1.2711 (~2.68km offset, 2 trips agree ±1.95km) |
| Steventon/Milton (entry boundary, eastbound only) | 51.6212, -1.3093 | 07:05:13–07:05:26 | Direction-aware bracket: 51.6169,-1.2652 (≈700m stretch) — tighter, awaits more same-direction data |
| Royal Wootton Bassett | 51.5416, -1.9045 | 19:14:09–19:15:01 (52s) | Confirmed match, ~2.7km offset |
| Iver/Slough | n/a (near two entries) | 18:31:43–18:32:19 (~36s) + 4s blip | Rejected — too short to be genuine |
| Box Tunnel | n/a | 19:27:35–19:28:58 (83s) | Rejected — tunnel, not phase break |
| Ealing/Acton | n/a | 18:16:07–18:16:48 (41s) | Inconclusive — too close to departure |
| Maidenhead-adjacent (2026-07-22) | n/a (nearest doc. section 10.8–12.1km away) | 07:27:54–07:28:42 (48s) | Rejected — no matching section, likely station-related wifi handover |
| Steventon/Milton (westbound entry, 2 trips) | 51.6212, -1.3093 | n/a | Direction-aware bracket: 51.6182,-1.2729 (~50m agreement, east-side boundary) |
| Royal Wootton Bassett (westbound entry, 2 trips) | 51.5416, -1.9045 | n/a | Direction-aware bracket: 51.5373,-1.9242 (~40m agreement, east-side boundary); no eastbound observation yet |
Route was on diversion (GWR planned engineering, week of 2026-07-18–24 — see gwr/engineering-2026). John reported live: “we are going via a diversion and so we hit the end of the catenary — train power went off but we are on diesel for a while.” This trip therefore has two distinct kinds of power-loss event, which should not be conflated: a genuine documented neutral-section crossing, and a diesel-changeover point specific to today's diversion routing (bi-mode train switching traction at the end of electrification, not a phase break).
Checked against the same PostGIS trace as the RWB match above (Bristol-bound, 2026-07-23). Airport Junction (closest approach 103.8 m, 20:32:23–20:32:27) and Ruscombe/Twyford (closest approach 130.3 m, 20:42:19) both showed continuous c13 wifi connectivity through closest approach — no outage, unlike the clean drop-reconnect signature seen at confirmed crossings. Steventon/Milton (closest approach 74.5 m, 20:59:29) showed a fragmented flicker instead of a clean drop: mobile at 20:59:12–20:59:20, a single c13 ping at 20:59:24, mobile again at 20:59:29–20:59:34, then continuous c13 from 20:59:39 — more consistent with reassociation noise than a genuine phase break, so not counted as a third confirmed observation there. Chipping Sodbury Tunnel was never approached (nearest fix >11.7 km away) — this trip terminated near Bristol Parkway before reaching it.
• Royal Wootton Bassett — third independent observation, second on this direction (Bristol-bound). Observed outage 21:17:21–21:18:28 (67s). Start-of-outage point 51.537294, -1.925499; end-of-outage point 51.52791, -1.97503; midpoint 51.5326, -1.9503. Offset from documented point (51.5416, -1.9045) ≈ 3.33 km — consistent with the two prior confirmed offsets (2.7 km and, combined with those, keeps this well inside the established error band. This crossing was correctly anticipated by the hibernate-on-approach monitor: it triggered at 21:15:06, 4.92 km out (radius=5 km), and the live hibernate/resume cycle completed successfully before the router itself dropped at 21:17:21.
Both confirmed RWB observations are westbound (Bristol-bound); raw fixes give a tight entry (east-side boundary) bracket for each: 2026-07-13 last connected 19:14:05 (51.537248,-1.923087) → ssid null 19:14:09 (51.537263,-1.926006), midpoint ≈ 51.5373,-1.9245; 2026-07-23 last connected 19:17:17 (51.53724,-1.922562) → ssid null 19:17:21 (51.537294,-1.925499), midpoint ≈ 51.5373,-1.9240. These agree to ~40m — tighter than anything previously written up here, and the two exit (west-side) brackets — 51.5303,-1.9620 (2026-07-13) vs 51.5283,-1.9735 (2026-07-23) — sit roughly 800m apart, similar order to the Steventon/Milton exit spread. No eastbound observation of RWB exists yet — today's (2026-08-03) eastbound leg passed through with no drop at all, so the west-side (eastbound entry) boundary remains unknown. This is the priority gap, not a repeat westbound trip — see Todo.
OwnTracks records bs (battery status: 1=unplugged, 2=charging, 3=full) alongside batt (percentage). During the 2026-07-15 outbound journey (Bristol → Swansea), John's phone was plugged into a USB port/charger the whole time yet bs toggled 2→charging while moving and 1→unplugged at every stop (home, a break at Cardiff West, arrival at destination). Battery percentage fell steadily throughout (100%→85%) despite bs=2 for most of the journey — the port evidently couldn't fully offset GPS/mobile-data drain, but John notes the charging did measurably reduce the drain rate compared to running unplugged.
This suggests bs (and drain-rate changes in batt) could serve as a secondary, independent signal for detecting mains power availability on a train — corroborating the primary wifi-router power-loss signal already used for phase-break/neutral-section detection. Two caveats before relying on it: (1) bs reflects USB port/charger state generally, not specifically mains-derived power — it would need cross-referencing against known train-seat-socket sessions to be useful for this purpose; (2) sampling interval and OS-level charge-state debouncing may lag the true power event, so timing precision is likely coarser than the wifi-drop method. Worth revisiting once more journeys with a phone charging cable are logged (see Todo).
Diversion ended today (tunnel reopened, see Todo). However the phone's wifi didn't join c13 until 07:31:47 at 51.529146, -2.294575 — already east of the Chipping Sodbury Tunnel gazetteer point (51.5444, -2.339), so this trip still produced no usable data point there; connection was on mobile the whole way from home until that point. Worth noting for future trips: the cold-start wifi join lag means an early-route neutral section can be missed even on the right route unless the router is already joined before reaching it.
Checked the full trace from ~07:40 to ~07:44 through the RWB coordinates (51.5416, -1.9045) — conn=w, ssid=c13 continuously throughout, no drop of any kind. This is the first trip of four to show no detectable phase break here, against three prior confirmed matches (2026-07-13, 2026-07-23 ×1 combined with an earlier pass). Possibly a different unit on this working, or the phase break simply didn't trigger a router power-cycle this time — not enough to draw a conclusion from a single non-detection.
Observed outage 08:07:45–08:08:51 (66s from ssid-null to reconnect; 56s conn=m to reconnect). Entry bracket, same method as 2026-07-22:
• 08:07:35 — 51.617786, -1.269800 (conn=w, ssid=c13, still fully connected)
• 08:07:45 — 51.617268, -1.266966 (conn=w but ssid goes null — reassociation starting)
• 08:07:55 — 51.616718, -1.264208 (conn=m — wifi fully gone)
This brackets the entry point to roughly 51.6170, -1.2656 — within ~50m of the 2026-07-22 eastbound bracket (51.6169, -1.2652), the tightest agreement between two independent same-direction observations so far. This strongly supports superseding the cross-direction combined midpoint with the eastbound-only bracket once a westbound-only bracket is also available (see Todo).
Passed closest approach (51.4756, -0.8655) at ~08:30:46 — conn=w, ssid=c13 continuous throughout, no drop. Same non-detection pattern as the 2026-07-23 trip at this location, and as RWB earlier on this trip.
Clean drop 08:34:09–08:35:21 (72s). Start-of-outage point 51.518251, -0.723318; end-of-outage point 51.524128, -0.667165; midpoint 51.5212, -0.6953. Train moving at speed throughout (not stopped), so not excluded by the station-stop rule despite starting almost exactly at Maidenhead station (51.518601, -0.722464, ≈70m from the outage start). Reconnection point is 4.4 km further east — too far for a simple station-wifi handover, which should resolve quickly rather than staying dropped for the length of track covered.
This is the second time this exact spot has produced a drop: the 2026-07-22 trip had a 48s blip 172m from Maidenhead at the same point in the route, which was rejected at the time because it didn't match any documented gazetteer entry (nearest, Ruscombe/Twyford, is 10.8–12.1 km away). With a second, longer, cleaner observation at the same location, this deserves treating as a live unconfirmed candidate rather than a one-off dismissal — either an undocumented sixth neutral section near Maidenhead, or a different systematic cause worth investigating (e.g. line-side infrastructure change, engineering-work-related power switching). See Todo.
Observed outage 19:00:55–19:01:31 (~36s conn=m, plus a single 4s blip at 19:01:45) at 51.618–51.621, -1.274 to -1.301 — consistent location and duration with the four prior confirmed Steventon/Milton crossings. Second westbound observation (first was 2026-07-13).
Raw fixes (pulled retrospectively for both westbound trips) bracket the entry (east-side) boundary tightly:
• 2026-07-13: last connected 18:55:14 (51.617949, -1.271165); first conn=m 18:55:20 (51.618401, -1.274010) — no intermediate ssid-null step captured. Bracket midpoint ≈ 51.6182, -1.2726.
• 2026-08-03 (this trip): last connected 19:00:51 (51.618008, -1.271653); ssid null 19:00:55 (51.618480, -1.274648, conn=w still, reassociation starting); conn=m 19:00:59 (51.618908, -1.277632). Bracket midpoint (connected→ssid-null) ≈ 51.6182, -1.2732.
The two westbound entry brackets agree to ~50m (51.6182,-1.2726 vs 51.6182,-1.2732) — as tight as the existing eastbound pair (51.6169,-1.2652 vs 51.6170,-1.2656). Exit (west-side) brackets are looser: 2026-07-13 last conn=m 18:56:01 (51.620643,-1.295301) → reconnect 18:56:06 (51.620804,-1.298286), midpoint ≈ 51.6207,-1.2968; 2026-08-03 last conn=m 19:01:31 (51.620855,-1.301208) → reconnect 19:01:35 (51.620973,-1.304092), midpoint ≈ 51.6209,-1.3027 — these differ by ≈400m, still much tighter than the round-trip midpoint method. Steventon/Milton now has two tight brackets in each direction: eastbound entry ≈ 51.6169,-1.2654 (west-side boundary); westbound entry ≈ 51.6182,-1.2729 (east-side boundary). These are physically different boundaries of the same neutral section and should not be averaged together — see updated estimate below, which supersedes the cross-direction combined midpoint.
Drop 19:10:31–19:11:12 (~41s conn=m) at 51.586, -1.664 to -1.695, between Chippenham and Swindon. Does not correspond to any documented gazetteer entry (nearest is Royal Wootton Bassett, 51.5416,-1.9045, well over 10km away). John reported live that the router had been physically knocked off its position around this time, so this is attributed to a physical dislodgement/reboot rather than a genuine phase break. Excluded from gazetteer-tweak candidates — flagged explicitly so it isn't mistaken for a new undocumented neutral section on review.
Drop 07:54:24–07:55:23 (~54s conn=m, from ssid-null to reconnect) at 51.5445,-2.1495 to 51.5419,-2.1145, on the outbound leg past Chippenham. Nearest gazetteer entries are Chippenham station (9.5 km) and Chipping Sodbury Tunnel neutral section (13.1 km) — both far outside the ~2–3 km error margin established by confirmed matches. John reported live that the router had just been knocked off its position (fell on the floor), so — same pattern as the 2026-08-03 Christian Malford/Dauntsey artefact — this is a physical dislodgement/reboot, not a genuine phase break. Excluded from gazetteer-tweak candidates.
Drop 08:45:17–08:45:57 (~44s, ssid-null to reconnect). Last-connected fix ≈880 m from Maidenhead station — same location as the two prior Maidenhead-area observations (2026-07-22, 48s; 2026-08-03, 72s). This is now 3 journeys showing a drop at this spot. Duration is more variable than Steventon/Milton or RWB (44–72s across the three), and it remains outside any documented gazetteer entry (nearest, Ruscombe/Twyford, is well over 10 km away). Kept as an open, unconfirmed candidate — not yet promoted to a confirmed match, and not dismissed as an artefact either, since nothing here points to a physical cause the way the two router-knock rejections above do. See Todo.
Full PostGIS trace pulled for the whole journey (06:09–08:49). John's router (SSID c13) held a continuous conn=w connection from 07:00:50 (near Bristol Parkway) all the way to 08:17:39 (Paddington approach), with zero drops to mobile/null anywhere en route — the only connectivity change in the entire trace is the expected station arrival sequence (c13 → mobile → #FreeStationWiFi → mobile, 08:17–08:26 near Paddington itself). Closest-approach fixes were checked individually against all five gazetteer candidates plus the Maidenhead unconfirmed candidate, and every one passed through on continuous c13 with no outage: Chipping Sodbury Tunnel (~07:07:59–07:08:47, though accuracy degraded to 723m in this stretch — a GPS gap, not a wifi drop), Royal Wootton Bassett (~07:18:56, 51.5348,-1.9031, closest approach essentially on top of the gazetteer point), Steventon/Milton (~07:42:01–07:42:07, 51.6178–51.6165,-1.2701–-1.2630 — directly through the established eastbound bracket at 51.6169,-1.2654), Ruscombe/Twyford, and Maidenhead (~-0.72 to -0.67 longitude band). This is the first trip to show a clean non-detection at Steventon/Milton, which had previously been the most consistently confirmed crossing (5/5 prior trips). Combined with the existing single non-detections at RWB (2026-08-03) and Ruscombe/Twyford (2026-07-23, 2026-08-03), this raises the open question of whether the phase break simply didn't trigger a router power-cycle on this particular unit/working, rather than pointing to any error in the gazetteer coordinates themselves — worth tracking non-detection rate over more trips rather than treating any single one as concerning.
Clean drop 07:58:18–07:59:03 (45s, ssid-null to reconnect). Last-connected fix 51.517609,-0.726809 (07:58:14); reconnect (conn=w, ssid=c13) at 51.522431,-0.689511 (07:59:03). Drop-start point is ≈320 m from Maidenhead station (51.518601,-0.722464). Same recurring location as the three prior observations, on the same eastbound approach direction.
This is the fourth independent observation at this spot (2026-07-22, 48s; 2026-08-03, 72s; 2026-08-06, 44s; 2026-08-13, 45s) — 4/4 trips through this stretch have shown a clean drop, a stronger hit rate than Ruscombe/Twyford (0/4) or RWB (3/4). Drop-start distance from the station varies considerably across the four (≈70 m, ≈172 m, ≈880 m, ≈320 m), which argues against a simple station-wifi handover (that would cluster tightly at the platform) and is more consistent with a genuine trackside neutral section whose apparent entry point shifts a little with speed/timing. Duration remains more variable (44–72s) than Steventon/Milton or RWB.
All four Maidenhead observations to date are eastbound only. No westbound (Paddington→Bristol) trip has yet been checked against this location, so it's unknown whether the drop occurs in that direction or what the boundary looks like approached from the west. See Todo.
Operationally relevant: on this trip the hibernate-on-approach monitor triggered/hibernated at Ruscombe/Twyford (which showed no drop, as on all four prior passes) and was not armed for the Maidenhead drop that followed shortly after. See Todo for the live bug this raises about the configured trigger location.
Outbound (Bristol→Paddington): checked full c13 transition history 06:00–09:30. Royal Wootton Bassett — clean drop 07:14:17–07:14:58 (41s, ssid-null to reconnect), from 51.5525,-1.9372 to 51.5439,-1.9209, plus a brief 4s blip at 07:15:05–07:15:12 immediately after (consistent with the fast-reassociation pattern seen elsewhere, not a second event). This is the first confirmed eastbound RWB observation — all three prior confirmed RWB crossings (2026-07-13, 2026-07-23 ×1, plus the westbound entry brackets) were westbound. Location is broadly consistent with the existing RWB gazetteer point (51.5416,-1.9045) and westbound exit brackets, though a proper eastbound entry-boundary bracket hasn't been computed yet — see Todo.
Steventon/Milton — clean drop 07:37:18–07:38:14 (56s) at 51.6164,-1.2623 to 51.6045,-1.2221, squarely in the established eastbound bracket (51.6169,-1.2654). Sixth confirmed observation, consistent with all prior eastbound passes.
Maidenhead — fifth observation overall (see 2026-08-13 outbound entry above for the eastbound leg, 07:58:18–07:59:03).
Return (Paddington→Bristol, in progress as of ~19:05): Maidenhead — clean drop 18:13:33–18:14:21 (48s) at 51.5153,-0.7377 to 51.5049,-0.7716. This is the first westbound observation of the recurring Maidenhead candidate — all four prior observations were eastbound only. Duration (48s) sits within the existing 44–72s range. Worth flagging in Todo as the priority westbound-boundary gap now closed for this candidate.
Steventon/Milton (westbound, ~18:38:50–18:39:44, with a 6s blip at 18:39:38–18:39:44) and Royal Wootton Bassett (westbound, ~19:03:24–19:04:04) both showed clean drops at their established westbound locations — consistent, not new. A short 19s drop at 18:03:42–18:04:01 near West Drayton/Iver matches the previously-rejected Iver/Slough short-blip pattern and is not treated as a genuine crossing.
Checked full trace from before Bristol Parkway boarding through to Paddington approach. conn=w/ssid=c13 held continuous throughout — no drop detected at Royal Wootton Bassett, Steventon/Milton, Ruscombe/Twyford, Maidenhead (unconfirmed candidate), or Airport Junction. This is a full-route non-detection, similar in pattern to 2026-08-10.
Possibly — not yet confirmed — John's computer crashed during the Reading–Paddington leg, despite no router drop detected anywhere on the route. Flagged live but not yet verified against actual boot/crash logs, so treat as tentative until checked (see Todo action item). If confirmed, it would be notable: the first case of a computer/device crash coinciding with a full router non-detection, rather than with a router drop the trigger simply missed (contrast the 2026-08-17 SBC crash, which did coincide with a detected drop — see Todo). John's working hypothesis, also unconfirmed: power interruptions on the Reading–Paddington stretch may be shorter than elsewhere — short enough that the router (perhaps via onboard capacitor buffering, or fast-enough reassociation to not register as a conn change at OwnTracks' polling resolution) rides through them without a visible wifi drop, while a computer's PSU/storage does not. If borne out, this would mean the router-drop signal is not a reliable proxy for “did the target device lose power” on this section specifically — the core assumption underpinning the whole hibernate-on-approach design (see Considerations, “Why a battery-less device changes the requirement”). Do not treat as established until the crash is confirmed and its timestamp correlated against the GPS trace — see Todo, deferred for later investigation.
Clean drop 08:17:32–08:18:28 (56s, ssid-null to reconnect). Last-connected fix 51.517683,-0.72618 (08:17:28); reconnect (conn=w, ssid=c13) at 51.523450,-0.679837 (08:18:28). Drop location and duration both sit squarely within the existing Maidenhead cluster (four prior eastbound observations: 2026-07-22 48s, 2026-08-03 72s, 2026-08-06 44s, 2026-08-13 45s). This is the fifth eastbound observation at this spot, 5/5 hit rate on this direction — flagged live by John (“i think we just had the computer go off”) and confirmed against the trace on request, rather than found by proactive checking. Reinforces treating this as a genuine undocumented neutral section rather than a one-off artefact; still not promoted to the gazetteer pending write access — see Todo.
Ran a systematic analysis over the entire location-db history instead of per-trip spot checks: detected all clean conn=w/ssid=c13 drop-reconnect events, filtered blips under 20s, and clustered by proximity against the current gazetteer. This confirmed and tightened the Royal Wootton Bassett brackets (see Todo) and surfaced one new unflagged recurring candidate.
New candidate, ~51.485,-2.078 (exact place name not verified — earlier “Bristol Parkway/Filton” label was an unchecked guess, likely wrong). 4 observations (3 westbound, 1 eastbound), 41-60s duration, spanning 2026-07-13 to 2026-07-30. ~11-14km from any existing gazetteer entry. Checked against the possibility this is just John packing/unpacking his own c13 router rather than a genuine phase break: ruled out — fix-by-fix speed through the 2026-07-13 event holds ~190-200km/h right up to the drop (matching approach speed exactly), the device keeps moving throughout the outage (fallback to conn=m, not a stop), and the same ~1-1.5km-wide cluster recurs across 4 separate calendar dates in both directions at a location that is mid-route, not near either end of the journey. Not yet promoted — still needs more repeat observations (only one direction has more than one hit) before treating as confirmed, per the same-direction-bracket standard used elsewhere.
Also noted: Airport Junction and Chipping Sodbury Tunnel gazetteer points still have zero matching drops within 3km across the whole history — both remain mileage-estimated placeholders rather than empirically confirmed locations. A one-off 2026-08-31 trip showed a cluster of drops near Wolverhampton/Birmingham and near Newport/South Wales — a different route entirely, not GWML Paddington–Bristol, excluded from consideration here.
Checked directly against location-db for the 2026-08-19 Whitechapel→Reading Elizabeth line leg (~15:33–17:53) and the subsequent GWR leg from Reading. Result: c13 never connects at all during either leg. The Elizabeth line portion shows GuestWL, mobile, VodafoneWiFi, mobile again, then Reading's #FreeStationWiFi — so there is no drop signal to assess for TfL/Crossrail candidate sections; the question is moot rather than answered either way. The GWR leg onward stays on mobile the whole way past Royal Wootton Bassett and Chippenham; the first wifi reconnection all evening is to a different SSID, c9, near Bristol Parkway at 20:11 — not c13. So none of the established GWML detections could have fired that evening regardless of whether power was actually lost at those points, and the c9 SSID (vs the usual c13) is unexplained and worth a separate look if it recurs.
Checked pomelo's local boot history and /home/john/hibernate-on-approach.log against the suspected 2026-08-20 Reading–Paddington window. last -x shows one continuous boot from 2026-08-19 08:00 to 2026-08-21 16:03, with no reboot or crash during the journey. The hibernator log records four successful hibernate/resume cycles that morning (RWB 07:16, Steventon/Milton 07:39, old Ruscombe/Twyford 07:58, Airport Junction 08:09), each followed by DB reconnection and continued monitoring. Therefore no computer crash occurred; the full-route c13 non-detection was not caused by a machine crash. Those historical log entries use the old pre-2026-08-26 trigger list, which is why they mention obsolete section names.
Additional local-log check for the separate 2026-08-17 Maidenhead incident: at the reported westbound drop (~19:04, around 51.515,-0.738), /home/john/hibernate-on-approach.log shows the old process still tracking Ruscombe / Twyford and reporting distances ~11-12km, so it did not trigger hibernation there. The same log shows successful hibernate/resume cycles later at Steventon/Milton and Royal Wootton Bassett, with DB reconnection afterward; last -x shows the surrounding system boot beginning 2026-08-17 19:57 and continuing until 2026-08-19 08:00, but cannot establish whether the user-reported event itself was a hardware/power crash. Conclusion: the app definitely did not cause that Maidenhead hibernate; the crash remains unresolved, but the stale trigger configuration explains why no protective hibernate occurred at the observed drop.
After splitting physical sections into direction-aware gazetteer rows, the script's arming map was still keyed by the full row name. With the 5km trigger radius, that could allow a second hibernate on the other directional row during the same crossing. Added section_group() to collapse eastbound/westbound entry names to one physical-section key for trigger and rearm state. Added regression coverage; 10 tests pass; deployed to /home/john/bin/hibernate-on-approach.py.
It was not a failed hibernate. It was an unclean power loss, and the hibernator behaved correctly. Investigated from /home/john/hibernate-on-approach.log on pomelo, which still holds 824 lines from that day. The log runs at the normal ~5 s cadence and then stops dead mid-stream:
19:04:16 fix age=4s lat=51.51760 lon=-0.72686 acc=9.0
nearest=Ruscombe / Twyford Neutral Section dist=10.70km armed=True
[ 18m 40s gap - no TRIGGER, no "hibernating", no shutdown ]
19:22:56 hibernate-on-approach starting, radius=5000m, poll=5s
19:22:58 fix lat=51.47600 lon=-1.03826 <- already well past Readingnearest=Ruscombe / Twyford dist=10.70km armed=True. Maidenhead was still only a candidate on 2026-08-17 and was not in the gazetteer, so the nearest section the hibernator knew about was 10.7 km away, far outside the 5 km radius. It was armed, tracking correctly, polling on schedule, and had no reason to act. Nothing in the software failed.TRIGGER → resume → reconnected to DB after hibernate sequence. So the mechanism was working normally either side of the incident.How much warning the fix would have bought: 54 seconds. Replaying that evening's track against the now-deployed westbound bracket, the first fix inside 5,000 m is 19:03:22 at 4,868 m; power was lost at 19:04:16 at 2,041 m. That is 2,827 m in 54 s, i.e. about 52 m/s (188 km/h). Whether 54 s is enough is still not known, because hibernate write time remains unmeasured — but it is circumstantially reassuring that the three hibernates which succeeded that same evening triggered at 4,823 m, 4,968 m and 4,224 m, i.e. comparable distances at comparable speeds. Not proof; the controlled stationary measurement is still the item that would settle it.
journalctl --list-boots reaches back only to 2026-09-15, and there are zero hibernation records before that. The controlled stationary test is therefore the only remaining route to the write-time number — it cannot be mined out of history./2 * check-hibernate is unrelated (it polls a note for an on-demand hibernate instruction). The script is started by hand. So after this power loss the machine came back with no neutral-section protection at all until it was manually restarted 18m40s later, and it would have passed further sections unprotected in between. A supervisor (systemd unit with Restart=always) would close this.John, 2026-09-17: "Maidenhead neutral section is not exactly at Maidenhead, though is it? If Maidenhead is a station, then that is NOT where you want a neutral section, where you need to head off and accelerate." Correct, and it follows from what a neutral section is: a gap in the overhead feed that a train coasts through. It is therefore sited on plain line at speed, never where a train needs traction to accelerate away from a stand. The gazetteer names are "nearest recognisable place", not positions.
This exposes something about the direction-aware brackets added on 2026-09-05. The eastbound and westbound "entry" points are far apart — Steventon/Milton 539 m, Royal Wootton Bassett 2,386 m, Maidenhead 3,057 m — yet a real neutral section is a dead span of tens of metres. They cannot both be the section. They are where the wifi drop was first observed in each direction, and that lags the actual power loss by however long the router takes to die and the phone to notice. Travelling east the observation lands east of the section; travelling west it lands west of it. So the true section lies between the two brackets, and their midpoint cancels a symmetric lag.
| Section | Estimated true position (bracket midpoint) | Nearest station | Distance from it |
|---|---|---|---|
| Maidenhead | 51.5146, -0.7330 | Maidenhead | 853 m |
| Steventon / Milton | 51.6176, -1.2692 | Didcot Parkway | 1,966 m |
| Royal Wootton Bassett | 51.5514, -1.9457 | Kemble | 14,893 m |
wtt_name, which are the only timetable references anywhere near it.