main
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Ashin Walpola
|
d107534eb2 |
Keep vanetza-idf in obu-firmware, so a plain clone builds the firmware
obu-firmware builds against the vanetza-idf C-ITS library, which until now came from the colleague's microbu-esp32c5 tree beside the repository and was not tracked here, so a clone of this repository could not build the firmware it ships. The library alone is now part of obu-firmware, as obu-firmware/external/vanetza-idf: their external/vanetza-idf at commit cf4b99f, unchanged (9775 files; see its PROVENANCE.md). CMake takes it from there by default; -DVANETZA_IDF_DIR still points the build elsewhere. The rest of the colleague's tree (their own VAM firmware, PKI tooling, station-link Python tools, the V2X2MAP bridge) stays out of this repository and gitignored; nothing is pushed to their repository. NOTES.md, docs/06, TODO.md and the pcap verifier's usage line point at the new location. |
||
|
Ashin Walpola
|
2f60623e18 |
Document the signed-ITS/VAM/BLE work and how it was verified
docs/06-signed-its-vam-ble.md: who does what between phone and ESP32-C5 (signing lives on the board), the link protocol, recovery paths (USB heartbeat watchdog, BLE supervision timeout and auto-reconnect, board-reset reconfiguration, app restart), the demo PKI, and what is still open. obu-firmware/test/verify_signed_pcap.py checks the IEEE 1609.2 signatures in a pcap with asn1tools and OpenSSL, independent of the firmware. On a capture of the CAM pinger (2026-09-23) all 12 signed CAMs verify under the demo ticket, whose chain verifies too. The CiT One receives the same CAMs but its MQTT interface exposes no security information, so it cannot confirm the signature itself. The V2X2MAP bridge on COM10 now verifies against the demo chain as well (change in the colleague's repository); signed CAMs and VAMs show as verified. TODO.md: bench checks confirmed so far ticked; open are BLE/ITS-G5 coexistence, time_regression over a longer stationary run, and board reset recovery over BLE. |
||
|
Ashin Walpola
|
7285fa19b7 |
Count and surface RX-queue drops on the ESP32-C5's promiscuous path
wifi_promisc_rx_cb() fed s_rx_queue with a 0-timeout xQueueSend() and never checked whether it succeeded, so a burst of captured frames arriving faster than rx_forward_task could drain them vanished with no counter anywhere - none of oversizeDrops/txFailures/rxCrcErrors caught it. Added a rxQueueDrops counter, threaded it through the STATUS heartbeat as a new trailing uint16 (old firmware/app on either side still parse fine), and surfaced it on the CAM Pinger card. Confirmed on the bench: flashed to the production OBU (COM3) and installed the matching app build on the phone, then watched the counter over logcat against obu-cam-transmistter's ~3.3 Hz beacon - it is real (0 -> 89 -> 90 across two sessions) but bursty around connect/reconnect rather than a continuous overflow under steady single-station traffic. |
||
|
Ashin Walpola
|
01204a2c22 |
Give the V2X live map its own screen, and a traffic light per SPATEM
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. |
||
|
Ashin Walpola
|
75d6d3b85c |
Receive signed ITS messages and forward each at its declared length
Signed packets. A GeoNetworking Basic Header NextHeader of 2 means a TS 103 097 (IEEE 1609.2) envelope follows, with the Common Header inside it. gn_unwrap_its rejected all of these, and most real traffic is signed: the 2026-08-17 capture holds 157 signed frames from 15 source MACs against 2 unsecured stations. It now opens a COER-encoded signedData, or a bare unsecuredData, and parses the inner packet as before. The inner packet comes first inside tbsData, so the certificate and signature are never parsed, and the signature is not verified - the firmware has no trust store. Such messages reach the phone with the new V2X_RX flags bit1, signed but not verified. The app reads only bit0 and is unaffected until it learns the flag. Encrypted payloads, nested signing and the legacy v1.2.1 envelope are still rejected. All 157 recorded signed frames have the layout this reads, in all three COER length forms, and asn1tools decodes every envelope to the same inner packet. Payload bounds. Every frame recorded through the ESP32-C5's promiscuous RX, about 15 000 of them, ends in 8 bytes that are not part of the 802.11 frame and not a valid FCS. obu-firmware reads frames through the same API and took the rest of the frame as the message, so it forwarded those 8 bytes to the phone after every message. UPER decoders stop where the message ends, so nothing visibly broke, but the bytes cost serial bandwidth and 8 bytes of the DENM's headroom, and they stayed attached wherever raw payloads were stored or passed on. The payload is now exactly what the Common Header's payload-length field declares, which is also what separates a signed message from its signature. A frame longer than main.c's 800-byte capture buffer is now reported as truncated instead of being forwarded cut off, and counted as an oversize drop through the new serial_link_note_oversize_drop, as it was when the cut-off frame failed serial_link's size check. Host tests in obu-firmware/test/host build the firmware sources unmodified with MSYS2 gcc; `make` runs all three. - test_chain: frames from the firmware's TX code checked byte by byte against EN 302 636-4-1 and parsed back, including hand-built signed frames, the payload-length rule, the RX trailer, and every truncation length against a no-access guard page. 1731 checks, 0 failures. - test_replay and check_replay.py: all 15 145 recorded frames through gn_unwrap_its, cut to 800 bytes as on the board, and re-derived independently in Python with the envelope decoded by asn1tools. They agree on every record; 15 131 accepted, 157 of them signed. 11 043 of the 11 106 distinct messages re-encode byte-identically. The other 63 fail the same way with the old 8 bytes put back, so the boundary is not the cause: 5 are our own CAMs from before the 2026-08-20 yawRateConfidence fix, and the rest, from other stations, are a follow-up in TODO.md. - fuzz_gn_unwrap: random edits of every recorded frame, each run against the guard page. 50 000 000 iterations, no crash. obu-firmware/test/pcap_gn_tally.py tallies GeoNetworking header fields per station over captures; it is how the other stations' lifetimes were measured. TODO.md collects what is still open, including the on-air check for this change: it builds on IDF 6.1 but has not been flashed. |