Jan, the GPS software is great, and very useful. I'm quite impressed! I've been playing with it since last night.

It wouldn't be an empeg project without feature requests, though, so here's my pie-in-the-sky wish list.


- My GPS unit is notorious for taking a long time to lock onto satellites and start being useful. Often, it takes 5 minutes between the time I start the GPS application and the time that it's actually able to track my movement. So what I'm wondering is if, at player boot up time, when the GPS app is first called by preinit, it could at that time send the command to activate the GPS unit and start its initialization. So that way, later, when I finally do go into the GPS application, the sats will be there when I come into the menu. This could, of course, be optionally disabled for those whose GPS units are solely battery powered. By the same token, I would like to make sure that the unit stays on in the background even when I exit the GPS software. I think it has a timeout of 90 seconds where if you don't talk to it for that long, it will shut itself down. So I think your software has to actively be there doing something, however small, the whole time. Not sure how that works on these things, though. (Note: It seems to already do this, at least the part about keeping the GPS active after I exit the GPSapp. Does it? I exited the GPS software for a few minutes, then went back in, and the satellites were still there.)

- I would like to see the software always count down to the next turn on the map screen, with the actual text of the next turn up on the screen. Right now there is the option of a "popup", but I spent a lot of time last night staring at a map screen with no text, despite toggling the popup feature on and off. I would come up to turns and it didn't pop up and tell me the turn. I'd rather just have the current turn's text be on the screen 100 percent of the time.

- Better indication of toggle states. For instance, a lot of the menu items are toggles, but I have no idea if I'm toggling them on or off. Popups, for instance.

- It seems like the right-hand side of the map screen is a distance to the final destination, a direction to the final destination, and a distance to the next turn. (Not sure). I would much rather see it be (optionally), a distance to next turn (large), estimated TIME to next turn (smaller), and current speed/altitude. No arrow.

- In the all-text screen, I'd like to see the left and right buttons do something useful, like scroll through the list of turns in addition to the knob as it does know.

- I'd like to see the knob be able to be volume control for music player software even when still inside the GPS software. Is that possible?

