OpenTrafficMap Wiki

User Tools

Site Tools

Trace: • c-its • your_node • community • coverage • receivers • placement • 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 19:00] – packet/json, tightened Connecting, catalogue wording 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 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 =====
Line 178: Line 178:
 | [[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 ====
Line 220: 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 228: 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 263: 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 286: Line 327:
 ^ 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 | 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; no licence stated | 
-^ Repository | [[https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware|jstsmthrgk/simple-its-g5-receiver-firmware]] | 
  
 ==== FritzBox 3390 ==== ==== FritzBox 3390 ====
Line 340: Line 365:
 ^ 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.1786381214.txt.gz · Last modified: by hajo