From bfc5ee16157c0ca8fa9a86d0498583004d01611b Mon Sep 17 00:00:00 2001 From: Mathieu Moran Date: Sat, 15 Aug 2026 17:48:23 -0400 Subject: [PATCH] docs: add BUG-24 (OBD stall reconnect) + GPS replay jitter fix notes --- BUGS.md | 19 +++++++++++++++++-- PLAN.md | 7 +++++++ 2 files changed, 24 insertions(+), 2 deletions(-) diff --git a/BUGS.md b/BUGS.md index a4ae211..d0102e5 100644 --- a/BUGS.md +++ b/BUGS.md @@ -43,6 +43,21 @@ When CLOSED, move the entire entry to Resolved — don't duplicate. server holding 279 more raw points than the Pi — both documented in the original analysis, not regressions. +### BUG-24 — OBD adapter stalls mid-drive; speed flatlines until the next ignition cycle +- **Status**: `CLOSED` 2026-08-15 +- **Commit**: `b0ad6fd` +- **Symptom**: on trip #8 (2026-08-13, 09:59–14:50), OBD speed went **102 → None** at + **14:14:31** and never recovered for the rest of the trip (~36 min). The log showed only + `No speed data received. #['14:16:35', 102.0]` — the ELM327 returned null speed responses + while still reporting `CAR_CONNECTED`, so the 10s reconnect loop never fired. Same stall + class as BUG-21 (which happened to recover on its own after ~20 min). +- **Fix**: `obd_speed()` now counts consecutive null-speed polls; after 10 nulls (~20s) it + force-closes the connection via `_mark_connection_lost()`, so `_reconnect_loop` re-runs + `connect_obd()` and the adapter is re-handshaken instead of silently flatlining until the + car is restarted. +- **Verification**: deployed to the Pi; the forced-reconnect path will be exercised on the + next real stall (in-car verification pending). + ### BUG-22 — Trip max speed ignores GPS-only stretch (shows OBD max only) - **Status**: `CLOSED` 2026-08-14 - **Commit**: `90cfd7b` @@ -67,8 +82,8 @@ When CLOSED, move the entire entry to Resolved — don't duplicate. only the portal was missing it. - **Verification**: trip #9 points at 22:23:55 previously returned speed 0.0 — now return GPS-derived speeds (e.g. 61.9 km/h at 22:23:55, labelled `gps`). API rebuilt + healthy. -- **Follow-up**: investigate why the OBD adapter dropped for ~20 min (reconnect on stalled - reads). +- **Follow-up**: see BUG-24 — the adapter stalls and returns null speed without dropping + the "connected" status; fixed with a reconnect-on-stale-speed guard. ### BUG-20 — Server trip IDs inflate far beyond the real trip count - **Status**: `CLOSED` 2026-08-14 diff --git a/PLAN.md b/PLAN.md index aa5170d..a451dc2 100644 --- a/PLAN.md +++ b/PLAN.md @@ -2301,6 +2301,13 @@ logged as `BUG-XX` entries in [BUGS.md](./BUGS.md) (BUG-16 onward) and fixed + v `app_sql.delete_trips_batch()` + a local `deleted_trip_markers` table keep deleted trips from resurrecting on rebuild. Deletion is **local-only** — raw tracking rows are preserved and the remote server is never notified (it keeps its archival copy). +- **BUG-24 (OBD adapter stalls mid-drive) — ✅ FIXED**: `obd_speed()` now counts consecutive + null-speed polls and force-closes the connection after ~20s of stale null speed, so the + reconnect loop re-handshakes instead of flatlining until the next ignition cycle. Root-caused + from trip #8 (2026-08-13): speed 102 → None at 14:14:31, never recovered for the trip. +- **GPS replay speed jitter — ✅ FIXED**: `route_points` (Pi) + `get_trip_route` (server) now + derive GPS speed over a trailing ~30s window instead of a single 5s segment, killing the false + 150+ km/h spikes. Verified: trip #8 max GPS speed 150+ → 127.8 km/h. Open items from the drive — fill in as reported: - (none clock-related — BUG-17/BUG-18 closed 2026-08-14).