Another day, another update.

And I haven't even had the time to play with the lyrics viewer
But I did pull a bunch of long overdue updates together and tested the result lightly.

The important changes are
- popups now work as I intended them to
- the negative altitude bug is fixed
- the code should track our current position in a route a bit better now
- if gpsd is available, connect to that instead of the serial port
- when a user is flipping through the waypoints with the knob, wait 10 seconds before we restart the automatic tracking of our position

Oh, almost forgot. I got a new desktop and as a result the GPSapp page has moved to a new address. I should try to log in to the old machine and set up a redirection as it still seems to be alive for now.

The new location is http://delft.aura.cs.cmu.edu/empeg/

Cool. Updated the FAQ entry which pointed to your page. Grabbing new version now.

Now, if only there were a way to get StreetAtlas 2003 routes into GPSapp, we'd be *so* set...

I wonder what I was working on last. I have this idea that I have more patches somewhere, but they sure don't seem to be in any of the obvious places.

If you want to run with gpsd, get an up-to-date gpsd (dbrashear
often posts new binaries on the empeg.comms.net BBS).

I didn't think I was *that* bad.

I didn't know of any 'official page' to send people to, and noticed a couple of posts you made with arm-binaries of gpsd.
I guess often is not really the word for it.

Well you definitely could consider me a Linux bigot, I've been running it exclusively since '93/'94, and been doing on and off kernel development since at least '96. As a result, I never have used windows (except for 3.11 or something) and don't know what I'm missing

So do you have to buy a new version of streetatlas each year to keep the version number right?

So do you have to buy a new version of streetatlas each year to keep the version number right?

I think pretty much, yeah... They don't seem to offer users the ability to download updated maps, just program bugfixes. So if you've got SA 2000, then you've got three-year-old map data.

Still, it's gotta be better than MapsOnUs.

I don't personally have a use for it but somebody else might. The BBC have traffic information online in XML format here and it does give WGS84 coordinates for it all as well. It's experimental so don't be too surprised if it does suddenly disappear or moves!

- Trevor

I should see what's holding up the next gpsd release. I can probably arrange for arm binaries to be on the main distribution page.

Finally got to try this version of GPSapp this afternoon. Jan, it rocks. I love the changes to the display layout, and the ten-second delay after spinning the knob is great. The giant lettering for the speed indicator is awesom. Great release, thank you!!!

I'm going to start a separate thread about the one remaining bug...

Wanna post a screen-shot? I have no GPS, but I'm curious to see what it looks like...

Which GPS model are you guys using this looks intresting to use for my Empeg..... We need DETAILS....

I started off with a Garmin Etrex Venture, which I now occasionally still use when debugging gpsapp on my laptop. In my car I wired one of the trimble SV6 receivers that were sold by www.bgmicro.com for something like $25 a while back. Some people are using Motorola Oncore, which were also sold by bgmicro for about $15 without the active antenna, or modified palm-III delorme earthmates that went for a similarily ridiculous low price when Staples decided to drop all palm III accessories.

I don't know of any current deals of this kind, and all of these low-cost solutions do require some additional parts and soldering to get power and RS232 level serial signals. But basically any receiver that spits out the industry standard NMEA sequences over a serial line should just work fine.

Wanna post a screen-shot?

There are screen shots at the GPSapp home page. Don't know if they're shots of the recent released version or not. Making a screen shot for me is tricky, since the GPS antenna is permanently installed in my car, and even if I did a force-DC, and ran GPSapp without an antenna, and added DC_servers=1 to my confic, etc., etc., it wouldn't look quite right without a proper location heading and speed on the screen.

Which GPS model are you guys using this looks intresting to use for my Empeg..... We need DETAILS....

You can use any one of many different GPS models. I'm using one I got on clearance at Staples for $10.00 (which is no longer available). Start here for connection information and work from there...

I picked up a Delorme Tripmate a few days ago for $25 from Half.com. I plan on doing the simple hack that makes it a generic NMEA unit and using it with the empeg.

I was reading those instructions, gpsapp already knows about the ASTRAL thing (and in fact sends some additional 'warm start' bootup codes) so you don't have to short pins 2 and 3 together.

Sweet. One less step to go through. I may still do it anyway so I can use other map software with it too. Thanks for the heads up.

