# C-ITS: Tracking Traffic Lights, Trams, and Cars with an ESP32

Source: https://media.ccc.de/v/glt26-688-c-its-mit-einem-esp32-ampeln-straenbahnen-und-autos-tracken/audio

Speakers: Peter Poetzi and Michael Ehrenreich

Note: This English translation is based on the locally generated Whisper transcript in `glt26-688-c-its.txt`. I normalized obvious speech-to-text glitches in proper names and technical terms, such as Grazer Linux-Tage, tracking, Wireshark, ASFINAG, ESP32-C5, CAM, DENM, MAPEM, and SPATEM.

## Translation

Welcome to the Grazer Linux-Tage, to our second talk of the day. We are now going to look at the exciting topic of how to track trams, traffic lights, and cars. With that, I will hand over to the speakers. Have fun.

First, briefly, who we are. My name is Michael Ehrenreich, also known as Mick. I will not say very much today because my voice is not fully cooperating, but I have been interested in electronics for quite some time, and in reverse engineering for even longer.

I am Peter Poetzi. I study computer science at TU Graz and also do electronics and software development. Since the question often comes up: we are also the people with the electric Bobby Cars. Some of you may have heard of that.

What do we want to do? We want to show you what your cars are transmitting. Many people do not know at all what their car sends. Of course, the point is always also to improve traffic safety. This is a protocol that was developed specifically for that purpose. Transparency and open data are also very important to us. We want to publish as much as possible of what we discovered during the project. We can also give you better public transport predictions than perhaps the city itself can.

Briefly about C-ITS. What is it? There is Vehicle-to-X, which many people probably heard about years ago, but then it somehow disappeared. Nobody really noticed what happened with it, whether it is being used or not. There are so-called roadside units installed in the city, mostly at traffic lights, and partly also on motorways. There are also mobile units, for example in Germany on construction site signs.

Then there are onboard units installed in vehicles, including private cars. VW was the first to install them, in 2019 in the Golf. Since then, more and more models have had this integrated. They send data by default. You probably have to agree to something at the beginning. Our car sends it; I cannot remember clicking anything, but probably I did. Buses and trams were all retrofitted with it. Fire brigade, police, and ASFINAG also transmit. The whole thing is sent at 5.9 GHz, unencrypted, and it can optionally be signed.

Use cases: the infrastructure operator, for example ASFINAG here, receives data from vehicles that are currently driving and can react to it. They can see, for example, where on the motorway people usually drive 130 but are now only driving 60. They could then reduce the speed limit. They also see when a car is stopped, either because the car reports it itself, or because other cars equipped with this system pass by, recognize it with their camera, and report: I saw a stopped vehicle.

At traffic lights, the main thing is priority for public transport and emergency vehicles. If I approach a traffic light in a bus or tram, it gets green sooner. You can see this on the traffic-light timer, where it counts down how many seconds of green or red are left. As soon as the tram arrives, it throws the timer away, counts down 4, 3, 2, 1, 0, and the tram has green. Vehicles also get driver-assistance systems that can react to other cars and to data from the infrastructure operator.

Now briefly about the protocol itself. The protocol stack is relatively complex. It consists of more than 50 ETSI standards that describe how the protocols are supposed to work. I am only describing the most common case we have seen. At the very bottom, IEEE 802.11p is an extension of the 802.11 standard. Unlike normal WLAN, it uses a channel width of 10 MHz instead of 20 MHz. Also, there are no access points in that sense; instead, it operates outside the context of a BSS. BSS stands for Basic Service Set.

The next layer in the protocol stack is GeoNetworking. That is an ETSI standard for a kind of mesh networking protocol, which has features such as: I want to send a broadcast to all devices in a circular area around this coordinate. Next is IEEE 1609.2. That is used to sign messages, though, as mentioned before, the messages we have seen are not encrypted. Next is BTP, roughly comparable to UDP, to map port numbers to certain known services. After that come the actual messages themselves, encoded in ASN.1.

What kinds of messages can be sent? There is CAM, the Cooperative Awareness Message. It is an announcement from one station to all other stations: hello, here I am. It contains various data, which we will look at shortly. Then there is DENM, the Distributed Environmental Notification Message. That is used to communicate everything unusual on the road. There are also MAPEM and SPATEM, which are especially important for traffic lights, and IVIM, which can be used to display traffic signs such as snow-chain requirements, free text, and so on. There are many others that we have never seen. For example, there are messages where electric charging stations can tell cars which charging spots are free, and you can then reserve a station via C-ITS so that only your car can charge there. We have never seen that in practice.

