What you need to actually hear C-ITS. There is one purpose-built receiver that most people use, and a growing number of independent projects that solve the same problem with different hardware. All of them end up in the same place: raw 802.11p frames on the central MQTT broker.

Whatever you build, where you mount it will make a bigger difference than which board you chose.

A purpose-built board: an ESP32-C5 with wired Ethernet and Power over Ethernet, in a 3D-printed enclosure you can mount outdoors. It needs one cable, it has no moving parts, and once it is up it needs no attention.

Several hundred receivers have been delivered in several waves by now. Whether more are available at the moment is best answered by the shop itself:

• Group order. We have boards produced in batches and pass them on at cost — around 20 €, including the 3D-printed enclosure. Ordering runs through our Pretix shop: pretix.opentrafficmap.org
• Have the PCB made yourself. Production files (Gerber, BOM, CPL) and the schematics are attached to the releases: opentrafficmap/its-g5-receiver/releases
• Build something else entirely. See Other receiver projects below.

Two variants. The boards are built in two versions, and it is worth deciding which one you want before ordering:

• Standard — built with the ESP32-C5-WROOM-1 module, which has the antenna printed on the module itself. This is the right choice for almost everyone; the built-in antenna performs very well.
• External antenna — built with the ESP32-C5-WROOM-1U module, which replaces the printed antenna with a u.FL connector.

If you take the external-antenna version, you need a pigtail as well: the module's connector is tiny, while most antennas terminate in an SMA plug. Watch out when buying, because the same connector format is sold under three different names depending on the manufacturer — Espressif lists all three as compatible:

• U.FL — Hirose
• MHF I — I-PEX
• AMC — Amphenol

A pigtail advertised as “u.FL to SMA”, “MHF I to SMA” or “IPEX to SMA” will therefore all fit. Note that I-PEX also makes MHF II, MHF 4 and so on — those are smaller, different connectors and will not mate.

Only go for the external-antenna version if you have a specific reason. The measurements under Antennas & polarization show the internal antenna coming very close to a 16 dBi external one — and an external antenna mounted with the wrong polarization is markedly worse than no external antenna at all.

Collection and delivery options in the shop:

• Pickup at realraum in Graz. You get an e-mail when your receiver is ready, together with times when somebody who knows the hardware will be there.
• Shipping within Austria (GLS) or to Germany (GLS), or free of charge with your own Post.at / GLS / DPD parcel label.

Payment options: online card payment through Pretix, bank transfer, or on site by card (SumUp).

The assembled receiver in its enclosure, front and back — the QR code on the back is the link to your self-service portal:

Schematics, KiCad sources and the enclosure live in opentrafficmap/its-g5-receiver. You can browse the circuit diagrams in the browser without installing KiCad: KiCanvas.

Revisions

• Revision 2 — current. Adds the jumper that selects active 802.3af PoE versus passive PoE, and pull-ups on I²C.
• Revision 1 — first batch, ordered at JLCPCB. Two errata: the 9.1 kΩ resistors R44 and R45 have to be removed, and passive PoE below 48 V requires a bridge between pins 4 and 5 of U8.

Enclosure. Four parts, designed in OpenSCAD, in the case directory of the hardware repository. We print in ASA, which is UV-stable without additives. Details and the outdoor considerations are on Placement & Outdoor.

• The receiver in its enclosure, printed in ASA
• A 3D-printed part for the bottom seal (bottom.stl) and screws (M4 × 12, TX20)
• A rubber plug for the LAN cable

You can power the receiver over Power over Ethernet or over USB.

With USB it does not matter which of the two ports you use — both are connected to the internal 5 V rail through a diode. Measured consumption is about 1.7 W to 2 W.

For PoE, a jumper selects the mode:

Do not supply USB and PoE at the same time.

If the receiver goes outdoors and the LAN cable runs back to a switch indoors, read Surge protection first.

The receiver takes its address over DHCP; plug it into any LAN port and it should come up on its own. A static configuration can be set over the console.

It has no Wi-Fi. The ESP32-C5 has one radio and one antenna, and both are busy receiving C-ITS. There is no way around this in the official firmware.

For a location without Ethernet, there are two practical options:

• A Wi-Fi repeater or range extender with a LAN port. The receiver sees a normal wired connection. Some models can be powered over USB, which keeps the whole setup to one power supply.
• A phone as an uplink. The receiver cannot emulate a network card over USB, so plain USB tethering does not work. What does work is a USB-Ethernet adapter plus a LAN cable to the phone; enable tethering after the receiver has booted and the link is up. Use a proper data cable, not a charge-only one.

If you would rather have real Wi-Fi, that is what Wi-Fi via SPI-EPPP below is for.

The receiver has no web interface on the local network. Nothing listens on port 80, and there is nothing to log into on your LAN.

Configuration parameters can be set two ways:

• Remotely, over MQTT, through the self-service portal — this is what you want for a mounted node.
• Locally, over USB, on the serial console.