- The short knob press should do something useful in the GPS software (doesn't seem to do anything at the moment). Perhaps it could be used to toggle between player track/volume controls and the GPS software controls. That way you could at least switch tracks and adjust the volume without exiting the GPS software.

- When you hold down the bottom button, it does not offer immediate feedback when switching screens. You have to release the held button to make the screen switch. This is opposite of how the other button hold features work on the player, which will switch the screen or feature as soon as the button was held long enough to activate that feature. Although both behaviors have a certain user interface validity, I think the GPS software should be consistent with the rest of the player in this regard.

- I'd like to have the ability to set default program startup options such as rubber band off, coordinates off, etc. That way, I don't have to set them every time I start the GPS app. It's OK if these have to go into config.ini or some other place, no need to use flash RAM for this.

- Corrolary: I'd like the ability to remove menu items completely. For instance, if I always like the rubberband off, the coordinates off, and always want it to be miles instead of clicks, then I would like to remove those selections from the menu so I don't have to scroll through them when I'm in the menu.

- Bugfix needed: Blinky satellite data screen as illustrated in the animated GIF file in my other thread.

- Bugfix needed: Sometimes keystrokes in the GPS app get through to the player software. Case in point: More than once, pressing the right button on the faceplate began to fast forward the current song and it did not stop fast forwarding until I exited the software back to the player and pressed the button again. Not sure how to force this to happen, it's intermittent. Seems to happen more easily if you are in the GPS software, then you exit the GPS software, then you go back into it. I got it to happen just now by doing that.

- The menu selection box looks the same as the "No Satellite Data" box and is in the same place on the screen. So it looks strange atop the "No Satellite Data" box. Perhaps the menu should be up higher on the screen and/or a different style than center-screen message box. Or vice versa.

- The message "Waiting for GPS Location". Should it be something like "Waiting for data from GPS receiver" instead? And the "No Satellite Data" message, perhaps it should be "Receiver found, looking for satellites" or something like that. This would have prevented my initial installation confusion, not knowing whether the GPS unit and serial cable were working or not.

- Can the actual NMEA sentences be scrolled in a small window on the satellite data screen? I saw a Palm app which did this, and it was very useful in determining that the GPS unit was working even before it got a satellite lock.

it could at that time send the command to activate the GPS unit and start its initialization.

That command is called "opening the serial port".

but I spent a lot of time last night staring at a map screen with no text, despite toggling the popup feature on and

It appears that the software can become confused and not realize you're coming up on a turn. It was estimating 230 miles to next waypoint on a 139 mile trip I made.

That way you could at least switch tracks and adjust the volume without exiting the GPS software.

You should get a remote for your empeg

I'll be selfish and say that autorouting is more interesting to me than practically any of your wishlist items.

Maybe I should take my laptop and try to work on some of this stuff for the hour I'll be on the train Friday morning.

You should get a remote for your empeg

If this is true, if the remote works on the music while the GPS software is running, then I withdraw that request. Pile more functions onto the front panel buttons instead.

f this is true, if the remote works on the music while the GPS software is running, then I withdraw that request.

Try it. It works for me.

If your GPS doesn't begin the aquisition process immediately upon the application of power then perhaps it is time to take advantage of one of the "fire sale" receivers now available for $15-$25. The one I have is up and running by the time the Empeg has booted and I can select GPSapp.

My remote seems to work just fine while GPSapp is running.

If you were to scan through some of the threads below I think you would find a lot of answers to these and other questions you are asking. They may not be in the FAQ (yet) but the discussion and problem solving that is going on here is responsive, productive and quite inclusive.

http://empeg.comms.net/php/showflat.php?Cat=&Board=hackers_prog&Number=119138&page=0&view=collapsed&sb=5&o=0&fpart=

http://empeg.comms.net/php/showflat.php?Cat=&Board=hackers_prog&Number=115801&page=0&view=collapsed&sb=5&o=0&fpart=

http://empeg.comms.net/php/showflat.php?Cat=&Board=hackers_prog&Number=104935&page=0&view=collapsed&sb=5&o=0&fpart=

You do illustrate a good point in that each of us does have out own set of preferences about how we like to interact with an application and with the geography. Any application will benefit from a certain degree of configurability. On the other hand, Jan has just recently started on this project and he has made more progress per unit time than anyone would or could ever expect, so I think we should all be grateful for what he has done along with his willingness to listen to all of our suggestions

Lynn

Jan has just recently started on this project and he has made more progress per unit time than anyone would or could ever expect, so I think we should all be grateful for what he has done along with his willingness to listen to all of our suggestions

Absolutely agreed. I think it's great, and that's just my "wish list", key word being "wish".

My GPS unit is notorious for taking a long time to lock onto satellites and start being useful. Often, it takes 5 minutes between the time I start the GPS application and the time that it's actually able to track my movement.

FYI, the 5 minute time is about right for a GPS that dosen't store any data on where it is, or dosen't have an RTC. My Garmin would have taken about that long to find it's location when I went to the Ohio empeg meet. Lucially, the Garmin stores the last location, and has a feature that you can select your rough location, and it will speed up the satelite discovery phase. Huge distance/elevation changes throw it off.

I guess it's time for me to tear my dash apart so I can participate in all the GPS fun. It's why I bought my cheepo GPS antenna ages ago, and it's still stuck in the front windshield from it's last usage with my laptop this past May.

I like this kind of feedback. A lot of these suggestions make a lot of sense. I can't really do much about the GPS lock time, as ellweber said it probably already starts searching as soon as the empeg is turned on (i.e. when the remote amp wire becomes active). The NMEA protocol is totally one-sided, and as there are no DTR or RTS/CTS signals and I never send anything, the GPS really doesn't know whether gpsapp is active or not. The long time before a lock probably is as Drakino suggested, the receiver doesn't remember satellite trajectories, last known fix and the time while it is powered down. One solution is to always keep it powered, don't know how quickly it could drain a car battery though. The other solution is probably similar to what the earthmate and tripmate drivers in gpsd are doing, find the magic sequence to upload the current time and approximate location to the gps. Time can come from the empeg clock, while the position can be stored in a config.ini file, even if it is off by about 100 miles it doesn't really matter much, and when it is off by more it will just take 5 minutes again. However, I have no clue as to what the magic incantations might be.

Menu toggle indicators, yeah the menus were just a quick hack. I guess I had 'make the menus better' in the todo-list since the first release. They probably should also be 'context sensitive', toggling 'tracklog' doesn't do anything in the satellite screen, and clearly those popups need some more work. Keeping them up permanently probably isn't that difficult, but others would like to not even see them at all. So with a better menu structure it could become off/popup/on.

Right hand side is distance to final destination, direction to the next waypoint and distance to the next waypoint. There is a distance/time menu option that changes this to ETE (estimated time elapsed) to final destination, direction and ETE to next waypoint. I don't know why everyone wants altitude, maybe I should get a better car that also drives vertically like everyone elses. Speed is probably a nice addition, but do we want an averaged 'velocity made good', i.e. velocity towards the target, or the actual GPS reported speed. I already have both numbers, just need to add them.

And why don't you like the arrow? I find it useful when I don't have an actual route, but just a destination point. As soon as the arrow points sideways I know I probably have to take the next available turn.

The remote IR codes are not intercepted, and it wouldn't be a problem to not hijack the knob turns, but to keep the knob press. Ofcourse we do need some space on the screen to visualize that the knob works for volume (I have a headunit and never use the knob on the empeg for volume control).

I should already have that blinky satellite screen fixed, just need to test it.

That ghosting of the buttons should not happen except if hijack is forgetting to 'hijack' the button codes. My kernel patch was basically prompted by the fact that people had their player switch to AUX and back, which in turn could very well result from the knob press ghosting through.
This is a clear indication that there is something more insidious going on than I first suspected.

The menu and the 'no satellite data' actually use exactly the same 'draw_msg' function to put themselves on the screen, so yeah they probably look quite similar

It would be hard to scroll the actual NMEA messages because by the time I update the screen, I'm working with something more like a summary of the data I got from parsing the messages.

osen't have an RTC

IIRC you can cheat with the Rand McNally unit since it's a Zodiac, by sending the NMEA sentence $PRWIINIT,V,,,,,,,,,,,,hhmmss,ddmmyy,
to init the clock.

Zodiac doc attached.

My wish list is just a simple FAQ for someone who's never done anything with GPS. Which GPS receivers work with the program, how to connect them to the Empeg (preferably solder-free.) I can figure out all the software crap, but I don't know all the ins and outs of GPS products. Are there ones that can pretty much just plug into the serial port and work?

Actually the time delay is probably from the moment that the empeg provides power to the RA line, and not when the serial port is opened. GPS units use an almanac and their known location to know which satellites should be visible, and if they don't have either, they have to wait until they hear an almanac broadcast from one of the satellites - this could easily take 15-20 minutes. Some receivers allow for an almanac to be loaded into them via software which would prevent this delay, although battery backup should prevent the almanac from being lost once acquired. It is possible that one of the other pins on the 'serial' port is actually a 3-5V memory line, but YMMV.

Hmmm... no posts for an hour, and then 4 in 3 minutes....I guess that I'm not the only one who watched Westwing.

I can't really do much about the GPS lock time, as ellweber said it probably already starts searching as soon as the empeg is turned on (i.e. when the remote amp wire becomes active).

Actually I guess I don't know about these but the Earthmate only turns itself on when the serial port is opened.

find the magic sequence to upload the current time and approximate location to the gps

I just sent it. I can contribute a patch, but it wants time in UTC. Do we want to rely on people having the right time? If so, tell me and I'll get a patch out tonight

I never got ETE working for me, but then, it might have been when gpsapp (0.7) was confused about the location of the next waypoint as relative to my position. (I was closing on it, but the estimated distance was increasing... but was almost 2x the distance of the whole trip, so I don't think it just "missed" me passing one.)

It would be hard to scroll the actual NMEA messages because by the time I update the screen, I'm working with something more like a summary of the data I got from parsing the messages.

How about an icon indicating data being received?

Which GPS receivers work with the program

Any receiver which speaks NMEA and supports serial output should "just work". I know of these exceptions:
-Earthmate doesn't speak NMEA
-Tripmate does but wants to hear the string "$IIGPQ,ASTRAL*73" before it starts talking; It makes life easy by saying ASTRAL to you until you answer.

I guess that I'm not the only one who watched Westwing.

I was eating.

Attachment isn't found on the server, can I grab it out of AFS somewhere?

Does the empeg tick it's clock in local time or UNIX time? I guess that if we want to send some initial coordinates they would probably come out of config.ini, so we could store a timezone offset in there as well.

ETE is continually changing. Initially I just did total distance / gps speed, which wasn't working too well, so then I tried averaged speed, then velocity made good towards the closest point in the route, still no good. Now it is averaged velocity made good towards the next waypoint, which seems to be giving the best estimate up until now.

That tripmate initialization sounds like a trivial addition to the NMEA parser.

/afs/andrew.cmu.edu/usr/shadow/Zodiac.pdf

I wonder why it didn't attach?

The tripmate init string is trivial. The Rockwell time init probably is too because you can send it safely regardless of what you have.

I guess I'll attach my empeg to the network and check the RTC.

As far as ETE, it wasn't changing, I was getting I think --:--

Hmm, it should only give --?-- when it doesn't have a speed estimate. I probably got something wrong somewhere. Was this using NMEA?

Mine looks to be set to UTC (the real time clock that is)

Yup. I only have one SVee6 set up, and it's NMEA. Likewise my Magellan.

Here's a cheap binary to print the date, since there's no /bin/date

Edit: and here's the source
#include <stdio.h>
#include <sys/types.h>

#include <time.h>

main() {
time_t when;
struct tm *tm;
time (&when);
tm = gmtime(&when);
printf("%02d/%02d/%04d %02d:%02d:%02d UTC\n", tm->tm_mday, tm->tm_mon+1, tm->tm_year+1900, tm->tm_hour, tm->tm_min, tm->tm_sec);
}

it probably already starts searching as soon as the empeg is turned on (i.e. when the remote amp wire becomes active).

In my case, I don't think that's what's happening. The one I've got doesn't have an off or on per se. It has a Li-Ion battery so in theory, it could be on all the time and just be getting charged up whenever I'm supplying it with power. But the instructions for the palm software say something about it shutting down automatically after 90 seconds of inactivity, and that the software can command it to stay on for longer than that. Or something like that, I don't understand it. Perhaps it's got a sensing switch on the power jack and goes into "always on" mode when the jack is plugged in? If that's the case then strange things should happen if I leave it plugged in all the time as it is now. The dox are really sketchy on the subject, I don't know how it's handled. But I got the impression that all on/off commands were "soft" and delivered through the serial port.

I was just assuming that it wasn't powering up until after I launched the GPS app the first time. I could be wrong.

Right hand side is distance to final destination, direction to the next waypoint and distance to the next waypoint. There is a distance/time menu option that changes this to ETE (estimated time elapsed) to final destination, direction and ETE to next waypoint.

Right. What I'm saying is that I couldn't care less about final destination distance or time. All I want is a countdown to the next waypoint, in both time and distance.

And why don't you like the arrow?

It's a very nice arrow (pats on head). I don't need it because I've already got the rubberband option (indicates the same thing) and the screen real estate would be better served with more fun stuff like speed, altitude, or more room for the popup text. If everyone else likes the arrow, that's fine. Make it an option.

It would be hard to scroll the actual NMEA messages because by the time I update the screen, I'm working with something more like a summary of the data I got from parsing the messages.

Ah well, no big deal, it would kinda be just eye candy. And only useful for receivers like mine where you sit there and wonder if it's even working at all.

I don't understand how GPS receivers work, and I'm curious: What's the difference between a gray hollow bar and a solid white bar on the satellite screen?

Ofcourse we do need some space on the screen to visualize that the knob works for volume

Now that I know you can use the remote to control the player app, I've changed my mind and would rather see the knob do what it currently does which is scroll through the list of waypoints. Works well for that.

I don't understand how GPS receivers work, and I'm curious

Read the GPS Guide. It explains the entire system in pretty decent detail, but is easy to understand,

Considering that gpsapp is only passively listening to the serial port in NMEA mode. Your receiver must be always on as long as it receives power through the jack.

I had the same 'I wonder if it really works' feeling when I connected the SV6. And it is one of the reasons why I added the signal strength display in the first place. Most things I write is to 'scratch an itch', if it bugs me enough I fix it.

The difference between hollow/dim and solid/bright right now is that the solid bars are the satellites used for the location fix, the others are either to weak or intermittend or just have an unlucky position in the sky so they can't add anything to the triangulation or something.

However, things keep changing and ITNR the bright vs. dim color will indicate whether we received a measument for that satellite within the last 2 seconds. I.e. you could have bright/hollow bars for satellites that are still received promptly but probably are not in the solution because they are too close to the horizon, or too weak. And dim/hollow bars for satellites that are currently obscured, and possibly even dim/solid bars for satellites that were used for the last solution, but are currently obscured (when we drive into a tunnel?)

And it doesn't switch from the "Waiting for GPS location" screen to the "No Satellite Data" screen until it hears something valid from the GPS?

Very interesting document, Tom, thanks.

Well, until it gets any input. It is basically waiting for the first screen refresh. So a button press would get it to the no satellite data message as well. But as long as you don't touch the empeg buttons only the serial data should cause a screen update.

Okay, so can someone recommend a good GPS receiver then? I'm imagining just installing GPSapp, plugging a GPS receiver into my car's DC power socket, plugging in the Empeg's serial cable, and having everything Just Plain Work (tm). Are we there yet?

I'm imagining just installing GPSapp, plugging a GPS receiver into my car's DC power socket, plugging in the Empeg's serial cable, and having everything Just Plain Work (tm). Are we there yet?

Yes, that's essentially what I did.

Important to remember, though, that the serial cable needs to be three wires only: Gnd, Rx, and Tx. Because the in-car serial port has some screwy stuff going on with certain pins. And also there will be some trial-and-error involved in the correct "swap" of Rx and Tx.

And, of course, installing preinit and gpsapp was tricky because of the difficulty I had creating the /programs0 partition. But maybe by the time you get the GPS receiver, Preinint will have been updated to automatically create /programs0 for you. Just remember, don't have the WinZip smart CR/LF conversion on when you extract the preinit TAR file.

And, of course, installing preinit and gpsapp was tricky because of the difficulty I had creating the /programs0 partition. But maybe by the time you get the GPS receiver, Preinint will have been updated to automatically create /programs0 for you. Just remember, don't have the WinZip smart CR/LF conversion on when you extract the preinit TAR file.

Thbpbpbpt. Winzip? I'm a UNIX guy, remember?

I will have no problem getting preinit and gpsapp working properly. The software stuff is the least of my concern. I just saw that you had to solder all sorts of things... I wanted a painless install but I guess I'll be hacking up a DB-9 cable anyway. Any kind of schematic you can provide? Even if it's just one of those fixed-width courier text diagrams on the BBS. Are all GPS receivers going to have the same pin allignment and so forth?