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).