The Cooperative Awareness Message is generally sent by vehicles. Not only vehicles, but mostly vehicles. It basically says: here I am, here is my position, and this is where I am going. Some stationary infrastructure also sends it, so that you do not drive into it or something like that, but mostly vehicles.

We will look at what such a CAM looks like when opened in Wireshark. It contains things such as: I am a car, I am driving in this direction at 106.2 km/h, I am 4.9 meters long and 1.9 meters wide, and right now, I do not know, the accelerator is being pressed, the brake is being pressed, cruise control is active, or whatever. Additionally, not in every message, but every now and then, it sends which lights are on, such as high beam, low beam, and indicators. It also sends a history of where the car has been recently. We are talking about seconds, or at most a few minutes.

It is sent four times per second. If, for Germany for example, I have eleven previous positions included, then I can see roughly the last three seconds, even if I did not receive the packets directly for some reason. Many packets are lost, because they are just sent out without regard for other stations. Where many of these packets are sent, many are lost because they collide with each other.

Then DENM, or however it is pronounced, is sent when there really are unusual traffic situations, such as roadworks or traffic jams. Wrong-way-driver warnings are also distributed via DENM. We actually once saw an object-on-the-road message sent by ASFINAG. As mentioned, it can be sent either by the infrastructure, such as ASFINAG, or by vehicles. If a vehicle detects that people are suddenly braking, or something like that, it can send a message saying: watch out. Unlike CAMs, DENMs are forwarded, up to ten times, depending on what the sender writes into the packet.

The forwarding works like this, for example: a car sends out, I have detected a traffic jam, and the message should be forwarded three times. Traffic lights, trams, and other cars receive it. The tram decreases the hop limit by one and forwards it. Maybe the next traffic light sees it, decreases it by one again, and forwards it. That way, from a range of a few hundred meters, I have gained a range of several kilometers.

Some important data inside such a packet includes the detection time, meaning when the event occurred; a time limit for how long the message remains valid after that detection time, in this case two minutes; and what the event is, in this case roadworks. ASFINAG sent this to us, I think on the way up toward the park. Somewhere there is an event zone, probably a polygon, defining the area where the construction site applies, that one lane is closed, probably only the hard shoulder in this case, and that the speed limit is 60 km/h.

Now we come to traffic lights. The traffic light itself sends us packets about the structure of the lanes. I always call it the geometry. For example, this is the traffic light at Schoenaugurtel and Conrad-von-Hoetzendorf-Strasse. Everything we display is sent to us by the traffic light. It says: here is a lane with these coordinates, and from this lane you can turn left, either onto this one or onto that one. There are also lanes where you can go straight or left or right. You can even see that for one lane they entered that you can make a U-turn. There are bicycle paths and pedestrian paths.

So the car can see, a few hundred meters before the traffic light, the exact structure of the intersection: which lanes can I use, where can I go, and what are the timings? It can see: right now it is red, but maybe only for a few more seconds, so I do not need to brake. Or it is still green, but it is about to turn red, so I can already reduce speed. Driver assistance systems may use this in the future. The traffic light itself of course also uses C-ITS to detect other vehicles and react accordingly, especially for public transport.

Here is the same thing stored in OpenStreetMap. This is the intersection. Everything colorful here is sent by the traffic light; it does not come from OpenStreetMap. The coordinates are not exactly the same. It does not send this curve exactly as drawn here; we inserted that ourselves. But from here to there is connected for the tram, and we can display timers. The timers are often a range. It says this should supposedly turn green after 182 to 197 seconds. That is not quite true, though. It does count down, but at some point something happens: either a vehicle arrives, or a timer inside the traffic light expires. Then it simply throws away the timer and counts down from 12 to 0, or from 4 to 0. We have all seen that.

What is the situation with the traffic lights? Holding Graz writes on its website that they are retrofitting 165 traffic-signal systems, 200 buses, and 100 trams. I think they wanted to finish it last October, or we did not understand that exactly. In any case, all trams and buses have been retrofitted. We once saw a tram that did not send anything; it was probably broken. But in general, all trams and buses transmit.

