OpenTrafficMap Wiki

User Tools

Site Tools

Trace: • c-its • placement • your_node • community • receivers • coverage • en_alt
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 14:23] – Image heights, wording and section cleanup (review feedback) hajoen_alt:receivers [2026/10/12 15:04] (current) – LTE modem: name the module variant, unify the breakout name 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 49: Line 49:
 ^ 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]] | ^ 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?231|The assembled board, with the enclosure}} +{{:en:circuit_board_front_with_housing.jpg?0x420|The assembled board, with the enclosure}} 
-{{:en:circuit_board_back.jpg?213|The back of the board}}+{{: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]]: 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?226|The enclosure, front}} +{{:en:case_front.jpg?0x420|The enclosure, front}} 
-{{:en:case_back.jpg?258|The enclosure, back, with the QR code}}+{{: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]]. 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]].
Line 72: Line 72:
   * A rubber plug for the LAN cable   * A rubber plug for the LAN cable
  
-{{:box.jpg?413|The receiver as shipped}}+{{:box.jpg?0x420|The receiver as shipped}}
  
 ==== Power ==== ==== Power ====
Line 91: Line 91:
 **Do not supply USB and PoE at the same time.** **Do not supply USB and PoE at the same time.**
  
-{{:opentrafficmapnode-mate-poe.jpg?560|The receiver running on an 802.3af PoE injector}} +{{:opentrafficmapnode-mate-poe.jpg?0x420|The receiver running on an 802.3af PoE injector}} 
-{{:node.jpg?274|The receiver with its LAN cable}}+{{: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. If the receiver goes outdoors and the LAN cable runs back to a switch indoors, read [[en_alt:placement#surge_protection|Surge protection]] first.
Line 149: Line 149:
 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. 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?558|EMC test setup at FH Villach}} +{{:emv1.jpg?0x420|EMC test setup at FH Villach}} 
-{{:emv2.jpg?558|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.** **Radiated emissions, class B, 30 MHz to 1 GHz: passed.**
  
-{{:emv3.png?609|Radiated emissions measurement}}+{{: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: 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?582|Transmit measurement on 5.9 GHz}} +{{:emv4.png?0x420|Transmit measurement on 5.9 GHz}} 
-{{:emv5.png?601|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. 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.
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 ^
 | [[en_alt:receivers#diy_ethernet|DIY Ethernet]] | any ESP32-C5 + W5500 or ENC28J60 | Ethernet | yes | | [[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#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#lte_modem|LTE modem]] | ESP32-C5 + SIMCom A7670E modem | LTE, PPP over UART | 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#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#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 206: Line 207:
  
 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. 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. 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 217: Line 221:
  
 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 225: Line 231:
 ^ 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]] |
 +
 +==== LTE modem ====
 +
 +For a spot with no Ethernet and no Wi-Fi at all: a mast in a field, a rooftop without a cable run, a vehicle. Instead of bridging to somebody else's network, the receiver brings its own — a **SIMCom A7670E** cellular modem on the AND BKP-A7670E breakout, connected over UART and speaking PPP.
 +
 +**Watch out when buying:** it comes in regional and feature variants that differ in the LTE bands and in whether GNSS is fitted — this one is an **A7670E-MASA**, European bands with GNSS.
 +
 +Wiring is three jumper wires and no soldering if the breakout's header is populated; the board's TXD and RXD are 3.3 V TTL, so no level shifter is needed either:
 +
 +| ''GPIO8'' (UART1 TX) | → | ''R'' (modem RXD) |
 +| ''GPIO9'' (UART1 RX) | → | ''T'' (modem TXD) |
 +| ''GND'' | → | ''G'' |
 +
 +{{:esp32-c5-a7670e-lte.jpg?0x420|A SIMCom A7670E on the AND BKP-A7670E breakout, wired to an ESP32-C5 board with three jumper wires}} \\
 +//Three jumper wires link the modem breakout to the ESP32-C5; the orange cable is the modem's own USB power supply. Note the three antennas that have to share the space: LTE (flat patch, left), GNSS (square ceramic, top right) and the receiver's own 5.9 GHz antenna (white, right).//
 +
 +**Power the modem separately.** This is the one thing that will bite you. Leave the breakout's ''V'' pin unconnected and feed the modem from its own micro-USB jack with **5 V and at least 2 A** — transmit bursts draw up to about 2 A, and running it off the MCU board drops the rail into the brownout detector. A supply that is merely weak does not produce an error message: the modem simply reboots under load and the link keeps dropping. The regulator on the breakout is linear, so do not feed it 9 or 12 V; the difference just becomes heat.
 +
 +Configuration is two console commands, and both take effect on the next boot:
 +
 +  config set lteapn internet
 +  config set ltesimpin 1234
 +
 +The APN can often be left alone — where the operator supplies one, the modem picks it up by itself. The SIM PIN is only needed if the card has one. Note that in this variant the console is on **USB-Serial/JTAG**, not on UART0 as in the Ethernet builds, because the ESP32-C5 Mini has no second port and the prompt has to stay reachable to set the APN at all.
 +
 +The modem also has **GNSS**, switched off by default because the antenna is optional. Enabled through ''LTE_SIMCOM_GNSS'' in ''menuconfig'', it multiplexes the single UART so the position can be read while PPP is up, at the cost of a slightly less reliable link bring-up. The ''lte'' console command then shows the link state and the last fix. The position is **not** sent to OpenTrafficMap — the code exists but is disabled, because there is no endpoint for it yet.
 +
 +**Keep the LTE and GNSS antennas well away from the ESP32's antenna.** The modem transmits at +23 dBm, and on LTE band 3 its third harmonic falls into the lower 5 GHz channels — so a badly placed modem antenna will quietly cost you C-ITS reception. See [[en_alt:placement#interference|Interference]] for the same problem with Wi-Fi access points.
 +
 +//Not in a release yet: this is [[https://codeberg.org/opentrafficmap/its-g5-receiver-firmware/pulls/30|pull request #30]], which builds on [[https://codeberg.org/opentrafficmap/its-g5-receiver-firmware/pulls/29|#29]]. For now you build it from the branch.//
 +
 +^ Hardware | an ESP32-C5 board, a SIMCom A7670E-MASA on the AND BKP-A7670E breakout, a SIM card, and a separate 5 V / 2 A supply for the modem |
 +^ Firmware | official firmware with ''sdkconfig.proto-lte-a7670'' — currently only in pull request #30 |
 +^ Uplink | LTE, PPP over UART |
 +^ Reports to OTM | yes, the same as the official board |
 +^ Advantages | completely independent of local infrastructure — power and a SIM are enough; no second chip and no router; optional GNSS gives the node its own position |
 +^ Drawbacks | needs a SIM and a data plan; the second power supply is mandatory, not optional; the modem can desensitise the C-ITS receiver if the antennas sit close together; not merged, so you build it yourself |
 +^ Repository | [[https://codeberg.org/opentrafficmap/its-g5-receiver-firmware/pulls/30|its-g5-receiver-firmware PR #30]] |
  
 ==== Mobile 5G setup ==== ==== Mobile 5G setup ====
Line 234: Line 278:
 Useful for surveying a location before mounting anything permanently, or for taking a receiver along on a route. 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?560|Mobile setup: FireBeetle 2 ESP32-C5, W5500, power bank and a 5G router}}+{{: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 | ^ Hardware | FireBeetle 2 ESP32-C5, W5500, power bank, ZTE MU5001 or any 5G router with an Ethernet port |
Line 247: Line 291:
 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 253: Line 297:
 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 260: Line 304:
 ^ 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 269: Line 313:
 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 279: Line 323:
 ^ 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 325: Line 353:
 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 333: Line 361:
 ^ 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.1786364588.txt.gz · Last modified: by hajo