The board has five status LEDs, and between them they tell you exactly how far the node got.

At power-on all five light up in a fixed pattern — red, yellow, green, blue, magenta. That is a lamp test, not status: the firmware suppresses real updates until it has finished booting. If the board stays on that pattern, it did not finish starting up. The operating colours below are different ones.

Read left to right when something is wrong: RCV tells you whether the radio is listening, ETH whether the node is on the network, MQT whether it reached the broker, PKT whether anything is actually on the air. An orange PKT with a yellow MQT is the classic “good antenna, broken uplink” picture.

Brightness and colour are adjustable in the self-service portal: brightness from 0 (off) to 255 (maximum), and an override colour that forces all five LEDs to one fixed colour. Turning the brightness down is worth doing on an outdoor node — at full brightness the LEDs contribute noticeably to the internal temperature.

The exact behaviour is defined in main/led.c in the firmware.

Revision 2 of the receiver has been through an EMC test, as a prerequisite for CE marking. The test was carried out at the EMC laboratory of FH Villach.

Radiated emissions, class B, 30 MHz to 1 GHz: passed.

We also programmed the receiver to transmit a C-ITS packet ten times per second on 5.9 GHz, to see how the module behaves as a sender:

The results look good, and the ESP32-C5 is very likely suitable for transmitting C-ITS packets. Note that the shipped firmware is receive-only: transmitting on 5.9 GHz is reserved for ITS services, so this was a laboratory measurement, not a feature.

1. Placement & Outdoor — get the mounting right, this matters more than the hardware
2. Your Node — set a password, give it a name, put it on the map
3. The OpenTrafficMap server — how the data actually leaves the node, and how to read along

Several people have built their own receivers. Each entry below is a self-contained project with its own hardware, its own firmware and its own way of getting online.

They differ mainly in what sits between the ESP32 and the internet, and in whether they report to OpenTrafficMap at all. Some are designed to be carried around, one runs on a discarded router, and one is a standalone tool with its own map.

The self-build closest to the official node: take any ESP32-C5 development board, add an SPI Ethernet chip, and run the official firmware. You get the same behaviour as the official receiver, without waiting for a batch.

The firmware ships prepared configurations for the two common Ethernet chips, so this is a matter of copying the right sdkconfig and building. Note that the official board uses a KSZ8851SNL, while the self-build variants target the cheaper and more widely available W5500 and ENC28J60.

The firmware README documents the wiring for a Waveshare ESP32-C5-WIFI6-KIT, which is the devboard it was tested against.

If you change the hardware or the configuration, set HW_VARIANT to custom. Otherwise your node may be offered over-the-air updates built for the official board, which will not match your hardware.

The answer to “I have no Ethernet where I want to mount this”. The ESP32-C5 cannot do Wi-Fi while receiving C-ITS, so this setup adds a second, small ESP32 that does nothing but Wi-Fi, and links the two over SPI. The second chip acts as a gateway: it joins your wireless network and forwards IP traffic to the receiver over the SPI link.

What it looks like in practice: an ESP32-C5 development board with the ESP32-C3 gateway piggybacked on top, wired by hand.

The mechanism is Espressif's eppp_link component — IP over SPI, with the receiver as the client and the gateway chip as the server, doing NAT towards your Wi-Fi.

Two implementations of the gateway exist:

