 So this next talk will be in English. And the topic, as you might know of this whole Datenspuren conference this time, is berechnete Welt, which means either calculated world or computed world, depending on how you look at it. And last time I looked, part of the world includes public transit. And if I may say so myself, it should be a bigger part of the world, actually. And if we want to compute what is going on in the world of public transit, then one approach is to collect data from the buses and trams driving around outside. And how to do that will be a topic in this talk. Open data, receive it yourself. I would like to welcome Tassilo, Oksa, and Marens, and have fun with this talk. Yeah, hello. Thanks for showing up. And today we want to discuss what can you learn from looking at the transmissions that the public transport sends all around Germany. And for the radio part, I'll give it to Marens. So on the left, you can see a bus, or it could also be a tram. And this bus wants to approach an intersection. And of course, buses should be on time, so they get green lights from the traffic light. And first, the bus passes by an infrared beacon. There it gets its location. The standard is roughly from the 80s or 90s, so GPS wasn't used back then. And this bus will send out telegrams to the traffic light on different locations. So first, when it approaches, it sends a pre-registration, a registration. When it closes its door, it also sends a telegram. And after it's over the traffic light, it will also send the traffic light, the registration telling that the bus is over and it can continue normally. So what the bus is sending out over radio can also be received by other antennas, not only the one on the traffic light. So we just put an antenna up on a high-res building and try to receive it ourselves. So from the antenna, the signal goes into an amplifier, a hardware filter, and then it gets digitized by a software-defined radio. You can also see one of our first prototypes of the combined hardware filter amplifier right here. So that's the standard I talked about. It's from Faudevau, for Banddeutscher Verkehrswende. It's an association of German transport companies. It's a standard for 20, and it was standardized roughly in the 80s and 90s, and they have numerous different telegrams the bus could send. And there are even more telegrams which have been, so it has been changed over the years. And for example, there is a wire shark de-sector for the R09 18 telegrams, which have not been originally in the standard. So what data can we receive, actually? There's some information about the tram. It's line number, it's run number, and the destination where it's going. There is some location-related data. It's a 16-bit integer, and the lower bits of the 16-bit integer are the four states. I just showed you the four locations where it sends out the telegram, the registrations. Oops, sorry. And there's also some other miscellaneous data, like train length or delay, and depending on which telegram type it's sending out, maybe more data. And this standard has been changed over the years, and there are more documents on it, how you should decode this data. It's different all around Germany. There's no real implementation, which shows they do it in this city like that, and obviously they do it differently. So yeah, you really have to figure out yourselves, and it's quite hard. So we're looking for a burst transmission in probably two meters, 70 centimeter, or four meter band, and it is a minimum shift keying, modulated also called fast frequency shift keying with 2,400 board, and trams and buses tend to send a telegram twice after another, and as you can see in the left waterfall, this band is quite busy. So we started like seeing these nice antennas right here on the traffic lights, basically on more or less all traffic lights where public transport is going by, and this receiver right here is the receiver which receives the telegrams from the buses and trams. There are also specifications of them. There's a nice labor print on the side, so if you just get close by, you can read it, and yeah, these are the four frequency bands, sorry, three frequency bands where you can look forward. They can look forward. We also have a table of known frequencies from different cities, so if you want to have a look, take a look at the slides after all, this is the link right here, and you can also do some OSIN, so just search for frequency of your city or Ampelbeinflussung, that's the German word for it. Yeah, it's used all over Germany and also the Dach region, and if you can see all the blue points, this is the original standard from the 80s, 90s we implemented the receiver for it, but there are also different standards which is different physical layer, like for example in Berlin, they use a tetrapole and the included data doesn't seem to change there. Now onto OXA, he will show us how we can get precise locations from the 16-bit integer. Yeah, so one of the inspirations for all of this was the live traffic maps that a lot of cities have, but not in Germany, unfortunately. So for that, we need to achieve two things, we need to identify the telegram and identify a vehicle that sends the telegram, and then we need to bind it to a map location so we can actually display it on a nice map and spoiler, you can play with live map by the small cell, there is a nice touch screen waiting. So the R09 telegram doesn't provide any map position data, it's identified by arbitrary integer reporting point, which is melt point in German, and from that, three different numbers are calculated, which is a junction number, which is an idea of a traffic light, the direction, and request status. When you, and unfortunately we don't know how this corresponds to actual map location. So when you don't know something, you just try Google Shit, and after doing some Google search, we found a company that actually does this system for Dresden, as in any big company they want to sell their stuff, and if you want to sell the stuff, you make a nice sales material with nice screenshots from your tools, and in these tools, you have a nice map with some very interesting looking numbers, which in the end end up to be traffic light IDs. So you can just see, pour yourself some coffees, write out this data to a nice JSON file, the first version was done by hand, to have a first proof of concept. But by hand doesn't scale too well, and OSINT is really unreliable source of information. Another point, we have way more telegrams than traffic light IDs. From the previous slide, the actually unique number, the reporting point, traffic light ID is only one part of it, so every cross on this diagram is a sent telegram, so right here will be a traffic light. First, imagine you have like two trams or two buses going, that one going on the intersection straight, other one turns left. So every one of them will send their telegram with a different direction identifier. Here for example, one and five. First it will pre-register at this traffic light, setting the request status to pre-registration. Then if it will stop at the stop and open doors, it will send a telegram and it will close the doors. Then it will register at the traffic light, telling the traffic light, yes, I'm already here. And after it passes the traffic light, it will de-register. And like once again for these two different lines, it will be done with a different direction identifier. So you have like six, in this scenario, you have like six to eight telegrams per intersection. So we need some way to correlate these telegrams to my application. And for that, we can just go around and record the telegrams, but for that we need to select the telegrams from the right vehicle. And to identify the vehicle in these telegrams, two numbers are used. First is the light number, which is kind of this one. And you also need a run number, which is identifies this exact vehicle on this line. And in, for example, with Dresden trams, it's super easy. The run number present is almost always, it's this small black number on a piece of white cardboard in front. Buses are kind of hit or miss, but you can find this number by looking on this nice driver monitor. Chemnets, yeah, when we was in chemnets, there was no run numbers in front. It's really hard to see the run number in the trams because the new trams don't have a window to see in front of the tram. Buses are also hit or miss because the brightness of these places is very low. But this is, this was good enough. And then you need a way to record the telegrams to correlate them to location. So for that, we build a nice small setup, which is practically an SDR with the Delfin client in a piece of Tupperware. These records, here we don't use any hardware filtering. We just, we want to record as less data as possible so it's easier to filter through afterwards. So perfectly, you want to record it on data only from the tram you're actually riding right now. This all runs running of a power bank. We have a small web thing running on this that helps you record all the numbers of the tram you're riding. And regarding recording location to correlate this transmission positions to locations, everyone has a perfectly capable GPS tracker in their pocket nowadays. And then we have a small command line tool to actually produce the data file that links every transmitted telegram to allocation. So right now the process looks like this. To bootstrap some locations in the city, you just go around the city with the warfare which is this small setup. You track your position and writing down line and run numbers of the buses and trams that you're riding. Then you correlate this data and you know which reporting point corresponds to which application. After you bootstrap some data, you don't need the warfare anymore. You can just go around the city and if you have like a decent coverage by radio stations about which this will talk in a moment. So you can just go around the city and just track your position and line and run number. And then you can correlate your positions to the historical telegrams which are by the way available at files.defourbed solutions. And extract location data like this. So and we have, we basically need to improve on our mapping pipeline nowadays. In some, as I said, for example, in cabinets there is no easy way to get run numbers. So you have to infer them from the reporting points that were passed by a vehicle in which you did actual mapping like for example with the warfare. Go around the city part sucks. If someone has an idea how can correlate telegrams to map locations without actually tracking your GPS and going around in a public transport, please tell us. And we're working on a nice web app to submit your GPS tracks together with line and run numbers or just line numbers after the inference part is done. So we can update the positions of transmission locations most automatically with crowdsourced data. And after all the foreshadowing regarding our infrastructure, I guess I can just give it over to Tassilo who will explain all of it. Yeah, so aren't explained the radio layer. So how we actually receive it and also explained how we come from, I received telegram to an actual position. And my job now is to show you how from a technical side, how we build up how is our current scale of operation. So what you can see here are our four permanent installations of receivers in Dresden and Chemnitz. So we have one at University, one at Wunstraße and one here on top of the building and one in Chemnitz near University. With only those four receivers, we on good days approximately get 2,500 telegrams in five minutes, so approximately 500 telegrams per second. Then so how far, so this is the amount of telegrams we get. How far can we see? And here you can see the all the known stops that we currently know by the method that OXA has described. And you can see, for example, nicely, for example, at Hopebahnhoof, you can see they're getting a little bit darker because this is, for example, a very busy intersection. So we call it them. So how efficient is our current setup? We know from this nice Orbeek tool that Orbeek is the company who does the traffic analysis. It sits right at the Betriebshoof. And we know from one of their PDFs that Dresden has approximately 450 slides, 450 traffic slides. And from some nice querying, we approximately see 325, so approximately 70 to 80%. But now it's the question, how does such a station or installations look like? This is our installation at Dresden, on top of Turm Lavor. For that, this is some old GDR power supply as host systems we use, Dell-wise, those are Dell Fin clients. As a radio SDR, we use primarily radio ones from Camp 2015. But any RTL-SDR or NSDR perfectly works fine. Then we have the hardware filter that Marin's teased. The antenna, we use ground plan or dipole antennas. And then like a couple of Michelinius items and healthy amounts of Kapton to nicely isolate everything. On the receivers, currently our digitalization is done by GNU radio. We have some very nice, very enterprise C-C++ code which does, which like levels the noise floor and does the converter, where you see a ton of keying into actual bits. Those are sent then to Telegram decoder, which does then regional specific encoding. For example, the reporting point is differently decomposed in Chemnitz, for example, compared to Dresden or the different versions of the R09 Telegram. And we also record all the raw telegrams because the standard has more than the R09 Telegram. There are 16 R telegrams and 16 C telegrams. R telegrams are sent by the vehicle, C telegrams are sent by Leitzentrale. Then those are all sent to data accumulator, which does authentication and then we send it to, for example, Funnel, which is a public web socket where you can fetch your data from or we do a modeling of the traffic network. For example, the for BRP and then like the other two services are for management. That's more or less all the spaghetti and rigatoni we wrote over the last four months, from start to finish, from the actual antenna to the live map you can see. The glue we use to set it all up is Nix. We wrote very nice Nix options, which you can use to also set up your own stations or configure it to your needs. This is, for example, one of the remake pre-built images which you can fetch. And this is, for example, the radio configuration on those pre-built images. And yes, to manage it, we use WireGuard for very nice net punching to get into all homes and all installation places. Yeah, so how much load we can get. So we approximately get currently with our four stations, seven telegrams per second, but I did some load testing and we can get easily up to, so the blue line is how much my testing script said it can pump in and the red line is how much was actually came out at the other end at our web socket. So we can handle approximately 2000 telegrams per second, which is more than enough to more or less handle Germany from load perspective because a major city just produces approximately six telegrams per second. A couple of technical loans we took around the road was, for example, we started with Influx, which turned out to be a very not-so-smart choice because the primary key Influx was time and we had more telegrams coming in per second, so we more or less lost data because of that and because then we had to give out text to the Influx debate and yeah, this resulted in very nice monitoring setup where we also died hourly. So we quite quickly realized that and swapped Postgres for storing our data. And we also have crates, which are all services you as we are, more or less the standard is implemented in Rust and all the big loan we took was hardware and majority. I talked about the Dell thing and the Dell, we got them really cheap and we more or less used them for everything which was not so smart because we want to supply you with pre-built images and only having more or less one hardware pieces, not so smart for that. But the more or less interesting question for you as a technical audience is what data you can currently get from us. So over a period of approximately four months, we recorded 7.7 telegrams and there are hourly dumps of the entire database at files.defobey.solutions. The other thing I already mentioned is Funnel and it's a web socket stream with more or less all the telegrams that we recorded in just more or less the standard but encoded in JSON. Then also the stop JSON also public. So if you want to look up there, for example, the junction or the transaction in front of your house is to get out that number, you can look it up there. And our modeling is very can more or less fetch the current state of the network. So as you maybe can see it's a huge project and you want to do it a community driven way. So currently we operate more or less all stations but this don't has to be, we have a public endpoint with authentication where you technically could where you can set up a station, register your station and then you can also contribute by sending data for example to us. We also have a dire need of front end developers. So if you are a front end developer, we want to speak to you. Yes, you can also help us by mapping the city more or less in this and it's quite easy because you just for example need the OSM tracker from asteroid and you just need, as Xoxo explained, the line to run the start time and the end time and the GPS track to correlate more positions. If you are in a city, not in Dresden, Chemnitz or for example Ulm, taking an SDR and looking around 150 megahertz really helps. We want to increase the known frequencies for all the different frequencies where the train operator send and test our images or give us roof access if you have access to really nice high buildings. We would happily install stations there and all our code is at github.com slash dump d4b and with that we come to an end and open, we are open for questions. You guys are really quick. You guys are really quick, that's only half your time. So there is ample time for questions if you've got any. Maybe also if someone is not too fond or too good with English we can also take a question in German maybe and translate it live. So is there anything coming from the audience? Currently that's not the case. I was going to ask if you have any end user applications but now you've already covered that. The address we want to work on or is there anything else that you want to showcase or hint at? Yeah, so this is our map. You can also see it before the plan is on. And as you just could see right now there are frames happily going all over the place and buses. If you're also very happy about end user applications. So if you for example want to try yourself at for example route planning, you can use this live data to more or less update. For example we also found some really large XML files of all the schedules. So if you want to enhance the schedules by real time data we also happily give you all the data you ever need in this regard. Can you see the different models of buses and trams from that? No, sadly we cannot. No, that's the same. I was wondering I could get a live alert maybe when the D4B finally puts the new tram into service. No. Any other questions? Have you also tried looking up the DVB or 440 website? They also have their timing. How, when the, they have the time when the trams arrive where? Also on the website, have you tried crawling that? So you mean the nice displays at the stations? As far as we know most of it is wired in. So this is done over the wire. As far as I understood it's the data that you see on the website. So presumably there could potentially be an API for that as well. I mean the DVB app for example also gets this information of when trams are delayed and such. Yeah, this is also a good question if where exactly they get this data. If there is someone from DVB from audience please talk to us. Any, oh yeah, there's another question there. Two things. So there is a public, well not public but publicly accessible API by DVB which can be used to get routes and also delay times but it's blocked for the IP range of Teodristen because some students from the traffic students try to make a display that updates every bus every second to have something like this except they made a request for every bus for every second. So DVB decided that's too much for us and just blocked the entire range and is also not answering any requests in the last few years since this happened. I think it might even be 10 years ago or something by now. The other question you mentioned the file server where we can download the dumps, is it supposed to be empty? Yeah, we check it, it should be, yeah, it goes live and the other thing you mentioned with the faculty students, the socket is live so a corporation would be highly appreciated because they can get the real time, the data real time from us without curling the DVB RP every second. So it's more or less designed for. So for example, the socket has filtering so you can just filter for example Dresden so you don't get the data for Chemnitz and yeah, for example an application I've thought about was for example notification so you can configure the stations located near your house and you can get more or less push up notifications when the bus arrives at some stop where you then should start going. And just a quick comment regarding blocking the IP range this is radio so they cannot really block us. So this is in fact really a public API not just a quote unquote public API. Yeah, yeah, it's pretty much in the ether. How much transponders would you need to spread around to actually get full coverage? Have you done any estimations? So another point we need to fix one of the stations that's on top of one of the towers right here. Then we will get, I guess we will get quite a nice coverage of the right bank of the elbow and then for full coverage the problem is Dresden is quite non-trivial, topography is quite non-trivial so maybe for some remote neighborhoods we will need a separate station. But in general with two and a half stations we already have what's 60 to 70% coverage calculated from orbit data. Oh yeah and we need Dresden. Anyone from Dresden here? Or any further questions? I was also thinking do you collaborate with the Freifunk community in any way? Well, we're talking to Freifunk people from different cities because they usually the ones, the people with the high roofs. For example, the equipment here is installed pretty much near the Freifunk equipment. Last call for questions. If I don't see any hands raising, there's a hand raised. Have you tried out what you can do if you send something on the frequencies? Sending on these frequencies first of all, quite illegal and yes, just if you want to know like security related question for responsible disclosure, please come up to us after the talk. We can talk about this. Further questions? If that's not the case, then I would like another round of applause for our speakers.