Add a V2X data logger to Settings > Developer

Records every received V2X message (CAM, DENM, SPATEM, MAPEM, VAM) into one
SQLite file per run, with a timestamp, the phone's GNSS fix, the OBU's GNSS fix
where there is one (CiT One), and RSSI where the hardware reports it (ESP32-C5).
Works on both hardware paths: V2X_RX frames from the ESP32 link, and the raw
v2x/rx plus processed v2x-uca topics over MQTT. The UPER bytes are stored
untouched; CAM, DENM and SPATEM also get a few decoded columns.

A foreground service keeps it recording with the screen locked. Subscribes to
v2x/rx/mapem so MAPEM is received on the CiT One.

The current ESP32-C5 firmware forwards only BTP ports 2001, 2002 and 2004, so
MAPEM and VAM appear in an ESP32 log only once it accepts 2003 and 2018.

Checked on a Pixel 9 Pro against a simulated car and an RSU: 10 minutes with the
screen locked and forced deep Doze, no gaps, files pass integrity_check.
This commit is contained in:
Ashin Walpola
2026-10-02 16:16:02 +02:00
parent d3fc9bf66c
commit c13c3891c9
17 changed files with 1336 additions and 5 deletions
+19
View File
@@ -5,6 +5,25 @@ Engineering to-do list. The reviewer-facing open items live in
## Waiting on hardware
### On-air check of the V2X data logger (added 2026-10-02)
Needs the phone, a second station sending (the simulated car works) and, for the CiT One part, the OBU.
Settings > Developer > V2X data logger. 110 unit tests pass. ESP32-C5 path checked on the Pixel 9 Pro on
2026-10-02 (see the ticked item); the rest has not run on a device.
- [x] **ESP32-C5 (done 2026-10-02, simulated car + RSU on air):** 153 CAMs and 60 SPATEMs in 30 s, RSSI -56..-36 dBm,
phone GNSS on every row, `obu_*` NULL, file integrity ok. MAPEM 0 as expected (firmware drops port 2003). Original steps: start a log, let the simulated car's CAMs arrive, stop. Pull the `.db` from
`files/v2x_logs/` and check `messages`: `msg_type='CAM'`, `source='esp32'`, `rssi_dbm` filled,
`phone_lat/lon` filled, `obu_*` NULL, `payload` decodes with `asn1tools`.
- [ ] **CiT One:** same, `source='cit_one'`, `rssi_dbm` NULL, `obu_*` filled from `v2x/rx/obu_gnss`.
Expect both `channel='raw'` and `channel='processed'` rows for the same CAM.
- [ ] **Screen off for a few minutes** with the log running: rows keep arriving (foreground service).
- [ ] **MAPEM and VAM on the ESP32-C5 need a firmware change.** `gn_unwrap.c` accepts only BTP ports
2001, 2002, 2004; add 2003 (MAPEM) and 2018 (VAM) and reflash. Real MAPEMs are mostly over the
512-byte link limit, so most will still be counted as oversize drops. The app side already logs
any port. On the CiT One, MAPEM arrives via `v2x/rx/mapem` (subscribed now) or the processed
`v2x-uca/output/json/map` topic; the API lists no VAM topic, so no VAM rows are expected there.
### Signed-TX firmware (vanetza-idf port), VAM and BLE: first on-air checks (added 2026-09-23)
obu-firmware is now a port of the colleague's `microbu-esp32c5` station (vanetza-idf, TS 103 097