Of the 165 traffic lights, we found 121. We also made a leaderboard for people operating mobile receivers, showing who sees the most traffic lights. Apparently AJ on Bike found 120 of the 121 traffic lights. There is one that only I found, with my ID.Buzz or on the scooter; I am not sure right now. We are relatively sure there are not more than 121 traffic lights, otherwise we would have found them. I assume the rest will simply come later. There are many large intersections, for example Conrad-von-Hoetzendorf-Strasse and Schoenaugasse, that simply do not transmit at all. That is actually one of the largest intersections, but they are currently rebuilding it because a new underground garage is coming. We assume that once that is finished, the transmitter will also be installed.

How can you send and receive this? There are commercial roadside units, of course, from Kapsch or Yunex Traffic, which used to be Siemens. They mainly do traffic lights. The onboard units in vehicles are typically installed at the factory, especially in cars, or they can be retrofitted, as was done here for public transport. Or you can use any 802.11p receiver. There are experiments with MikroTik routers, for example, using a Qualcomm Atheros chip that can receive it. Or you can use what we announced, the ESP32-C5, which costs about two to four euros. It is a microcontroller from China.

Officially, it actually cannot do 802.11p at all, but Espressif built a practical function into their closed-source WLAN libraries called `phy_11p_set`. You can call that, and suddenly it works after all. Then you still have to use the low-level function to set the channel, because 5900 MHz is not a normal WLAN channel. I found that through reverse engineering, which in this case is even allowed, because Espressif publishes these blobs under the Apache 2 license. Thank you for that. Espressif has in fact confirmed at least once that reverse engineering of the blobs is allowed.

We built a receiver board, and we brought several of them with us. It looks like this; we have the picture on the slide. We have an ESP32-C5, an SPI-to-Ethernet chip, and we also do PoE with it. You can power it purely through PoE and provide data and power that way. It can do active or passive 48 volts, and also passive 24 volts, though at the moment you have to resolder something for that. We have two USB-C connectors, one for serial and programming, and one for JTAG. You can also output the packets there and watch them live directly in Wireshark as they arrive. There is a microSD connector, which could be used to record packets offline, but that is not implemented yet, and a temperature sensor.

For these receivers, we also have cases. We brought some. We simply placed a larger order for these boards in China, and we 3D-print the cases. They can be mounted on poles. The two pictures are not from Austria; I think this one is from Muenster in Germany, and this one is in Hungary. Basically, these things hang all over the place. We distribute them. You do not have to use our boards; you can also build it yourself. We will get to that later. Of course, the more people hang up these receivers, the more coverage we get.

We built a map out of this for Graz. This is now live. I hope it continues to work. We have a different instance than you do, so it should not break for us if you open it. Here we can see live data from our receivers. Here is a tram, and we can see exactly which receivers received it. In this case, Office North and Office Window have very good reception and received a packet within less than a second. Office South is obviously not receiving so well right now. Other stations across the city are also shown. Schmidgasse, for example, saw it four minutes ago. It apparently passed somewhere near Herrengasse four minutes ago.

We also see how fast this tram is going. At the moment, 0 km/h. It is standing at the station, Auer-Welsbach-Gurtel. It has now received green and is already moving off. We see the speed: 16, 17, 18. So it is really driving now. If you were standing there, it would be live, with only a few milliseconds of delay. We can see the tram moving.

From the MAC address of each tram, we recorded pictures. I once stood at Jakominiplatz for an hour. This is tram 659. We also entered that it is a Cityrunner type and wheelchair accessible. We have pictures for all trams except eight, which have not been running in the last few days. I was told some of them are in revision. But as soon as they run, we will add the pictures too. I can click on any tram, for example this one is 209, and I can see that this tram is now driving here, line 7 toward LKH Med Uni, and how fast it is going. Only where there is coverage, of course, but our coverage with 20 receivers is already relatively good.

We see a car driving there, though coverage in that area is probably not very good. It will disappear after ten seconds if we do not have data. But we still have data. Maybe we can find another car. There is one driving on Bahnhofgurtel. It is doing 54 km/h in a 50 zone. Green means it is leaving the coverage area again. Now it is 53. Green means the driver is pressing the accelerator. Red would mean braking. We also detect cruise control. Now acceleration again, speeding up again. But there is red ahead anyway. Not for much longer, only another 2400 seconds. I hope the traffic light throws away the timer again and recalculates. Now reception is gone again; we last saw it seven seconds ago. But I think near the traffic light it should work again soon. We just do not have many receivers; there are only 20.