• hn/esp32-spi-eppp-server — the original. Wi-Fi credentials are compiled in via menuconfig; there is no runtime configuration. Targets the ESP32-C3.
• robbi5/esp32-spi-eppp-server — a fork with a Wi-Fi manager. If it has no valid credentials, it opens an unprotected access point called ESP32-Config with a captive portal on port 80, so you can enter your network from a browser (manually at http://192.168.4.1 if the portal does not pop up). It also adds a serial CLI, supports the ESP32-C3, C3-XIAO, S3 and S2, and publishes ready-to-flash binaries — so you do not need a build environment at all.

On the receiver side, build the official firmware with sdkconfig.proto-spi-eppp. That configuration targets a 4 MB flash board with a single status LED; it was developed against an ESP32-C5-DevKitC-1 N4.

Practical warning: several people have hit SPI checksum errors that turned out to be wiring problems, and some GPIOs did not work as the datasheets suggested. If the link does not come up, try different pins before you suspect the software.

The temporaerhaus hackerspace in Ulm documents this build end to end (in German) with two Seeed Studio XIAO boards — a XIAO ESP32-C5 as the sniffer and a XIAO ESP32-C3 as the Wi-Fi bridge, both stamp-sized and solderable in an evening. The page gives the exact pin mapping and links prebuilt images you can flash from the browser, so no build environment is needed. The sniffer image comes from a fork of the receiver firmware.

TODO: Pull request #24 makes the EPPP link non-blocking and self-healing, so the receiver no longer hangs when the gateway is missing at boot and recovers without a reboot. It is still open, so the released firmware does not contain it. Update this section once it is merged.

Not a separate project so much as a way to package the DIY Ethernet build for use away from any infrastructure: a FireBeetle 2 ESP32-C5 with a W5500 Ethernet module, a power bank, and a 5G router that has an Ethernet socket. The receiver sees an ordinary wired network; the router provides the uplink over mobile data.

Useful for surveying a location before mounting anything permanently, or for taking a receiver along on a route.

An alternative firmware for people who already run Home Assistant. It is an ESPHome external component that turns an ESP32-C5 into an ITS-G5 receiver, so the received frames become an ordinary ESPHome event you can do anything with.

The component gives you an on_packet trigger carrying the raw frame bytes, the signal strength, the channel and the data rate, plus two counters (packets_received and packets_dropped) as sensors. The channel is configurable and defaults to 5900 MHz — see How it works for the other channels. It deliberately leaves out what ESPHome already handles itself, such as over-the-air updates.

A complete example configuration, its-g5-opentrafficmap.yaml, is included and forwards every frame to the OTM broker with the correct topics, so a node built this way is indistinguishable from an official one on the broker side. It also publishes temperature and uptime, and drives the five status LEDs.

Because the component takes over the radio exclusively, it cannot be combined with Wi-Fi — you need Ethernet or another uplink.

One caveat: the author describes the patched Ethernet component needed for the official board's KSZ8851SNL chip as experimental and likely to compile only with a specific ESPHome version. On self-built hardware with a W5500 or ENC28J60 this problem does not arise.

Note that this is a different thing from monitoring a node in Home Assistant, where the node runs on its own and Home Assistant simply reads its telemetry. That is described under Monitoring in Home Assistant.

A portable receiver: a Seeed Studio XIAO ESP32-C5 plugged into an Android phone with a USB-C data cable. The phone supplies power, receives the frames over USB serial, and forwards them to the broker over its own mobile data. There is a companion app that does the work, and it can even flash the firmware onto the board for you, so no PC is needed at all.

Beyond forwarding, the app records PCAP files locally and can display received data.

It is also the only one that can transmit: it can send raw frames you enter, and it contains a CAM generator. Be aware that transmitting on 5.9 GHz is reserved for ITS services in most of Europe, and the project's own documentation warns about this.

The author notes in the README that the repository is largely AI-generated and asks users to review and test accordingly.

No ESP32 at all. An AVM FRITZ!Box 3390 has an Atheros AR9580 Wi-Fi chip, and with patches to the ath9k driver that chip can be tuned to the ITS channels at 5.9 GHz. The result is an OpenWrt image that turns a discarded consumer router into a permanently installed C-ITS receiver.

The image is zero-touch: after flashing, it configures its own WAN port and starts publishing captured frames to the OTM broker about a minute after boot, with no manual configuration. A small daemon captures frames with libpcap and publishes each one unmodified over MQTT — the same wire format the ESP32 firmware produces. It also keeps a rotating PCAP capture in RAM for local analysis, and repurposes a front-panel LED to blink on every received frame.

The build is deliberately receive-only. Transmitting would be possible with the hardware, but the project stays passive on purpose.

Two things to know before you start. First, there is no prebuilt image — you have to build OpenWrt yourself, which needs roughly 25 GB of disk and half an hour to an hour for the first run. Second, the 2.4 GHz radio of the 3390 sits on a second chip that mainline OpenWrt has never supported, so that half of the router is permanently dead.

The bridge package is not tied to the 3390: anything with an ath9k radio that can be put into monitor mode on 5.9 GHz should work with minor adjustments.

A complete standalone receiver with its own live map. The firmware is a fork of ours, adapted to the Waveshare ESP32-C5-WIFI6-KIT devboard; the board streams frames to an Android app over USB or Bluetooth LE, and the app decodes them on the phone and draws vehicles, traffic lights and warnings on an OpenStreetMap background. Nothing has to leave the device.

The app covers a lot of ground: offline map caching, a frame log grouped by station, a marker per vehicle with heading and speed, an indicator for whether a message was signed, PCAP recording, and a “Geiger counter” mode that clicks on every received frame. There is also a Windows installer that flashes the board and pre-fills the node ID.

Upload to OpenTrafficMap is optional and switched off by default. If you enable it, the OTM broker is preconfigured.

A deliberately minimal firmware: it receives 802.11p frames and writes them to USB serial with SLIP framing, and does nothing else. No Ethernet, no console, no configuration at runtime — the channel is a compile-time constant. The entire firmware is a single source file of about ninety lines, built with PlatformIO and the Arduino framework rather than ESP-IDF.

A small Python script is included that either prints the frames as hex or writes a valid PCAP file, which you can open directly in Wireshark.

This project does not report to OpenTrafficMap. Its README states plainly that there is currently no good way to publish from it to OTM: the obvious bridge only speaks MQTT v5, which does not work with our broker. Treat it as an analysis and hacking tool, not as a way to contribute data to the map.