Nothing transmits on CAN: the single writer is obd-poller, on the K-line; gnss live

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

README.md

@@ -34,7 +34,7 @@ Planned repositories and the reasoning behind the split are described in
 |---|---|
 | NVIDIA Jetson Orin Nano Super (`mikkeli-orin-nano`) | Car unit: main compute, JetPack r36.4 / Ubuntu 22.04 |
 | NVIDIA Jetson Orin Nano Super (`mikkeli-orin-nano-2`) | Development unit: builds, CI, bench (see [REPOS](docs/REPOS.md)) |
-| PEAK PCAN-USB | Car CAN bus access (`can_pcan`, 500 kbps measured at the OBD port; `obd-poller` is its single writer) |
+| PEAK PCAN-USB | Car CAN bus access (`can_pcan`, 500 kbps measured at the OBD port; nothing transmits on it; OBD-II is on the K-line, through a Bluetooth ELM327) |
 | Onboard MTTCan | Second CAN interface (`can_onboard`) |
 | Waveshare SIM7600G-H-M.2 | LTE Cat 4 (povo, fallback uplink below WiFi/Ethernet) + GNSS |
 

docs/ARCHITECTURE.md

@@ -30,7 +30,7 @@ The Orin runs headless: no local video out. The tablet app is the display.
 | Service | Responsibility | Transmits on CAN |
 |---|---|---|
 | `can-bridge` | Read SocketCAN frames, timestamp, publish raw | No |
-| `obd-poller` | Active OBD-II PID request/response | **Yes** |
+| `obd-poller` | Active OBD-II PID request/response, on the K-line through the Bluetooth ELM327 (decision 30); never on CAN | **Yes** |
 | `gnss` | gpsd client → position, speed, time fix | No |
 | `decoder` | Raw frames → named signals via DBC | No |
 | `recorder` | Persist raw + decoded sessions to disk; raw CAN and GNSS read directly, not via the bus (decision 25) | No |
@@ -52,7 +52,8 @@ protocol, so it necessarily transmits onto a 2008 car's bus. Constraints that
 follow:
 
 - `can-bridge` runs listen-only and must never transmit.
-- `obd-poller` is the **single writer**. No other service opens a TX-capable socket.
+- `obd-poller` is the **single writer**: the only service that sends anything to the car, OBD-II
+  requests on the K-line through the ELM. No service transmits on CAN; none opens a TX-capable CAN socket.
 - Transmission is rate-limited and restricted to standard OBD-II diagnostic IDs.
 - TX is a distinct, explicitly enabled mode — not the default state on boot.
 

docs/REPOS.md

@@ -24,7 +24,7 @@ contracts repo, not copied into each consumer.
 | [orin-nano-env-setup](gitea:yukart/orin-nano-env-setup) | Jetson host bring-up |
 | [app-flutter](gitea:yukart/app-flutter) | Flutter display client |
 | [contracts](gitea:yukart/contracts) | Topic namespace, payload schemas, signal registry |
-| [svc-core](gitea:yukart/svc-core) | Acquisition + processing cluster: `recorder`, `decoder`, `orin-status`, `obd-poller` now; `can-bridge`, `gnss` to come |
+| [svc-core](gitea:yukart/svc-core) | Acquisition + processing cluster: `recorder`, `decoder`, `gnss`, `orin-status`, `obd-poller` now; `can-bridge` to come |
 | [svc-gw](gitea:yukart/svc-gw) | Telemetry gateway — aggregation and the display boundary |
 | [svc-nav](gitea:yukart/svc-nav) | Navigation service — routing and guidance |
 | [svc-vision](gitea:yukart/svc-vision) | Camera: capture and the live view; recording and inference to come |

docs/ROADMAP.md

@@ -70,14 +70,17 @@ mark …`, or the app's Mark button), on the same clock as the frames.
 - [x] `obd-poller` — active OBD-II PIDs, single writer, 2026-10-12: mode 01, the
       nine `obd2` signals (~10 Hz fast, 1 Hz slow), only while the bus is alive;
       `can_pcan` out of listen-only. Recorded beside the frames (`vehicle.ndjson`).
-      **Disabled 2026-10-13:** the Z27AG doesn't answer OBD-II on CAN (likely
+      2026-10-13: the Z27AG answers OBD-II only on the K-line (ISO 9141-2), so the
-      K-line, pin 7); kept for later active-send use
+      poller now goes through the Bluetooth ELM327 (classic serial, no pairing):
+      the `obd_*` signals, calibration references per decision 30
 - [ ] OBD-II beyond mode 01: DTC scan (modes 03/07/0A) and MUT-III `21 xx`
       requests, both needing multi-frame (ISO-TP) replies
 - [ ] First decoding captures in the car, per contracts
       `docs/impl/plans/Z27AG-CAPTURES.md` — first checklist session 2026-10-13
       (117 marks, yukart-data `can-captures/`); jack-stands section still to do
-- [ ] `gnss` — position/speed, useful as ground truth for validating decoded speed
+- [x] `gnss` — position/speed, useful as ground truth for validating decoded speed,
+      2026-10-13: svc-core `gnss`, the fix as `yukart/gnss/<signal>` (speed, heading,
+      position, altitude, satellites); `yukart/gnss/fix` for navigation still to come
 
 OBD-II gives standardised signals quickly and is worth doing early; it also
 provides a cross-check for reverse-engineered ones.