I have a suggestion to GPSApp- why not make a file (called Named Pipes or FIFO in unix?) that other processes can read from to get the current coordinates and speed (and maybe other stuff?) from GPSApp. I'm sure people can think of a lot of useful apps that will read the vehicle's speed and do something with it.
I have another feature suggestion to GPSapp also: Calculating the sunrise/sunset time for the current location. This information is very useful to me as an amateur photographer. I found some code that does this and I'm going to get it working on the empeg. If I get it into a function form would the author of GPSApp, jaharkes?, be interesting it into integrating into the UI for me?

That would only work for a single external program unless you're willing to have a fifo for each.
I guess you could implement it as a socket though.

- Trevor

Calculating the sunrise/sunset time for the current location.

COOL. That's a nifty idea for GPS software I hadn't thought of yet. I can think of a lot of uses for this. For instance, I have a friend who follows a religious tradition of fasting during the daylight hours on certain days of the year. For him, the exact moments of sunset and sunrise become rather critical.

What other neat things can we do with a GPS that aren't necessarily obvious right off the bat? Here's what I've seen so far:

- Automatically set the player's time clock and time zone, and keep them accurate.

- Calculate sunrise/sunset as described above.

- Use a database to warn when you're near a fixed speed-camera trap or other similar civil-revenue-generator.

Anyone else have any ideas? Sitting here thinking about it, I imagined another one: Astronomy. Calculate what planets and constellations would normally be visible from your current location and time, and list them with directions to locate them. Dunno if the empeg screen is large enough for an actual full-sky display, though. It'd have to be just a sliver of the sky that you could scroll.

Ooo, would make a cool visual, though... have the display be an accurate picture of the horizon, based on location and heading. For instance, if the moon is setting on the horizon with Venus next to it, you'll see that on the empeg screen if you happen to be driving west. And then it could have symbols up on the screen telling you what you're seeing.

Making a file requires remounting a filesystem read/write.

That would be pretty neat.. Would also be cool to have the Knob rotate through highlighting the displayed stars, and give name/info..

requires remounting a filesystem read/write.

Yes, *creating* a file requires r/w mount. Once it's created, though, updating it in-place could be done with raw writes to the disk, even with the drive mounted ro. This is on the list of Hijack features that would be nice to have someday, but haven't created a high enough demand for Mark to implement it.

There's no point in counting on using features that don't exist. There's probably a better way.

Since a fifo doesn't store any data on the drive, it works fine on a read-only file system. That's how TTSd works.

One of the neat features of unix.

You still need to create it.

And I still think we can do something better.

To be a little more clear, a fifo limits you to one external app at a time. If each app just reads from the fifo and closes it, it's available for another to read. Although, I'm not sure if you can tell if another app is trying to read from it so you should wait...

letting you know when you are near a petrol stations / how far to the next one... and if the data is available (as it is in Perth and more generally Australia) what the price at the station is today.

Not sure about a db of lat lons, but should be able to be generated from the street addresses and access to an online map. Once generated for an area could be a useful resource to share with others.

Cheers

Kim

letting you know when you are near a petrol stations / how far to the next one...

Ooo, what would be really good is if one could go by company. I have a Chevron card and prefer to buy my gas at Chevrons for that reason. I'd love to always know where the next Chevron was along my planned route.

Way back in days of old when I used to write QNX apps, we used to use the IPC message sending abilities quite a lot (see here for a quick description).

