Subscribe to RSS Subscribe to Comments

freesoftwhere.org

Slightly more on RDS, TMC and open source

Just an update to my painfully slow learning process about Radio Data System (RDS), the FM-broadcast system for side-channel data.  As a recap, RDS can be used to send a variety of different data types, including FM channel niceties like the currently playing song (or the next song), station call-letters, weather alerts.  The most interesting to me is Traffic Message Channel, TMC, because RDS-TMC broadcasts are free updates about current traffic conditions.  The actual traffic info is gleaned from road sensors, traffic lights, even emergency responders.

Supporting RDS-TMC in any free software OS or app requires libraries to read and decode the data, and hardware that supports it.  The latter is the first topic of new info; it seems as though the Nokia N900 phone’s built-in FM receiver supports RDS.  That’s excellent news, as Maemo is the most open, just-like-desktop-Linux phone platform and has a developer community that’s one-hundred-and-crazy-percent motivated.

I’ve also stumbled upon a developer who is working on FM RDS support at codeplex; he is writing Windows code though.  The base library is http://www.codeplex.com/FM  and he is blogging about it as well.  Unfortunately, the code is only available under the Microsoft Public License (MsPL), which means it cannot be reused inside GPL’ed libs or applications.  But at least there’s knowledge.

Obviously, with HTC (ie Android) and Maemo devices supporting RDS generally, there are great possibilities for basic RDS usage, like having the FM tuner show RDS song info… supposedly Martin Grimme’s fmradio Maemo app  does read RDS data, but I haven’t found it to work for any of my local stations (this is not a bug report, though — it could easily just be my lousy stations).  Reading the Python code makes it look really straightforward, but it’s not immediately usable by other apps.  Which I care about because the more interesting possibility to me is RDS-TMC on these platforms.

Sources of data

That brings me to the next subject for update: a polished RDS-TMC stack with supported hardware still needs a live, broadcasting source of TMC information.  I’m having a great deal of trouble tracking down accurate info on TMC FM broadcasts in North America.

The Wikipedia entry has been updated several times since my last post, but is thin on references — and how lame is it that Wikipedia is my best source of information?  Allegedly “INRIX,” Navteq Traffic, Clear Channel and Tele Atlas all broadcast FM TMC … somewhere.  Where exactly is not specified.  Even the Navteq Traffic wiki page lists a few big cities, but without an external reference.

Worse, the suggestion is that commercial TMC broadcasts are often encrypted in one way or another.  And you guessed it, there is little in the way of public information about that….

License compatibility of data

An even bigger  problem, however, is the legality of using TMC data.  The trouble hinges on the fact that TMC messages use location tables to compactly encode where events are happening, and the location tables are not available for free.  Then again, it also hinges on the fact that private companies like Navteq Traffic collect the road sensor data and sell that as a service to the people who actually broadcast the FM signal.

In the long run, there is at least a possible workaround for the TMC location table nastiness: TomTom has started an open source location referencing project called OpenLR.  I wrote about it in September.

As I mentioned last time, there are also alternative methods to grab rough traffic information, such as Floating Car Data aggregated by GPS-equipped cars and phones. I still don’t think there’s a free software project collecting that info.

The End!  I know I’m only barely scratching the surface of this subject; it’s way outside my usual beat so I’m doing a lot of lernin along the way.  Comments welcome.

Traffic

Are you a satisfied OpenStreetMap user? You should be; OSM has user-generated and user-maintained data, and provides a service equal to that proprietary software companies have been charging exorbitant rates for … based solely on the scarcity of the free, public information at the service’s core.

Which got me to thinking about real-time traffic data.  The situation is exactly like the pre-OSM map situation: the “data” is public and free, and consumers have to pay to see it because there is no free alternative.  Ripe for change.

It’s a complicated subject, but in broad strokes there are two major ways to determine traffic information: listen to public Traffic Message Channel (TMC) information on the radio, and aggregate individual user motion culled from participating GPS devices on-the-road.

TMC is a form of Radio Data System (RDS) broadcast and is a published standard. RDS is a sideband of FM radio, and is also used to broadcast song titles by participating FM stations, emergency alerts, and a few other information types. The trouble is that so few devices pay attention to the RDS channel — only a handful of car radios do, and expensive in-vehicle navigation systems do, and that is about it. So the free RDS-TMC data is flowing right past all of us, doing no good.

Making use of it means getting it into the computer, and that seems to have some prerequisites: first, an FM tuner; second, that FM tuner must provide raw access to the antenna, not something hardware-converted directly into a stereo audio stream; third, something to decode the RDS-TMC data stream itself; and fourth, a database to look up the highly-abbreviated hexadecimal TMC messages and convert them into useful stuff like place names.

As near as I can tell, there is exactly one GPL software package capable of reading RDS: srdsd. Unfortunately, it is built to be hooked up to external tuning equipment, perhaps because the authors are as interested in RDS encoding as decoding. There are a few hardware adapters out there specific to RDS, bluetooth and USB, but they are all from one company, GNS, and naturally there are not free drivers. So the big question is how many FM tuners in Linux boxes can actually receive RDS signals?

Scratch that; a better question is how many FM tuners in cell phones can receive RDS signals? Supposedly many can, and suposedly many GPS devices are also capable of RDS decoding, but so far I have not turned up a definitive list.  Apparently some HTC devices can, because there is a shareware project to support them. The Dash Express and TomTom dashtop devices have RDS-TMC built-in or available as add-ons.

Anyway, to sum up, here is what I think would be required to build a crowd-sourced free traffic data source: daemons running on mobile (or desktop) devices that receive RDS-TMC data from nearby FM transmissions, and report what they hear to the central database. Of course, each device can utilize the local data for its own routing purposes; the aggregation would benefit users who don’t have a device and assist in route planning by showing a broader picture. The good news is that “real time” data here is far slower than with GPS tracking; on the scale of one update every few minutes, let’s say. Stationary devices could participate, too, since relaying the information is helpful to everyone even if you yourself are not on the move.

Unfortunately, I have no idea how many FM or GPS devices are out there that can pick up RDS-TMC, so I can’t even begin to speculate on what the coverage would be like. It would require each device owner to run specialized (albeit unobtrusive) software on their device. The other big option would be to have GPS-capable devices simply phone in their position and speed (anonymously, hopefully), then aggregate that.  Far more devices could participate, no RDS-TMC drivers or decoding needed, but it would still involve widespread participation to provide meaningful traffic updates.

Any thoughts?

Based on FluidityTheme Redesigned by Kaushal Sheth