Captures plan: OBD-II through the ELM on the K-line, obd_* names, what each poller state means

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DDwfd6Ki8UfG4hK6W5YpJz

docs/impl/plans/Z27AG-CAPTURES.md

@@ -13,8 +13,8 @@ ground truth. Prior art and first candidates: [the prior-art report](../reports/
 
 | In the session directory | From | Use |
 |---|---|---|
-| `can-*.log(.zst)` | the PEAK, every frame, kernel timestamps | what gets decoded; also holds every OBD request (`7DF`) and reply (`7E8`) |
-| `vehicle.ndjson` | `obd-poller` via the bus | the same OBD replies as values (rpm, speed, throttle, load, MAP, MAF ~10 Hz; coolant, intake air, fuel 1 Hz); `env.timestamp` equals the reply frame's timestamp |
+| `can-*.log(.zst)` | the PEAK, every frame, kernel timestamps | what gets decoded (nothing transmits on CAN: OBD-II is on the K-line) |
+| `vehicle.ndjson` | `decoder` and `obd-poller` via the bus | decoded CAN signals, and the `obd_*` references from the K-line through the ELM327 (rpm, speed, throttle, load, MAF, timing, O2 every round; coolant, intake air, trims every 5 s); `env.timestamp` is the reply's arrival at the Orin |
 | `events.ndjson` | marks from the app | when each step happened |
 | `gnss.ndjson` | gpsd (SIM7600) | speed and position for the drive |
 
@@ -33,8 +33,9 @@ ground truth. Prior art and first candidates: [the prior-art report](../reports/
   session` when there is no traffic yet (ignition on, PEAK plugged). A mark sent with
   the link down waits (`unacked`) and goes when it is back, with its delay noted.
 - The **Mark** button on the main screen is still there for anything off-plan.
-- **OBD is working** when `engine_rpm`, `vehicle_speed_kph` and the rest appear in
-  the signal list and move. If they never appear, see *If OBD stays silent*.
+- **OBD is working** when `obd_engine_rpm`, `obd_coolant_temp_c` and the rest appear
+  in the signal list and move (the ELM on the OBD port, through the Y harness beside
+  the PEAK). If they never appear, see *If OBD stays silent*.
 
 ## The steps
 
@@ -80,15 +81,19 @@ The parked steps can be split over several sessions; the drive is the important
 ## If OBD stays silent
 
 `yukart/system/obd-poller` says why (visible in `mosquitto_sub -v -t 'yukart/system/#'`
-on the Orin):
+on the Orin), and the signal list's `elm_connected` shows the Bluetooth link:
 
-- `bus idle: not polling`: no traffic: ignition off or PEAK unplugged.
-- `no ECU answers 01 00`: the engine ECU does not do standard mode 01 on this bus.
-  Then OBDb's MUT-III (`21 xx`) requests are the next thing to try.
+- `ELM …: … (unplugged, asleep or out of range)`: no Bluetooth link. The ELM in the
+  port? Its light on? A phone app holding it (it takes one connection)? Retried
+  every minute.
+- `ECU not answering (…): ignition off?`: the ELM is there, the car is not. The
+  adapter's own words are in the brackets (`BUS INIT: ...ERROR`, `NO DATA`).
+- `ECU silent for 60 s: adapter released`: ignition off for a minute; the poller let
+  go so the ELM can sleep, and tries again every minute.
 - To see what answers, on the Orin: `sudo systemctl stop yukart-obd-poller`,
-  `yukart-obd-poller --once` (supported PIDs and one value each, with reply times),
-  `sudo systemctl start yukart-obd-poller`. Never two pollers at once: their
-  replies would cross.
+  `yukart-obd-poller --elm $(. /etc/default/yukart-elm; echo $ELM_ADDR) --once`
+  (adapter, protocol, supported PIDs and one value each, with reply times), then
+  `sudo systemctl start yukart-obd-poller`.
 
 ## Afterwards