Question about the route directions...

If I'm in the Text screen, with the list of text directions up, and I'm cycling backwards and forwards through the list with the knob... Sometimes the wording of the directions will change as I cycle through the list. For instance, one particular line will flash between "bear right on xxx" and "continue on xxx", as if the software can't make up its mind which of the two turn instructions to give me.

Is this by design, and if so, why?

In a way it is by design. The 'turn' information is not stored in the route files, but generated on the fly by calculating the difference between the incoming and outgoing heading of a turn. This is stable for all points except for one, which is the turn we're approaching. This is because the code assumes that our existing location is more precise and if we were to approach a turn from the wrong direction after a short 'detour', the instructions will still be right.

It bugged me when it was telling me to take a right onto fifth avenue when I knew it should be a left because I had selected a route with a different startpoint but the same endpoint as where I was going to.

It makes sense, I suppose.

I guess that's the same thing I reported earlier, where it was telling me to turn left at a location where I needed to go straight... because my actual position was slightly to the right of where the mapping data thought the road should be...

Ok, got to play with this today. The altitude bug isn't totally fixed. Apparantly I was at 4 billion feet altitude at some point. I know I live on a hill, but it's not that high

Suggestion. Can you stat the routes directory immediately upon startup, before even being selected in hijack? We know that at startup the disk is spun up, and this would eliminate the display delay that occurs when trying to select a route when the disks are spun down. And if you leave the current stat in place where it is (but discard the results) then that will spin the disks up as soon as we start to look through our route list, hence keeping load times much the same as they are now.

The altitude bug isn't totally fixed. Apparantly I was at 4 billion feet altitude at some point.

Altitude seemed to work for me, but I wasn't spending a lot of time looking at it. Is that some kind of a signing-flag bug?

I think this is a bug:

I looked in the readme to see if this was configurable, but I didn't see an option for it, so I'm assuming this is a bug. Of course, we all know what happens when you make an assumption: You make an ass out of you and Umption...

On the map screen, there are three numbers to the right side of the screen. I can clearly see that the bottom two numbers are current speed and distance to next waypoint. My assumption is that the top number is supposed to be distance remaining to the final destination.

But when I was using GPSapp yesterday, as I was following the route, I noticed the top number was counting up instead of down. As if it were measuring the distance from the start of the route rather than the end of the route. My destination was about ten miles from my start, and when I finished the trip, the top number was saying about 10 miles.

Is that by design or is that a bug?

And by the way, I know I was following the correct route, not a reverse of the route. The turns were all in the right order and it tracked correctly.

I've also noticed that it still has trouble snapping to the correct waypoint in certain "really close" situations. It's hard to describe, but I'll try.

Imagine the following route (this is an actual example from my route to work in the morning):



A and B are actual waypoints, requiring that I make a turn. In this case, the distance between A and B is very small, perhaps only a hundred feet or so. Maybe less.

The mapping data is pretty accurate for this set of streets, but it's not perfectly aligned with the real GPS readings. So my path is off from the map data, just a little, as you can see.

GPSapp malfunctions on this set of turns. It either tells me about waypoint B much too late (after I'm already executing the turn), or it never stops telling me about waypoint A (requiring me to twiddle the knob to get it tracking properly again).

I understand that the real path isn't exactly on the data path, so I can see why GPSapp is having trouble with it. But I'm wondering if there's any way GPSapp can be more clever about how it snaps to the next waypoint. For example, it might be able to use my heading direction to decide whether or not I've actually executed a turn. Or it could notice that the next two waypoints are really close together, and temporarily "tighten up" its snap distance to make sure that I don't miss the B waypoint.

You'll probably say you can't, but if you could capture some GPS output through this segment, and give me a route file...

I should look at the code and see if there are multiple ways we can get altitude. From gpsd I have this vague idea that there are multiple ways which provide a different answer unless you remember to normalize for what the input actually is.

Oh, another feature request...

When changing waypoints, can we get an autozoom so that the next waypoint is on the screen at an appropriate scale? I'm guessing that this would need to be a toggleable option.

You'll probably say you can't, but if you could capture some GPS output through this segment, and give me a route file...

How would this be done?

Do you mean stream the serial output from the GPS unit to a file? If that can be done with some kind of softare on the player, I'd be happy to do it.