I've been reading a lot of threads lately about GPS, and specifically, GPS dongles.
I recently retired early from more than 35 years as an IT professional, and my specialties were building and maintaining large computer networks, scalable storage systems, and RF radio systems (usually trunking systems for public safety service). During my tenure I learned the hard way how important accurate timekeeping can be, and how often it is ignored (often resulting in god-awful trouble calls, downed systems, etc.)
I've been building a new rig based on StellarmateOS, and in the process of trying to improve my mount's (an old CGEM) guiding/tracking accuracy, have spent some time considering time. At it's heart, a GEM mount is really nothing more than a clock. RA is measured in hours/minutes/seconds right? That's because our units of time measurement are divided up to reflect the rotation of the earth. So one hour in real time, would result in an RA movement of 15 degrees. Unless you have time problems, that is. Simply put, celestial coordinates rely on timekeeping, and cannot be accurately determined without it. So how important do you think accurate timekeeping should be to an Astronomer?
So, lets talk a bit about GPS.
GPS time has two component parts:
The $GPZDA string, which contains the current time and date in whole seconds
The 1 pulse-per-second (1PPS) "chime" or tick, whose rising edge begins exactly at the start-of-second, and is phase-locked to a cesium oscillator.
The $GPZDA string is received by your local GPS after radio transit lag, and varies according to string length, and speed of serial ports. So the time at your system clock is late by the amount of that lag (offset). Also, since the transit time and string length are variable, the $GPZDA time has significant jitter as well.
Using NTPd with the GPS data helps, since NTP sits between the GPS and system clock, and NTPs specialty is smoothing erratic time sources and compensating for the wambliness. NTP uses both components of a GPS time, to produce a single corrected system time, and it works hard to prevent that time from wandering too much - unless you feed it wambly time data.
On my system, using an RPi 4b4g and Adafruit ultimate GPS breakout, with the PPS output fed to the Debian kernel via the PPIO kernel module, then fed to GPSD along with the $GPZDA string, and then fed to NTPd via shared memory, I haver measured my local time error as:
$GPZDA Offset: -566.62ms Jitter: 26.154ms
PPS Offset: -.001ms Jitter: 0.001ms (1 nanosec)
Thus, my PPS conditioned timeserver's time is accurate to 1 millionth of a second (1 nanosec). Unconditioned by PPS, the NMEA time would be half a second off and vary on every reading.
(Offset is the average delay from correct time, jitter is the average magnitude of wrongness.)
Here's what a the transmissions from the GPS constellation really looks like (taken from a stratum 1 timeserver):
Notice that GPS reports a course and speed. Recall that this server hasn't moved so much as a millimeter in a month. The receiver averages the time variation to create a "cooked TPV" , however it has to have a PPS tied to it to get the start of second. So the time is going to be off >= a half second on each time pushed to GPSD. The location can't be averaged however, since the course and heading values are used for navigation, and need to be real time. Software using the location data should use a regression to average the value into a true course approximation, or just average the values over a period of time to get the true location (which will not be precise, but within the 10m radius error bubble of the receiver.
NTP can fix the time issue by using the PPS signal. Here's what they look like:
Here you can see the time derived from the PPS + GPS listed as ".PPS."
The GPS alone, is listed as ".GPS." (The GPS entries lower down are actually the PPS or SHM clocks at other sites)
Notice the huge offset on the GPS time, along with a massive jitter value. This means, that the time received differs from the correct time by 631ms (.631 seconds) and the reported time varies by 51 milliseconds around that offset on every (once per second) transmit from the GPS. That's a lot of error. Notice that the PPS condition time barely varies at all - .001ms or 1 microsecond. The actual value is a bit less than that.
And now we arrive at the point of the post. Not all GPS units provide an
accessible PPS pulse. USB Dongles seldom provide it.
Thus, the vast majority of dongles will set your system clock a half second off, and each time it sets the time, your clock start-of-second will be different by as much as 26ms, and your system clock will slew every time GPS updates your time, and that error will change both your mount alignment model, and your system timer rates (which are based on tick count - which is what is changed by resetting time.). So, where you are pointing becomes wrong, and your tracking rate becomes wrong as well, and changes to a different error every time the GPS updates the mount time. God help you if it also updates location again too - thus blowing up your mounts timekeeping (alignment and clock rates), and - your tracking/guiding suffers.
Recall that GPS positions are accurate to within about 10 meters in all directions. Update location once, then never again until you shut the mount down, or it will mess up your alignment. Manual just makes more sense here. Use google earth on your phone. You'll get a more accurate location anyway.
If you want to use GPS, then you'll need to go the extra mile, and configure it to be a reliable time source, and that means setting it up to read both $GPZDA and PPS, and then using those signals to lock your timebase down, and ensure all devices are using the same thing.
You flatly cannot get accurate time from most dongle GPS units, and thus using one on your rig, is certain to hose your alignment and tracking a bit, and it will get worse every time it updates your mount's time..
For most users, installing a DS3231 Precision RTC chip in your RPi makes far more sense. This little chip is capable of keeping pretty damn accurate time, down to about 20 PPM of error, and thats pretty good indeed. Set the time on it from an accurate source, set location via google earth, and you'll maintain much better alignment and tracking than a GPS dongle without pps ever will. For a lot less money and hassle. The Stellarmate units come with a DS3231, and plugging a USB dongle into one is just dumb.
If you have an Observatory, or your mount is always connected to your local network, then I recommend using an RPi (2,3,or 4), an adafruit ultimate GPS, and a puck antenna, and building an inexpensive timeserver for your home. Configure the Pi to use the PPS pin on the Adafruit chip, enable PPSIO in the Pi's linux kernel, set up GPSd and NTPd to use it, then change your home router settings to push your time server IP to all dhcp clients. Boom, whole house on time accurate to within a few nanoseconds. Set up your local Pi running Stellarmate or Astroberry (or whatever else) to run NTP, and point it to the timeserver. It will maintain the time very accurately, and eliminate system clock jitter and offset, thus improving your base time, and all system timers based on it (and thats most of them, including software created timers). Cost? About $80 bucks. I spend far more than that on a single filter. I guarantee my TV is more accurate than your Mount
If you are going to the field, use a DS3231. Why pay another $40 to add GPS when a $5 chip will work far better, won't bust your alignment, and with less hassle and no antenna or extra wires to deal with?