Wrong assumption #1.

Of course, you still have to deal with not letting one client change the device's functions on top of another. Maybe just a filter for such strings and let the daemon do the init, with a suggestion to the clients to not try inits and define the way that the daemon will set it up.

Most things you can do to change a GPS receiver are harmless. The ones that might matter that I can think of are changing whether you cold start and making sentences come in less frequently or not at all (for receivers that support configuring what and when you get sentences)

You could simply filter all proprietary sentences but some of them are useful. Making a "blacklist" would work but could get messy, since it means we need to know what every proprietary sentence *is*.

How about an ioctl() interface in Hijack which lets user apps (in this case, GPSapp) register a /proc entry and another ioctl() for them to publish information to that /proc entry. Then Hijack stays out of the business of parsing NMEA/TSIP/whatever.

So gpsapp would do its normal parsing of whatever GPS data is there, and register a proc entry with something like

char szProcFilename[16] = "empeg_gps"

char szGpsBuffer[4096];



rc = ioctl(fd, EMPEG_HIJACK_PROCREGISTER, &szProcFilename);



// parse GPS data, put it into text buffer szGpsBuffer



rc = ioctl(fd, EMPEG_HIJACK_PROCPUBLISH, &szGpsBuffer);

.

Then any app can put an entry in /proc, and any other apps can go and read that data. Worthwhile or no?

I have the older gpsTripMate... but then I haven't actually plugged it in recently...

Cheers

Kim

The Tripmate will do NMEA, it just needs you to send the "ASTRAL" init string at it.

Instructions for fixing that are here or here.

Has someone already looked into compiling gpsd and using it? Seems like a decent little daemon for this purpose...

Search the bbs for gpsd. Better yet, read the changelog in the directory you provided the link to.

oops sorry about that it appears people have checked it out more than i know..

In reply to:

---

Yeah. That would work. You'd have to make sure all of the programs behaved and would close the fifo when it's not needed. I'm also not sure how you'd know that somebody else is reading the fifo.

The problem with the fifo is that you'd need to make sure that the fifo is being read at the same or faster rate than it's being written to by the gps daemon. Otherwise you're going to end up with stale data. *shrug*

---

I'm just learning about fifo's but I've read when you open a fifo for writing, and that fifo is not opened for reading, then the open command returns an error. Is this correct on the empeg, too?