RevSpace - Gebruikersbijdragen [nl]

Its-g5

2026-09-02T13:39:28Z

Bertrik Sikken: /* WeAct ESP32-C3FH4 */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* Transmitting ITS-G5 signals? https://codeberg.org/opentrafficmap/its-g5-receiver-firmware_txenabled/src/branch/main/main/tx_custom.c Would be nice to have on your bicycle! :D

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages
* Power is provided to the esp32-c3, which then distributes power as raw 5V/GND to the esp32-c5. The esp32-c5 uses its own regulator to turn it into a stable internal supply voltage.

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
=== Sniffer ===
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board for the sniffer part:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

=== Bridge ===

An ESP32-C3 is used as the bridge part.

==== Supermini ESP32 ====
At first, I used a 'supermini'.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

The esp32-c3 supermini apparently has a design flaw causing it to run very hot:
* https://www.dailyduino.com/index.php/2026/01/20/the-spicy-esp32-c3-super-mini-when-2-boards-become-2-heaters/
* https://community.home-assistant.io/t/esp32-c3-supermini-getting-very-hot/980177/5
So in software you need to keep this in mind:
* lower the CPU frequency, makes a few degrees difference: this seems to make SSL network connections unreliable though
* allow some 'idle' time in Arduino, e.g. using delay(50) or delay(100) in loop()

==== WeAct ESP32-C3FH4 ====
I plan to try this as an alternative to the "supermini".

More info: https://github.com/WeActStudio/WeActStudio.ESP32C3CoreBoard

Is a larger board, has a PCB antenna instead of a chip antenna.

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

Its-g5

2026-09-01T08:49:33Z

Bertrik Sikken: /* WeAct ESP32-C3FH4 */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* Transmitting ITS-G5 signals? https://codeberg.org/opentrafficmap/its-g5-receiver-firmware_txenabled/src/branch/main/main/tx_custom.c Would be nice to have on your bicycle! :D

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages
* Power is provided to the esp32-c3, which then distributes power as raw 5V/GND to the esp32-c5. The esp32-c5 uses its own regulator to turn it into a stable internal supply voltage.

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
=== Sniffer ===
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board for the sniffer part:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

=== Bridge ===

An ESP32-C3 is used as the bridge part.

==== Supermini ESP32 ====
At first, I used a 'supermini'.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

The esp32-c3 supermini apparently has a design flaw causing it to run very hot:
* https://www.dailyduino.com/index.php/2026/01/20/the-spicy-esp32-c3-super-mini-when-2-boards-become-2-heaters/
* https://community.home-assistant.io/t/esp32-c3-supermini-getting-very-hot/980177/5
So in software you need to keep this in mind:
* lower the CPU frequency, makes a few degrees difference: this seems to make SSL network connections unreliable though
* allow some 'idle' time in Arduino, e.g. using delay(50) or delay(100) in loop()

==== WeAct ESP32-C3FH4 ====
I plan to try this as an alternative to the "supermini".

More info: https://github.com/WeActStudio/WeActStudio.ESP32C3CoreBoard

Is a larger board, has a PCB antenna instead of a chip antenna.
Unfortunately, this board does not have a user-controllable LED.

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

Its-g5

2026-08-30T21:24:46Z

Bertrik Sikken: /* WeAct ESP32-C3 */

Its-g5

2026-08-30T21:23:51Z

Bertrik Sikken: /* Bridge */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* Transmitting ITS-G5 signals? https://codeberg.org/opentrafficmap/its-g5-receiver-firmware_txenabled/src/branch/main/main/tx_custom.c Would be nice to have on your bicycle! :D

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages
* Power is provided to the esp32-c3, which then distributes power as raw 5V/GND to the esp32-c5. The esp32-c5 uses its own regulator to turn it into a stable internal supply voltage.

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
=== Sniffer ===
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board for the sniffer part:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

=== Bridge ===

An ESP32-C3 is used as the bridge part.

==== Supermini ESP32 ====
At first, I used a 'supermini'.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

The esp32-c3 supermini apparently has a design flaw causing it to run very hot:
* https://www.dailyduino.com/index.php/2026/01/20/the-spicy-esp32-c3-super-mini-when-2-boards-become-2-heaters/
* https://community.home-assistant.io/t/esp32-c3-supermini-getting-very-hot/980177/5
So in software you need to keep this in mind:
* lower the CPU frequency, makes a few degrees difference: this seems to make SSL network connections unreliable though
* allow some 'idle' time in Arduino, e.g. using delay(50) or delay(100) in loop()

==== WeAct ESP32-C3 ====
I plan to try this as an alternative to the "supermini".

Is a larger board, has a PCB antenna instead of a chip antenna.

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

MainsFrequency2.0

2026-08-26T14:01:40Z

Bertrik Sikken: Bertrik Sikken heeft pagina MainsFrequency2.0 hernoemd naar GridFrequency

#DOORVERWIJZING [[GridFrequency]]

GridFrequency

2026-08-26T14:01:40Z

Bertrik Sikken: Bertrik Sikken heeft pagina MainsFrequency2.0 hernoemd naar GridFrequency

