gpsapp v0.12

Well, yes, but the idea was to avoid opening it in case I came up with a palm3.

Well, yes, but the idea was to avoid opening it in case I came up with a palm3.

You won't be doing anything that will damage your ability to hook it up to a palm3. If you do a nice job of making a clean hole for the serial cable, you'll have a nice StreetFinder with a dangling serial cable that can connect to either a Palm or the Empeg, whichever you like.

But I have to say that GPSapp is already better than any of the Palm software I tried, so there's no point in bothering with it.

But I have to say that GPSapp is already better than any of the Palm software I tried, so there's no point in bothering with it.

Well, yes, if you have an empeg with you.

I think I found a bug in the mapsonus parser. It is trying to parse for <xmp></xmp>, but the html I am getting from their site has those in caps <XMP></XMP> so the parse if failing. This was working a day or two ago so I don't know if the parse changed or their site did.

-Mike

God, I hate case-sensitivity.

You never know, maybe at some point I might just 'port' gpsapp to run on my Handera 330. But seriously, palms are even more challenging to develop for, no unix environment and battery life becomes a big issue, so you can't really run the (slow) CPU at full throttle all the time.

Ok, redid it so that now it isn't depending on <XMP> </XMP> tags. as a result we can now even parse the dump when it was saved as plain text.

Is that version up yet?

I just synced the CVS archive, give me 10 seconds...

Ok, v0.14 is up.

Does 14 also contain that clock patch posted earlier in this thread?

Route reversal... Just plan the reverse route offline and upload that as well. It just seems like a bit to much work for no real gains. i.e. there already is a perfectly working way to do it that actually handles one-ways etc, and doesn't complicate the code. And I would rather start playing with actual vector map data.


Fair play...it was just a thought, but I wouldn't want to distract you away from something that will be far more valuable. And of course, you're right, my need for reverse routes would only be based upon my laziness

wrt track points. I wonder if now is the time to consider what we might eventually want to see gpsapp write out to disk. Considering that it has to run 'root' anyway, getting gpsapp to remount /programs0 (or /programs1 if it exists) should be trivial.

No, I thought you said it didn't make any difference.

No, I thought you said it didn't make any difference.

Didn't SEEM to, but the timing of that thing is always variable.

wrt track points. I wonder if now is the time to consider what we might eventually want to see gpsapp write out to disk. Considering that it has to run 'root' anyway, getting gpsapp to remount /programs0 (or /programs1 if it exists) should be trivial.

Although track points are the last thing I'd want written out to disk, I could envision some other things it might write out to disk that would be useful...

Is it possible to write out the almanac data to the disk (only when I say so from a menu item) and then feed it back into the GPS at boot up? Does the GPSapp even get the almanac data or is that only internal to the GPS?

DBrashear, here's a photo of my StreetFinder opened up and wired for serial. You can see which pins are which pretty easily.

In this configuration, I was able to close up the case and just stick those pins into a female serial cable.

But later, I completely got rid of the plastic casing so that I could stealth mount it and position the antenna wherever I wanted. I wrapped the whole thing in electrical tape and soldered a proper serial cable to the PCB instead of the loose pins.

You don't have to go this far if you still want to use it with the palm3.

In reply to:

---

Although track points are the last thing I'd want written out to disk, I could envision some other things it might write out to disk that would be useful...

---

I have a suggestion that it should be possible to build a route up from scratch simply by driving it & marking key places/waypoints as you drive (gpsapp could even do this automatically as well using each turn you do more than X degrees from the last heading as a "waypoint").

That way for those of us outside the US who cannot find a MapsonXXX equivalent we can record/create routes we use simply and easily.

Doing this requires that we be able to save these waypoints somewhere - now I don't like the idea of running my Empeg with rw mounted disks anymore than anyone else, so maybe we could look at creating a small ext3 filesystem somewhere that can be left rw mounted permanently for apps like the GPs one to save stuff to as and when required.

