OpenTrafficMap Wiki

User Tools

Site Tools

Trace:
en_alt:receivers

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
en_alt:receivers [2026/08/10 17:22] – Illustrate the SPI-EPPP build hajoen_alt:receivers [2026/08/15 00:06] (current) – Renamed to The OpenTrafficMap server; Berlin coverage; imprint moved hajo
Line 1: Line 1:
 ====== Receivers ====== ====== Receivers ======
  
-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 [[en_alt:reporting|central MQTT broker]].+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 [[en_alt:server|central MQTT broker]].
  
 Whatever you build, [[en_alt:placement|where you mount it]] will make a bigger difference than which board you chose. Whatever you build, [[en_alt:placement|where you mount it]] will make a bigger difference than which board you chose.
Line 167: Line 167:
   - [[en_alt:placement|Placement & Outdoor]] — get the mounting right, this matters more than the hardware   - [[en_alt:placement|Placement & Outdoor]] — get the mounting right, this matters more than the hardware
   - [[en_alt:your_node|Your Node]] — set a password, give it a name, put it on the map   - [[en_alt:your_node|Your Node]] — set a password, give it a name, put it on the map
-  - [[en_alt:reporting|Reporting to OTM]] — how the data actually leaves the node, and how to read along+  - [[en_alt:server|The OpenTrafficMap server]] — how the data actually leaves the node, and how to read along
  
 ===== Other receiver projects ===== ===== Other receiver projects =====
  
-Several people have built their own receivers, and their work is worth knowing about even if you own the official board — one of these may fit your situation better. Each entry below is a self-contained project with its own hardware, its own firmware and its own way of getting online.+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 really a standalone tool with its own map.+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.
  
 ^ Project ^ Base hardware ^ Uplink ^ Reports to OTM ^ ^ Project ^ Base hardware ^ Uplink ^ Reports to OTM ^
