OpenTrafficMap’s €20 ESP32-C5 Board Turns 802.11p V2X Into a Public Map of Traffic Lights and Buses

Executive Summary

OpenTrafficMap is an open-source hardware project from Graz, Austria that builds a stationary C-ITS (Cooperative Intelligent Transport System) receiver out of a Waveshare-style ESP32-C5 module — the first low-cost ESP32 with dual-band Wi-Fi and 5.9 GHz support, which is what lets it listen to the 802.11p / ITS-G5 radio stack that European traffic lights, buses, trams, trucks, and connected cars use to broadcast their status. The board adds a 10/100 Mbps Ethernet port (KSZ8851SNL SPI-to-Ethernet) with active/passive Power-over-Ethernet support, a microSD slot, a temperature sensor, and a 7–58 V PoE input, all on a 93×50 mm PCB. Approximate cost is ~€20 per board, sold through a group buy of 450 units, with limited shipping to several European countries.

The firmware decodes the standard C-ITS message types — CAM (vehicle position/speed), DENM (hazards), SPATEM (signal phase and timing), MAPEM (intersection geometry) — via raw 802.11 capture into a NATS message bus, with tshark (the Wireshark CLI) doing the decode and a Node.js backend feeding the decoded JSON onto the public OpenTrafficMap site. About 20 receivers are already in the field; deployments use either Ethernet or a 4G LTE uplink (e.g., a Mikrotik router). For security researchers, the relevance is that this is the cheapest publicly available point of entry into the C-ITS message ecosystem — the same data the European automotive industry pays substantial money to ingest from licensed roadside units is now reaching researchers and hobbyists at a €20 hardware cost.

The hardware

The receiver is built around an ESP32-C5-WROOM-1 module — either the N16R8 (16 MB flash, 8 MB PSRAM) or N8R8 (8 MB flash, 8 MB PSRAM) variant — clocked at up to 240 MHz on a single RISC-V core plus a 40 MHz low-power RISC-V coprocessor. The CNX Software piece lists the rest of the bill of materials in clean form; the key specs as published:

• SoC / module: ESP32-C5 (RISC-V), 384 KB SRAM, 320 KB ROM, 8 MB external PSRAM, 8 or 16 MB SPI flash, microSD slot.
• Wireless: dual-band 2.4/5 GHz Wi-Fi 6 (802.11ax), with 802.11b/g/n fallback, OFDMA up/down, MU-MIMO downlink, Target Wake Time; Bluetooth 5.0 LE; 802.15.4 (Zigbee 3.0 / Thread 1.3).
• V2X radio: 5.9 GHz support is what lets the same dual-band radio tune into 802.11p / ITS-G5 broadcasts.
• Wired networking: 10/100 Mbps Ethernet RJ45 via KSZ8851SNL (SPI-to-Ethernet bridge); 2× USB-C (one JTAG, one UART).
• Power: 7–58 V via active/passive PoE; TPS2378DDAR 802.3af/at-compliant PoE controller.
• Sensor: on-board LM75BDP temperature sensor.
• Mechanical: 93×50 mm PCB; PCB antenna; optional 3D-printed enclosure with pole mount for outdoor installs.

The hardware is open: schematics, PCB layout and bill of materials are published in KiCAD 10 format on Codeberg, alongside the firmware and a Node.js backend. The 3D enclosure (below) is OpenSCAD.

The data pipeline

The decode path is short and conventional. The ESP32-C5 captures raw 802.11p frames on 5.9 GHz and forwards them as raw packet captures via NATS (a lightweight message broker) to a backend, where tshark — the CLI sibling of Wireshark — runs the ITS-G5 dissector and emits decoded JSON. The JSON is then republished back through NATS, and a small Node.js script normalises the records onto the OpenTrafficMap map at opentrafficmap.org. Because the decode happens off-device, the firmware can stay small and the heavy ITS-G5 protocol logic lives in mainstream tooling that already has good test coverage.