We probably have another car somewhere. This one is also driving at exactly 50, so that is okay. It also has green. Where else do we have cars? Here is one. If it is blue, we have current reception within the last ten seconds. There is also one driving there. We probably received that from Grieskai five seconds ago. That is outside the coverage area again. Our coverage is simply not that good yet.

For example, what you see here is 4.3 by 1.1 meters. Those are the street sweepers. That is why they stick out. They are not driving; they are standing in the garage. The GPS is just not good. I am surprised they have reception at all, but it is not very good. We also talked to the manufacturer of these onboard units and I asked why it sometimes sends braking or acceleration, even though I am very sure it is standing in the garage. He said they did not know where to connect brake or accelerator on the control unit, so they detect it via GPS. If it becomes faster or slower, it sends accelerator or brake.

We also have photos for some buses, but only about half so far. Maybe we can find a bus with a photo. This one, for example. This is bus 115, a solo bus, with its license plate. I also photographed the buses I came across. The MAC address is static.

Here is also a very interesting situation at this traffic light. They rebuilt it at Neutorgasse, and the mappings of the signal groups are wrong. A signal group is something the traffic light sends. Often several lanes belong to one signal group. You can see that cars and pedestrians have green at the same time, but that is not actually the case. We were there and investigated it for a long time. In reality, this light down here is actually the one up there, and what is green now is actually over there, and this is somewhere else again. They entered it incorrectly in their system. We investigated it several times, including the raw Wireshark packets. We are very sure the traffic light really sends it like that.

I already know someone who says he no longer looks at the light itself at the traffic light, only at his phone, because it is live. He stands there, wants to cross, sees green, and starts walking. But at the same time, these also get green. We still have to report that to the city. Because what do I trust more? A light on a pole, which anyone could somehow mount, or a signed packet from a Siemens MAC address with a Siemens certificate? That is actually much more trustworthy. There are often still errors in it, though.

There are also intersections where they simply messed something up. For example, at this intersection, this tram track goes right through the river Mur, which is certainly not the case. But most of them are actually very good. If I zoom out a bit, we now have 121 traffic lights. I can hide the cars, buses, and trams. Now only the traffic lights remain, plus a few roadside units, whatever they send. I can also look at the JSON. No idea; you would have to look at it calmly. Of course, we do not display everything yet. If they send construction-site messages, for example, we do not parse those yet. You would have to look at the JSON.

The yellow traffic lights are the ones where we have live data. The grey traffic lights are ones we have seen before, but where we do not have live reception within the last ten seconds. Sometimes they disappear because they are only barely inside the reception area. But especially in the city center, the coverage is already relatively good. For Neutorgasse and Conrad-von-Hoetzendorf-Strasse, for example, I also get timers.

I think we still have enough time, so we can explore something live. This should turn green in two seconds. Yes, it happened. And there, between 17 or 16 and 26 seconds. The tram also has green. I do not know whether there is one there. I had hidden it. Ah, there it comes. It will probably drive across now. It only has five seconds of green left, but it will probably just make it. The tram is across. It should turn red soon. Now it got another 70 seconds of green. Is another one coming? No, actually not. Well, now the pedestrians have to wait longer. We do not know why. Just now it said 12 seconds. Okay, now it says 12 seconds again. The timers change very often. If anything happens at the traffic light, if it detects vehicles, or if an internal timer expires, it throws those seconds away and then something else appears. Now 2, 1, 0. This is green, and they also have green at the same time.

There are also different types of green. On the left there is protected green and permissive green. That means whether I have to expect pedestrians when I turn right, for example. So now it is green; one would have to look at it in detail.

We also made statistics, which we will get to shortly. For example, there are these signal groups. Often several traffic lights are attached to one signal group. Here, for example, pedestrians and cyclists are in signal group 12. At this point, signal groups 13 and 14 always turn green at the same time. We could split them up, but the traffic light is probably simply wired differently.

