https://www.windytan.com/2013/11/decoding-radio-controlled-bus-stop.html absorptions a blog about sound & signals by windytan [oona raisanen] Pages * home * list of posts * about & FAQ * my nerd story Decoding radio-controlled bus stop displays by Oona Raisanen (Oona Raisanen) Sunday, November 24, 2013 In the previous post I told about the 16 kbps data stream on FM broadcast frequencies, and my suspicion that it's being used by the bus and tram stop display system here in Helsinki. Now it's time to find out the truth. I had the opportunity to observe a display stuck in the middle of its bootup sequence, displaying a version string. This revealed that the system is called IBus and it's made by the Swedish company Axentia. Sure enough, their website talks about DARC and how it requires no return channel, making it possible to use battery-powered displays in remote areas. [Image: Photo of a liquid crystal display showing the text: 8589 IBUS 6.5.70d] Not much else is said about the system, though; there are no specs for the proprietary protocol. So I implemented the five-layer DARC protocol stack in Perl and was left with a stream of fully error-corrected packets on top of Layer 5, separated into hundreds of subchannels. Some of these contained human-readable ISO-8859-1 strings with names of terminal stations. They seemed like an easy starting point for reverse engineering. Here's one such packet after dissection: [Image: An infographic titled 'Bus & Destination Packet', showing the hex bytes of a 64-byte packet, divided into fields that are labeled according to their apparent purpose. There are counters, size fields, the bus stop identifier, bus line identifiers, and apparent references to other types of packets. Several fields containing Latin-1 text are also transcribed. The text in them reads '23N RUSKEASUO BRUNAKARR'.] Each display seems to store in its memory a list of buses that can be expected to pass the stop, along with their destinations in both official languages. The above "bus & destination packets" are used to update the memory. This is done once a day for each display on a narrow-band subchannel, so that updating all the displays takes the whole day. The mapping of the bus stop ID to actual bus stops is not straightforward, and had to be guessed from the lists of buses, on a case-by-case basis. A different kind of packet updates the remaining waiting time for each bus in minutes. This "minutes packet" is sent three times per minute for every display in the system. [Image: An infographic titled 'Minutes Packet', showing another type of labeled packet. Most fields are one byte long and they contain the number of minutes until the next bus arrives, in 7 bits, and one bit telling whether this estimate is based on positioning or time tables. Information about which number belongs to which bus is contained in the references from other types of packets.] These packets may contain waiting times for several displays using the same subchannel; the "bus & destination packet" contains an address to the correct minutes slot. (The subchannel address is signaled on a lower protocol layer.) A special flag is used to signify an unused slot; another flag indicates that the bus has no working GPS and that the time is an approximation based on timetables. This causes a tilde "~" to appear before the minutes field. This means all calculation is done centrally and the displays only show numbers they hear on the radio. There's also an announcement packet that's used to sent text messages to the displays. Often these will be about traffic disruptions and diverted routes. It's up to the displays to decide how to display the message; in the low-end battery-powered ones, the actual minutes function is (annoyingly) blanked for the duration of the slowly scrolling message. I have yet to figure out the meaning of some packet types with non-changing data. A special subchannel contains test packets with messages such as "Tama on Mono-Axentia-testia... Toimiiko taa ees..." and "Maaritykset ja tiedotteet tehty vain Monolla - ei mitaan IBus:lla" suggesting that they're planning to migrate from IBus to something called Mono. Interestingly, there's also a repeating test message in German - "Bus 61 nach Flughafen aus Haltestelle 1". What good is it, you ask? Well, who wouldn't want a personal display repeater at home, telling when it's time to go? [Image: Photo of a small liquid crystal display kit with its PCB showing, obviously home-soldered to a bunch of wires, and displaying the text: '72 TAPANILA ~12'.] Labels: FM subcarriers, infodump, reversing, signals - Newer Post Older Post - 26 comments: 1. [blogger_lo] toni24 November, 2013 14:59 Hmm, what would be the most straightforward way to figure out if the bus/tram stops in Berlin use the same system? ReplyDelete Replies 1. [blogger_lo] Oona Raisanen25 November, 2013 00:39 Check Axentia's site for different types of displays they have, and see if they match. Delete Replies Reply 2. [blank] Anonymous28 November, 2013 02:45 actually berlin seems to use http://www.lumino.de/ referenzen.html those guys, they mention nothing with radio on their site. but maybe the train cars and busses themselves send something. Delete Replies Reply 3. [blogger_lo] toni30 November, 2013 23:05 I found out that they might be using commercial-grade TETRA (non-encrypted). The equipment is made by Funkwerk. Not as easy to listen on as the IBUS system but could be still doable. Here is some more info about TETRA in Germany: http:// tetra.osmocom.org/trac/ Delete Replies Reply Reply 2. [blank] Anonymous24 November, 2013 15:16 Funnily the German isn't correct... it sounds like something a foreigner would use. :) ReplyDelete Replies 1. [39140447_6] Saint Fnordius25 November, 2013 18:10 Actually, it looks more like a case of placeholders in a string that the bus company decided not to use/implement, with "Flughafen" as a placeholder for the the end station, and "Haltestelle 1" for the origin/first stop along the route. No thought was given to actually naming the stations or altering the strings. Delete Replies Reply Reply 3. [Poikola_An] Antti Poikola24 November, 2013 17:30 cool! I wonder if the radio data is the same that comes out from the HSL API http://developer.reittiopas.fi/media/ Omat_Lahdot_v101.pdf / http://developer.reittiopas.fi/pages/fi/ other-apis.php ReplyDelete Replies 1. [blogger_lo] Oona Raisanen24 November, 2013 17:31 I hear it's the same. Delete Replies Reply 2. [blank] Tuukka Hastrup24 November, 2013 17:51 The Omat lahdot service and open API from the transport authority contain this same data indeed. However, the textual messages are not available through those, so that's new. Moreover, the GPS location data from the busses would be interesting as that is not available like it is for the metro, trams and trains. Welcome to participate in the transport authority's developer community! http://dev.hsl.fi/ Delete Replies Reply Reply 4. [blank] Anonymous24 November, 2013 18:28 Good job! How nice of Axentia to have created such an open system. Perhaps their aim was to crowdsource the maintenance of bus stop bus lists, as well as estimated times of arrival for buses ;-) So, to add to your list of potential applications: helping HSL with bus stop display maintenance tasks. ReplyDelete Replies Reply 5. [blogger_lo] Lauri Kangas24 November, 2013 21:58 The mentioned Mono (monitorien ohjaus) controls most information displays at terminals. The same suite of sofware also provides the Omat lahdot -service and API. Mono gets the real time information from a system called Helmi, which is an implementation of the Thoreb IT-radio product. Helmi also controls the non-battery powered displays at bus and tram stops direct. Helmi is rather old and based on a proprietary radio network with Satel radio modems. The buses don't send out their location. Instead they track their location against route and timetable data and send out event messages about their progress. This is basically due to the limited data carrying ability of the radio network. Route and timetable data is updated at the depot via wifi (used to be something else). The real time GPS location information for trams is provided by separate newer devices, which are not installed in buses. ReplyDelete Replies 1. [blogger_lo] Oona Raisanen24 November, 2013 22:03 Thanks for the insight! Delete Replies Reply Reply 6. [Self] Peter25 November, 2013 16:10 Very cool. Would it be possible to broadcast your own FM signal to overwrite the displays? ReplyDelete Replies 1. [R0011581-4] Johan Adler29 November, 2013 09:47 In theory it is possible, but also illegal of course. You do not want to transmit on frequencies you are not allowed to use, and public service FM channels are usually very much off limits. :-) Delete Replies Reply Reply 7. [blogger_lo] banjohat25 November, 2013 23:58 Very impressive! I've been looking for this for years - even called the bus company once but they didn't know anything about how it worked. I believe that it's the same system (in a different package) that is used in the Copenhagen area. Would be a lot of fun to try and see if it was really the same system. What confuses me is the broadcasting. is it correct that route information (lines and destinations) are sent once a day to the displays, while the timing information is sent 3 times a minute - to all displays in the system? ReplyDelete Replies 1. [blogger_lo] Oona Raisanen26 November, 2013 00:03 You're correct. (I believe it's up there) Delete Replies Reply Reply 8. [Untitled-1] Seepra26 November, 2013 18:15 I'm incredibly envious of your skills and expertise. I'm definitely subscribing and devouring all of the content you've put up, thank you a lot! :3 ReplyDelete Replies Reply 9. [blank] Antti Paasivaara26 November, 2013 22:16 That should be turned into home decorative. I would put such device to my hallway. Would be handy. No need to check busses from computer anymore. Just go and check near the door, when the next one comes. Would be great to have such thing as an application too. For non-technicians. :) ReplyDelete Replies Reply 10. [blogger_lo] Unknown30 November, 2013 01:05 What would be the smallest form factor hardware setup this could be implemented on? I could actually do the processing on a separate machine and send the data via TCP. So I guess I would be looking at some very simple SoC with WLAN and LCD interface. Any suggestions for this? ReplyDelete Replies 1. [blogger_lo] Oona Raisanen30 November, 2013 09:32 Arduino can do all of this, save for the DSP stuff. Or you could make your own FPGA. Delete Replies Reply 2. [R0011581-4] Johan Adler30 November, 2013 13:09 A Raspberry Pi should be able to handle it, I think, and it is rather cheap. Connecting an LCD display should not be a problem, and Ethernet is there from the start. If you want an embedded solution you may want to check one of the STM32F4 Discovery boards (www.st.com/stm32f4-discovery). The ARM Cortex M4 MCU line is said to have specific DSP instructions, and the 32F429IDISCOVERY (http://www.st.com/web /catalog/tools/FM116/SC959/SS1532/LN1199/PF259090) even has a TFT display. This and the original STM32F4DISCOVERY (http:// www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1199/ PF252419) both have USB OTG, but I suspect that you may have to write your own rtl-sdr library for that platform. The boards mentioned above have support for Ethernet but need some external hardware, so one possible solution would be to have e.g. a RPi with the dongle, maybe running rtl_tcp, and let the ARM board handle the DSP part. If you want something smaller than the RPi you could check the Carambola 2 (http://8devices.com/carambola-2) running OpenWRT, I have read about the rtl-sdr library being ported to OpenWRT. Delete Replies Reply Reply 11. [blank] ruben28 December, 2013 02:04 regarding the german message you've found, maybe it's something from http://www.initag.com . it's what is used here, and for what i know, they use wifi and other radio stuff to communicate with the displays (and their "hangars" for the chip payment systems).. hope that helps ;) ReplyDelete Replies Reply 12. [blank] Anonymous21 February, 2014 17:46 Greetings from Munich! The local public transport company also uses the Axentia iBus system, and now I think I have to get some more SDRs and build some nice displays... :) Thanks for doing all the stuff like descrambling the data, releasing the code...just thanks a lot! Keep on doin'! :) ReplyDelete Replies Reply 13. [blank] simosagi18 May, 2015 15:28 Today I spotted a display that was apparently also stuck at bootup, it was showing 8221 IBUS 6.5.100d. Doesn't seem there has been any big f/w updates in the last 2 years ;-) ReplyDelete Replies Reply 14. [blogger_lo] Unknown28 October, 2018 17:37 Extremely interesting. Would this be usable for accessing a terminal a few kilometers away where internet access is an issue? ReplyDelete Replies Reply 15. [blogger_lo] Craig11 September, 2021 09:30 Thanks for the information, yours was the first site I came across, when I searched Google. Currently playing with my new SDR, so looking for things to decode in UK. ReplyDelete Replies Reply Add comment Load more... The comments section is pre-moderated; it will take some time for the comment to show up. You might want to check out the FAQ first. Subscribe to: Post Comments (Atom) absorptions Absorptions is one computer geek's personal hobby diary. I write about my research and adventures in the world of signals and sound, and fun things I do with the computer. See the FAQ. I'm on the fediverse and Twitter Labels biohack (2) computer art (8) computer vision (5) cryptography (4) FM subcarriers (9) hardware (15) infodump (16) life hack (2) Linux (5) music (5) Perl (4) puzzle (2) reversing (11) security (4) signals (33) toys (5) two-way radio (4) Popular Posts * [dialup-fin] The sound of the dialup, pictured If you ever connected to the Internet before the 2000s, you probably remember that it made a peculiar sound. But despite becoming so familia... * [bitteja] Mystery signal from a helicopter Last night, YouTube suggested a video for me. It was a raw clip from a news helicopter filming a police chase in Kansas City, Missouri. I q... * [IMG_0541a] Decoding radio-controlled bus stop displays In the previous post I told about the 16 kbps data stream on FM broadcast frequencies, and my suspicion that it's being used by the bus... * [rdstmc] A determined 'hacker' decrypts RDS-TMC As told in a previous post , I like to watch the RDS-TMC traffic messages every now and then, just for fun. Even though I've never had a... * [IMG_4114a] Eavesdropping on a wireless keyboard Some time ago, I needed to find a new wireless keyboard. With the level of digital paranoia that I have, my main priority was security. But ... * [darc] Broadcast messages on the DARC side By now I've rambled quite a lot about RDS, the data subcarrier on the third harmonic of the 19 kHz FM stereo pilot tone. And we know the... * [IMG_7613] The burger pager A multinational burger chain has a restaurant nearby. One day I went there and ordered a take-away burger that was not readily available. (E... Check out these blogs * Hack a Day * Gough's Tech Zone * DataGenetics Powered by Blogger.