That's great. So now we can use GPS to make it accurate without requiring user intervention! Any takers?

It would take an injection of, well, *something* to turn me back into any sort of programmer, but I may try to follow along with whoever does this. My inferior motive continues to be a big, plain HH:MM:SS clock that would update from a 1pps signal (for an in-dash rally clock -- no need to run with the player, could run off Hijack in place of the player).

On a quick and dirty basis, I even thought of a script that would pipe time stamp to "date" to keep clock synched on a settable, periodic basis (once every 10-30 minutes would work for me). I found an ARM date binary that worked, FWIW.

I know that over in some of the other GPS threads, yn0t_ and others mentioned the program gpsd. (Not sure who is maintaining this now. I found a "gps3d" at http://www.mgix.com/gps3d/ with sources. Not sure if it is branched from the original gpsd or what). Anyhow, not sure what the proc/memory footprint would be for one of these, but I wonder if it would be feasible to use? The advantage would seem to be that the daemon would already handle the serial interface, leaving you only to worry about fetching data from the daemon and displaying it (or updating clock or...). One other advantage, I think, would be that a gpsd/gps3d could handle requests from multiple clients, so if you wanted to run a nav screen along with a clock setting program along with....whatever, you could mix and match --- not have to stuff everything into one binary that has the serial port locked.

(Of course, the gpsd may, relatively-speaking, be a pig, so this tangentential thought may not be the right lean-and-mean approach)