Ashin Walpola
01204a2c22
The map was a third view mode inside the V2X Monitor's topic pane, below the use case alert panel and the DENM/CAM TX cards. On a phone that left it about a third of the display tall, which is not enough to see where anything is relative to anything else - the one thing a map is for. It is now its own destination, V2xMapScreen on route v2x_map, reached from a map button in that screen's header. The button sits in the header rather than the view-mode row so it is also reachable from the message detail pane and does not move as the available modes change with the selected hardware. The status bar and bottom nav are hidden on this route; the screen carries its own floating back button, and system back still works. Both hardware paths get the same screen: everything drawn comes from CamUseCaseRepository, which already merges the CiT One's MQTT feed and the ESP32-C5's serial feed into one set of flows. With the map gone from the toggle row, the row offers a single choice on the ESP32-C5 path - there is no broker there and `topics` is always empty - so it is hidden entirely in that mode. SPATEM markers. Hazards already drew as a warning triangle; signalised intersections did not draw at all. They now draw as a traffic light with one lamp lit. Two things are worth knowing, because neither is forced by the data: - SPATEM carries signal state but no geometry, which is MAPEM's job and MAPEM is not decoded. The only position available is the sending RSU's own CAM, so the light is drawn there, and that RSU is drawn once - as the light, not as a CAM pin with a light on top of it. An intersection whose sender has not been heard over CAM cannot be placed; the map says how many rather than dropping them silently. - Which lamp lights follows the rule DashboardScreen's SignalCard already uses, the signal group changing soonest speaking for the intersection, so the same intersection reads the same way in both places instead of inventing a second convention. Four drawables rather than one tinted at runtime: setTint recolours every path in a vector, so a single shared asset would turn the whole light one flat colour and stop it reading as a traffic light. Marker reuse. Every incoming message recomposes the map, and the update block cleared the overlay list and rebuilt every Marker, decoding and mutating a fresh Drawable per marker - at up to 10 Hz per station. It also called animateTo(own) on every update, restarting the pan animation before it could finish. Drawables are now loaded once per alert level and phase and shared (osmdroid sets the icon's bounds on each draw, so one instance across markers is safe), Markers are cached by key, and the overlay list is only reordered, which moves references without allocating. Following uses setCenter, keeping animateTo for the one move worth seeing: the rider asking for follow back. Follow-own now hands over to the rider on the first touch and returns via the location button, which lights up while following. Before this the map could not be panned at all while traffic was flowing, since the next CAM dragged the viewport back. Also on the map view: tiles scaled to DPI, the floating +/- buttons off (they sit where the thumb lands and duplicate pinch), a zoom range, and more tile threads so a pan that exposes a screenful of new tiles is not served two at a time. Compiles and the unit tests pass. None of it has been seen with live traffic; TODO.md lists the on-device checks under "Waiting on hardware", including which of the HAW RSUs send CAM alongside SPATEM.
7.8 KiB
TODO
Engineering to-do list. The reviewer-facing open items live in
docs/01-requirements-traceability.md ("Open items"); this file is the working list behind them.
Waiting on hardware
On-device check of the full-screen V2X live map (added 2026-09-15)
The live map moved out of the V2X Monitor's view-mode row into its own full-screen destination
(V2xMapScreen, route v2x_map), reached from the map button in that screen's header. Markers are
now cached and reused across updates instead of being rebuilt on every incoming message, and
SPATEM intersections are drawn as traffic lights at the position of the RSU's own CAM. All of that
compiles and the unit tests pass, but none of it has been seen with live traffic.
Needs: the phone with the app, plus a CAM/DENM/SPATEM source - either the CiT One, or the OBU ESP32-C5 with a second board or a real RSU transmitting.
- Both hardware modes: tap the map button, confirm the map fills the screen (no status bar, no bottom nav) and the back button returns to the V2X Monitor.
- Panning stays smooth while CAMs are arriving - this is what the marker reuse is for. Compare against the old behaviour if it still judders.
- Touching the map stops it recentring; the location FAB resumes follow and lights up.
- A DENM shows the warning triangle, and a SPATEM intersection shows a traffic light with the lamp matching the Dashboard's SignalCard for the same intersection.
- Near a real RSU: confirm the RSU is drawn once, as a traffic light, not as a CAM pin with a light on top of it. If the RSU sends SPATEM but no CAM, the "signals not shown" note should appear instead - worth knowing which of the two the HAW RSUs actually do.
Over-the-air check of the GN lifetime fix (added 2026-09-11)
geonet.c now writes GN lifetime 0x05 (1 s) instead of 0x83, which decoded to 3200 s. Changed
in both obu-firmware and obu-cam-transmistter. Both still build (IDF 6.1 / 5.5.4), and the
compiled geonet_wrap_shb stores the new byte, but it has not been seen on air yet. Nothing else
reads this byte (gn_unwrap.c ignores it, the app never sees GN headers), so the app does not
need updating alongside the firmware.
Needs: the phone with the app, the OBU ESP32-C5, and a second ESP32-C5 running
its-g5-receiver-firmware to capture with.
- Flash
obu-firmware(seeobu-firmware/FLASHING.md). - Connect the phone, let it send CAMs, and confirm the CAM Pinger's
tx failcounter stays 0. - Capture with the receiver into
its-g5-receiver-firmware/recordings/. - Run
python obu-firmware/test/pcap_gn_tally.py its-g5-receiver-firmware/recordings/<capture>.pcap. The rows for the phone's pseudonym MACs must show SHB, port 2001, lifetime0x05, exactly like every other station's CAMs. - While the phone is connected: real-station CAMs/DENMs still reach the app (RX path unchanged).
Partial check possible with one board and no phone: flash it, idf.py -p COMx monitor, and look
for OCB @ 5900 MHz - TX/RX armed. That proves the new build boots and brings the radio up, not
that it transmits correctly.
obu-cam-transmistter yawRateConfidence fix (added 2026-09-11)
Its cam.c (compiled into that firmware) wrote yawRateConfidence as 3 bits / 7 instead of
4 bits / unavailable(8), the bug the app fixed on 2026-08-20. Fixed in it and in obu-firmware's
reference copy; asn1tools now decodes the CAM and re-encodes it byte-identically, and it builds on
IDF 5.5.4. No board runs this firmware right now (the production OBU runs obu-firmware), so this
only matters if it is flashed again:
- After flashing it: capture, run
pcap_gn_tally.py, and decode the CAM payload with asn1tools (py -3.11, modules inasn1/).
Signed-message reception and exact payloads (added 2026-09-11)
obu-firmware's gn_unwrap.c now unwraps TS 103 097 signed packets (signature not verified,
reported as V2X_RX flags bit1) and cuts every message to the length its header declares, dropping
the 8 bytes the chip's RX appends to each frame, which were forwarded to the phone until now.
Verified on the host (obu-firmware/test/host: chain, replay of all recordings against asn1tools,
50M-iteration fuzz) and built on IDF 6.1, but not flashed: the production OBU still runs the
2026-09-10 build. Needs the OBU with this build, the phone, and signed traffic - real vehicles or
RSUs, since the bench CiT One sends unsigned. A second ESP32 running the receiver firmware is
optional, but shows what was on air at the time.
- Flash obu-firmware (this also carries the GN lifetime fix above).
- Near signed traffic: signed CAMs/DENMs appear in the app, and a simultaneous capture shows
them on air (
pcap_gn_tally.pylists them assecured). - Unsigned bench traffic still decodes in the app as before (messages now arrive 8 bytes shorter).
- The heartbeat's oversize counter still counts over-long messages (e.g. road SPATEMs).
Set up host testing
- Install MSYS2 UCRT64 gcc (done 2026-09-11: gcc 16.2.0, GNU Make 4.4.1; chosen over WSL,
vanetza is not going to be built). Setup and the PATH gotcha:
obu-firmware/test/host/README.md. - Host round-trip test
obu-firmware/test/host/test_chain.c(geonet_wrap_shb->dot11p_build_frame->gn_unwrap_its, byte-checked against the standard). Done 2026-09-11: 491 checks, 0 failed. Runmakein that folder before flashing any firmware fix. - Replay of the recorded captures (
test_replay.c+check_replay.py, independent asn1tools check). Done 2026-09-11: C and Python agree on all 15 145 records. - Mutation fuzzer
fuzz_gn_unwrap.c, inputs against a no-access guard page. Done 2026-09-11: 50 000 000 iterations, no crash.makeruns a 2 000 000-iteration pass every time.
Firmware ideas from the vanetza review (2026-09-11, not started)
Suggested order after the host tests exist:
- Read secured packets (GN NextHeader=2) without verifying them. Done 2026-09-11 in
gn_unwrap.c, host-verified; flagged to the phone as V2X_RX flags bit1. On-air check under "Waiting on hardware". - Forward the full GeoBroadcast area: shape (circle/rectangle/ellipse), DistanceB, angle,
appended to the V2X_RX prefix behind a capability bit. Port vanetza's
geonet/areas.cppinside_or_at_borderto the app, which currently treats every area as a circle. - RX filtering before the serial link: duplicate detection for GBC (last 8 sequence numbers per source, as vanetza does), drop our own frames, reject GN version != 1.
- Read the DCC-MCO field (the 4 "reserved" bytes of an SHB header): neighbours' channel busy ratio for free.
- Minimum TX gap in firmware as a DCC safety net (vanetza reactive table: 60 ms relaxed ... 460 ms restrictive), with a CBR estimate in the heartbeat.
- Generic V2X_TX message (BTP port, SHB/GBC, traffic class, lifetime, area) so the phone can send DENM and VAM without reflashing. Consider QoS Data frames: vanetza's Cohda receive path drops non-QoS ones.
Dropped: building vanetza as a GN/BTP oracle. Real captures (pcap_gn_tally.py), the host
round-trip test and asn1tools for UPER cover what it would have checked.
Follow-ups found 2026-09-11
- App: show the signed flag.
V2xRxFrame.parseinSerialFrame.ktonly reads bit0 of the flags byte; read bit1 (signed, not verified) and show it where messages are listed. - Messages that do not decode with asn1tools. In the recordings, 56 from the CiT One
(
aa:f8:76:7d:bd:ad: 54 CAMs of 245 bytes, 2 DENMs of 402 bytes) and one 218-byte CAM from6e:94:03:1b:05:26fail againstcam_1_4_1/denm_1_3_1+cdd_1_3_1_1, with or without the old trailing bytes. A newer module version on the sender, or a sender bug; check what the app's decoders make of them (check_replay.pylists the records).