I just ran..../mnt/initfs/usr/bin/retutime --get-time and see that the internal clock is 8 hrs ahead of my local time (PST) yet the clock on the NIT is correct.

If the GPS is using the internal clock it would be looking for the satellites in that timezone doesn't that mean it would take time to "right itself" to those in the timezone one is in????

Could it be that easy of an issue....

I live in NW Indiana. While I wouldn't consider it to be as flat as the DFW area (I lived there for 2 years myself) It is definitely not mountainous by any stretch of the imagination

I think the "internal clock" is probably reporting UTC (PDT or PST should be about that) which would be exactly what the GPS would use natively.

Though I think those who are thinking almanac might be onto something.

It would be interesting to see how the nvd_data changed under differing conditions (on under open sky, restart 5 minutes later, restart indoors, etc.).

Correct. To compare hw clock and sw clock, use 'date -u' from the command line to get sw clock UTC time if you want to compare.

I have collected 300 copies of nvd_data, mostly without physically moving the tablet but just by turning off, waiting a bit, then turning on.

The file contains several sections of hex-encoded data. Sometimes, when there is only a few seconds delay since the last on/fix/off cycle, only about
50 bytes change. Other times, about 900 bytes change, or some intermediate amount. I tried looking for data sent to the chip as seen with strace, but didn't see any. Either I did it wrong or the data is reformatted. I guess I was hoping to see something simple, like the
last position or UTC time, but it's not obvious. Anyway, Nokia have the
documentation and if they are working on a fix, that's great.

If anyone is actually interested in this data, let me know (send me an email).

It's in the builtin help (./demo4 -h) but OK, I've written up a few notes
and posted the other versions:
http://andrew.triumf.ca/N810/gpstest/

I may make a version to create GPX. I already have 3 different formats
from my Garmin (Garmin text, GPX and Linux "gd" output) I use to geotag photos, and a 4th is too much ..

oops..."-h" switch for help, how did I miss that...thank you...

When I tried, I found this affected the first fix. Subsequent fixes (with stopping/starting the GPS) where nvd_data was saved with the "wrong" time, were fast.

I note in passing that although the system clock is set from the hardware clock on boot, the hardware clock is not set from the system clock on shutdown (as it is on my desktop). So that if the system clock is adjusted with ntp, ntpdate or "date -s", the system time will revert to
the hardware time on reboot. The desktop application
does change the hardware clock. The GPS programs (gpsdriver, gpsd etc.) do not seem to set either the system or hardware clocks, as would happen on a dedicated GPS device. It might be a good idea to do this;
positional GPS is not as good as a time-setting GPS used as a tier 0
NTP server (NMEA only returns time to the second, and doesn't account for software delays), but hey, it's good to a second or so, close enough for most purposes.

I tried creating /etc/init.d/rc0.d/K05hwclock to save the time, but
couldn't get it to work for some reason. So I just have my crontab entry
set the hardware clock, too:

4 * * * * ntpdate pool.ntp.org && /mnt/initfs/usr/bin/retutime --rtc-from-system

(having ported a simple cron from David Parsons)

data sent to the chip can be seen via strace (given strace's limitations) by using it on gpsdriver.

e.g. "strace gpsdriver" in one xwindow (or via ssh) and then connect to /var/lib/gps/gps_driver_ctrl, e.g. "socat stdio /var/lib/gps/gps_driver_ctrl", where "P 3" followed by return powers up and turns things on, and "P 0" shuts it off. They will echo back when the command is complete, and even if you don't do strace you will get output as it turns on and off.

There are messages even without strace.

SiRF are kind enough to provide documentation of how to talk to their chipsets (http://www.usglobalsat.com/downloads...y_Protocol.pdf), for example how to pass almanac/ephemeris data. This doc says (p3-23) that their ephemeris data is based on ICD-GPS-200 (which is here: https://gpstest.46tg.af.mil/webpub/general/BBS.nsf/0/cb09775cdcb7eb6e8825662d0056ee92/$FILE/icd200c.pdf).

Might be worth a look if anyone is still interested in reverse engineering the nvd_data format.