Nov 24, 2013

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 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.

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 strings with names of terminal stations. They seemed like an easy starting point for reverse engineering.

Here's one such packet after dissection:

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.

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. 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.

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) disabled for the duration of the 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 "Tämä on Mono-Axentia-testiä... Toimiiko tää ees..." and "Määritykset ja tiedotteet tehty vain Monolla - ei mitään 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?

72 comments:

  1. Once again, terrific reverse engineering!

    ReplyDelete
  2. 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. Check Axentia's site for different types of displays they have, and see if they match.

      Delete
    2. 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
    3. 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
  3. I'd love to have one of these at home! Unfortunately I'm just a lowly web programmer that knows nothing about signals.

    ...You could totally Etsy this thing.

    ReplyDelete
  4. Funnily the German isn't correct... it sounds like something a foreigner would use. :)

    ReplyDelete
    Replies
    1. 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
  5. Dear mother of God. I think I'm in love.

    ReplyDelete
  6. Now it's time to spoof the signal and display your own messages in bus stops!

    ReplyDelete
  7. FYI, you have been slashdotted.

    ReplyDelete
    Replies
    1. http://tech.slashdot.org/story/13/11/24/148237/tapping-data-from-radio-controlled-bus-stop-displays

      Delete
  8. Amazing blog you got!!!!

    ReplyDelete
  9. Very impressive.

    I would love to buil myself a display showing my home stop's info. Please make your work open source when you feel up for it!

    ReplyDelete
  10. 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. The Omat lähdöt 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
  11. Fascinating hobby you have and I really enjoyed your write up.

    I used to use TNC's to decode satellite signals many years back when I was a licensed HAM operator. Built my own antennas and steering software as well.

    Radio has come a long way with USB software radios and controlling software. I would love to get into this again.

    Thanks for sharing...

    ReplyDelete
  12. 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
  13. Aivan aluksi, sun löydöksiä on ihana seurata - todella taitavaa puuhaa - olen oikeasti hyvin kateellinen :-) Sun aikaisempia 'edesottamuksia' on muuten julkaistu myös RTLSDR-blogissa (http://www.rtl-sdr.com), myös tämä juoruttiin sinne joten eiköhän lukijoita tule taas pian isosti lisää.

    Tsemppiä ja vielä kerran kiitos, loistava saitti!

    -Mac

    ReplyDelete
  14. The mentioned Mono (monitorien ohjaus) controls most information displays at terminals. The same suite of sofware also provides the Omat lähdöt -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
  15. Well Done, Very Nice,, must check how our bus system works, Could a receiver be built to deploy that bus updates to a Ios or Android app.. So you know how far the bus is from arriving at your place of pick up..or vice versa or where on the route it was ?

    :-)

    ReplyDelete
  16. Oona, you are awesome, thanks for sharing.

    ReplyDelete
  17. Fantastic.

    http://www.axentia.se/db/DARC%20Technology.pdf

    ReplyDelete
  18. Wow, congratulations !

    I tried to do the same in Paris and it looks they also use DARC to transmit the data.
    You can imagine my excitement when I saw somebody who went through the trouble of implementing DARC (I know nearly nothing in radio, so I was quite intimidated).

    Is it possible to have a few more technical informations to see if we can apply it in Paris?
    What hardware and software did you use? An RTL-SDR and gnuradio or something completely different?
    And the obvious question everyone is wondering: do plan releasing the code?

    Anyway, kiitos paljon!

    ReplyDelete
    Replies
    1. I used rtl_fm for FM detection, SoX for filtering, and the rest I wrote in C and Perl. No gnuradio involved. The radio has an RTL chip.

      I'm a bit reluctant to release The Code, because it's a hack using FIFOs and all kinds of nasty stuff, and I really wouldn't want to try and make it work across platforms - plus I wouldn't have the time to do tech support ;p

      Delete
    2. Thank you for the details.

      I understand that the code is a hack (yet impressive), but I believe it’s something I can cope with (much more than trying to understand all those strange things as phase shift).
      If I understand how it works, maybe I’ll be able to make something more robust, and if I don’t understand… well… at least I will have tried ;)

      Delete
    3. You sure are coy! I'm an expert C and Perl coder (so cool to see you also like it). I could easily help you clean up the "nasty stuff." I don't think anyone is clamoring for a cross-platform solution. We all just want to see what such a cool hack looks like.

      Delete
    4. Open sourced now. No need to help me though.

      Delete
    5. Open sourced? Hm, where? Cannot find it. PS: Great work! Thanks.

      Delete
    6. darcsdec.pl attempts to pipe to non-existent ./bits on line 102. Can you help with that?

      That is some gnarly looking code! You did warn me that running it would mess my machine right up, and it did. I take it one step at a time.

      Delete
    7. Yeah so I kinda forgot about this one bits.c. Thanks for the compliment about my code and great that you read the warnings

      Delete
    8. I just tested your darcdec package, I get the following sox error which terminates the program:

      mkfifo: cannot create fifo `pipe_01_bp': File exists
      mark/space split
      envelope
      difference
      bits
      sox FAIL mixer: Invalid options for this channel combination

      Parts above sox FAIL included for reference, to help understand which sox invocation is causing trouble. I have not started troubleshooting it myself yet, being far behind you in sdr and decrypting skills.

      Oh, and by the way, if the 'syndrome82' file is generated once and not changing, why not include it in the git? Took quite a while to generate it here. :-)

      Also, though not strictly necessary, wouldn't it be possible (in theory) to have the perl program clean up after itself when it terminates, killing those background processes and removing the fifo:s? Just curious, I do not expect you to implement it.

      Delete
    9. In Paris what radio station has the signal ?
      Thank you.

      Delete
  19. Very cool. Would it be possible to broadcast your own FM signal to overwrite the displays?

    ReplyDelete
    Replies
    1. 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
    2. some smartphones now has FM transmitter with RDS so you can send your mp3 music from the phone to your stereo on the frequency you decide....power of transmitter is low but maybe if you are very near to the bus stop you can send a fm signal with a nice message to display? :P

      Delete
  20. 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. You're correct. (I believe it's up there)

      Delete
  21. beautiful, and also gorgeous pictograms :)

    ReplyDelete
  22. Awesome project! What package are you using for your data visualization? The packet breakdowns look great, and some of your other posts have fantastic looking plots too.

    Thanks for sharing your cool projects!

    ReplyDelete
    Replies
    1. Thanks! I designed the packet breakdowns from scratch in Inkscape. For waveform plots I alternate between Audacity and Baudline, and then edit them in GIMP. Some plots are home-made with Perl.

      Delete
    2. Awesome, will definitely look into those. Thanks! Keep the learning coming!

      Delete
  23. Great work! would love to try this in denmark as well. Could you elaborate a bit more on the setup you use for this? i.e. hardware for recieving the signal etc.

    ReplyDelete
    Replies
    1. RTL2838 DVB stick was the radio. Should work with any SDR. The previous post elaborated on the physical layer demodulation.

      Delete
  24. Really nice article! I'm a young electronic designer and technician, mostly self taught and this is really inspiring :) Greetings from Spain!

    ReplyDelete
  25. 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
  26. Cool! I was first wondering how easy case this was based on hs article and found out it is not that trivial! Congratulations.

    ReplyDelete
  27. 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
  28. Wow, that's great!

    I really like the fact that you've put effort in designing those pictures too.

    ReplyDelete
  29. Hienoa! Kehoittaisin silti varovaisuuteen radiolähetysten kanssa. Laki sanoo että vaikka vastaanottaisi radiolähetyksiä joita ei ole salattu niin niitä ei saa jakaa eteenpäin jos niitä ei ole ko. kuuntelijalle tarkoitettu. Tämäkin laki on jotain esihistoriallista mutta tällaista tämä on..

    ReplyDelete
    Replies
    1. Kiitos huolenpidosta. Tunnen kyllä lait.

      Delete
  30. Todella mielenkiintoista! Et mitenkään voisi olla niin kiltti ja laittaa lähdekoodia ainakin osin jakoon? Tämä sivusto meni kirjanmerkkeihin nyt :)

    ReplyDelete
  31. Aivan valtavasti kiitoksia, kiltti nörttityttö! Uskomattoman hienoa työtä!

    ReplyDelete
  32. 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. Arduino can do all of this, save for the DSP stuff. Or you could make your own FPGA.

      Delete
    2. 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
  33. 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
  34. Just saw your CCC talk on YouTube... excellent work!

    ReplyDelete
  35. 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
    1. I've recently moved to Munich - ever tried to hack the local system?

      Delete
  36. Meni kyllä kirjanmerkkeihin. Upeaa hakkerismia ja hauskaa nähdä nuori nainen asialla!

    ReplyDelete
  37. This needs to be embedded to a wrist watch.

    ReplyDelete

To prevent spam, comments will only appear after moderation.