I had a quick google (as I don't write Linux apps for a living) and came up with the details of the same mechanism in Linux(here).

So I guess that it would be possible for GPSApp (or the backend to it if it ends up being split) creating a message queue with a known key, so it can be found by any app that wanted the info. Each app in turn could also set up its own queue, and and send the details for that to GPSApp when registering in GPSApps queue.

Then whenever GPSApp has some data to send (an update from the receiver), it checks its queue, and adds any new queues to its list, then just cycles through all of the quese it knows about sending them the same data, that way the app writer has the option of only checking the data when it wants, or sitting recv blocked waiting for the latest data.

So, any comments?

I was already discussing this with dbrashear in some other thread. Basically gpsapp should at some point be split up in a backend, which very possibly could be gpsd, and possible multiple frontends. Communication could go through a shared memory page, socket, or named pipe.

Things that frontends could do are numerous. Show directions to local restaurants that are still open, especially fun if it isn't a list of mickey d's, but those excellent local places that you'd never know about unless someone told you. Automatically reprogramming the tuner for local radio stations when driving long distances. Public 802.11 access points in the area, to get that daily empeg.comms.net fix while you're on the road.

It would also make it easier to keep gpsapp responsive, a background thread/process could do the map-drawing while the main program just deals with key input and refreshing the display. Similarily we could track progress and pop up directions even while the gpsapp visuals are not active (i.e. when we're in the player app).

The sky is the limit. Although in reality, available programming cycles are probably more the limit

Automatically reprogramming the tuner for local radio stations when driving long distances.

Oh yeah, I'd forgotten about that one. That would rock!

Public 802.11 access points in the area, to get that daily empeg.comms.net fix while you're on the road.

Ah, the empeg equivalent of warchalking. COOL.

Ah, the empeg equivalent of warchalking. COOL.

And, thus, the term "warpegging" was born.

Delorme Street Atlas has information on local radio stations and restuarants, gas stations, etc.. The restaurants and rest stops could be exported and transformed to another format via parsing the output of a Garmin GPS emulator I found. (i.e. SA will not export routes to a text file usuably but it will export them to a Garmin GPS).
Radio stations I dunno about.. more details on this as I look into it more.

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*

- Trevor

And, thus, the term "warpegging" was born.

That spelling leads me to think of two pronounciactions. The one I'm sure you were going for is "war-pegging", while the other sounds like something the Ferengi might do to the Enterprise: "Warp-egging".

Anyone remember the game "Stellar 7" from back in the C-64 days? You ended each level by flying into a warplink. My friend never understood what a war-plink was...

The stock empeg kernel doesn't actually have SysV IPC compiled in. We'd need to convince Mark to turn it on for his Hijack kernel. This is assuming the user wants the Hijack kernel...

- Trevor

For less than the bloat (small) involved in SYSV IPC, we could just have Hijack capture the NMEA strings and make them globally available under /proc/

No complex messaging or shared memory required. Just open /proc/nmea and read the most recent NMEA strings.

Or we could also have Hijack parse the strings, and just save the timestamp and position info for /proc/, so that each induhvidual app doesn't have to learn NMEA as well.

Hijack accepts patches..

-ml

Not all GPS is NMEA though, so it's not as simple as that.

Okay, all those in the room using a non-NMEA capable GPS with GPSapp today please raise your hands.. Not theoretically, but actually doing it today, with the GPSr normally used for that purpose? Anyone?

-ml

Hi.

Also, anyone using an Earthmate, put your hand up now.

You know, I'll be really sad if it's just me

Raising my hand. My trimble uses TSIP.

Also we're not just interested in postition, but also server signal strength, speed, quality of the location estimate, direction of travel. Some applications are more likely to work in a polling fashion while others might want to get notified as soon as updates are available. And then this information comes in different messages. It is important to know that the last position update was 10 minutes ago, but that we've seen a satellite in the past 2 seconds.

There are also different rules about when the information is good enough to use for instance to sync your local clock. And those rules do vary slighly on a per-gps basis. Also gps receivers don't supply all information all of the time, or only provide speed in knots instead of m/s, and somewhere a decision needs to be made which measurement to use. For instance on the trimbles, I'm getting notified of location updates as long as there is a 'fix', but have to poll the receiver for satellite information and to discover that we lost our lock and we're not getting realistic location information.

In defence of Mark's scheme, you could cache the last received sentence of each type (or in the case of sentences where you get e.g. 3 of them to get all of the info they provide, all 3 of them) and a timestamp, and still have all the information you do now. It doesn't address polling versus notified.

I'd think it would make more sense to have a daemon application that listened to the GPS and to which applications could connect over a socket. The daemon could send all immediate data to each application connected to it and respond to any directed queries. At its most basic level, it could essentially just multiplex the data to each connected socket, but that doesn't address multiple initializations, etc.

Regardless, the basic issue is multiplexing the data. It would seem to make sense not to recitify the data too soon. You also need some way to contend with multiple writers, especially when the write changes the GPS in some way, but even when querying for certain information and providing that data back to the correct client, and not to others.

(Note that I know fairly little about GPS, so some of my assumptions could be wrong.)

Regardless, the basic issue is multiplexing the data. It would seem to make sense not to recitify the data too soon. You also need some way to contend with multiple writers, especially when the write changes the GPS in some way, but even when querying for certain information and providing that data back to the correct client, and not to others.
If you're passing a query through to the gps receiver, the response can be received by all receivers safely. Those which don't want to use that data can just ignore it. If it's a sentence they parse, they use it, otherwise they don't. No harm, no foul.

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?