It always seemed to me that this side is green when I ride from the ice cream shop to the driving school, while in the direction of the hotel I always have to wait. So I made the statistics. Signal group 12 is the one where I thought it was always green. It is actually green 64 percent of the time. I will make this a bit bigger. The waiting time has a median of 29 seconds. P05, the fifth percentile, is also 29 seconds, so shorter probably simply never happens. The maximum is one minute 29. This is over a 24-hour observation period. We generate this statistic automatically. The phase time, meaning how long it is green, ranges between 29 seconds and two minutes 20.

Signal groups 13 and 14, over there, are red much longer. They are red 80 percent of the time. The median waiting time is one minute 11, and we measured up to two minutes 36. The green phase is also relatively long, especially, I think, when the tram is driving over there. I can view this for every traffic light in the coverage area, for which we have packets throughout the day. For every lane, or rather every signal group, I can see what percentage of the time it is green and red. Traffic lights where we have poor reception are not included.

For some traffic lights, we also have photos, showing what the controller looks like. This controller is from Yunex Traffic. There are also other manufacturers. It is often mounted like this, often on a slightly elevated position.

About cars: as I said, so that cars cannot be tracked easily, they regularly change their MAC address. We observed that every 5 to 15 minutes, they exchange both MAC address and certificate. The certificate can be requested in batches in the background from the manufacturer, so that the car can change certificates frequently. That prevents us, and hopefully everyone else, from tracking them persistently.

I will hide the traffic lights, and also the traffic-light geometry. If a car simply stops, and a new car starts from the same place with the same dimensions, we can basically assume it is the same car. That should happen now and then. I am looking; it could be that it happened here, that this car stopped there and then continued there. It has exactly the same dimensions. We would have needed to observe it live. Maybe we will see one changing its MAC address live. At the moment it does not look like it.

You would have to watch live as the car disappears from the map and then a new car appears at the same place. The only thing the manufacturers forgot is that they also send a sequence number with the packet. It increments with every packet, and they do not reset it when they reset the MAC address. So honestly, you do not even have to watch that carefully or try to match coordinates. You can simply look at the sequence number. I know how fast it increases, and even if I do not have reception in an area for a while, I can link it again. Car manufacturers should really fix that. The standard is honestly designed to be as data-minimizing as possible for what it does. Of course, since this is a standard for traffic safety, so that cars behind me can brake when I brake, it is clear that I have to send my position, and it is also somehow clear that it is unencrypted. They did many things well. If something is not correct, such as the sequence number in this case, we will report it to the manufacturers.

So we are showing you how cars can be tracked, but actually this is a very data-sparing standard. There are many things in it to make tracking harder. If I park my car now, the next day it is completely impossible to recognize that it is the same car again. But we are not really interested in the cars anyway. We are mainly interested in buses and trams. If I am standing somewhere, I may want to know when the next tram is coming. At Hauptplatz we briefly received data, and at the main station where they drive underground, I can see exactly: I am standing here, the next tram may already be coming, and I can roughly estimate how fast it is going and when it will reach me.

We have seen that the data quality is often better than the public-transport predictions. Those say the tram will come in one minute or two, but it has actually already passed, or the opposite. I do not know exactly what those predictions are based on, but with this we at least have live data showing where my tram is and how fast it is going. And I can see that the tram still has red, so it might take another minute.

Maybe by now we have a car that changed its MAC address. This one, for example. It will disappear. 5.1 by 1.9 meters. The car apparently drives to here. Well, that is a different car, because those are two lanes. But maybe we will still find one that changes its MAC address. You can imagine it anyway: it remains standing on the map, and then a new car drives out from that point with the sequence number continuing upward.

This is the sweeper. The sweeper is the street-cleaning vehicle. It is actually shown as a car, not as a sweeper. We only programmed it so that if it is 4.3 by 1.1 meters, then we are very sure it is a street sweeper.

This map is available to everyone. It is at opentrafficmap.org, and it will remain online after today. We want to keep operating it as long as possible so all of you can use it. The tram does not change its MAC address. Traffic lights and buses do not either. Only vehicles, mainly cars. There are also pilot projects where pedestrians or cyclists are equipped with this, but we have not received any yet. In that case, the car could say: attention, pedestrian in your lane, if it receives that.

Someone asks whether that would be received or sent by a smartphone. I do not know what can be received or sent with a smartphone, because this is a band that is not actually a WLAN band. The phone does not have certification for that. In the future, perhaps.

What about trains? Trains do transmit, but not this. They transmit something completely different, unfortunately. We already checked.