Either that or we dust off the old talk from some time ago about a special "raw" disk driver that reads and writes disk blocks itself directly [no need for mounting the special filesystem then.

Given that The latest hijack now includes ext3 support, maybe this is the time to make use of it?

Can't think of any other way to get permanent storage on the Empeg can you?

AFAIK, most receivers will output and allow input of almanac data, but generally only in their own binary protocol. How long the almanac remains valid for is another matter that I'm sure that Derrick could answer.

Writing track points out to disk could have uses:
Survey - although the receivers/antennas we are typically using aren't up to the accuracy of proper survery units, it still might be useful/fun.
Map making/calibration.
Road Trip Logging.
If live routing ever becomes a possibility (the map data issue obviously needs to be resolved first), then track logs may be useful for retroactive routing validation.
It'd be cool to be able to 'mark' a place for attention, much like you'd mark a track for attention. How many times do you see an unusual place or shop and think "Must remember that's there...", only to forget exactly where it was? Or stop on vacation and take a photo of a wonderful vista, only to forget exactly where. If JEmplode could check a known directory, and find a date/time/position log, and the route taken to it, then you could process that information, give it a name and reupload it as a normal route, or use it to help label your photos.
Custom route creation - if you know a better route from Exit X of I95 to your house/church/whatever, than mapquest/mapsonus/whatever can find, then you could drive that route, and then retroactively use it to create driving directions for friends/relatives/whoever - including typical timings.

So many possibilities.

That way for those of us outside the US who cannot find a MapsonXXX equivalent we can record/create routes we use simply and easily.

Well you could use google and find in a couple of seconds programs like
www.gartrip.de and http://home.t-online.de/home/gpsinfo/ which allow you to create tracks and routes based on digitized topographic maps by tracing the track you want to follow.

If you're from england and rather not use those german programs, www.gpsu.co.uk does similar stuff.

Either that or we dust off the old talk from some time ago about a special "raw" disk driver that reads and writes disk blocks itself directly [no need for mounting the special filesystem then.

Writing to the disk is writing to the disk, whether you use a filesystem or write the blocks yourself. i.e. you could create a single large file without holes in any given filesystem and as long as it doesn't change it size the access is equivalent to writing to a raw device.

However, it is simply the actual process of writing bits to the disk that is dangerous. I believe some recent IBM 3.5" IDE drive was renowned for writing even when the power was cut so it would scribble over low level data between the tracks. This basically turned the disks into a brick that could be shipped back to the factory.

How long the almanac remains valid for is another matter that I'm sure that Derrick could answer.

Well, the almanac data is rough anyway, it's an idea of where in the sky to look for what, so basically, you can use it for months, with decreasing accuracy, but that's ok.

Ephemeris data is what's interesting, but I don't know what receivers cache it.

Actually,. I bet one of
Joe Mehaffey, or [url=http://www.edu-observatory.org/gps/gps.html]Sam Wormley[/url[ have a good explanation. I'm merely a somewhat enlightened amateur (though before selective availability was turned off, the quest for accuracy meant I learned a lot more than I would probably bother to today; for that matter, I also learned about datum shift bother using Molodensky and a shift table, and why for NAD27 to NAD83 you want a table, for instance, because I have maps calibrated in both, and wanted to use them all together, usefully)

Writing out track info to disk could be very useful, and at the same time, it opens the "read/write disk" can of worms. The thing that I want, probably, is a network attached disk external to the player, possibly CF based. The problem is, network attached disk (it doesn't need to be secure in my car unless I'm dumb enough to use wireless, can anyone say reverse wardriving?) isn't really cheap enough that you'd throw CF in a device and use it for this sort of thing... yet.

But basically I want it external to my empeg, so it doesn't use up either IDE channel that I could use for real data, and slow access is ok. Serial would probably be ok, except for that "out of ports" bit.

Writing out track info to disk could be very useful, and at the same time, it opens the "read/write disk" can of worms.


Maybe it's me, but sometimes I think that we all get a bit carried away about this. Yes, the empeg guys did a fantastic job of protecting our drives in their daily use - both in HW (choosing laptop drives, shock mounting) and in SW (keeping the disks spun down as much as possible, only mounting read-only), and I am both impressed with and grateful for their design ingenuity.

But the fact remains - these are laptop drives, and they are shock mounted. Millions of people use laptops with RW disks spinning in cars, on aeroplanes etc, carrying them around and plonking them down on hard desks without regard to whether they are going to crash their heads. I suppose one might argue that when being used on a lap in a car, that the person provides some shock mounting for the laptop as a whole, but that isn't the only modus operandi.

I'm not saying that we should mount all the paritions RW, and leave the disks spinning all the time. But I do wonder whether our collective paranoia is un-necessary. I'm tempted to interface an accelerometer to my empeg, and attach it to the drive caddy. The only problem is that I'd need the disks RW to log the results

I don't think that we should write data constantly either - but we could cache data to be written, thus minimizing risks as far as possible.

Mark Lord has talked about making a disk writing feature available in Hijack. As mentioned, it would operate on a few sectors in-place, and could be done while the drives are mounted r/o. The kind of features you guys are talking about are definitely good uses for this kind of thing, at least, better uses than high scores for empacman or favorite trivia categories for emptriv.

Hopefully as the weather gets colder we'll see Mark around here more, and he'll make this happen. I agree, the "thou shalt not write while in the car" thing is a bit overboard, and we should allow for at least a limited write-while-driving API in Hijack.

In reply to:

---

That way for those of us outside the US who cannot find a MapsonXXX equivalent we can record/create routes we use simply and easily.

Well you could use google and find in a couple of seconds programs like
www.gartrip.de and http://home.t-online.de/home/gpsinfo/ which allow you to create tracks and routes based on digitized topographic maps by tracing the track you want to follow.

If you're from england and rather not use those german programs, www.gpsu.co.uk does similar stuff.

---

Yes, I realise all this, but my point is that not everyone has the same common "solution" for all countries, so there will be a lot of "home-brew" type setups out there, therefore allowing the building of routes by "driving them" is always useful.

Personally, I'm using TUMONZ (The Ultimate Map of New Zealand) which is all 100% vector based maps with route information & planning and it only costs $100 (about $USD50) and allows uploading/downloading routes/waypoints to Garmin & Magellan GPS units.
It also comes with "aerial photographs which you can "drape" over your map to allow you to merge actual aerial photos the landscape with the topography - see the opening screenshot on the TUMONZ website for an example.

Considering the price this is pretty amazing stuff.

But, you need a Windows PC to run it, and its not much use to anyone outside of New Zealand (unless you're Mark Lord and want to plan your next mountain expedition).

In reply to:

---

Writing to the disk is writing to the disk, whether you use a filesystem or write the blocks yourself. i.e. you could create a single large file without holes in any given filesystem and as long as it doesn't change it size the access is equivalent to writing to a raw device.

However, it is simply the actual process of writing bits to the disk that is dangerous. I believe some recent IBM 3.5" IDE drive was renowned for writing even when the power was cut so it would scribble over low level data between the tracks. This basically turned the disks into a brick that could be shipped back to the factory

---

I agree, but my idea is only bringing up something that Mark Lord mentioned a long time ago when some form of permanent rw storage was mentioned.

While Network Attached storage sounds really useful, I am not sure of the life span of any hard disks in a mobile environment when kept powered up all the time.

Ideally we need a solution that uses solid state [flash] RAM - something like one of those USB Flash based "disk drives" would be exactly right -
but you would need a USB **master** device between that and the Empeg (This is required [to act as a master device and go-between between the USB slavees to "route/mirror" all copy data requests from empeg (on USB Slave Port A) to USB data device (on USB Slave port B) and/or "route" read requests from Empeg on Slave USB A to data device on USB slave B.)

In addition we'd need a way to get the USB ports to dock/undock reliably/easily in the car - something which could be done if there was a USB master device in a small portable chip - and thats a bit of a tall order right now.

Either that or we come up with a simple solution that can "clip" onto the rear of the Empeg and plugs into the USB port on the back and "fills up"/uses the space between the rear of the Empeg and the rear of the sled - preferably something that could take a USB flash device.
I'm thinking something sized and designed like the Nomad Muvo here [but again thats only a USB slave device].

There are multiple problems that affect reliability of drives. One is vibration, the heads are floating close to the platters too much vibration could disrupt the airflow causing the heads to hit the platters. The airflow also disappears when the drive spins down, so it is very important to move the head away. Another factor is that te spinning platter works like a gyroscope, moving sideways or rotating it in the horizontal plane is pretty much ok. Moving it vertically is a bit worse, but twisting is rough on the bearings. Laptops typically spin their disks down quite often. This is not to save power, as it costs more energy to spin a drive back up and seek to the correct track than just leaving the disk spinning at a constant rotation. So this is to avoid the possibility of head crashes and perhaps even wear to the bearings.

A big factor however is power loss. Laptops only predictably lose power, their battery runs low and the system suspends/hibernates itself before we completely run out. However in a car we have possible power dips and loss due to starting the engine, pulling the player out of the sled, a bad alternator/battery, etc. And when the power cuts out, the platter slows down and and the heads have to be moved off the platter as soon as possible. With the drives I mentioned before, when a write was in progress at this time, it wasn't aborted during the 'emergency head park' and so the bits got written in a sweeping arc across the disk.

Laptop drives are typically better protected for the mechanical wear and tear of mobile devices, but are definitely not designed for sudden power failure. They'll probably be able to handle it to a point, but where that point is exactly...

It's not the shock mount, it's the fscking, that concerns me. I trust the hardware.

It's not the shock mount, it's the fscking, that concerns me. I trust the hardware.

I trust neither, and I especially don't trust that the power will be there from the beginning of the write to the end of the write.

But if we're talking about just unlocking /programs0 to write one file and the locking it again, I don't see a problem with doing that as long as it's user-triggered.

I would be perfectly happy if there were a menu option in GPSapp that says "Write data to disk now", and when I hit it, it saves everything all at once: Track history data, almanac/ephemeris data, whatever. It would then indicate when it was done on the screen somehow.

That way, if the data was important to me, I could make sure to do it and be sure it was done with the write before I turn off the ignition and pull the player out of the dash. And only when the car wasn't going over bumpy roads.

I wouldn't care about mounting anything read/write, or adding hijack hacks to update ext2 even when the filesystem is mounted readonly.

Just open("/dev/hda6", O_RDWR) (yes the swap partition), and you can just write blocks directly, add a checksum so that we can later tell whether the block was completely written or not. The player won't be using the swap in the car, and because the swap partition is as far as I can see on the outer tracks of the drive, I'm assuming it requires a smaller seek to park the head and in the worst case you'd only be trashing across the unused swap partition. Maybe even open it O_SYNC to keep actual writes as short as possible. There wouldn't be any metadata that could become inconsistent. I guess this is similar to how the player uses it's raw partition.

As long as we don't damage the first sector which contains the signature for the swap partition and recover the data when we're back on AC somewhere before the player starts an fsck.

Not all receivers support giving the user the almanac. The rockwell in the Palm 3 unit might; The SVee6 doesn't.

I still think parsing Tiger data is far more exciting than this. Other free apps do this; If Jan gets autorouting working he'll be the first open source author to do so

Just open("/dev/hda6", O_RDWR) (yes the swap partition)

Ew.

I guess I should bother to see if it adds the swap partition from the second disk. If not, and you have 2 disks, that's less worrisome.

Actually, no almanac from the Rockwell, either. However, looking at the Zodiac doc reminded me... are your slow starts in weak coverage areas?

are your slow starts in weak coverage areas?

No, I live on a mountaintop with wide open skies in all directions. And once the satellites lock, I get pretty consistent solid coverage from several sats.

Everything I've read says that with these particular devices (StreetFinders), it's normal for it to take a long time to get a lock like that because the units don't have any local storage. I'm just curious what we can do in empeg software support to speed it up since we've got the storage if we really need it.

Actually the SV6 does support almanac and ephemeris exchange with the attached device but not via NMEA. The SV6 from BGMicro was an OEM product that has a limited subset of NMEA implemented with lots of fail-safe provisions, probably used for vehicle tracking or ?? The NMEA mode in these SV6s doesn't allow much, if any configuration.

If you reflash it to TSIP you get a much richer interface that allows upload and downlod of ephemeris, almanac, initial position and time along with customizing many other of its modes of operation. For example, you can set it to provide an overdetermined solution where it will use more than 4 SV to improve the precision of the nav solution. You can also set it to track the highest 8 SV or the highest 6, change the mask parameters, dynamics filters, operate in MSL or geoidal height modes, etc. It is a real luxury for Trimble GPS users that Jan has included the TSIP parser in GPSapp.

NMEA, per se, doesn't allow almanac or ephemeris interchange. Individual manufacturers have defined proprietary NMEA-like sentences that are then useable for expanded functions. Unfortunately, these are different for each manufacturer's GPS so the interface to use them gets almost as complex as providing for the various binary protocols.

NMEA was originally intended to interconnect marine electronics such as speed logs, compasses, auto pilots, LORAN etc. GPS came later and was added as the $GPxxx series along with a provision for manufacturers proprietary messages in the $Pyyyx series, where YYY denotes the manufacturer (such as GRM for Garmin).

When all is said and done the almanac/ephemeris functions really belong in the GPS. If a GPS receiver (designed for navigation use) doesn't store these then it is most likely a hardware fault (bad battery or "Gold Cap" or BBRAM). I don't know of any decent nav receiver that doesn't store this data by design. Dependency on an external device is devistating to performance.

If a GPS receiver (designed for navigation use) doesn't store these then it is most likely a hardware fault (bad battery or "Gold Cap" or BBRAM). I don't know of any nav receiver that doesn't store this data by design.

The StreetFinder, I'm told, doesn't store this data permanently after it's been shut off. It only keeps it as long as it's on.

After a good bit of searching I did find a little bit of info on the StreetFinder's receiver. Link follows:

http://www.gpsnuts.com/myGPS/GPS/Hardware%20reviews/RandMcNally/rand_mcnally_gps.htm

If this is the same receiver you have, it would appear that the RTC is not loaded. Probably a cost saving measure that relied on the Palm for initialization. Too bad they cut this corner as it is probably an otherwise ok receiver.

This guy seems to think you can upload initial position and time but implicitly NOT ephemeris data. Your Time To First Fix will probably never get better than 90 seconds or so as the receiver would not output any solution until it collects a valid ephemeris from each satellite it is going to use. Add some overhead and latancy to the 30 second long data message and allow for an occasional satellite selection challenge and...

Looking further for info onthe Rockwell Zodiac receiver I found a spec for a related version here:

www.navchina.com/right/product/pdf/zodiac_dg_gps_33.pdf

This seems to imply that almanac and last known position data (and more) are stored in EEPROM, not requiring a battery (see page 6-12, 13). If this applies to your receiver then all that is needed is time initialization.

Receivers that store recent ephemeris have an advantage in reaquisition (only after short losses of power) as the validity of the ephemeris is relatively short, it changes at least once per hour. Some receivers may use an old ephemeris for a short time while collecting a new one but that is risky in terms of accuracy and detecting faults in the satellites.

Lynn

I did find a little bit of info on the StreetFinder's receiver. Link follows:

The review you linked was for a laptop-connected "mouse shaped" model. I do not know if its guts are in any way related to the Palm3 model I got.

Probably a cost saving measure that relied on the Palm for initialization.

Even when I used the Palm software, this thing had long acqusition times. It's even in the manual for the Palm software as being "normal".

Your Time To First Fix will probably never get better than 90 seconds or so as the receiver would not output any solution until it collects a valid ephemeris from each satellite it is going to use.

90 seconds would be a dream.

This seems to imply that almanac and last known position data (and more) are stored in EEPROM, not requiring a battery (see page 6-12, 13).

Well, I know that the receiver instantly spits back its last known position as soon as it starts talking to the serial port. So that part is true for sure. Dunno about the almanac/ephemeris data.

If this applies to your receiver then all that is needed is time initialization.

If true, then why didn't that timecode patch improve my acquisition times? Was it because of some kind of a timezone-off error? For example, my player's timezone is set to GMT-8 which is PDT. Should I have set my player's timezone to GMT before trying that patch? I would have figured the patch was smart enough to convert my timezone to GMT before sending the time.

Interesting. I just peeked at the navman web site (the StreetFinder for Palm3 is a Navman product) and saw this. Note the highlighted text, I didn't realize this...

Question/Symptom:
What can I do to improve my Time To First Fix (TTFF)? The unit takes to long to acquire a fix when first turned on.

Answer/Solution:
There are several issues that can effect GPS acquisition. The receiver will often be blamed for poor reception or greater than average Time To First Fix (TTFF) in cases where user education can fix the problem. Realizing the limitations of the GPS system and utilizing your device for maximum performance will solve any problems you might be having.

1. View of the Sky- A GPS will typically take several minutes to acquire its initial position fix if it has not had a fix in your location on the planet previously. This is called a cold start. To obtain a cold start the GPS must have a view of the sky sufficient to 'see' four to five satellites continuously for about 45 seconds. It takes this long for the GPS receiver to download a data set from the satellites which is used to acquire a fix more rapidly on a future start (warm start). You must be located in an area with a clear view of the horizon around you. Buildings, houses, trees and other object will all affect this process. For Navman systems used in vehicles, they will typically be able to get a 'cold start' fix from inside the vehicle, but the vehicle can NOT be moving for the initial cold start. If the vehicle is moving it constantly changes the view of the sky and prevents the GPS from having a view of those same 4-5 satellites for 45 seconds.

2. Keep the GPS off- The GPS will acquire a fix more rapidly if it has an estimated position to work with. The GPS remembers where it was turned off and uses that position as a starting point. This is called a warm start or a hot start. The Navman GPS3420 has an integrated GPS expansion pack that is on (using power from the iPAQ) whenever a piece of software is looking at data from the allocated COM port. That is, when the SmartST Professional application is open then the GPS is on. If you leave the GPS on indoors for more than three minutes then it will go into a cold start mode. If it is left on then it thinks it can not 'see' the satellites it thinks it should. The GPS then believes it has been transplanted to a different part of the world and will try and start over doing a 'cold start'. This will cause it to have a longer time to first fix (TTFF) as if it has just been taken out of the box.
To Do:
-Make sure that you are stationary when initially turning on the GPS. You must have a clear view of the sky. The fix should not take long and you should see some progress from the GPS Status or GPS info screens.
- make sure that the SmartST Professional application is minimized or closed when the GPS is indoors or is not in a position to acquire.
-On the iPAQ, make sure all other applications have been shut down. The design of the Pocket PC is such that just clicking on the X in the corner doesn't really shutdown most applications. Many may still be running in the background. In some cases you might even want this, such as when listening to music while doing something else but for gps use shut everything down. Shutting down everything is not easy on a pocket pc. Method one is to use the Start menu and traverse to the shutdown command with 'start menu -> Settings -> System -> memory -> Running Program -> Stop All'. The second method is to use the iTask hardware key on the bottom right. This will list running programs and you can tap and hold to choose 'close all tasks'. Of course a soft reset also works.

How much power does the receiver really pull? Maybe you could just tie it to your always-on lead and never let it turn off. You could put a switch somewhere for those times when you know you'll not be in the car for a loooong time. Or maybe even figure out a way to build a timer that will turn it off after two or three days.

You're right. I'm seriously considering trying this.

How would I measure its load on my car's charging system?

Cut (separate a connection you already have) the power or ground wire and connect an ampere meter (or multimeter in current measuring mode) to the ends.

/Michael

PST is -8, PDST is -7 relative to UTC but that is probably not the major problem though it could be slowing things down quite a bit. It is analogous to moving your presumed position about 800 miles at your latitude. Time is used along with the almanac and your presumed position to estimate the doppler shift of the carrier and hence target the search. I don't know about the patch but a sign error (UTC +7 instead of UTC -7) would probably slow the aquisition down to several tens of minutes at least. Trying different timezone offsets could be revealing.

Fast moving cars are really slow compared to moving satellites so the caution you quote relates to obstructions that interrupt data collection not the above mentioned doppler estimate.

The spec I found stated 125 ma at 5 volts for the Rockwell version of the receiver.

At some point you may want to consider writing off your $9.50 (plus tax) and invest in a less compromised receiver

Lynn

At some point you may want to consider writing off your $9.50 (plus tax) and invest in a less compromised receiver

This is also something I have considered. Anyone have suggestions? Preferably something under $100.00.

Thought I opened up this can of worms in another thread starting with this post. I think several people recommended some options that were getting towards the $100 range, though I think some had some 5V/12V conversion problems... Never got the perfect answer I was looking for, though.

Go Sv6 or Oncore...there's rumours that someone is working on a pcb.

If true, then why didn't that timecode patch improve my acquisition times? Was it because of some kind of a timezone-off error?

The patch sends the time in UTC. The time on your player should be set in UTC in the real time clock. I sent a date binary a week ago you can use to check. Check.

Should I have set my player's timezone to GMT before trying that patch? I would have figured the patch was smart enough to convert my timezone to GMT before sending the time.

The player should have a timezone setting, which has nothing to do with the actual real time clock setting in the hardware, by the way. The patch has no business doing time zone correction, because it's a unix machine: you set the time in UTC, and the timezone setting in software shows you the correct time for the zone you have set. When you change timezones, you change your view of the time, not the actual hardware clock. That's how my player works, and I didn't do anything special.

Windows is weird and encourages you to keep your hardware clock in your local time. I have so much hatred for them.

Is there a difference between GMT and UTC?

I know it's set in GMT because I've set my timezone to US-pacific time (gmt-8) and the clock is right.

Turning off the GPS when you shut down and not moving it while it's off should be sufficient to deal with the problem you highlight. It's the same as the Earthmate hardware. As they say, it's not a cold start.

The cold start problem can be "solved' with another patch, which tweaks the GPS state to hint to it to not fall back to cold start so easily, which I will try to come up with later.

But not via NMEA is the key. Once you turn on TSIP you can do lots of stuff, but most software doesn't speak TSIP. If you only care about gpsapp, ever, sure.

For the purposes of this conversation, UTC is GMT. Note the patch uses gmtime() to deal with time.

So yes, you're good. I'll look at the other patch I alluded to probably tomorrow. I can probably provide a few other tweaks if we're willing to assume "car", which I guess if it's coded into gpsapp isn't outlandish.

Greenwich Mean Time became so popular that someone decided to rename it Coordinated Universal Time. (If you're wondering why that is acronymed to UTC, it's because the french got involved. But take a look at the second letter of the sedond word, and what would happen if they hadn't.. !)

I guess the French still haven't forgiven us for Waterloo.

The French also want to redefine the prime meridian, what with their tree line north and south from Paris. Good for them. Anyhow, here's some commentary on universal time.

GMT explained

The cold start problem can be "solved' with another patch, which tweaks the GPS state to hint to it to not fall back to cold start so easily, which I will try to come up with later.

Ah, coolness. Thanks!

Since the SV6 is a small cheap OEM module with no display of its own then I guess that is all I will use it for. If you are restricted to NMEA then you will have to make do with those limitations. For $25 (and a little soldering) my Empeg now has its own GPS with more horsepower than I'll ever need in the car

Tony,

If you read what dbrasher has said (about how your PC stores time) and what I said previously (about how your GPS aquires signals from the satellites) I think you will see that you may be sending the wrong time to your StreetFinder and that any of these time offsets could easily explain your slow aquisition symtoms.

Lynn

If you read what dbrasher has said (about how your PC stores time) and what I said previously (about how your GPS aquires signals from the satellites) I think you will see that you may be sending the wrong time to your StreetFinder and that any of these time offsets could easily explain your slow aquisition symtoms.

But I have my clock and timezone set correctly. If I need to deliberately mis-set my clock and/or timezone in order to make it work, that's fine, but then exactly how should I do that?

I may be misinterpreting this but dbrasher said:

"The player should have a timezone setting, which has nothing to do with the actual real time clock setting in the hardware, by the way. The patch has no business doing time zone correction, because it's a unix machine: you set the time in UTC, and the timezone setting in software shows you the correct time for the zone you have set. When you change timezones, you change your view of the time, not the actual hardware clock. That's how my player works, and I didn't do anything special.

Windows is weird and encourages you to keep your hardware clock in your local time. I have so much hatred for them."

This means to me that your PC in not set to UTC unless you set it to UTC and forget about local time. This agrees with my own observations as well. [I'm trying to install Linux on another disk and the Linux installer thinks UTC is our local time from the PC clock.] You then said:

"I know it's set in GMT because I've set my timezone to US-pacific time (gmt-8) and the clock is right."

Seems like you are off by 7 hours.

Maybe I am missing the point here but it seems clear to me.

Also, I don't think daylight savings is going to end until Sunday morning a 2 am so we are now on PDST which is GMT/UTC-7 hours. Maybe you have Greenwich on DST also! UTC never changes, even though local time in the UK does shift with the seasons.

You might want to try various offsets to see if it helps your SreetFinder before going too far down this path.

Good luck, I'm going back to the Linux install for a while!

Lynn

Maybe I am missing the point here but it seems clear to me.

Perhaps I'm the one missing the point, but I think he was saying the opposite of what you interpreted:

Windows computers like to have the timeclock set to the local time.

But we're not on a windows computer. We're on the empeg, which is a Unix computer. And unix computers have their timeclock set to UTC/GMT (which are the same).

The only reason the time looks correct to me is that when I'm in the player software, I have selected the timezone setting. And that timezone setting changes the displayed time to be my timezone (-8 or -7 depending on DST). But the internal clock is still set to UTC/GMT, and that's what his code was sending to the GPS. Am I right?

Now, I suppose there is a chance it could be off by one hour, i.e., we're in DST right now so when I set the thing to US Pacific (which is -8) and set the time, I'm actullay at GMT-7 or something. Anyone know the answer to that particular thing?

That could be it - GMT/UTC never changes.

In the Unix world, the clock is always supposed to be set to UTC/GMT, and the display offset changed to take account of DST.

If you set the offset to -8 and it reads the same time as your watch then you are off by one hour, your Empeg thinks that UTC is one hour later than the Royal Observatory does. That is enough to slow down your aquisition. As I said earlier, it is equvalent to an 800 mile position error for purposes of estimating the center of the doppler search for the satellite's carrier.

And yes, I was in left field about which computer was which (and I am not Barry).

Lynn

Okay, so I can try setting the clock back and hour and seeing if that work with the patch (Gonna have to do that tomorrow night anyway, ROFL).

So, Derrick, can you try making that patch again, this time against the 0.14 codebase, and throwing a binary my way?

Since the SV6 is a small cheap OEM module with no display of its own then I guess that is all I will use it for.

Except I was already using a non-display GPS with my laptop and first Hugo, then Xastir, so for me it's not necessarily true.

Timezone doesn't matter (still) and you said your clock was right. I still think you should install the date binary I provided (or build the source) and make sure it is.

Jan rolled it into the CVS so it will be in 0.15.

Meantime, try this.

This, even.

If the displayed local time is correct and the time zone is incorrect doesn't that impliy that the underlying clock is also off.

Yeah. Helps to read carefully

The player should have a timezone setting, which has nothing to do with the actual real time clock setting in the hardware, by the way. The patch has no business doing time zone correction, because it's a unix machine: you set the time in UTC, and the timezone setting in software shows you the correct time for the zone you have set.

I was under the impression the empeg RTC was UTC like it should be, but it used internal code to the player for timezone info, and not the standard Unix timezone settings. Thus Hijack has to have an offset setting to have it's clock right...

Or has this changed?

I was under the impression the empeg RTC was UTC like it should be, but it used internal code to the player for timezone info, and not the standard Unix timezone settings. Thus Hijack has to have an offset setting to have it's clock right...

If that's the case, then doesn't GPSapp still Do The Right Thing since it's just sending UTC to the GPS?

That's a timezone setting in software, isn't it?

No really, the GPS wants UTC. It's not an arguable point, the documentation says as much.

I was just asking randomly as it seemed people here were poking at the time code again. My main irritation has been my forgetfulness to set the hijack offset properly, and was hoping it wasn't needed anymore.

I never understood exactly why it was, and some work with strace never revealed anything useful. I haven't actually bothered to see if my clock is still correct, despite the player having the correct UTC time.

There's definately something quirky about the player<->RTC clock interactions.

I've just installed Roger's base-tar distribution so that I could set up ntpdate, and when testing 'date' from the command line, I get:

"Thu Apr 27 21:49:29 /home/empeg/arm 2034"

and this is about 3 minutes after having set the date and clock right.
Now, the "home/empeg/arm" entry definately looks dodgy. It should return the timezone, but appears to be returning the start of a path.

And then when I run ntpdate, I get:
"27 Oct 21:54:57 ntpdate[43]: Can't adjust the time of day: Invalid argument" due to the year being so out of whack.

Then running:
sh-2.03# date 102817582002
Mon Oct 28 17:58:00 /home/empeg/arm 2002
sh-2.03# date
Mon Oct 28 17:58:02 /home/empeg/arm 2002
sh-2.03# ntpdate ntp_server
28 Oct 17:57:22 ntpdate[49]: step time server 192.168.1.1 offset -46.919752 se

resets the date correctly, but still results in the wrong TZ being presented by 'date'.

I just grabbed a copy of libc from the empeg and ran it through strings and grep..

/home/empeg/arm-empeg-linux-new/etc/localtime

Badly set up cross compilation environment, or a messed up glibc configure script. Because this path doesn't exist, none of the userspace binaries in the developer image can find timezone information. Either rebuilding libc6 with the correct paths or creating a symlink should fix it.

mkdir -p /home/empeg
ln -s / /home/empeg/arm-empeg-linux-new

Yeah, I tried that at the time, and it didn't help. I still have the symlink on that player (my wife's).

Of course, I think I discovered later some alternate reason why it didn't help, and probably it works fine now.

I haven't tried this yet, at all. I will, shortly. It won't blow up your GPS receiver or any such thing, but it's conceivable it might core.

If you don't have a Zodiac GPS receiver, this is useless to you, so if you don't have what Tony has, there's no point.

And if you care, here's the diff. Not ready for prime-time, I intend to change some stuff before I give it to Jan.

/me downloads anxiously...

And on the plus side it doesn't affect a Magellan Gold. I'll try an SVee6 (NMEA mode) later; If someone with a Garmin could see if this binary (which sends binary data your receiver can't use, but again it won't let the magic smoke out) in any way confuses their receiver, I'd appreciate it.

It may be smarter to use a config.ini option to enable this anyway, since you don't "need" it if you set the wrong option you should still be ok.

Rock. Seems to work. Satellite acquisition is almost instantaneous. Rock rock rock.

Agreed about the config.ini option, just make sure to let me know what the option *is* when the time comes that it gets rolled into the main codebase.

Question: Does this mean I can put the unit back on Amp.Rem power instead of constant power?

THANK YOU!!!

What happens if you run ``TZ=EST5EDT date''?

I'll include a patch to the README, but if it's harmless to just send the Zodiac stuff, there's no reason not to just send the Zodiac stuff always.

Hopefully someone with a Garmin can comment.

It also should enable optimization for "car" mode (as opposed to plane, boat, pedestrian, or static, for instance).

It also should enable optimization for "car" mode (as opposed to plane, boat, pedestrian, or static, for instance).

Wow, didn't know there was an option for that. Wonder what it does differently?

Question: Does this mean I can put the unit back on Amp.Rem power instead of constant power?

Forgot to answer this. Yeah, it should be safe. Basically the optimizations should put the Zodiac in the same mode it would be in if your automaker had mounted the unit in the car, at least if I understand the documentation.

I'm a bit displeased with doing everything in words instead of bytes, but I guess it's not that big a deal. I still need to clean up sequence number allocation, not that that should matter, either, but it would be nice to be technically correct.

I should probably also document some of the quirks about the zodiac_send interface which were again coded that way to conserve memory.

If you still have the base-tar dist install, could you check whether the following helps...

Make sure /etc/localtime is linked to the correct /usr/share/zoneinfo/.../... file. As I', not entirely sure whether the player app uses this link when changing the timezone so it might be missing. And set the TZDIR environment variable to override the incorrect search path for timezone files.

Something like,

ln -s /usr/share/zoneinfo/US/Eastern /etc/localtime

export TZDIR=/usr/share/zoneinfo

date or ntpdate

If this works, we're one step closer to getting the clock right. If this works well I can easily add the setting of TZDIR to the empeg specific initialization in empeg_ui.c.

Too cool.

It's unfortunate that the people who wrote the original Palm software for the unit didn't take this into account. All of the software that came with the unit (and all of the third party apps I tried) let it cold boot every time. So already, GPSapp is better for this unit than any of the commercial software. Thanks again!

No clue. The documentation only says it "adjusts the receiver's dynamics"

Wouldn't it be more useful to check whether sending the approximate location in the initialization sentence helps the startup time?

Wouldn't it be more useful to check whether sending the approximate location in the initialization sentence helps the startup time?

In my particular case, the receiver already has the approximate location at startup. It doesn't need any help from the software application to do this. The instant the software starts talking to the receiver, it spits back its last recorded location as Lat/Long coordinates. So my particular receiver doesn't need this information.

Seems as though all it needed was the appropriate instruction to just boot quickly (using the existing stored information from its last session) instead of cold-boot.

Question: Does this mean I can put the unit back on Amp.Rem power instead of constant power?

Forgot to answer this. Yeah, it should be safe. Basically the optimizations should put the Zodiac in the same mode it would be in if your automaker had mounted the unit in the car, at least if I understand the documentation.

Initial tests seem to indicate that I must leave the receiver fully powered in order to get the fast-startup benefit. I'm still curious about finding out how much current it draws and whether I'm going to drain my battery with it.

Ofcourse it 'starts fast' when you leave the receiver fully powered. gpsapp doesn't turn the receiver on or off, so the receiver just keeps tracking the satellites. The interesting part is what happens when receiver comes up from nothing. i.e. even the internal battery is drained. Does it remember the coordinates in that case?

Measuring current is can be done by measuring the voltage drop over a known resistance. Assuming a current draw between 100 and 250 ma, the voltage over a 5 ohm resistor in the power feed should drop between 0.5 and 1.25 volts. Most resistors should be able to handle the 0.4W of dissipated heat if I'm at all correct with my estimates.

Most resistors should be able to handle the 0.4W of dissipated heat if I'm at all correct with my estimates.


For a short while - long enough to take a quick measurement anyway. But most resistors available in RatShack are going to be either 1/8W or 1/4W. They do stock a few values in 1/2W, IIRC.

As opposed to turning off cold start? Well, how do you remember the approximate location? gpsd has switches to allow that, but it requires user input. Where do we get the input?

i.e. even the internal battery is drained. Does it remember the coordinates in that case?

If the hardware is like the Earthmate, yes (that or whatever backing store they use uses a very small amount of power and I never left it off long enough to matter, but it ran from AA batteries and powered off when the serial port wasn't open, so it seems like they won't try to charge something from those).

But maybe the hardware isn't.

I was thinking of allowing lat/long in config.ini. As long as we're correct within a couple of hundred miles that should be enough, so someone could put their home address in there, or maybe use whatever value the last point in a route called 'home' has.

I actually looked at the cold-start process of the SV6 when there is no backup battery. As it doesn't know time or place, it randomly scans for satellites. Once it finds one it pretty much immediately has a reasonable approximate time estimate and starts downloading the almanacs for all satellites. Once it has the almanac of the current satellite, it assumes this satellite is located approximately directly overhead and from that location estimate starts scanning for other visible satellites. As I was testing from inside the satellite it saw first was in fact at the horizon, so it really had a hard time finding my real location.

But a reasonable time estimate is something that we seem to get pretty much as soon as we hear from any single satellite, while location takes a lot more time and effort as the location estimate affects which satellites are assumed to be visible.

I considered that, but it makes me sort of leery. It's not that hard to do. It's still worth turning on the "car" optimization.

What should I do?

Ofcourse it 'starts fast' when you leave the receiver fully powered. gpsapp doesn't turn the receiver on or off, so the receiver just keeps tracking the satellites.

Actually, with my particular receiver, once something has been disconnected from the serial port for any length of time, it supposedly turns the receiver off. I think its timeout is 90 seconds. That's what was happening to me, any time the player has been unplugged for a while, it would cold boot again. So it doesn't "just keep tracking the satellites" as long as it has power, it also has to be connected to something. At least that seems to be case in the behavior I've observed. I have no idea how it "knows", but it seems to.

The interesting part is what happens when receiver comes up from nothing. i.e. even the internal battery is drained. Does it remember the coordinates in that case?

Yes, it seems to save the coordinates and spit them back out just fine, even after a complete drain.

However, after the internal battery is drained, it seems to go into the cold boot on the next power application anyway. I am not certain that this is the behavior, but it seems to be the case. I've only tried it once since getting Derrick's patch.

I've got a hunch that my unit's battery may be old and decrepit, as it doesn't seem to hold a charge for long. If I turn off the power feed to the receiver, it still sends data to the player for a little while but it eventually shuts off completely. Or maybe that's the 90-second timeout I'm experiencing, not sure. I'm not completely clear on how this receiver detects that it's "in use" and what its expected behavior is.

Can you let the battery drain and then attach it to a laptop and capture the NMEA in hyperterm or something as it's powered on?

I was never able to successfully get the thing working on a PC connection, and it's installed pretty deeply in my dash now. Don't have a laptop (of my own... wife rarely lets me use hers).

If the device has an eeprom setting anything like position or time is useless. Looking over the zodiac docs, do you think we could run the PRWIBIT internal test and see whether the thing has something like an EEPROM/RTC/etc in the first place.

Don't have a laptop (of my own... wife rarely lets me use hers).

Me either. Work owns mine. My wife owns hers. Free tech support means she lets me use it when I want to, or she can fix it herself.

This would be so much easier if my unit were useful at the moment.

So you propose "don't send time if it has an RTC" and "don't send position, do deny cold start if it has an EEPROM"?

I'm not completely clear on how this receiver detects that it's "in use"

I forget how you said you hooked up the serial port, but DTR and/or DSR signals seem an obvious mechanism.

I'm only using TX, RX, and ground. Still seems to know.

I actually just bumped into an interesting reference by googling for streetfinder information.

Some of StreetFinder units think they are still in Asia (where they were last tested in a plant prior to shipping), and they are looking for satellites that are visible in Taiwan. After a period of time (up to 30 minutes), the unit will reset and acquire properly. If your unit fails to do so, download the GPS Meter program from here. This utility will initialize your GPS unit more quickily and provide other information regarding direction and satellite strength.

That does imply it remembers its last position, meaning disabling cold start after you've gotten a fix once you should be fine.

Yeah, very interesting. That program is palm-only, though, and my unit wasn't affected by that particular problem I don't think.

From that same website it looks like the delorme gps uses the DTR line to detect whether they are connected, but that still doesn't explain how the streetfinder figures it out. http://www.gpspilot.com/Palm-GPS.htm

It would be noce to know, maybe it doesn't really know whether it is in use or not and just chooses the 'safe option' (i.e. stay on). My guess is that when it is idling it should be able to keep it's ram fresh for a really long time on the battery.

more interesting info, the device stays on when not running off of the battery. http://www.cetusgps.dk/info/faq.html#rand

It would be noce to know, maybe it doesn't really know whether it is in use or not and just chooses the 'safe option' (i.e. stay on).

According to the documentation, it shuts itself off after being disconnected for a while. My experimentation seems to bear this out. If I pull the player, then put it back in again soon afterwards, the receiver acts like it had been on the whole time and just keeps working. But if I pull the player and go inside for an hour or so, then bring the player back out again, it seems as though the receiver had shut itself off: Cold boot cycle. Even if I have the receiver on permanent power.

The exception seems to now be:
- With Derrick's non-coldboot-patch, AND
- with the receiver on permanent power, THEN
it seems to boot up quick every time.

I haven't done a lot of testing of all the variables to be sure that's the behavior, but that's what it SEEMS to be for now.

the device stays on when not running off of the battery.

Hmm. Yesterday I left it on permanent power, went into the house with the player, came back out after a couple hours, and : Cold boot behavior. BUT... that was without Derrick's no-coldboot-patch. Now that he's got the no-coldboot-patch, it seems to be the case that it stays on.

That sounds really suspicious.

That sounds really suspicious.

You're telling me.

Then again, there's this theory: Main 12v power voltage fluctuates and perhaps even does a negative spike when I shut off my car's ignition. Unless I have the engine running, I often get the "battery icon" on the player, especially if I get a big bass hit. So maybe something is making the GPS think that it's been pulled off of mains power or something. I dunno, the thing is a real black box to me.

My guess is, the gps actually uses the DTR line to detect whether the serial port is active, from what I found on the net that would be pin 1 i.e. the opposite side of where the ground is connecting to. But it also activates similar to how the empeg detects whether it is on AC or DC, probably by breaking a ground line when the plug is inserted which makes the 'dtr' line float high with a pullup resistor. Maybe it also turns on when it sees data on the RX line. but I highly doubt that. It is more likely that with an unconnected DTR the line 'naturally' floats high, implicitly activating the receiver. But then again even that would be suspicious because that would activate the receiver whenever it is disconnected from the palm.

Perhaps the best thing to do is to connect DTR, and possibly wire it directly to the power lines on the board as it will provide a nice and regulated source without negative spikes and probably fewer dropouts. It also allows the receiver to go to standby whenever the empeg powers down or is removed.

My guess is, the gps actually uses the DTR line to detect whether the serial port is active,

That's what the Tripmate and Earthmate do.

Then why would it stay on all the time, connected to my empeg, when only the RX, TX, and GND are connected?

This page claims the DTR thing is Delorme only.

I still really don't want to solder inside my Navman; I wonder if I can find someone with a dead Palm 3 I can salvage the connector from.

More reading indicates there's a way to shut off "auto-shutdown" on the Streetfinder, which means either it is a (serial) signal being asserted or withheld, or it's a packet that the documentation I have doesn't seem to cover.

I still really don't want to solder inside my Navman; I wonder if I can find someone with a dead Palm 3 I can salvage the connector from.

Why? It's the easiest option and doesn't prevent the unit from being used with a palm. Doesn't require scrounging rare connectors, so it's a lot less hassle. I even posted a picture of which pins get soldered.

This page claims the DTR thing is Delorme only.

Not really, because the streetfinder connects directly to the palm and doesn need a palm->DB9 serial adapter. And it claims that only delorme needs to have the dtr connected in that adapter. It doesn't know what the streetfinder uses because it doesn't have to.

But If you open the receiver you can check whether the pin that should be DTR is connected to anything or if it's pad is completely isolated. If it is connected it must be used for something...

Some of the pads are isolated on one side but seem to go somewhere on the underside, and it's obscured what's what. I thought of that.

Remco Treffkorn (the author of gpsd) notes that the IPaq when you put it to sleep drops from 12v on Tx to 0v on Tx. He suggests perhaps the Navman sleeve is keying on this rather than DTR.

As far as Tony's comments that I should suck it up and solder, well, I'd need to find my soldering iron

drops from 12v on Tx to 0v on Tx. He suggests perhaps the Navman sleeve is keying on this rather than DTR.

Sounds logical.

In other news:

Consistently, leaving the GPS on permanent 12v power for several hours with the empeg unplugged and the car parked outside, then re-inserting the empeg with the no-cold-boot-patch version of GPSapp, results in instantaneous satellite re-acquisition.

The same conditions, when left overnight parked in my garage, results in a full cold boot when I come out the next morning.

Since the garage's metal roof blocks the satellite signals down to unusable levels, I wonder if the unit simply gives up the ghost at some point because of LOS and the software/timing has nothing to do with it. To that end, I have parked the car outdoors tonight to see what it does when I put the player back in tomorrow morning.

One point of the cold boot disable patch is more or less for that situation. Maybe in this case (the case of this receiver) that's the only point of it.

is more or less for that situation.

Which situation? Being left outdoors unattended for a few hours, or being left on in a no-reception location?

Are you saying it's behaving as expected, or that it should have behaved nicely even when parked under the metal roof overnight?

Left powered in a no-reception area.

Expected that if you run unpatched gpsapp and leave it powered that it behaves as it does.

Actually, I misunderstood. He *guessed* the iPaq did that.

Expected that if you run unpatched gpsapp and leave it powered that it behaves as it does.

In my experience, with unpatched GPSapp, leaving it unpowered for more than a few minutes and it does a full cold boot... Not a lot of testing done with that to be sure but it seems to be the case...

Ok, but that's not the point I was making

By the way, leaving the car parked out overnight under the stars, and then putting the player into the dash with the patched GPSapp, resulted in an "instant boot up" this morning. No waiting. So it seems that part of the equation is if the receiver can't get a satellite signal for a certain length of time.

So it seems that part of the equation is if the receiver can't get a satellite signal for a certain length of time.


With the GPS receiver powered, this is known. Without the GPS receiver powered, this is potentially new information, but not entirely shocking depending on how long the receiver stays active after the player is disconnected from it.

In either case, if the receiver stays active for too long, without the patch, it will attempt to "fall back" to cold boot mode. I thought I managed to explain this, but I guess not.

I got this diff closer to "ready for prime time". So now there's a config.ini option here for "coldstart" (defaults to true, setting it to false enables the code to send "don't coldstart" to the gps receiver), and one for "serialport" (which takes a path to an alternate serial port, if you've done something like hook a gps receiver up to the tuner serial port and rename the device)

However before I send it on to Jan I want to do a bit more.

Any fix for the "map zoom fastforwards the song" yet?

Sure, borrow my player. I've never had it happen.

Can you reference a post other than the one from your trip to Vegas?

That shouldn't be a GPS issue, and would probably also affect any other 3rd party app that traps that button.

It's almost without doubt a hijack issue - for some reason the button press ends up in the player button queue instead of the application button queue. Why? I couldn't tell you... the queue mechanisms aren't the easiest part of hijack to read and understand. It could also be Jiffy related..Now if it happened consistently, it would be much easier to look at..

Probably. I was still hoping someone had a good description of it that could be referenced.

Best description that I can give is that there seems to be some event, which could even be something like the player crashing and restarting. At this point Hijack forgets it was redirecting the buttons or even the screen. I've noticed once that I was dropped back into the player application, but gpsapp was in fact still running and still getting the button redirection. This seems to happen very infrequently and we either lose the screen overlay, or the button redirections, or both.

It happens reliably when I start gpsapp before starting the engine. The accessory line (perhaps even the main power) is switched off while the starter is active and the empeg goes into standby or possibly some 'emergency shutdown' state. Once the car has started and the power returns, the empeg comes back and shows the player screen (with the battery icon) instead of gpsapp and all the redirections are lost. It is definitely not a reboot cycle because I don't get the startup sequence.

At this point gpsapp is still running in it's main-loop waiting for button presses and serial input. It doesn't realize it is no longer in control and hijack isn't returning any errors in the ioctls, so I can't recover without pulling the sled to restart everything.

Then that's "fast-forwarding the song fast-forwards the song", and I already knew about that, having experienced it slightly differently.