Effective receive range is, per the project, several hundred metres in urban areas and more than 10 km with line of sight. The currently deployed fleet is about 20 receivers; the public group buy ordered 450 boards.

The Graz Linux Days 2026 talk

The project was introduced publicly at Graz Linux Days 2026. The CNX Software piece links the talk and an AI-translated English copy of the slides (the original presentation is in German).

The CNX Software write-up also links to an AI-translated English PDF of the 30-page slide deck, and to the original German PDF.

Why this matters for security researchers

• C-ITS visibility at €20. Historically, ingesting the European ITS-G5 V2X stack required a Cohda-class on-board unit or a licensed roadside-unit dev kit. OpenTrafficMap collapses that to a Waveshare board, a CAT5 cable and a hobbyist budget. That changes the population of who can build research and detection content on top of C-ITS data.
• Companion app on the receive side. CNX Software’s adjacent V2X2MAP Android app pairs the same ESP32-C5 firmware with a phone over USB OTG / BLE — the receiver hardware is shared; only the upstream changes.
• Tshark / Wireshark integration is the right pattern. Anyone building C-ITS detection content can reuse the same decode tooling; the JSON-over-NATS interface is straightforward to subscribe to from any SIEM or SOC pipeline.
• Stationary infrastructure is also a target. A 24/7 receiver attached to a pole becomes a fixed observation point an adversary may want to neutralise or feed false data to. The board’s own attack surface (Ethernet, PoE, USB, the ESP-IDF Wi-Fi stack) is small but not zero.
• Privacy footing. CAM messages are pseudonymised but positionally identifiable; large-scale aggregation onto a public map raises the same GDPR questions any other crowdsourced traffic dataset does. OpenTrafficMap’s answer is project policy + opt-in submission, not protocol-level anonymity.

Key Takeaways

Hardening Checklist (for C-ITS operators)

• Inventory passive receivers in your AOR. If your roadside units broadcast SPATEM/MAPEM/DENM at 5.9 GHz, you should assume hobbyist receivers exist within range — that’s now a $20 capability.
• Verify DENM signing. ITS-G5 supports certificate-backed DENM authentication; confirm your downstream consumers reject unsigned or invalidly-signed hazard messages, especially when a $20 board with a transmit-capable firmware flip could conceivably emit them.
• Consider rate-limiting SPATEM/MAPEM at perimeter intersections near sensitive sites (industrial, government, defence). The timing data is operationally valuable.
• For privacy compliance teams: revisit your CAM-data DPIA. Aggregated CAM positions are now publicly mappable; expect questions.
• For deployment teams: if you stand up your own OpenTrafficMap receivers, treat them like any other Internet-connected IoT device on a publicly accessible pole. Network segmentation, signed firmware, and a clear ownership/contact tag on the enclosure are basic hygiene.
• For SOC content authors: the JSON-over-NATS schema is a reasonable input for anomaly-detection rules — sudden CAM bursts from a single pseudonymous source, malformed SPATEM phases, or DENM hazards in unexpected zones are detectable.

Conclusion

The OpenTrafficMap board is a quietly significant artefact: a €20, open-hardware, PoE-powered receiver for a radio stack that was supposed to be the preserve of automotive OEMs and roadside-infrastructure vendors. For Europe’s already-deployed C-ITS estates, that means visibility, research, and external scrutiny are no longer expensive. For security teams, it means the threat model for V2X has to assume motivated adversaries can also build receivers (and, with firmware effort, transmitters) at hobbyist cost. CNX Software’s write-up is the easiest practical entry point; if you want to build one, follow the group-buy link or pull the KiCAD project from Codeberg.

This article is an independent English-language rewrite of «OpenTrafficMap ESP32-C5 C-ITS receiver board can help improve traffic efficiency using 802.11p V2X communication» by Jean-Luc Aufranc (CNXSoft), originally published on CNX Software on May 24, 2026. All product photos and original reporting are the author’s. The OpenTrafficMap project itself is open hardware available at codeberg.org/opentrafficmap. Please cite CNX Software and the OpenTrafficMap team when referencing this material.