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.

Comments(0)

I really like the fact that Ubuntu is revamping the GNOME “notification area” because as it stands now, it is a trough that accumulates interface debris.  But aside from the inconsistency, the one use case I don’t understand is minimize-to-tray, in which an application disappears from the window list (ie, usually disappears from the panel), but still lives in an icon.

For one thing, this behavior is almost always prompted by the user attempting to quit the app (such as with the “X” button), so it’s incorrect. Quitting is the “common case;” the common case should be fast, and should be consistent across the desktop.  When I click the “X” on Thunderbird or EOG, the window/app quits.  So when an update release of Rhythmbox decides that *it* will no longer quit, but simply minimize to the tray on “X,” it is breaking the convention and detracting from the consistency of the desktop.  Tenfold more annoying when the behavior appears in one release without warning.

But the second and more fundamental complaint I have is that there is no advantage to minimizing to the notification area.   There, each app is represented by a single icon.  In the default GNOME panel’s window list, each app gets its icon and the window name if space is available. That’s right, IF.  There is no space saved by minimizing to icon-only form, because the extra text of the app/window name is only displayed if the required space is free.  The other notification-area-icon uses (displaying a blink on activity, popping up a message) are also available to the app when minimized to the window list.  I frequently “check my messages” by glancing at the window list to see if the window name has changed (e.g., Inbox (32), Facebook (New message from CrazyDudeFromHS!)).

In other words, minimizing to an icon in the notification area just needs to go, period.  There are certainly use cases for apps needing to live only in the notification area (such as Update Manager alerts), but for interactive user applications, there’s no case, and no benefit.

Comments(0)

So I’ve finally figured out what bothers me about 3-D entertainment (and no, it’s not that all of it sucks post-Captain Eo … although that is true….).  It’s focus.  In 2-D photography and cinematography, depth-of-field creates a sense of depth, naturally, by having the foreground in focus and the background gradually more and more out-of-focus as it recedes.  But it’s a bit of a trick; we can look directly at part of the out-of-focus image, and it stays out-of-focus.  Unfortunately, this is not how our eyes actually work in real life.  In real life, our eye automatically re-focus on everything we look at, meaning when we look at a scene, in a certain sense, everything appears in-focus.  Our sense of three-dimensionality comes from being physically present in the 3-D environment, and the depth perception of using two eyes to look at it. But when we focus on what’s in the foreground, we do actually lose focus on the background.

3-D movies mess with those independent senses; if there is shallow depth-of-field, we can look at part of the image and it stays out of focus, but still feels 3-D because of depth cues caused by the high-tech magic of the imagery.  If there is deep focus, we don’t have that screwyness, but we’re limited to the odd camera lenses  (often wide-angle) that produce deep focus, or very peculiar lighting to cater to the more stringent aperture requirements.  Either way, that stops looking natural after a few hours.  Citizen Kane is all peculiar photography, but you can’t watch everything shot that way.

In short, I guess you can count me among those who really thinks 3-D  “looks cool” to the eye because it’s so UNnatural.  So it’s novel, yes, and impressive, perhaps, but I’ve never thought it made anything look better.

Comments(0)