====== 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:server|central MQTT broker]].

Whatever you build, [[en_alt:placement|where you mount it]] will make a bigger difference than which board you chose.

===== The official receiver =====

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.

==== Get one ====

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: [[https://pretix.opentrafficmap.org/locale/set?locale=en&next=/otm/z798k/|pretix.opentrafficmap.org]]
  * **Have the PCB made yourself.** Production files (Gerber, BOM, CPL) and the schematics are attached to the releases: [[https://codeberg.org/opentrafficmap/its-g5-receiver/releases|opentrafficmap/its-g5-receiver/releases]]
  * **Build something else entirely.** See [[en_alt:receivers#other_receiver_projects|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 [[en_alt:placement#antennas_polarization|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 [[https://realraum.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).

==== Board reference ====

^ Radio | ESP32-C5-WROOM-1 (N16R8 or N8R8), or ESP32-C5-WROOM-1U on the external-antenna variant. [[https://www.espressif.com/sites/default/files/documentation/esp32-c5-wroom-1_wroom-1u_datasheet_en.pdf|Datasheet]] |
^ Ethernet | KSZ8851SNL, SPI-to-Ethernet, 100 Mbit |
^ PoE | TPS2378DDAR for standards-compliant active PoE, plus an isolated DC-DC converter accepting 7–58 V for active or passive PoE |
^ Storage | microSD slot |
^ USB | 2× USB-C — one JTAG, one UART |
^ Sensors | LM75BDP temperature sensor |
^ Antenna | Two build variants: the standard one uses the antenna printed on the module, the other has a u.FL connector for an external antenna — see [[en_alt:receivers#get_one|Get one]] |

{{:en:circuit_board_front_with_housing.jpg?0x420|The assembled board, with the enclosure}}
{{:en:circuit_board_back.jpg?0x420|The back of the board}}

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

{{:en:case_front.jpg?0x420|The enclosure, front}}
{{:en:case_back.jpg?0x420|The enclosure, back, with the QR code}}

Schematics, KiCad sources and the enclosure live in [[https://codeberg.org/opentrafficmap/its-g5-receiver|opentrafficmap/its-g5-receiver]]. You can browse the circuit diagrams in the browser without installing KiCad: [[https://kicanvas.org/?repo=https%3A%2F%2Fcodeberg.org%2Fopentrafficmap%2Fits-g5-receiver|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 [[en_alt:placement#enclosure|Placement & Outdoor]].

==== In the box ====

  * 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

{{:box.jpg?0x420|The receiver as shipped}}

==== Power ====

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:

{{:en:poe_switch.jpg?700|The PoE jumper}}

^ Power source ^ Jumper position ^ Notes ^
| Active PoE (IEEE 802.3af/at) | ''802.3af'' | Power over the LAN cable from a standards-compliant PoE switch or injector. The board signals itself as a powered device; the port is only switched on after successful negotiation. In this position the jumper is merely parked and has no electrical connection. |
| Passive PoE | ''passive'' | Power over the LAN cable from a passive injector supplying 7–58 V directly — no negotiation, no classification. Does **not** work on an 802.3af switch, where the port simply stays off. |
| USB | irrelevant | Either port. Independent of the jumper position. |

**Do not supply USB and PoE at the same time.**

{{:opentrafficmapnode-mate-poe.jpg?0x420|The receiver running on an 802.3af PoE injector}}
{{:node.jpg?0x420|The receiver with its LAN cable}}

If the receiver goes outdoors and the LAN cable runs back to a switch indoors, read [[en_alt:placement#surge_protection|Surge protection]] first.

==== Getting online ====

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 [[en_alt:receivers#wi-fi_via_spi-eppp|Wi-Fi via SPI-EPPP]] below is for.

==== Configuration ====

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 [[en_alt:your_node|self-service portal]] — this is what you want for a mounted node.
  * Locally, over USB, on the serial console.

==== LEDs & troubleshooting ====

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.

^ LED ^ Appearance ^ Meaning ^
| **SYS** | white, toggling once per second | The firmware is running. This is a heartbeat and never stops. |
| **RCV** | red | The C-ITS receiver is not running. |
| ::: | green | The receiver is running and listening. |
| **ETH** | off | No Ethernet link at all. Check the cable and the switch port. |
| ::: | blinking | Link is up, but the node has no IP address yet. Usually DHCP. |
| ::: | solid | Link is up and the node has an IP address. |
| ::: | //green or orange// | Applies to both blinking and solid: green means 100 Mbit, orange means the link fell back to 10 Mbit. |
| **MQT** | off | No network yet — there is nothing to connect with. |
| ::: | yellow | The network is up, but the node is not connected to the broker. |
| ::: | green | Connected to the broker. This is the state you want. |
| **PKT** | off | Nothing being received right now. |
| ::: | blue flash | A C-ITS frame arrived and is being reported. One flash per frame, 50 ms. |
| ::: | orange flash | A C-ITS frame arrived, but there is **no MQTT connection** — you are receiving, and it is not reaching the map. |

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 [[en_alt:your_node#node_settings|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 [[https://codeberg.org/opentrafficmap/its-g5-receiver-firmware/src/branch/main/main/led.c|main/led.c]] in the firmware.

==== Compliance & EMC ====

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.

{{:emv1.jpg?0x420|EMC test setup at FH Villach}}
{{:emv2.jpg?0x420|EMC test setup at FH Villach}}

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

{{:emv3.png?0x420|Radiated emissions measurement}}

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:

{{:emv4.png?0x420|Transmit measurement on 5.9 GHz}}
{{:emv5.png?0x420|Transmit measurement on 5.9 GHz}}

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.

==== Next steps ====

  - [[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:server|The OpenTrafficMap server]] — how the data actually leaves the node, and how to read along

===== Other receiver projects =====

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.

^ Project ^ Base hardware ^ Uplink ^ Reports to OTM ^
| [[en_alt:receivers#diy_ethernet|DIY Ethernet]] | any ESP32-C5 + W5500 or ENC28J60 | Ethernet | yes |
| [[en_alt:receivers#wi-fi_via_spi-eppp|Wi-Fi via SPI-EPPP]] | ESP32-C5 + a second ESP32 | Wi-Fi via the second chip | yes |
| [[en_alt:receivers#mobile_5g_setup|Mobile 5G setup]] | FireBeetle 2 ESP32-C5 + W5500 | 5G router with an Ethernet port | yes |
| [[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#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#usb_to_a_computer|USB to a computer]] | ESP32-C5 DevKitC-1 or XIAO | USB serial only | **no** |

==== DIY Ethernet ====

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.

^ Hardware | any ESP32-C5 board plus a W5500 or ENC28J60 Ethernet module |
^ Firmware | the official firmware, built with ''sdkconfig.proto-w5500'' or ''sdkconfig.proto-enc28j60'' |
^ Uplink | wired Ethernet |
^ Reports to OTM | yes, the same as the official board |
^ Advantages | no waiting, cheap parts, identical behaviour and identical support |
^ Drawbacks | you build and flash it yourself; no enclosure, no PoE unless you add it |
^ Repository | [[https://codeberg.org/opentrafficmap/its-g5-receiver-firmware|opentrafficmap/its-g5-receiver-firmware]] |

==== Wi-Fi via SPI-EPPP ====

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.

{{: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.//

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:

  * **[[https://github.com/hn/esp32-spi-eppp-server|hn/esp32-spi-eppp-server]]** — the original. Wi-Fi credentials are compiled in via ''menuconfig''; there is no runtime configuration. Targets the ESP32-C3.
  * **[[https://github.com/robbi5/esp32-spi-eppp-server|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 [[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.

^ Hardware | an ESP32-C5 board plus a second ESP32 (C3, C3-XIAO, S3 or S2) |
^ Firmware | official firmware with ''sdkconfig.proto-spi-eppp'', plus one of the two gateway firmwares |
^ Uplink | Wi-Fi, through the second chip |
^ 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 |
^ 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]] |

==== Mobile 5G setup ====

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.

{{:firebeetle-2-esp32-c5-w5500-powerbank-mu5001-mobile-setup.jpg?0x420|Mobile setup: FireBeetle 2 ESP32-C5, W5500, power bank and a 5G router}}

^ Hardware | FireBeetle 2 ESP32-C5, W5500, power bank, ZTE MU5001 or any 5G router with an Ethernet port |
^ Firmware | the official firmware, W5500 configuration |
^ Uplink | Ethernet into a mobile router |
^ Reports to OTM | yes |
^ Advantages | fully portable, no installation, standard firmware |
^ Drawbacks | runtime limited by the power bank; mobile data costs; not weatherproof |

==== ESPHome firmware ====

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 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.

^ Hardware | the official board, or any ESP32-C5 with an Ethernet chip |
^ Firmware | ESPHome plus the ''its_g5_receiver'' external component |
^ Uplink | your choice; the example configuration uses Ethernet |
^ 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 |
^ Drawbacks | no Wi-Fi; the KSZ8851SNL path is experimental |
^ 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:server#monitoring_in_home_assistant|Monitoring in Home Assistant]].

==== USB to an Android phone ====

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.

^ Hardware | Seeed Studio XIAO ESP32-C5, an Android phone with USB host support, a USB-C data cable |
^ Firmware | its own, derived from the OTM receiver firmware, plus an Android app |
^ Uplink | USB to the phone, then the phone's network |
^ Reports to OTM | yes — the OTM broker is the app's default |
^ Advantages | mobile; power and network from the phone; flashing without a PC; local PCAP recording |
^ 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 |
^ Repository | [[https://codeberg.org/sascha8a/cits-to-go|sascha8a/cits-to-go]] |

==== FritzBox 3390 ====

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.

^ Hardware | AVM FRITZ!Box 3390, or another ath9k-based device |
^ Firmware | OpenWrt with V2X kernel patches, plus the ''otm-bridge'' package |
^ Uplink | Ethernet |
^ Reports to OTM | yes, automatically from first boot |
^ Advantages | cheap second-hand hardware; permanent mains-and-Ethernet installation; no phone or PC involved; local PCAP mirror |
^ Drawbacks | you must build the image yourself; flashing may require the bootloader recovery procedure; no 2.4 GHz; not portable |
^ Licence | WTFPL for the project's own code; the kernel patches derive from GPL-2.0 work |
^ Repositories | [[https://github.com/MPW1412/avm-fritz3390-802.11p-otm|avm-fritz3390-802.11p-otm]] (image) · [[https://github.com/MPW1412/openwrt-otm-bridge|openwrt-otm-bridge]] (package) |

==== v2x2map ====

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.

^ Hardware | Waveshare ESP32-C5-WIFI6-KIT, plus an Android phone or a PC |
^ Firmware | a fork of the OTM firmware, plus an Android app and a Python bridge |
^ Uplink | USB or Bluetooth LE to a phone; USB to a PC |
^ Reports to OTM | optional, **disabled by default** |
^ 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 |
^ Licence | MIT |
^ 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]] |