You can also see service trips and driving-school runs. Here line 100 is going to service trip. You often see driving school. Maybe one is driving right now. I will hide the traffic lights. There is Smart City, Wetzelsdorf. Ah, there: driving school to 550. They do not actually transmit names. So when it says "with none", in reality they send line 007 to 06. The 06 is the course number. If several trams are driving on line 7 at the same time, those are courses 1, 2, 3, 4, 5, 6. The destination number is 596. We do not know which destination that is because we do not have the list. What we do is: whenever we see a destination that we do not know, we go there and look at what is written on the tram. In this case it is probably LKH with no text for 596. Often we do not know the destination because it occurs very rarely.

Especially around Hauptplatz, tram reception is very poor. You often see a tram here and there, but not in the curve, because we receive only a few packets there. If someone lives near Hauptplatz and would be willing to set up a receiver, that would help us a lot. Normally, with the driving school too, you can see where it is going. If you are at the driving school, I do not know whether it is going to Liebenau or Puntigam, but on the map we can see it. I can see how many trams are currently out there, but I last saw them three minutes ago because coverage is poor there. Every now and then we receive them.

I think we still have a quarter of an hour and a few slides. Plus Q&A.

How far does this reach, roughly? We currently have about 20 receivers, most of them in Graz. There are also a few in Germany and in Linz. We also once had one in Hungary. As you saw, we have large coverage areas, but also large gaps. If someone lives in one of the gaps, especially toward Hauptplatz, Karlau, or Andritz, where we currently have very few receivers, we would be happy. We brought many receivers. You can also build or order them yourself, if someone operates one and reports data to us. You do not have to send the data to us; you can also process it locally. We published that as open source, which we will get to shortly.

How far can you get with it? As we saw, several hundred meters, sometimes up to a kilometer. If the location is higher, then you can get many kilometers. With this PCB antenna on the ESP, over 24 hours, in a range of two to three kilometers, we received millions of packets. The farther away it is, the fewer packets you receive. It should actually be more because the radius is larger, but most packets are lost. We received one packet at a range of 16.9 kilometers, because the sender GPS position is always in the packet. That was really the farthest. Most are within a two to three kilometer radius, which is already very good for such a small PCB antenna. It would probably work even better with a directional antenna.

How does our map work? We receive the packets that are sent to the broadcast address. We send the raw 802.11 packets as binary data into the cloud. With Wireshark, we convert them to JSON. We have a Node script that prepares this JSON for the map, because in the background there is much more data that does not need to be displayed. We stream it to the map via a WebSocket. In the background, we store all these messages for further analysis, such as the waiting-time statistics.

What have we published? We published the PCB design for the receiver board. We published the case design, so you can print it yourself. You can either join a group order for the board, or order it yourself from China. We published the firmware that receives these packets and sends them to the cloud, and the bridge that converts the raw 802.11 packets from MQTT into JSON. That is already live, so you can build it yourself too.

How does your own receiver work? Either you order this board; we have a few here. In the 3D-printed receiver, you slide the board into a tray and then screw it shut at the end. You can also build it yourself. It is simply an off-the-shelf ESP32-C5 and an SPI Ethernet adapter wired on a breadboard, plus an external PoE injector - I always say ejector, but I think it is called a PoE splitter. Or you can run it mobile in a car with an LTE router, as we do, with the board connected to it.

On privacy: as mentioned, the MAC address and certificate change frequently, which makes persistent tracking harder. We will report the sequence-number issue to car manufacturers and tell them that they should also change it when the MAC address changes. They probably simply overlooked it. It is also something that does not come from the application, but is added by the modem.

The whole thing is a peer-to-peer network and works without central infrastructure. Even in countries where it is not deployed at all, or where there are no roadside units, cars can communicate with each other and forward the data. There is also Cellular Vehicle-to-X, which works over 4G or 5G and has central infrastructure where all the data is also reported. That would make tracking much easier for the infrastructure operator from a data-protection perspective, and would therefore be worse for privacy if it went over 4G or 5G. For the traffic-safety application, they actually did it relatively well, even though of course it partly allows us to track things now.

We are not the only ones receiving the packets. Others receive them too. The city of Graz has all these traffic lights, and the traffic lights can also report the packets centrally. We do not know whether they do that. Maybe the city of Graz has exactly the same map, or a much better map because they have more coverage. Maybe they do nothing with the packets. We do not know. I also did not find a privacy statement or anything like that. We can ask.