{{Project
|Name=MainsFrequency2.0
|Picture=gridfrequency.jpg
|Omschrijving=A simple mains frequency counter
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
This project is a reboot of this [[MainsFrequency|earlier main frequency counter]], aiming for more accuracy and lower latency.

This has been achieved by using an ESP32c3 board with the 'phasing' algorithm described below.
No mains interfacing hardware is required, measurement data can be easily transferred using MQTT over a WiFi network.

=== Concept ===
Instead of just counting pulses from zero-crossings, we sample the actual 50 Hz waveform and try to estimate the zero-crossing as accurately as possible.

Desired end result:
* get more accurate frequency measurement, aiming for 1 milli-Hertz accuracy
* get more responsive frequency measurement, i.e. instantaneous value (1 second), not a running average over 50 seconds.

A suitable module for relatively safely sampling the mains voltage is this
[https://nl.aliexpress.com/item/1005001499454445.html ZMPT101B] module.
It contains a transformer and an op-amp circuit.

More information about this module:
* https://www.electroschematics.com/voltage-sensor/

=== Phasing algorithm ===
The algorithm is as follows:
* Sample the mains frequency waveform continuously at 5000 Hz
* Correlate each sample with a perfect 50 Hz reference waveform, by keeping a sum of the waveform multiplied by a cosine (I) and a sum of the waveform multiplied by a sine (Q)
* For each second, calculate the phase using the accumulated I and Q sums with atan2(Q, I).
* The change in phase during one second is directly proportional to the frequency deviation from the 50 Hz reference frequency

This results in:
* A continuous process, with a new frequency value every second
* The algorithm uses *all* of the data contained in one second (there is no single threshold value), thus producing a robust value
* Any DC offset in the mains frequency waveform is automatically balanced out, no need to keep track of the median or quartile values

=== Zero cross algoritm (old idea) ===
This is my older idea for an algorithm to get accurate instantaneous frequency:
* During approximately 100 ms, sample the mains frequency waveform and store it in a buffer.
* Calculate the median, lower and upper quartiles of the waveform amplitude data
* During approximately 1000 ms, sample the waveform and apply a linear regression algorithm on the waveform value (shifted by the median value)
* The linear regression algorithm is active in between the lower and higher quartile values and calculates an interpolated zero crossing of the waveform (with sub-sample resolution)
* Keep track of the first and the 50th interpolated zero-crossing time, then calculate the frequency from the time difference
-> this should give about 1 millihertz frequency resolution in one second

== Visualisation ==
There are (at least) the following two ways we can output the data:
* publish frequency as a number over WiFi / MQTT for visualization as a graph-over-time on our grafana server
* idea: directly on a LED ring. The ring shows an integer number (e.g.) of 50 Hz cycles, with the color of the pixel indicating the analog value
* just show the relative phase angle on the LED ring, this could be a single bright pixel for the latest phase measurement and progressively dimmer pixels for older phase measurements.

=== Analog panel meter ===
Get a basic panel voltage meter, make sure of the following:
* it measures *DC voltage*
* range is *3V*
Typically sold as "85c1-v" 3V DC.

=== Mains waveform ring ===
Concepts:
* The LED ring shows the raw waveform over time. Position along the ring is time, intensity/color is based on the instantaneous value of the mains voltage. So (for example) three 50 Hz cycles show up as 3 dark spots and 3 light spots around the ring, approximately 120 degrees apart. Basically it shows the phase compared to a reference 50 Hz frequency.
* The LED ring is drawn based on a reference time (derived from the crystal oscillator), assumed to be exactly 50 Hz. A slightly fast mains waveform results in a clockwise rotation of the waveform pattern, a slightly slow mains waveform results in a counter-clockwise rotation of the waveform pattern.
* Use a colourful gradient, not just intensity. Example: https://github.com/FastLED/FastLED/wiki/Gradient-color-palettes

Calculation:
* Mains frequency is nominally 50 Hz, so period is 20 ms (0.02 sec)
* With three waveforms around the ring, the ring represents 60 ms of mains signal
* Intended LED ring has 24 RGB LEDs, so 60ms / 24 LEDs = 2.5 ms per LED. So we could sample the waveform at 400 Hz, and put 1 sample on each LED.
* Example: 16 LED ring -> sample frequency 266.66.. Hz, or sample at 800 Hz and average 3 samples/LED
* Example: 40 LED ring -> sample frequency 666.66.. Hz, or sample at 2000 Hz and average 3 samples/LED
* Example: 45 LED ring -> sample frequency 750 Hz
* Example: 60 LED ring -> sample frequency 1000 Hz

== Hardware ==
[[File:luatos_esp32c3_pinout.png|right|thumb|ESP32c3 luatos board pinout]]

=== Luatos ESP32C3 ===
This module (I recommend the one with serial chip) seems to work quite well so far:
* Senses mains waveform from surroundings with just a wire into its ADC input, using the 'phase' software algorithm
* Clock crystal appears to be accurate, ESP32c3 datasheet claims it requires a 10 ppm crystal (or 0.5 mHz at 50Hz). Measured value corresponds to https://mainsfrequency.com
* Has WiFi, works with WifiManager library, so can easily push measurements to MQTT over WiFi for example
* Inexpensive, only 3 euros or so

The ADC1/UART1 RX pin is the input for 50 Hz. You can just leave that unconnected and it will pick up 50 Hz, or perhaps connect a short piece (20 cm or so) of wire to it.

=== Using ZMPT101B (old idea) ===
For measurement with an ESP8266, like a Wemos D1 mini or nodemcu, you need to put a 180k ohm resistor in line with the output from the ZMPT101B to the A0 input.
The A0 input already has a 220k/100k resistive divider, effectively becoming a 400k/100k resistive divider with the series resistor, scaling down the 0-5V range to the 0-1V range required for the ADC on the ESP8266.

The "blue pill" seems to have too low accuracy of the built-in crystal, about 100 ppm, while we need about 20 ppm to get 1 mHz resolution. Notes about blue pill crystal accuracy:
https://sparklogic.ru/arduino-for-stm32/accurate-blue-pill-clock-frequency-adjustment.html

{| class="wikitable"
|+Connections
|-
!ZMPT101B
!Wemos D1 mini
!Remark
|-
|GND
|GND
|Ground
|-
|VCC
|5V
|Powers the ZMPT101B from the wemos D1 mini
|-
|OUT
|A0
|Analog mains waveform, 0..5V, 180 kohm resistor in series
|}

== Software ==
New github project: https://github.com/bertrik/GridFrequency

To flash the esp32c3 board:
* Clone the code from github:
git clone https://github.com/bertrik/GridFrequency
cd GridFrequency
* Set up a python virtual environment and install platformio
python3 -m venv .venv
source .venv/bin/activate
pip3 install platformio
* Connect the board, compile and upload
pio run -t upload
* Connect over WiFi to the access point inside the ESP32
* Configure your WiFi credentials on 192.168.4.1
* Connect with serial terminal, to watch frequency measurements
pio device monitor

== Integration into revspace sensor infrastructure ==
There is a measurement device present at revspace (above the green tool board). It sends frequency data to the revspace MQTT server once every 5 seconds.

Processing of this data into something that our grafana can display is unfortunately broken (is that documented somewhere anyway!?), see:
https://revspace.nl/grafiekjes/d/3deykmVmz/power?orgId=1&refresh=1m

You can watch the data (using mosquitto for example):
mosquitto_sub -h revspace.nl -t revspace/sensors/ac/frequency -v
Example data:
topic = "revspace/sensors/ac/frequency", payload = "50.025 Hz" (retained)

In the #revspace IRC channel, you can issue a command to show the most recently known value:
!netfrequentie
(where is the script that handles this?)
Example data:
23:00 <@bertrik> !netfrequentie
23:00 <@bar> bertrik: 49.898 Hz

Bestand:Gridfrequency.jpg

2026-08-26T13:21:33Z

Bertrik Sikken:

GridFrequency

2026-08-26T13:21:22Z

Bertrik Sikken:

GridFrequency

2026-08-26T13:13:17Z

Bertrik Sikken: /* Analog panel meter */

{{Project
|Name=MainsFrequency2.0
|Picture=ZMPT101B.png
|Omschrijving=A simple mains frequency counter
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
This project is a reboot of this [[MainsFrequency|earlier main frequency counter]], aiming for more accuracy and lower latency.

This has been achieved by using an ESP32c3 board with the 'phasing' algorithm described below.
No mains interfacing hardware is required, measurement data can be easily transferred using MQTT over a WiFi network.

=== Concept ===
Instead of just counting pulses from zero-crossings, we sample the actual 50 Hz waveform and try to estimate the zero-crossing as accurately as possible.

Desired end result:
* get more accurate frequency measurement, aiming for 1 milli-Hertz accuracy
* get more responsive frequency measurement, i.e. instantaneous value (1 second), not a running average over 50 seconds.

A suitable module for relatively safely sampling the mains voltage is this
[https://nl.aliexpress.com/item/1005001499454445.html ZMPT101B] module.
It contains a transformer and an op-amp circuit.

More information about this module:
* https://www.electroschematics.com/voltage-sensor/

=== Phasing algorithm ===
The algorithm is as follows:
* Sample the mains frequency waveform continuously at 5000 Hz
* Correlate each sample with a perfect 50 Hz reference waveform, by keeping a sum of the waveform multiplied by a cosine (I) and a sum of the waveform multiplied by a sine (Q)
* For each second, calculate the phase using the accumulated I and Q sums with atan2(Q, I).
* The change in phase during one second is directly proportional to the frequency deviation from the 50 Hz reference frequency

This results in:
* A continuous process, with a new frequency value every second
* The algorithm uses *all* of the data contained in one second (there is no single threshold value), thus producing a robust value
* Any DC offset in the mains frequency waveform is automatically balanced out, no need to keep track of the median or quartile values

=== Zero cross algoritm (old idea) ===
This is my older idea for an algorithm to get accurate instantaneous frequency:
* During approximately 100 ms, sample the mains frequency waveform and store it in a buffer.
* Calculate the median, lower and upper quartiles of the waveform amplitude data
* During approximately 1000 ms, sample the waveform and apply a linear regression algorithm on the waveform value (shifted by the median value)
* The linear regression algorithm is active in between the lower and higher quartile values and calculates an interpolated zero crossing of the waveform (with sub-sample resolution)
* Keep track of the first and the 50th interpolated zero-crossing time, then calculate the frequency from the time difference
-> this should give about 1 millihertz frequency resolution in one second

== Visualisation ==
There are (at least) the following two ways we can output the data:
* publish frequency as a number over WiFi / MQTT for visualization as a graph-over-time on our grafana server
* idea: directly on a LED ring. The ring shows an integer number (e.g.) of 50 Hz cycles, with the color of the pixel indicating the analog value
* just show the relative phase angle on the LED ring, this could be a single bright pixel for the latest phase measurement and progressively dimmer pixels for older phase measurements.

=== Analog panel meter ===
Get a basic panel voltage meter, make sure of the following:
* it measures *DC voltage*
* range is *3V*
Typically sold as "85c1-v" 3V DC.

=== Mains waveform ring ===
Concepts:
* The LED ring shows the raw waveform over time. Position along the ring is time, intensity/color is based on the instantaneous value of the mains voltage. So (for example) three 50 Hz cycles show up as 3 dark spots and 3 light spots around the ring, approximately 120 degrees apart. Basically it shows the phase compared to a reference 50 Hz frequency.
* The LED ring is drawn based on a reference time (derived from the crystal oscillator), assumed to be exactly 50 Hz. A slightly fast mains waveform results in a clockwise rotation of the waveform pattern, a slightly slow mains waveform results in a counter-clockwise rotation of the waveform pattern.
* Use a colourful gradient, not just intensity. Example: https://github.com/FastLED/FastLED/wiki/Gradient-color-palettes

Calculation:
* Mains frequency is nominally 50 Hz, so period is 20 ms (0.02 sec)
* With three waveforms around the ring, the ring represents 60 ms of mains signal
* Intended LED ring has 24 RGB LEDs, so 60ms / 24 LEDs = 2.5 ms per LED. So we could sample the waveform at 400 Hz, and put 1 sample on each LED.
* Example: 16 LED ring -> sample frequency 266.66.. Hz, or sample at 800 Hz and average 3 samples/LED
* Example: 40 LED ring -> sample frequency 666.66.. Hz, or sample at 2000 Hz and average 3 samples/LED
* Example: 45 LED ring -> sample frequency 750 Hz
* Example: 60 LED ring -> sample frequency 1000 Hz

== Hardware ==
[[File:luatos_esp32c3_pinout.png|right|thumb|ESP32c3 luatos board pinout]]

=== Luatos ESP32C3 ===
This module (I recommend the one with serial chip) seems to work quite well so far:
* Senses mains waveform from surroundings with just a wire into its ADC input, using the 'phase' software algorithm
* Clock crystal appears to be accurate, ESP32c3 datasheet claims it requires a 10 ppm crystal (or 0.5 mHz at 50Hz). Measured value corresponds to https://mainsfrequency.com
* Has WiFi, works with WifiManager library, so can easily push measurements to MQTT over WiFi for example
* Inexpensive, only 3 euros or so

The ADC1/UART1 RX pin is the input for 50 Hz. You can just leave that unconnected and it will pick up 50 Hz, or perhaps connect a short piece (20 cm or so) of wire to it.

=== Using ZMPT101B (old idea) ===
For measurement with an ESP8266, like a Wemos D1 mini or nodemcu, you need to put a 180k ohm resistor in line with the output from the ZMPT101B to the A0 input.
The A0 input already has a 220k/100k resistive divider, effectively becoming a 400k/100k resistive divider with the series resistor, scaling down the 0-5V range to the 0-1V range required for the ADC on the ESP8266.

The "blue pill" seems to have too low accuracy of the built-in crystal, about 100 ppm, while we need about 20 ppm to get 1 mHz resolution. Notes about blue pill crystal accuracy:
https://sparklogic.ru/arduino-for-stm32/accurate-blue-pill-clock-frequency-adjustment.html

{| class="wikitable"
|+Connections
|-
!ZMPT101B
!Wemos D1 mini
!Remark
|-
|GND
|GND
|Ground
|-
|VCC
|5V
|Powers the ZMPT101B from the wemos D1 mini
|-
|OUT
|A0
|Analog mains waveform, 0..5V, 180 kohm resistor in series
|}

== Software ==
New github project: https://github.com/bertrik/GridFrequency

To flash the esp32c3 board:
* Clone the code from github:
git clone https://github.com/bertrik/GridFrequency
cd GridFrequency
* Set up a python virtual environment and install platformio
python3 -m venv .venv
source .venv/bin/activate
pip3 install platformio
* Connect the board, compile and upload
pio run -t upload
* Connect over WiFi to the access point inside the ESP32
* Configure your WiFi credentials on 192.168.4.1
* Connect with serial terminal, to watch frequency measurements
pio device monitor

== Integration into revspace sensor infrastructure ==
There is a measurement device present at revspace (above the green tool board). It sends frequency data to the revspace MQTT server once every 5 seconds.

Processing of this data into something that our grafana can display is unfortunately broken (is that documented somewhere anyway!?), see:
https://revspace.nl/grafiekjes/d/3deykmVmz/power?orgId=1&refresh=1m

You can watch the data (using mosquitto for example):
mosquitto_sub -h revspace.nl -t revspace/sensors/ac/frequency -v
Example data:
topic = "revspace/sensors/ac/frequency", payload = "50.025 Hz" (retained)

In the #revspace IRC channel, you can issue a command to show the most recently known value:
!netfrequentie
(where is the script that handles this?)
Example data:
23:00 <@bertrik> !netfrequentie
23:00 <@bar> bertrik: 49.898 Hz

GridFrequency

2026-08-26T12:34:09Z

Bertrik Sikken: /* Visualisation */

{{Project
|Name=MainsFrequency2.0
|Picture=ZMPT101B.png
|Omschrijving=A simple mains frequency counter
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
This project is a reboot of this [[MainsFrequency|earlier main frequency counter]], aiming for more accuracy and lower latency.

This has been achieved by using an ESP32c3 board with the 'phasing' algorithm described below.
No mains interfacing hardware is required, measurement data can be easily transferred using MQTT over a WiFi network.

=== Concept ===
Instead of just counting pulses from zero-crossings, we sample the actual 50 Hz waveform and try to estimate the zero-crossing as accurately as possible.

Desired end result:
* get more accurate frequency measurement, aiming for 1 milli-Hertz accuracy
* get more responsive frequency measurement, i.e. instantaneous value (1 second), not a running average over 50 seconds.

A suitable module for relatively safely sampling the mains voltage is this
[https://nl.aliexpress.com/item/1005001499454445.html ZMPT101B] module.
It contains a transformer and an op-amp circuit.

More information about this module:
* https://www.electroschematics.com/voltage-sensor/

=== Phasing algorithm ===
The algorithm is as follows:
* Sample the mains frequency waveform continuously at 5000 Hz
* Correlate each sample with a perfect 50 Hz reference waveform, by keeping a sum of the waveform multiplied by a cosine (I) and a sum of the waveform multiplied by a sine (Q)
* For each second, calculate the phase using the accumulated I and Q sums with atan2(Q, I).
* The change in phase during one second is directly proportional to the frequency deviation from the 50 Hz reference frequency

This results in:
* A continuous process, with a new frequency value every second
* The algorithm uses *all* of the data contained in one second (there is no single threshold value), thus producing a robust value
* Any DC offset in the mains frequency waveform is automatically balanced out, no need to keep track of the median or quartile values

=== Zero cross algoritm (old idea) ===
This is my older idea for an algorithm to get accurate instantaneous frequency:
* During approximately 100 ms, sample the mains frequency waveform and store it in a buffer.
* Calculate the median, lower and upper quartiles of the waveform amplitude data
* During approximately 1000 ms, sample the waveform and apply a linear regression algorithm on the waveform value (shifted by the median value)
* The linear regression algorithm is active in between the lower and higher quartile values and calculates an interpolated zero crossing of the waveform (with sub-sample resolution)
* Keep track of the first and the 50th interpolated zero-crossing time, then calculate the frequency from the time difference
-> this should give about 1 millihertz frequency resolution in one second

== Visualisation ==
There are (at least) the following two ways we can output the data:
* publish frequency as a number over WiFi / MQTT for visualization as a graph-over-time on our grafana server
* idea: directly on a LED ring. The ring shows an integer number (e.g.) of 50 Hz cycles, with the color of the pixel indicating the analog value
* just show the relative phase angle on the LED ring, this could be a single bright pixel for the latest phase measurement and progressively dimmer pixels for older phase measurements.

=== Analog panel meter ===
Get a basic panel voltage meter, make sure of the following:
* it measures DC *voltage*
* range is *3V*
Typically sold as "85c1-v" 3V DC.

=== Mains waveform ring ===
Concepts:
* The LED ring shows the raw waveform over time. Position along the ring is time, intensity/color is based on the instantaneous value of the mains voltage. So (for example) three 50 Hz cycles show up as 3 dark spots and 3 light spots around the ring, approximately 120 degrees apart. Basically it shows the phase compared to a reference 50 Hz frequency.
* The LED ring is drawn based on a reference time (derived from the crystal oscillator), assumed to be exactly 50 Hz. A slightly fast mains waveform results in a clockwise rotation of the waveform pattern, a slightly slow mains waveform results in a counter-clockwise rotation of the waveform pattern.
* Use a colourful gradient, not just intensity. Example: https://github.com/FastLED/FastLED/wiki/Gradient-color-palettes

Calculation:
* Mains frequency is nominally 50 Hz, so period is 20 ms (0.02 sec)
* With three waveforms around the ring, the ring represents 60 ms of mains signal
* Intended LED ring has 24 RGB LEDs, so 60ms / 24 LEDs = 2.5 ms per LED. So we could sample the waveform at 400 Hz, and put 1 sample on each LED.
* Example: 16 LED ring -> sample frequency 266.66.. Hz, or sample at 800 Hz and average 3 samples/LED
* Example: 40 LED ring -> sample frequency 666.66.. Hz, or sample at 2000 Hz and average 3 samples/LED
* Example: 45 LED ring -> sample frequency 750 Hz
* Example: 60 LED ring -> sample frequency 1000 Hz

== Hardware ==
[[File:luatos_esp32c3_pinout.png|right|thumb|ESP32c3 luatos board pinout]]

=== Luatos ESP32C3 ===
This module (I recommend the one with serial chip) seems to work quite well so far:
* Senses mains waveform from surroundings with just a wire into its ADC input, using the 'phase' software algorithm
* Clock crystal appears to be accurate, ESP32c3 datasheet claims it requires a 10 ppm crystal (or 0.5 mHz at 50Hz). Measured value corresponds to https://mainsfrequency.com
* Has WiFi, works with WifiManager library, so can easily push measurements to MQTT over WiFi for example
* Inexpensive, only 3 euros or so

The ADC1/UART1 RX pin is the input for 50 Hz. You can just leave that unconnected and it will pick up 50 Hz, or perhaps connect a short piece (20 cm or so) of wire to it.

=== Using ZMPT101B (old idea) ===
For measurement with an ESP8266, like a Wemos D1 mini or nodemcu, you need to put a 180k ohm resistor in line with the output from the ZMPT101B to the A0 input.
The A0 input already has a 220k/100k resistive divider, effectively becoming a 400k/100k resistive divider with the series resistor, scaling down the 0-5V range to the 0-1V range required for the ADC on the ESP8266.

The "blue pill" seems to have too low accuracy of the built-in crystal, about 100 ppm, while we need about 20 ppm to get 1 mHz resolution. Notes about blue pill crystal accuracy:
https://sparklogic.ru/arduino-for-stm32/accurate-blue-pill-clock-frequency-adjustment.html

{| class="wikitable"
|+Connections
|-
!ZMPT101B
!Wemos D1 mini
!Remark
|-
|GND
|GND
|Ground
|-
|VCC
|5V
|Powers the ZMPT101B from the wemos D1 mini
|-
|OUT
|A0
|Analog mains waveform, 0..5V, 180 kohm resistor in series
|}

== Software ==
New github project: https://github.com/bertrik/GridFrequency

To flash the esp32c3 board:
* Clone the code from github:
git clone https://github.com/bertrik/GridFrequency
cd GridFrequency
* Set up a python virtual environment and install platformio
python3 -m venv .venv
source .venv/bin/activate
pip3 install platformio
* Connect the board, compile and upload
pio run -t upload
* Connect over WiFi to the access point inside the ESP32
* Configure your WiFi credentials on 192.168.4.1
* Connect with serial terminal, to watch frequency measurements
pio device monitor

== Integration into revspace sensor infrastructure ==
There is a measurement device present at revspace (above the green tool board). It sends frequency data to the revspace MQTT server once every 5 seconds.

Processing of this data into something that our grafana can display is unfortunately broken (is that documented somewhere anyway!?), see:
https://revspace.nl/grafiekjes/d/3deykmVmz/power?orgId=1&refresh=1m

You can watch the data (using mosquitto for example):
mosquitto_sub -h revspace.nl -t revspace/sensors/ac/frequency -v
Example data:
topic = "revspace/sensors/ac/frequency", payload = "50.025 Hz" (retained)

In the #revspace IRC channel, you can issue a command to show the most recently known value:
!netfrequentie
(where is the script that handles this?)
Example data:
23:00 <@bertrik> !netfrequentie
23:00 <@bar> bertrik: 49.898 Hz

Its-g5

2026-08-25T09:07:17Z

Bertrik Sikken: /* Bridge */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* Transmitting ITS-G5 signals? https://codeberg.org/opentrafficmap/its-g5-receiver-firmware_txenabled/src/branch/main/main/tx_custom.c Would be nice to have on your bicycle! :D

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages
* Power is provided to the esp32-c3, which then distributes power as raw 5V/GND to the esp32-c5. The esp32-c5 uses its own regulator to turn it into a stable internal supply voltage.

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
=== Sniffer ===
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board for the sniffer part:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

=== Bridge ===
An ESP32-C3 is used as the bridge part. I used a 'supermini'.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

The esp32-c3 supermini apparently has a design flaw causing it to run very hot:
* https://www.dailyduino.com/index.php/2026/01/20/the-spicy-esp32-c3-super-mini-when-2-boards-become-2-heaters/
* https://community.home-assistant.io/t/esp32-c3-supermini-getting-very-hot/980177/5
So in software you need to keep this in mind:
* lower the CPU frequency, makes a few degrees difference: this seems to make SSL network connections unreliable though
* allow some 'idle' time in Arduino, e.g. using delay(50) or delay(100) in loop()

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

Its-g5

2026-08-22T08:57:14Z

Bertrik Sikken: /* Bridge */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* Transmitting ITS-G5 signals? https://codeberg.org/opentrafficmap/its-g5-receiver-firmware_txenabled/src/branch/main/main/tx_custom.c Would be nice to have on your bicycle! :D

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages
* Power is provided to the esp32-c3, which then distributes power as raw 5V/GND to the esp32-c5. The esp32-c5 uses its own regulator to turn it into a stable internal supply voltage.

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
=== Sniffer ===
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board for the sniffer part:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

=== Bridge ===
An ESP32-C3 is used as the bridge part. I used a 'supermini'.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

The esp32-c3 supermini apparently has a design flaw causing them to run very hot:
* https://www.dailyduino.com/index.php/2026/01/20/the-spicy-esp32-c3-super-mini-when-2-boards-become-2-heaters/
* https://community.home-assistant.io/t/esp32-c3-supermini-getting-very-hot/980177/5
So in software you need to keep this in mind:
* lower the CPU frequency, makes a few degrees difference: this seems to make SSL network connections unreliable though
* allow some 'idle' time in Arduino, e.g. using delay(50) or delay(100) in loop()

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

Its-g5

2026-08-06T15:29:37Z

Bertrik Sikken: /* Introduction */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* Transmitting ITS-G5 signals? https://codeberg.org/opentrafficmap/its-g5-receiver-firmware_txenabled/src/branch/main/main/tx_custom.c Would be nice to have on your bicycle! :D

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages
* Power is provided to the esp32-c3, which then distributes power as raw 5V/GND to the esp32-c5. The esp32-c5 uses its own regulator to turn it into a stable internal supply voltage.

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
=== Sniffer ===
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board for the sniffer part:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

=== Bridge ===
An ESP32-C3 is used as the bridge part. I used a 'supermini'.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

The esp32-c3 supermini apparently has a design flaw causing them to run very hot:
* https://www.dailyduino.com/index.php/2026/01/20/the-spicy-esp32-c3-super-mini-when-2-boards-become-2-heaters/
So in software you need to keep this in mind:
* lower the CPU frequency, makes a few degrees difference: this seems to make SSL network connections unreliable though
* allow some 'idle' time in Arduino, e.g. using delay(50) or delay(100) in loop()

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

Its-g5

2026-07-30T10:47:24Z

Bertrik Sikken: /* Bridge */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages
* Power is provided to the esp32-c3, which then distributes power as raw 5V/GND to the esp32-c5. The esp32-c5 uses its own regulator to turn it into a stable internal supply voltage.

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
=== Sniffer ===
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board for the sniffer part:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

=== Bridge ===
An ESP32-C3 is used as the bridge part. I used a 'supermini'.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

The esp32-c3 supermini apparently has a design flaw causing them to run very hot:
* https://www.dailyduino.com/index.php/2026/01/20/the-spicy-esp32-c3-super-mini-when-2-boards-become-2-heaters/
So in software you need to keep this in mind:
* lower the CPU frequency, makes a few degrees difference: this seems to make SSL network connections unreliable though
* allow some 'idle' time in Arduino, e.g. using delay(50) or delay(100) in loop()

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

Its-g5

2026-07-30T10:47:04Z

Bertrik Sikken: /* Bridge */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages
* Power is provided to the esp32-c3, which then distributes power as raw 5V/GND to the esp32-c5. The esp32-c5 uses its own regulator to turn it into a stable internal supply voltage.

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
=== Sniffer ===
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board for the sniffer part:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

=== Bridge ===
An ESP32-C3 is used as the bridge part. I used a 'supermini'.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

The esp32-c3 supermini apparently has a design flaw causing them to run very hot:
* https://www.dailyduino.com/index.php/2026/01/20/the-spicy-esp32-c3-super-mini-when-2-boards-become-2-heaters/
So in software you need to keep this in mind:
* lower the CPU frequency, makes a few degrees difference: this seems to make SSL network connections unreliable though
* allow some 'idle' time in Arduino, e.g. using delay(50) or delay(100) in loop()

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

TPMS

2026-07-27T09:17:20Z

Bertrik Sikken: /* Software */

{{Project
|Name=CC1101 TPMS receiver
|Picture=whyunopicture.png
|Omschrijving=Receiving TPMS signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==

== Design ==
The plan is to use an CC1101 module, connect it to an ESP8266 and start receiving TPMS radio frames.

Example frame, as received:
22 30 61 07 E0 1D B9 39 F5
Analysis:
* byte 4: 0xE0 = wheel?
* bytes 5/6, bits 0-12 = 0xDB9 = 3513 hPa absolute -> about 2.5 bar above ambient pressure
* byte 7, 0x39 = 57 = temperature in Celcius?
* byte 8: 0xF5 = checksum?

See also https://github.com/merbanan/rtl_433/tree/master/src/devices and check for decoders starting with "tpms_".

== Hardware ==
[[File:cc1101-module.png|right|alt=CC1101 module]]

{| class="wikitable"
|+Connections
|-
!CC1101 module
!Wemos D1 mini
!Remark
|-
|1 Ground
|G
|Common ground
|-
|2 VCC
|3.3V
|Common power
|-
|3 GD0
|D1
|"IRQ" pin
|-
|4 CSN
|D8
|SPI Chip select (inv)
|-
|5 SCK
|D5
|SPI clock
|-
|6 MOSI
|D7
|SPI master out slave in
|-
|7 MISO
|D6
|SPI master in slave out
|-
|8 GDO2
|D2
|"GPIO" pin, probably unused
|}

== Software ==
My experiments at: https://github.com/bertrik/esp-tpms

See also:
https://github.com/andi38/TPMS/blob/main/CC1101_TPMS_433.ino

TPMS

2026-07-27T09:16:23Z

Bertrik Sikken: /* Design */

{{Project
|Name=CC1101 TPMS receiver
|Picture=whyunopicture.png
|Omschrijving=Receiving TPMS signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==

== Design ==
The plan is to use an CC1101 module, connect it to an ESP8266 and start receiving TPMS radio frames.

Example frame, as received:
22 30 61 07 E0 1D B9 39 F5
Analysis:
* byte 4: 0xE0 = wheel?
* bytes 5/6, bits 0-12 = 0xDB9 = 3513 hPa absolute -> about 2.5 bar above ambient pressure
* byte 7, 0x39 = 57 = temperature in Celcius?
* byte 8: 0xF5 = checksum?

See also https://github.com/merbanan/rtl_433/tree/master/src/devices and check for decoders starting with "tpms_".

== Hardware ==
[[File:cc1101-module.png|right|alt=CC1101 module]]

{| class="wikitable"
|+Connections
|-
!CC1101 module
!Wemos D1 mini
!Remark
|-
|1 Ground
|G
|Common ground
|-
|2 VCC
|3.3V
|Common power
|-
|3 GD0
|D1
|"IRQ" pin
|-
|4 CSN
|D8
|SPI Chip select (inv)
|-
|5 SCK
|D5
|SPI clock
|-
|6 MOSI
|D7
|SPI master out slave in
|-
|7 MISO
|D6
|SPI master in slave out
|-
|8 GDO2
|D2
|"GPIO" pin, probably unused
|}

== Software ==
See:
https://github.com/andi38/TPMS/blob/main/CC1101_TPMS_433.ino

TPMS

2026-07-27T09:13:45Z

Bertrik Sikken: /* Hardware */

{{Project
|Name=CC1101 TPMS receiver
|Picture=whyunopicture.png
|Omschrijving=Receiving TPMS signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==

== Design ==
The plan is to use an CC1101 module, connect it to an ESP8266 and start receiving TPMS radio frames.

Example frame, as received:
22 30 61 07 E0 1D B9 39 F5
Analysis:
* byte 4: 0xE0 = wheel?
* bytes 5/6, bits 0-12 = 0xDB9 = 3513 hPa absolute -> about 2.5 bar above ambient pressure
* byte 7, 0x39 = 57 = temperature in Celcius?
* byte 8: 0xF5 = checksum?

== Hardware ==
[[File:cc1101-module.png|right|alt=CC1101 module]]

{| class="wikitable"
|+Connections
|-
!CC1101 module
!Wemos D1 mini
!Remark
|-
|1 Ground
|G
|Common ground
|-
|2 VCC
|3.3V
|Common power
|-
|3 GD0
|D1
|"IRQ" pin
|-
|4 CSN
|D8
|SPI Chip select (inv)
|-
|5 SCK
|D5
|SPI clock
|-
|6 MOSI
|D7
|SPI master out slave in
|-
|7 MISO
|D6
|SPI master in slave out
|-
|8 GDO2
|D2
|"GPIO" pin, probably unused
|}

== Software ==
See:
https://github.com/andi38/TPMS/blob/main/CC1101_TPMS_433.ino

TPMS

2026-07-26T23:07:01Z

Bertrik Sikken: /* Hardware */

{{Project
|Name=CC1101 TPMS receiver
|Picture=whyunopicture.png
|Omschrijving=Receiving TPMS signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==

== Design ==
The plan is to use an CC1101 module, connect it to an ESP8266 and start receiving TPMS radio frames.

Example frame, as received:
22 30 61 07 E0 1D B9 39 F5
Analysis:
* byte 4: 0xE0 = wheel?
* bytes 5/6, bits 0-12 = 0xDB9 = 3513 hPa absolute -> about 2.5 bar above ambient pressure
* byte 7, 0x39 = 57 = temperature in Celcius?
* byte 8: 0xF5 = checksum?

== Hardware ==
[[File:cc1101-module.png|right|alt=CC1101 module]]

{| class="wikitable"
|+Connections
|-
!CC1101 module
!Wemos D1 mini
!Remark
|-
|1 Ground
|G
|Common ground
|-
|2 VCC
|3.3V
|Common power
|-
|3 GD0
|D1
|"GPIO" pin
|-
|4 CSN
|D8
|SPI Chip select (inv)
|-
|5 SCK
|D5
|SPI clock
|-
|6 MOSI
|D7
|SPI master out slave in
|-
|7 MISO
|D6
|SPI master in slave out
|-
|8 GDO2
|D2
|Interrupt, probably unused
|}

== Software ==
See:
https://github.com/andi38/TPMS/blob/main/CC1101_TPMS_433.ino

TPMS

2026-07-26T23:06:30Z

Bertrik Sikken: /* Hardware */

{{Project
|Name=CC1101 TPMS receiver
|Picture=whyunopicture.png
|Omschrijving=Receiving TPMS signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==

== Design ==
The plan is to use an CC1101 module, connect it to an ESP8266 and start receiving TPMS radio frames.

Example frame, as received:
22 30 61 07 E0 1D B9 39 F5
Analysis:
* byte 4: 0xE0 = wheel?
* bytes 5/6, bits 0-12 = 0xDB9 = 3513 hPa absolute -> about 2.5 bar above ambient pressure
* byte 7, 0x39 = 57 = temperature in Celcius?
* byte 8: 0xF5 = checksum?

== Hardware ==
[[File:cc1101-module.png|thumb|right|alt=CC1101 module]]

{| class="wikitable"
|+Connections
|-
!CC1101 module
!Wemos D1 mini
!Remark
|-
|1 Ground
|G
|Common ground
|-
|2 VCC
|3.3V
|Common power
|-
|3 GD0
|D1
|"GPIO" pin
|-
|4 CSN
|D8
|SPI Chip select (inv)
|-
|5 SCK
|D5
|SPI clock
|-
|6 MOSI
|D7
|SPI master out slave in
|-
|7 MISO
|D6
|SPI master in slave out
|-
|8 GDO2
|D2
|Interrupt, probably unused
|}

== Software ==
See:
https://github.com/andi38/TPMS/blob/main/CC1101_TPMS_433.ino

TPMS

2026-07-26T22:52:42Z

Bertrik Sikken: /* Design */

{{Project
|Name=CC1101 TPMS receiver
|Picture=whyunopicture.png
|Omschrijving=Receiving TPMS signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==

== Design ==
The plan is to use an CC1101 module, connect it to an ESP8266 and start receiving TPMS radio frames.

Example frame, as received:
22 30 61 07 E0 1D B9 39 F5
Analysis:
* byte 4: 0xE0 = wheel?
* bytes 5/6, bits 0-12 = 0xDB9 = 3513 hPa absolute -> about 2.5 bar above ambient pressure
* byte 7, 0x39 = 57 = temperature in Celcius?
* byte 8: 0xF5 = checksum?

== Hardware ==
[[File:cc1101-module.png|thumb|right|alt=CC1101 module]]

{| class="wikitable"
|+Connections
|-
!CC1101 module
!Wemos D1 mini
!Remark
|-
|1 Ground
|G
|Common ground
|-
|2 VCC
|3.3V
|Common power
|-
|3 GD0
|D1
|"GPIO" pin
|-
|4 CSN
|D8
|Chip select (inv)
|-
|5 SCK
|D5
|SPI clock
|-
|6 MOSI
|D7
|SPI master out slave in
|-
|7 MISO
|D6
|SPI master in slave out
|-
|8 GDO2
|D2
|Interrupt, probably unused
|}

== Software ==
See:
https://github.com/andi38/TPMS/blob/main/CC1101_TPMS_433.ino

TPMS

2026-07-26T22:48:11Z

Bertrik Sikken: /* Design */

TPMS

2026-07-26T22:47:46Z

Bertrik Sikken:

TPMS

2026-07-26T22:46:27Z

Bertrik Sikken: /* Hardware */

{{Project
|Name=CC1101 TPMS receiver
|Picture=nopicture.png
|Omschrijving=Receiving TPMS signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==

== Design ==
The plan is to use an CC1101 module, connect it to an ESP and start receiving TPMS radio frames.

== Hardware ==
[[File:cc1101-module.png|thumb|right|alt=CC1101 module]]

{| class="wikitable"
|+Connections
|-
!CC1101 module
!Wemos D1 mini
!Remark
|-
|1 Ground
|G
|Common ground
|-
|2 VCC
|3.3V
|Common power
|-
|3 GD0
|D1
|"GPIO" pin
|-
|4 CSN
|D8
|Chip select (inv)
|-
|5 SCK
|D5
|SPI clock
|-
|6 MOSI
|D7
|SPI master out slave in
|-
|7 MISO
|D6
|SPI master in slave out
|-
|8 GDO2
|D2
|Interrupt, probably unused
|}

== Software ==
See:
https://github.com/andi38/TPMS/blob/main/CC1101_TPMS_433.ino

TPMS

2026-07-26T16:59:23Z

Bertrik Sikken:

TPMS

2026-07-25T15:55:15Z

Bertrik Sikken:

TPMS

2026-07-25T15:54:32Z

Bertrik Sikken: /* TPMS receiver */

{{Project
|Name=CC1101 TPMS receiver
|Picture=nopicture.png
|Omschrijving=Receiving TPMS signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==

== Hardware ==
[[File:cc1101-module.png|thumb|right|alt=CC1101 module]]

Bestand:Cc1101-module.png

2026-07-25T15:53:36Z

Bertrik Sikken:

TPMS

2026-07-25T15:53:24Z

Bertrik Sikken: /* TPMS receiver */

== TPMS receiver ==
[[File:cc1101-module.png|thumb|right|alt=CC1101 module]]

TPMS

2026-07-25T15:52:39Z

Bertrik Sikken: Nieuwe pagina aangemaakt met '== TPMS receiver == alt=CC1101 module'

== TPMS receiver ==
[[File:cc101.jpg|thumb|right|alt=CC1101 module]]

Meshcore

2026-07-25T14:12:45Z

Bertrik Sikken:

{{Project
|Name=MeshCore
|Status=In progress
|Picture=Meshtower.png
|Contact=Bas
|Contact1=Anne Jan
|Contact2=Paul
}}

{{Event
|Name=Workshop/Lecture MeshCore
|DateStart=29 November 2025 15:00
|DateEnd=29 November 2025 18:00
|Info=Lecture/Workshop about MeshCore
|InfoLocation=RevSpace
|InfoOpen=12:30
}}

= Revspace meshcore repeater =
Er is een Revspace meshcore repeater, type [https://heltec.org/project/meshtower/ MeshTower], gegevens per 2026-7-xx:
* Fysiek staat ie bovenop de kast rechts naast de bar
* Geconfigureerd met settings volgens https://meshcore.envoyage.io/configurator/
* Firmware 1.16
* SF7/CR5
* 2-byte hashes (mode 1) + regio scopes
* -Naam "RevSpace", password bekend bij [[Bertrik]] en [[Crashjuh]]-

Nieuwe firmware flashen:
* Schroef het kastje open
* Steek een kabel in de USB-C van de meshtower en het andere eind in je computer
* Ergens naast de USB-C connector zit een klein knopje (reset of RST), druk die 2x kort in (binnen 1 seconde)
* Op je computer zie je een USB drive verschijnen, de meshtower is nu in bootloader mode
* Flash een firmware via de web interface van https://meshcore.co.uk/flasher.html , kies "Heltec MeshSolar / MeshTower", kies rol repeater.

Configureren:
* Via de browser lukte mij niet
* Uiteindelijk geconfigureerd via USB-seriele poort console:
<pre>
screen /dev/ttyACM0 115200
</pre>

In seriele poort console kan je commando's intypen zoals:
<pre>
Radio instellingen (EU868): set radio 869.618,62.5,7,5
Advert interval: set advert.interval 180
Flood advert interval: set flood.advert.interval 50
Naam: set name RevSpace
Eigenaar: set owner.info bertrik@gmail.com
Latitude: set lat 52.0862
Longitude: set lon 4.3947
RX delay: set rxdelay 0.0
TX delay: set txdelay 0.5
Interference threshold: set int.thresh 1
Max hop count: set flood.max 48
TX power: set tx 22
EU regio aanmaken: region put eu
Land regio aanmaken: region put nl
Provincie regio aanmaken: region put nl-zh nl
Bredere regio 1 aanmaken: region put nl-hag nl
Bredere regio 2 aanmaken: region put nl-lid nl
Gemeente regio aanmaken: region put nl-zh-lsv nl-zh
Plaats regio aanmaken: region put nl-zh-lds nl-zh
Flood toestaan: EU: region allowf eu
Flood toestaan: land: region allowf nl
Flood toestaan: provincie: region allowf nl-zh
Flood toestaan: bredere regio 1: region allowf nl-hag
Flood toestaan: bredere regio 2: region allowf nl-lid
Flood toestaan: gemeente: region allowf nl-zh-lsv
Flood toestaan: plaats: region allowf nl-zh-lds
Standaardregio (provincie): region default nl-zh
Thuisregio: region home nl-zh-lds
Regio's opslaan: region save
Path hash mode: set path.hash.mode 1
Loop detectie: set loop.detect moderate
Duty cycle: set dutycycle 10
Admin wachtwoord: password ***
Herstarten: reboot
</pre>

=Workshop=
Een introductie in MeshCore en als je een compatible apparaatje meeneemt (wij hebben ook een aantal mee, dus geen aankoopplicht ;) ): tevens een workshop om er mee te beginnen!

Heb je eerder dit jaar tijdens het Hackerhotel een Meshtastic kitje aangeschaft, maar niets meer met je Meshtastic gedaan? Dan is dat kitje met Heltec V3 een prima starter bij deze MeshCore workshop.

Je kunt eventueel een Heltec V3 meebestellen voor 25 euro incl btw. Zet dat dan even in de tabel hieronder erbij. Maar je mag natuurlijk ook je eigen spul meenemen.

==Inhoud==
* Wat is MeshCore
* Waarom is het leuk
* Verschillende rollen
* Hardware (en hoe het uit de hand loopt)
* Configuratie
* Demo
* Speeltijd en hulp met het werkend krijgen.

https://pad.bitlair.nl/p/lora

https://docs.google.com/presentation/d/1h6CC3s-rCDkTylBscA9Ky0ZhBM5mxv8rZMoFVbLMzFs/edit?usp=sharing

==Aanmelden==
Let op: we kunnen maximaal 20 deelnemers huisvesten en begeleiden.

Je kunt geen Heltec v3 meer meebestellen. Hij is zonder case nog wel leverbaar via TinyTronics: https://www.tinytronics.nl/nl/development-boards/microcontroller-boards/met-lora/heltec-wi-fi-lora-32-esp32-s3-sx1262-met-0.96-inch-oled-display

{| class="wikitable"
|+ Bijschrift
|-
! Naam !! Meebestellen Heltec V3 !! Betaald?
|-
| Wheeze_NL || Nee || .
|-
| Crashjuh || Nee || .
|-
| polyfloyd || Nee || .
|-
| Colomax || 2x || ja
|-
| Atoomnet || Nee || .
|-
| blaat || 1x || ja
|-
| Lukkie || 1x || ja
|-
| Wilbert || nee || .
|-
| CH23 || nee || .
|-
| TeQ || nee || .
|-
| Kartoffel || nee
|-
| Ries || ja || .
|-
| Gori || nee || .
|-
| Dimi || nee || .
|-
| Muad-Dib || nee || .
|-
| florian || nee || .
|-
| Colomax + 1 || nee || .
|-
| FooBar || nee || .
|-
| - || - || .

|}

=Inkoopactie voor een Meshcore Router op de space=

We willen de https://heltec.org/project/meshtower/ MeshTower van Heltec. Er is al MeshCore firmware voor.

{| class="wikitable"
|+ Bijschrift
|-
! Wie !! Hoeveel tientjes !! Betaald?
|-
| Bas || 2 || ja
|-
| CH23 || 2 || ja
|-
| Wilbert || 2 || ja
|-
| Crashjuh || 3 || ja
|-
| Elborro || 2 || ja
|-
| sting || 1 || ja
|-
| Colomax || 1 || ja
|-
| Wheeze_NL || 1 || ja
|-
| Boekenwuurm || 1 || nee
|-
| thomas || 1 || ja
|-
| jelle || 2 || ja
|-
| Lukkie || 2 || ja
|-
| cmpxchg || 1 || nee
|-

| Voorbeeld || Voorbeeld || Voorbeeld
|}

Totaal: 200 euro van de 200 euro

Wil je ook een MeshTower meebestellen of iets anders van HelTec? Dat kan, zet het hieronder jouw bestelling. Met meerdere MeshTowers zakt de prijs van 230 euro per stuk naar ongeveer 200!

{| class="wikitable"
|+ Bijschrift
|-
! Wie !! Wat !! Totaal ex verzenden in $ !! Totaal berekend door Bas incl verzenden !! Betaald?
|-
| RandomData (via Bas)|| 1x MeshTower|| .|| 200|| Ja
|-
| Bas || 1x Heltec V4 || .|| x || Ja
|-
| Bart Jan (RandomData) || 1x MeshTower ||.||200||Ja
|-
| Lukkie || 1x MeshTower || .||200||Ja
|-
| BlackDragon || 1x Heltec V4 || 20 || 25 || ja
|-
| Wheeze_NL || 1x Heltec V4 || 20 || ?? || ja
|-
| HS Nijmegen via Bas || 1x MeshTower ||.||200||Ja
|-
| cmpxchg || 1x MeshTower ||.||200|| ja
|-
| Synq || 1x MeshTower, 1x V3||.||225||Ja
|-
| Elborro || 1x MeshTower ||.||200||Ja
|-
| Dimi || 1x MeshTower ||.||200||Ja
|-
|}

De inkoopactie is gesloten. Alle hardware is besteld (9x MeshTower, 6x V3 en 3x V4).

Meshcore

2026-07-13T14:26:52Z

Bertrik Sikken: /* Revspace meshcore repeater */

{{Project
|Name=MeshCore
|Status=In progress
|Picture=Meshtower.png
|Contact=Bas
|Contact1=Anne Jan
|Contact2=Paul
}}

{{Event
|Name=Workshop/Lecture MeshCore
|DateStart=29 November 2025 15:00
|DateEnd=29 November 2025 18:00
|Info=Lecture/Workshop about MeshCore
|InfoLocation=RevSpace
|InfoOpen=12:30
}}

= Revspace meshcore repeater =
Er is een Revspace meshcore repeater, type [https://heltec.org/project/meshtower/ MeshTower], gegevens per 2026-6-6:
* Fysiek staat ie bovenop de kast rechts naast de bar
* Geconfigureerd met settings volgens https://meshcore.envoyage.io/configurator/
* Firmware 1.15
* SF7/CR5
* 2-byte hashes (mode 1) + regio scopes
* Naam "RevSpace", password bekend bij [[Bertrik]] en [[Crashjuh]]

Nieuwe firmware flashen:
* Schroef het kastje open
* Steek een kabel in de USB-C van de meshtower en het andere eind in je computer
* Ergens naast de USB-C connector zit een klein knopje (reset of RST), druk die 2x kort in (binnen 1 seconde)
* Op je computer zie je een USB drive verschijnen, de meshtower is nu in bootloader mode
* Flash een firmware via de web interface van https://meshcore.co.uk/flasher.html , kies "Heltec MeshSolar / MeshTower", kies rol repeater.

Configureren:
* Via de browser lukte mij niet
* Uiteindelijk geconfigureerd via USB-seriele poort console:
<pre>
screen /dev/ttyACM0 115200
</pre>

In seriele poort console kan je commando's intypen zoals:
<pre>
Radio instellingen (EU868): set radio 869.618,62.5,7,5
Advert interval: set advert.interval 180
Flood advert interval: set flood.advert.interval 50
Naam: set name RevSpace
Eigenaar: set owner.info bertrik@gmail.com
Latitude: set lat 52.0862
Longitude: set lon 4.3947
RX delay: set rxdelay 0.0
TX delay: set txdelay 0.5
Interference threshold: set int.thresh 1
Max hop count: set flood.max 48
TX power: set tx 22
EU regio aanmaken: region put eu
Land regio aanmaken: region put nl
Provincie regio aanmaken: region put nl-zh nl
Bredere regio 1 aanmaken: region put nl-hag nl
Bredere regio 2 aanmaken: region put nl-lid nl
Gemeente regio aanmaken: region put nl-zh-lsv nl-zh
Plaats regio aanmaken: region put nl-zh-lds nl-zh
Flood toestaan: EU: region allowf eu
Flood toestaan: land: region allowf nl
Flood toestaan: provincie: region allowf nl-zh
Flood toestaan: bredere regio 1: region allowf nl-hag
Flood toestaan: bredere regio 2: region allowf nl-lid
Flood toestaan: gemeente: region allowf nl-zh-lsv
Flood toestaan: plaats: region allowf nl-zh-lds
Standaardregio (provincie): region default nl-zh
Thuisregio: region home nl-zh-lds
Regio's opslaan: region save
Path hash mode: set path.hash.mode 1
Loop detectie: set loop.detect moderate
Duty cycle: set dutycycle 10
Admin wachtwoord: password ***
Herstarten: reboot
</pre>

=Workshop=
Een introductie in MeshCore en als je een compatible apparaatje meeneemt (wij hebben ook een aantal mee, dus geen aankoopplicht ;) ): tevens een workshop om er mee te beginnen!

Heb je eerder dit jaar tijdens het Hackerhotel een Meshtastic kitje aangeschaft, maar niets meer met je Meshtastic gedaan? Dan is dat kitje met Heltec V3 een prima starter bij deze MeshCore workshop.

Je kunt eventueel een Heltec V3 meebestellen voor 25 euro incl btw. Zet dat dan even in de tabel hieronder erbij. Maar je mag natuurlijk ook je eigen spul meenemen.

==Inhoud==
* Wat is MeshCore
* Waarom is het leuk
* Verschillende rollen
* Hardware (en hoe het uit de hand loopt)
* Configuratie
* Demo
* Speeltijd en hulp met het werkend krijgen.

https://pad.bitlair.nl/p/lora

https://docs.google.com/presentation/d/1h6CC3s-rCDkTylBscA9Ky0ZhBM5mxv8rZMoFVbLMzFs/edit?usp=sharing

==Aanmelden==
Let op: we kunnen maximaal 20 deelnemers huisvesten en begeleiden.

Je kunt geen Heltec v3 meer meebestellen. Hij is zonder case nog wel leverbaar via TinyTronics: https://www.tinytronics.nl/nl/development-boards/microcontroller-boards/met-lora/heltec-wi-fi-lora-32-esp32-s3-sx1262-met-0.96-inch-oled-display

{| class="wikitable"
|+ Bijschrift
|-
! Naam !! Meebestellen Heltec V3 !! Betaald?
|-
| Wheeze_NL || Nee || .
|-
| Crashjuh || Nee || .
|-
| polyfloyd || Nee || .
|-
| Colomax || 2x || ja
|-
| Atoomnet || Nee || .
|-
| blaat || 1x || ja
|-
| Lukkie || 1x || ja
|-
| Wilbert || nee || .
|-
| CH23 || nee || .
|-
| TeQ || nee || .
|-
| Kartoffel || nee
|-
| Ries || ja || .
|-
| Gori || nee || .
|-
| Dimi || nee || .
|-
| Muad-Dib || nee || .
|-
| florian || nee || .
|-
| Colomax + 1 || nee || .
|-
| FooBar || nee || .
|-
| - || - || .

|}

=Inkoopactie voor een Meshcore Router op de space=

We willen de https://heltec.org/project/meshtower/ MeshTower van Heltec. Er is al MeshCore firmware voor.

{| class="wikitable"
|+ Bijschrift
|-
! Wie !! Hoeveel tientjes !! Betaald?
|-
| Bas || 2 || ja
|-
| CH23 || 2 || ja
|-
| Wilbert || 2 || ja
|-
| Crashjuh || 3 || ja
|-
| Elborro || 2 || ja
|-
| sting || 1 || ja
|-
| Colomax || 1 || ja
|-
| Wheeze_NL || 1 || ja
|-
| Boekenwuurm || 1 || nee
|-
| thomas || 1 || ja
|-
| jelle || 2 || ja
|-
| Lukkie || 2 || ja
|-
| cmpxchg || 1 || nee
|-

| Voorbeeld || Voorbeeld || Voorbeeld
|}

Totaal: 200 euro van de 200 euro

Wil je ook een MeshTower meebestellen of iets anders van HelTec? Dat kan, zet het hieronder jouw bestelling. Met meerdere MeshTowers zakt de prijs van 230 euro per stuk naar ongeveer 200!

{| class="wikitable"
|+ Bijschrift
|-
! Wie !! Wat !! Totaal ex verzenden in $ !! Totaal berekend door Bas incl verzenden !! Betaald?
|-
| RandomData (via Bas)|| 1x MeshTower|| .|| 200|| Ja
|-
| Bas || 1x Heltec V4 || .|| x || Ja
|-
| Bart Jan (RandomData) || 1x MeshTower ||.||200||Ja
|-
| Lukkie || 1x MeshTower || .||200||Ja
|-
| BlackDragon || 1x Heltec V4 || 20 || 25 || ja
|-
| Wheeze_NL || 1x Heltec V4 || 20 || ?? || ja
|-
| HS Nijmegen via Bas || 1x MeshTower ||.||200||Ja
|-
| cmpxchg || 1x MeshTower ||.||200|| ja
|-
| Synq || 1x MeshTower, 1x V3||.||225||Ja
|-
| Elborro || 1x MeshTower ||.||200||Ja
|-
| Dimi || 1x MeshTower ||.||200||Ja
|-
|}

De inkoopactie is gesloten. Alle hardware is besteld (9x MeshTower, 6x V3 en 3x V4).

Its-g5

2026-07-13T09:02:58Z

Bertrik Sikken: /* Hardware */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages
* Power is provided to the esp32-c3, which then distributes power as raw 5V/GND to the esp32-c5. The esp32-c5 uses its own regulator to turn it into a stable internal supply voltage.

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
=== Sniffer ===
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board for the sniffer part:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

=== Bridge ===
An ESP32-C3 is used as the bridge part.
I used a 'supermini' but apparently they have a design flaw causing them to run very hot:
* https://www.dailyduino.com/index.php/2026/01/20/the-spicy-esp32-c3-super-mini-when-2-boards-become-2-heaters/

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

Its-g5

2026-07-13T09:02:27Z

Bertrik Sikken: /* Hardware */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages
* Power is provided to the esp32-c3, which then distributes power as raw 5V/GND to the esp32-c5. The esp32-c5 uses its own regulator to turn it into a stable internal supply voltage.

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board for the sniffer part:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

An ESP32-C3 is used as the bridge part.
I used a 'supermini' but apparently they have a design flaw causing them to run very hot:
* https://www.dailyduino.com/index.php/2026/01/20/the-spicy-esp32-c3-super-mini-when-2-boards-become-2-heaters/

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

Its-g5

2026-07-13T09:02:14Z

Bertrik Sikken: /* Hardware */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages
* Power is provided to the esp32-c3, which then distributes power as raw 5V/GND to the esp32-c5. The esp32-c5 uses its own regulator to turn it into a stable internal supply voltage.

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board for the sniffer part:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

An ESP32-C5 is used as the bridge part.
I used a 'supermini' but apparently they have a design flaw causing them to run very hot:
* https://www.dailyduino.com/index.php/2026/01/20/the-spicy-esp32-c3-super-mini-when-2-boards-become-2-heaters/

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

Its-g5

2026-07-13T08:19:12Z

Bertrik Sikken: /* Design */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages
* Power is provided to the esp32-c3, which then distributes power as raw 5V/GND to the esp32-c5. The esp32-c5 uses its own regulator to turn it into a stable internal supply voltage.

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

Its-g5

2026-07-07T09:09:13Z

Bertrik Sikken:

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Perhaps configure a keystore/certificate for secure mqtt (mqtts), if needed
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

Its-g5

2026-07-06T09:17:36Z

Bertrik Sikken: /* Hardware */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Perhaps configure a keystore/certificate for secure mqtt (mqtts), if needed
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

This project uses an ESP32-C5-devkitC-1 board:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

Its-g5

2026-07-05T09:13:47Z

Bertrik Sikken:

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Receiving ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Crowd-sourced live map of messages received: https://opentrafficmap.org/ Their wiki: https://wiki.opentrafficmap.org
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No hardware modification required (e.g. desolder capacitors on SPI wires of the esp32-c5)
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: protocol, host, port, user, pass
** Perhaps configure a keystore/certificate for secure mqtt (mqtts), if needed
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

I got an ESP32-C5-devkitC-1 board, and it worked for me:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

Bestand:Its-g5.png

2026-07-04T14:10:44Z

Bertrik Sikken: Bertrik Sikken uploaded a new version of File:Its-g5.png

Its-g5

2026-07-01T21:41:15Z

Bertrik Sikken: /* Hardware */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Investigating ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Crowd-sourced live map of messages received: https://opentrafficmap.org/
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* How to contribute to opentrafficmap: https://wiki.opentrafficmap.org

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 (as an inexpensive jellybean part) for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No need to desolder capacitors on SPI wires of the esp32-c5
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: host, port, user, pass, base topic
** Perhaps configure a keystore/certificate for secure mqtt (mqtts), if needed
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

I got an ESP32-C5-devkitC-1 board, and it worked for me:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

Its-g5

2026-06-30T06:46:47Z

Bertrik Sikken: /* Design */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Investigating ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Crowd-sourced live map of messages received: https://opentrafficmap.org/
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* How to contribute to opentrafficmap: https://wiki.opentrafficmap.org

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The design is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 (as an inexpensive jellybean part) for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No need to desolder capacitors on SPI wires of the esp32-c5
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: host, port, user, pass, base topic
** Perhaps configure a keystore/certificate for secure mqtt (mqtts), if needed
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

I got this ESP-C5-devkitC-1 board, and it worked for me:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

Bestand:Esp32-c5-sniffer.jpg

2026-06-29T20:06:31Z

Bertrik Sikken:

Its-g5

2026-06-29T20:06:13Z

Bertrik Sikken: /* Design */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Investigating ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Crowd-sourced live map of messages received: https://opentrafficmap.org/
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* How to contribute to opentrafficmap: https://wiki.opentrafficmap.org

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
[[File:esp32-c5-sniffer.jpg|thumb|right|alt=esp32-c5-sniffer]]

The plan is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 (as an inexpensive jellybean part) for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No need to desolder capacitors on SPI wires of the esp32-c5
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: host, port, user, pass, base topic
** Perhaps configure a keystore/certificate for secure mqtt (mqtts), if needed
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

I got this ESP-C5-devkitC-1 board, and it worked for me:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

Its-g5

2026-06-29T06:54:58Z

Bertrik Sikken: /* opentraffic map interface */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Investigating ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Crowd-sourced live map of messages received: https://opentrafficmap.org/
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* How to contribute to opentrafficmap: https://wiki.opentrafficmap.org

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
The plan is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 (as an inexpensive jellybean part) for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No need to desolder capacitors on SPI wires of the esp32-c5
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: host, port, user, pass, base topic
** Perhaps configure a keystore/certificate for secure mqtt (mqtts), if needed
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

I got this ESP-C5-devkitC-1 board, and it worked for me:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 :
* no user name / password
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string, like {"emac":"xx:xx:xx:xx:xx:xx","ver":"github.com/bertrik/its-g5-receiver-v0.0.1","hwv":"esp32-c5-devkit-c1"}
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

Its-g5

2026-06-29T06:52:59Z

Bertrik Sikken: /* Hardware */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Investigating ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Crowd-sourced live map of messages received: https://opentrafficmap.org/
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* How to contribute to opentrafficmap: https://wiki.opentrafficmap.org

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
The plan is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 (as an inexpensive jellybean part) for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No need to desolder capacitors on SPI wires of the esp32-c5
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: host, port, user, pass, base topic
** Perhaps configure a keystore/certificate for secure mqtt (mqtts), if needed
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

I got this ESP-C5-devkitC-1 board, and it worked for me:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

{| class="wikitable" style="margin:auto"
|+ Connections
|-
! ESP32-c5 !! ESP32-c3 !! Remark
|-
| GND || GND || shared ground
|-
| 5V || 5V || raw power
|-
| U0TXD/GPIO11 || RX/GPIO20 || Data link
|}

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 , no user/pass:
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

Its-g5

2026-06-29T06:49:45Z

Bertrik Sikken: /* Hardware */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Investigating ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Crowd-sourced live map of messages received: https://opentrafficmap.org/
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* How to contribute to opentrafficmap: https://wiki.opentrafficmap.org

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
The plan is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 (as an inexpensive jellybean part) for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No need to desolder capacitors on SPI wires of the esp32-c5
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: host, port, user, pass, base topic
** Perhaps configure a keystore/certificate for secure mqtt (mqtts), if needed
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

I got this ESP-C5-devkitC-1 board, and it worked for me:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

How to wire it up, what I did:
* Put both the esp32-c3-supermini board and the esp32-c5-devkit-c1 on a breadboard
* Use male-male dupont wires to connect:
** 5V to 5V, GND to GND, esp32-c5 TX to esp32-c3 RX
* Programmed the esp32-c5 with firmware
* Plug an USB-C cable into the esp32-c3, programmed it with firmware, now it's powering both the esp32-c3 and the esp32-c5

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 , no user/pass:
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

Its-g5

2026-06-28T21:18:20Z

Bertrik Sikken: /* Software */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Investigating ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Crowd-sourced live map of messages received: https://opentrafficmap.org/
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* How to contribute to opentrafficmap: https://wiki.opentrafficmap.org

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
The plan is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 (as an inexpensive jellybean part) for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No need to desolder capacitors on SPI wires of the esp32-c5
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: host, port, user, pass, base topic
** Perhaps configure a keystore/certificate for secure mqtt (mqtts), if needed
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

I got this ESP-C5-devkitC-1 board, and it worked for me:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

== Software ==
See https://github.com/bertrik/its-g5-receiver

This is heavily inspired by https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
but with a fixed size ring buffer instead of dynamic allocation.

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

In short: server = mqtts://cits1.opentrafficmap.org:8883 , no user/pass:
* topic 'its/<node>/status' (online or offline), retained
* topic 'its/<node>/info' with a JSON string
* topic 'its/<node>/packet' for sniffed packets (raw, not JSON encoded)

Its-g5

2026-06-25T08:13:59Z

Bertrik Sikken: /* Design */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Investigating ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Crowd-sourced live map of messages received: https://opentrafficmap.org/
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* How to contribute to opentrafficmap: https://wiki.opentrafficmap.org

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
The plan is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 (as an inexpensive jellybean part) for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No need to desolder capacitors on SPI wires of the esp32-c5
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: host, port, user, pass, base topic
** Perhaps configure a keystore/certificate for secure mqtt (mqtts), if needed
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, UART-TX for the ESP-ESP serial connection.
* The esp32-c3 and esp32-c5 share their 5V and GND power lines. Each board derives its own internal power supplies from this 5V.
* The serial link doesn't have to be very high speed, 115200 for example. We use a hardware UART on both sides of the serial link.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

I got this ESP-C5-devkitC-1 board, and it worked for me:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

== Software ==
See https://github.com/bertrik/its-g5-receiver

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c

Its-g5

2026-06-25T08:03:05Z

Bertrik Sikken: /* Compiling the firmware */

{{Project
|Name=ITS-G5
|Picture=its-g5.png
|Omschrijving=Investigating ITS-G5 signals
|Status=In progress
|Contact=bertrik
}}

== Introduction ==
[[File:its-g5-wireshark.png|thumb|right|alt=wireshark analysis]]

This page is about investigating reception and processing of so-called C-ITS or ITS-G5 signals (802.11p) as used in the Netherlands, see also https://en.wikipedia.org/wiki/Vehicle-to-everything
These signals are exchanged between passenger cars, emergency vehicles, traffic lights and other traffic-related equipment.

An ESP32-C5 development board is capable of receiving WiFi in the 5 GHz band and can receive/sniff these kinds of packets from live traffic.

Stuff to investigate:
* Source code for an ITS-G5 receiver https://github.com/pit711/v2x2map
* Crowd-sourced live map of messages received: https://opentrafficmap.org/
* Simplest source code for Arduino-based sniffer: https://git.devlol.org/jstsmthrgk/simple-its-g5-receiver-firmware
* How to contribute to opentrafficmap: https://wiki.opentrafficmap.org

In the Netherlands, SPAT/MAPem messages from traffic lights are not transferred over wifi-p, but over UDAP.
You need credentials to access that data, it is not clear if it is feasible to hobbyist to access it.
Interesting project: https://github.com/idkmanLool9/Verkeerslicht

== Design ==
The plan is:
* Use an esp32-c5 for sniffing 802.11p frames only
* Use an esp32-c3 (as an inexpensive jellybean part) for receiving sniffed frames from the esp32-c5, connect to WiFi and upload packets over MQTT
* The interface beteween the two boards is '''serial''', this is simpler than SPI as used in other projects:
** Only three wires required: GND, +5V and serial DATA
** No need to desolder capacitors on SPI wires of the esp32-c5
** A serial interface is more universal, e.g. can be connected to an arbitrary linux SBC, to run a python bridge for example
** On the esp32-c5 use the same wires as the existing USB-UART bridge, so you can also receive packets over USB-serial
* Run a simple web server on the esp-c3:
** Configuration page with MQTT settings: host, port, user, pass, base topic
** Perhaps configure a keystore/certificate for secure mqtt (mqtts), if needed
** Optional: show some nice stats: mqtt status, packet rate, last packet, packets per type
** Optional: run a very basic parser for e.g. CAM messages

Practical:
* The serial link runs over the USB-UART chip of the esp32-c5.
* A simple command processor runs on the other UART (the emulated USB serial port)
* On the esp32-c5 side, use pins GND, 5V, GPIO-XX for the ESP-ESP serial connection. These pins are right next to each other on the esp32-c5-devkitc-1.
* The esp32-c3 and esp32-c5 have their 5V power lines connected together. Each board derives its own internal power supplies from this 5V.
* The serial link probably doesn't have to be very high speed, start with 115200 for example. We use a hardware UART on both sides for this.
* Use https://registry.platformio.org/libraries/thomasfredericks/MicroSlip for framing packets over the serial port.

== Hardware ==
[[File:esp32-c5-devkitc-1.jpg|thumb|right|alt=esp32-c5]]
[[File:esp32-c3-supermini.jpg|thumb|right|alt=esp32-c3]]

I got this ESP-C5-devkitC-1 board, and it worked for me:
* Aliexpress product page https://nl.aliexpress.com/item/1005012416463528.html
* Espressif schematic https://dl.espressif.com/dl/schematics/SCH_ESP32-C5-DevkitC-1_V1.1_20240621.pdf . Actually my board is not exactly like this, the USB-UART is connected to pins GPIO11 (TX) and GPIO12 (RX), not GPIO25/GPIO24.
* Espressif devkit-c page: https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32c5/esp32-c5-devkitc-1/user_guide.html

It has an onboard antenna. There are also other boards with an antenna connection, which allows using an external antenna. This may be better, I don't know yet.

== Software ==
See https://github.com/bertrik/its-g5-receiver

=== Compiling the firmware ===
Uses python and platformio, see the README.md in the source archive.

Watch packets come in:
pio device monitor
Packets are logged as a 'hexdump'.

The can be converted for wireshark, for example:
text2pcap -l 105 message.txt message.pcap
Then viewed in wireshark:
wireshark message.pcap

=== opentraffic map interface ===
See https://github.com/MPW1412/openwrt-otm-bridge#wire-format-mimics-the-esp32-c5-firmware for the mqtt wire format.

See also https://github.com/pit711/v2x2map/blob/main/firmware/main/mqtt.c