Line 181: Line 181:
 | [[en_alt:receivers#esphome_firmware|ESPHome firmware]] | official board or any ESP32-C5 | your choice | with the supplied example config | | [[en_alt:receivers#esphome_firmware|ESPHome firmware]] | official board or any ESP32-C5 | your choice | with the supplied example config |
 | [[en_alt:receivers#usb_to_an_android_phone|USB to an Android phone]] | Seeed XIAO ESP32-C5 | the phone's mobile data | yes | | [[en_alt:receivers#usb_to_an_android_phone|USB to an Android phone]] | Seeed XIAO ESP32-C5 | the phone's mobile data | yes |
-| [[en_alt:receivers#usb_to_a_computer|USB to a computer]] | ESP32-C5 DevKitC-1 or XIAO | USB serial only | **no** | 
 | [[en_alt:receivers#fritzbox_3390|FritzBox 3390]] | AVM FRITZ!Box 3390 | Ethernet | yes, automatically | | [[en_alt:receivers#fritzbox_3390|FritzBox 3390]] | AVM FRITZ!Box 3390 | Ethernet | yes, automatically |
 | [[en_alt:receivers#v2x2map|v2x2map]] | Waveshare ESP32-C5-WIFI6-KIT | USB or Bluetooth to a phone | optional, off by default | | [[en_alt:receivers#v2x2map|v2x2map]] | Waveshare ESP32-C5-WIFI6-KIT | USB or Bluetooth to a phone | optional, off by default |
 +| [[en_alt:receivers#usb_to_a_computer|USB to a computer]] | ESP32-C5 DevKitC-1 or XIAO | USB serial only | **no** |
  
 ==== DIY Ethernet ==== ==== DIY Ethernet ====
  
-The straightforward self-build: 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 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 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**.
Line 208: Line 208:
  
 {{:esp32-c5-c3-spi-eppp.jpg?0x420|An ESP32-C5 development board with an ESP32-C3 wired on top as the Wi-Fi gateway}} \\ {{:esp32-c5-c3-spi-eppp.jpg?0x420|An ESP32-C5 development board with an ESP32-C3 wired on top as the Wi-Fi gateway}} \\
-//What it looks like in practice: an ESP32-C5 development board with the ESP32-C3 gateway piggybacked on top, wired by hand. This is a self-built receiver, not the official board.//+//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. 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.
Line 220: Line 220:
  
 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. 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 [[https://wiki.temporaerhaus.de/c-its#seeedstudio-xiao-basierte_sniffer-kombi|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:** [[https://codeberg.org/opentrafficmap/its-g5-receiver-firmware/pulls/24|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. **TODO:** [[https://codeberg.org/opentrafficmap/its-g5-receiver-firmware/pulls/24|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.
Line 228: Line 230:
 ^ Reports to OTM | yes, the same as the official board | ^ Reports to OTM | yes, the same as the official board |
 ^ Advantages | no cable to the mounting point; the ''robbi5'' variant configures Wi-Fi from a browser and ships binaries | ^ Advantages | no cable to the mounting point; the ''robbi5'' variant configures Wi-Fi from a browser and ships binaries |
-^ Drawbacks | two boards and five SPI wires to get right; wiring problems are common; neither project documents a licence |+^ Drawbacks | two boards and five SPI wires to get right |
 ^ Repositories | [[https://github.com/hn/esp32-spi-eppp-server|hn]] · [[https://github.com/robbi5/esp32-spi-eppp-server|robbi5]] | ^ Repositories | [[https://github.com/hn/esp32-spi-eppp-server|hn]] · [[https://github.com/robbi5/esp32-spi-eppp-server|robbi5]] |
  
Line 250: Line 252:
 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. 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 [[en_alt:c-its#how_it_works|How it works]] for the other channels. It deliberately leaves out the things ESPHome already does better, such as over-the-air updates.+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 [[en_alt:c-its#how_it_works|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. 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.
Line 256: Line 258:
 Because the component takes over the radio exclusively, it **cannot be combined with Wi-Fi** — you need Ethernet or another uplink. Because the component takes over the radio exclusively, it **cannot be combined with Wi-Fi** — you need Ethernet or another uplink.
  
-One caveat worth taking seriously: 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.+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.
  
 ^ Hardware | the official board, or any ESP32-C5 with an Ethernet chip | ^ Hardware | the official board, or any ESP32-C5 with an Ethernet chip |
Line 263: Line 265:
 ^ Reports to OTM | yes, with the supplied example configuration | ^ Reports to OTM | yes, with the supplied example configuration |
 ^ Advantages | frames become Home Assistant data; free choice of uplink and destination; ESPHome's configuration and update model | ^ Advantages | frames become Home Assistant data; free choice of uplink and destination; ESPHome's configuration and update model |
-^ Drawbacks | no Wi-Fi; the KSZ8851SNL path is experimental; no licence stated in the repository |+^ Drawbacks | no Wi-Fi; the KSZ8851SNL path is experimental |
 ^ Repository | [[https://github.com/hn/esphome-its-g5|hn/esphome-its-g5]] | ^ Repository | [[https://github.com/hn/esphome-its-g5|hn/esphome-its-g5]] |
  
-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 [[en_alt:reporting#monitoring_in_home_assistant|Monitoring in Home Assistant]].+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 [[en_alt:server#monitoring_in_home_assistant|Monitoring in Home Assistant]].
  
 ==== USB to an Android phone ==== ==== USB to an Android phone ====
Line 272: Line 274:
 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. 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 simply forwarding, the app records PCAP files locally and can display received data. It is the most actively developed of the alternative projects.+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. 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.
Line 282: Line 284:
 ^ Uplink | USB to the phone, then the phone's network | ^ Uplink | USB to the phone, then the phone's network |
 ^ Reports to OTM | yes — the OTM broker is the app's default | ^ Reports to OTM | yes — the OTM broker is the app's default |
-^ Advantages | genuinely mobile; power and network from the phone; flashing without a PC; local PCAP recording | +^ Advantages | mobile; power and network from the phone; flashing without a PC; local PCAP recording | 
-^ Drawbacks | ties up a phone and drains its battery; the transmit feature is legally delicate; AI-generation caveat from the author |+^ Drawbacks | ties up a phone and drains its battery; transmitting on 5.9 GHz is restricted in the EU; AI-generation caveat from the author |
 ^ Licence | GPL-3.0 | ^ Licence | GPL-3.0 |
 ^ Repository | [[https://codeberg.org/sascha8a/cits-to-go|sascha8a/cits-to-go]] | ^ Repository | [[https://codeberg.org/sascha8a/cits-to-go|sascha8a/cits-to-go]] |
- 
-==== USB to a computer ==== 
- 
-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. 
- 
-^ Hardware | ESP32-C5-DevKitC-1 or Seeed XIAO ESP32-C5 | 
-^ Firmware | its own, PlatformIO / Arduino | 
-^ Uplink | USB serial to a computer | 
-^ Reports to OTM | **no** | 
-^ Advantages | very small and readable code; straight to PCAP and Wireshark; no ESP-IDF toolchain needed | 
-^ Drawbacks | no OTM upload, no Ethernet, no runtime configuration; the stream carries no metadata such as signal strength; no licence stated | 
-^ Repository | [[https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware|jstsmthrgk/simple-its-g5-receiver-firmware]] | 
  
 ==== FritzBox 3390 ==== ==== FritzBox 3390 ====
  
-The odd one out, and rather elegant: 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.+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 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.
Line 328: Line 314:
 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. 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 is the most elaborate piece of user interface in this list: 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.+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. Whether it is listed here or treated as a separate project is a matter of taste — it is listed here because if you are asking "what can I receive with", you want to see it.+**Upload to OpenTrafficMap is optional and switched off by default.** If you enable it, the OTM broker is preconfigured.
  
 ^ Hardware | Waveshare ESP32-C5-WIFI6-KIT, plus an Android phone or a PC | ^ Hardware | Waveshare ESP32-C5-WIFI6-KIT, plus an Android phone or a PC |
Line 336: Line 322:
 ^ Uplink | USB or Bluetooth LE to a phone; USB to a PC | ^ Uplink | USB or Bluetooth LE to a phone; USB to a PC |
 ^ Reports to OTM | optional, **disabled by default** | ^ Reports to OTM | optional, **disabled by default** |
-^ Advantages | immediate visible result with no server involved; works without a cable over BLE; beginner-friendly installer; offline maps |+^ Advantages | immediate visible result with no server involved; works without a cable over BLE; Windows installer that flashes the board; offline maps |
 ^ Drawbacks | tied to one specific devboard; needs a phone or PC alongside; no documented concept for unattended long-term operation | ^ Drawbacks | tied to one specific devboard; needs a phone or PC alongside; no documented concept for unattended long-term operation |
 ^ Licence | MIT | ^ Licence | MIT |
 ^ Repository | [[https://github.com/pit711/v2x2map|pit711/v2x2map]] | ^ Repository | [[https://github.com/pit711/v2x2map|pit711/v2x2map]] |
 +==== USB to a computer ====
 +
 +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.
 +
 +^ Hardware | ESP32-C5-DevKitC-1 or Seeed XIAO ESP32-C5 |
 +^ Firmware | its own, PlatformIO / Arduino |
 +^ Uplink | USB serial to a computer |
 +^ Reports to OTM | **no** |
 +^ Advantages | small, single-file code base; straight to PCAP and Wireshark; no ESP-IDF toolchain needed |
 +^ Drawbacks | no OTM upload, no Ethernet, no runtime configuration; the stream carries no metadata such as signal strength |
 +^ Repository | [[https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware|jstsmthrgk/simple-its-g5-receiver-firmware]] |
  
en_alt/receivers.1786375350.txt.gz · Last modified: by hajo