ASFINAG also receives it. This is the map of Austria. All these blue antennas are ASFINAG antennas. They have almost continuous reception on the motorways. They see on every meter of motorway how fast people are driving, who has the fog lights on, where an accident happened, where a stopped vehicle is reported, and they can react immediately. Of course, only a few cars currently have this installed, but a few cars are enough. I can still see that today there are many more vehicles than usual, or that even the few cars that have it are driving more slowly. That may already allow the conclusion that there is a traffic jam.

We already covered waiting times. What can you do for this? As mentioned, you can set up these receivers at locations where we have poor reception. You can either buy one through a group order from us or build it yourself. You can also flash it yourself; everything is open source. We are also partly looking for sponsors, especially for cloud, storage, and compute. We are currently paying for it ourselves, but we would like to continue operating it.

That brings us to the end. I think we now have 10 or 15 minutes for questions.

Question: about the number of receivers. There are some people from Radlobby Wien here, and it would be interesting to establish this a bit in Vienna. Could we integrate that into your OpenTrafficMap, or would we have to operate it ourselves?

Answer: We drove through Vienna once and picked up a few traffic lights, but no trams or buses. Maybe they are only being retrofitted, maybe not. At the moment there is no receiver online in Vienna. You are welcome to operate some; it will work immediately.

Question: Ah yes, okay. I think we would be interested in that.

Answer: There are also receivers in Germany. At Easterhegg, I gave one to someone from Muenster. Now we can also see vehicles driving there. It should work throughout Europe. I do not know exactly where the receivers are. We distributed some of them in larger numbers, and where they ended up... one can guess roughly. I can filter by receiver. Where could this be? We do not know exactly where they are, but we are happy about the data that comes in.

Question: Just a quick question about the protocol. Could I communicate Europe-wide over this protocol if I make the hop count correspondingly large?

Answer: That is a good question. It is of course forwarded by all participants. We have not yet seen a packet with more than 10. I think there is also a maximum size. It is probably 255 or something like that. One would have to try it.

Question: What does it look like in other Austrian cities?

Answer: In Vienna, the traffic lights transmit. In Linz, we received one traffic light. Maybe there will be more in the future. We have not driven all over Linz. We do not know about other cities. In Innsbruck, feel free to try it.

Also briefly on the topic of buses, which we forgot to mention earlier: these packets are optionally signed with a certificate. Many buses have a certificate. Some buses do not have a certificate and send unsigned. Anyone could send that. We do not know whether the certificate is important. Maybe the buses without a certificate are the ones that stand forever at the traffic light and nobody can explain why. Or maybe the certificate does not matter, but anyone could send that they are a bus. That would also have to be tried.

Question: Can the ESP also transmit on that frequency?

Answer: We have not tried it yet, but in principle yes.

Question: Okay, then the question has already been answered. The buses send this unsigned. It would be fun to play around with that.

Answer: Definitely. Open point.

Question: I wanted to ask whether the website and the Node.js stuff are public too.

Answer: Not yet. It will come. There will be a version. At the moment this is relatively complex. It runs over several servers and several instances. I have a different instance than you do, so that if yours is overloaded, it does not affect me during the talk. We will make a light version that runs with Docker or something like that.

Question: What is the average reception radius of such an ESP?

Answer: Many hundreds of meters, sometimes line of sight over a kilometer directly in the city if the street is nicely straight, even with dense buildings. If you are higher up, for example on a mobile-phone mast or something similar, then you get correspondingly farther.

Question: How realistic would it be for the ESP32 firmware to switch between normal WLAN and the 10 MHz 802.11p mode? I am thinking of a phone hotspot, a small ESP, and a bicycle.

Answer: That is probably rather difficult. But we could make a board with two ESPs on it: one for WLAN, one for receiving.

Question: If I walk through the city with one of your devices, or something like that, to search for devices, how long can they store data until I enter it into a map if I have no reception?

Answer: At the moment they do not store anything. When we walk through the city, we always have an LTE router and report live. We could still implement storage, but it is not implemented right now. The data volume is about 50 GB per month for a receiver at a good location, sometimes 100 GB per month. You could store correspondingly long on a microSD card.

Question: For cars that support this, is there a way to deactivate it, or is it always active?

