Gpsd is an option (the code is there), but we can't open a tcp connection to localhost because there is no loopback network device, and because the disks are not writable a named pipe or unix domain socket is probably hard to do as well.

(Wow! I have to say that I am feeling "Hijacked!" by this thread. Another evolving project where Jim just can't keep up!! Seriously, it is exciting to see all the activity. Less talk, more action, indeed.)

No loopback interface. Interesting! Never gave that a thought. I'm thinking that was left out to help reduce the image. Is there any way to work a Hijack-style workaround? I'm just feeling that there could be other reasons down the road to use loopback.

On the clock front, I looked in the Readme (finally!) and elsewhere and didn't see any reference to setting the Empeg's clock. I didn't necessarily expect this, but I began to think about what would be the most desirable way to derive time for a clock display in the case that satellites were not in view.

I don't want to overestimate the risk of having no GPS time available. While most commercial units seem to refuse to display much of anything unless an initial fix has been achieved, is there any reason a custom application could not display time from as few as 1 satellite? I mean, they are all UTC, and I wasn't thinking delay would be a huge factor (or that GPSs did much to adjust time from traingulating satellites. I could certainly have a lot of this stuff all wrong.)

If you could display time from a 1-2 satellites independent of quality of fix, then going through the loop of having clock display read from Empeg's local clock would seem less necessary. OTOH, it would be a nice feature....and might be another reason to lust after loopback access to gpsd -- another modular process could set the local clock from gpsd rather than having the main gps app do it.

For a big-digit clock, was thinking of some kind of quality meter on the right hand of the display with 4 or 5 bars. Something like:
0-Local clock not set in past 3 hours
1-local clock set in past 3 hours, but GPS time not now available.
2-local clock set in past 3 hours, and GPS stream now available.
3-local clock set in past 30 minutes, but GPS time not presently available.
4-local clock set in past 30 minutes and GPS time available.
5-local clock set in past 10 minutes from GPS time

I probably haven't thought this through very completely yet, but will give it some more thought and welcome any comments. The goal is to have a clock that is always available and is as accurate as possible, but with some indication of trustworthiness. If I missed any clock related stuff in the work to date. my apologies.

Again, this is very exciting. I need to get that serial interface built!