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.
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.