Answer: In my car, it is a slider where I can say yes or no. When I first went into that menu, it was on. I assume I had to click something to accept when I first switched on the car. I do not remember. In any case, it was on. You can turn it off.

Question: Are there strange names that manufacturers use for it? What is it usually called in cars? Is that standardized, or do they use cryptic names?

Answer: Usually it is called V2X, Vehicle-to-X, or Car2X.

Question: How is the airtime for these things? If they have several hops, and there are 20 cars in front of the traffic light that can do this, and they receive the signal and all relay it again, how does that continue?

Answer: There are extensions so that the channel is used less when they detect that a lot is being sent. But basically, many packets simply collide. That is why they are sent repeatedly.

Question: Could this also be built into navigation apps, so that the navigation app chooses the traffic light that is most likely to be green?

Answer: Definitely, but there is currently no central place where I can query the data for all of Graz. We also do not have reception everywhere. The navigation device would have to receive it locally.

Question: You are now collecting a lot of data about all the trams. Would it not be a good idea to suggest to GVB that you do predictive maintenance?

Answer: No, I think they also have the data themselves. We hope they do not mind that we collect the data. But I think trams have relatively little privacy, which is why I can track them well.

Question: How useful is it to collect the data while moving, and on the other hand, how long would we have to do it stationary to get a data basis sufficient for statistical statements?

Answer: We are happy about all data that is reported. We store it, especially from traffic lights. You can also see that all traffic lights we have ever received remain on the map forever. But things like tram, bus, or car seen disappear again immediately. We want to publish as much data as possible, especially about traffic lights. We will not publish collected car data, because that does not make sense.

Question: How long should it be stationary?

Answer: If you want to operate it longer, we are of course happy. The best is: longer.

Question: I am wondering whether the drivers know that they are being monitored so precisely: what speed they are currently driving, how closely they cross a traffic light at red, and so on.

Answer: I can tell you that I did not know it for my car until I saw the packet from my car myself in Wireshark.

Question: I meant more the employees of Holding Graz.

Answer: The employees? Well, I assume the trams also send other real-time data, so they probably already know.

Question: How easy or useful would it be to implement this as a live display in your own car, to see what is happening around you?

Answer: You would have to adapt the website or make an app out of it so that it knows where you are and then shows you the lanes: left, straight, right. We do not know which lane you are in, but we can approximately know which traffic light you are approaching and from which direction, and show you the timer that the traffic light does not give you directly.

Question: I was thinking of vehicles around you.

Answer: Vehicles around you? I mean, you probably see those yourself better. That is more for driver-assistance systems, for automatic braking. If you can see the car, you do not need to look at the map.

Question: Have you thought about building a small heads-up display or similar for bicycles, where you could see: hey, the next green phases line up, or I do not need to rush, and can ride calmly?

Answer: Of course one could do that. It is currently relatively difficult to parse offline. Mick is working on a parser in Rust so that we could process it directly on the ESP. At the moment we have to send the packet to the cloud, because Wireshark does not run on the ESP. But as soon as it can be parsed offline, one could build it completely offline with a display and without an LTE connection.

Question: There are also bollards and barriers. Do they send anything too?

Answer: We have not seen that yet. Railway crossings, for example, do not send anything.

Question: Which car brands have you detected so far that send this? You mentioned VW.

Answer: Exactly. We also see Audi and Cupra very often. It is not a VW standard; they were simply the first to implement it. There will certainly be other car brands. I do not look out the window at every car to see what brand it is. But the tendency is increasing; more and more models will have it.

Question: Is it known whether any authorities or speed cameras also work with it? For example, where should I stand as a police officer, where do cars accelerate the most before red lights, where should I react faster, or something like that?

Answer: As I said, the traffic lights can report the data centrally. We do not know whether they use it. I cannot tell you that.

Question: Is it known whether cars that have this function also receive the data themselves and do something with it?

Answer: Yes, they definitely do. They show warnings around the vehicle. I get a warning: attention, stopped vehicle ahead of you, if that is sent.

We slowly have to finish now. I think you will still be reachable somewhere near the front, right?

We will be over in the other building afterwards at realraum, radio, fire, amateur radio. You can meet us there for longer, ask questions, and also pick up receivers.

Okay, great, thank you very much. On behalf of Grazer Linux-Tage, I thank you warmly, and have a nice day.

Thank you.

Applause.