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?

Thanks for your explaination!
I wonder if it really matters the movement of the mount itself.
I use an iOptron mount with it's own GPS. And also OnStep (using GPS PPS on a Teensy 4.0) on a G11.

Honestly I don't see how the time of the Raspberry will affect the mount speed itself. It doesn't update the time, all the time, right?
If I understand correctly, it shouldn't matter at all if the mount updates Ekos, correct?

These days I have been following @bdavis comments on GPSs and time here and on SM facebook. I am installing a second pi unit on my telescope trolley to run a surveillance camera and a gps and those post helped get a more accurate idea of ​​how the whole stuff works.

On the other hand, it is being difficult to me to get up-to-date information on how to set a pps disciplined time server. Currently raspberry pi os uses datetimectl instead of ntp/ntpd. datetimectl is a client side-only system and it’s is very limited in all aspects. I can remove it and install ntp but then there is chrony which is described as a (more) modern ntp system. Should install chrony instead? Unfortunately there are less examples available in the net with chrony.

Anyway, my question:
How the GPSD driver handles time ? Does it take PPS into account?

There is a lot of excellent technical detail covered here. But you are greatly over thinking things.
Primarily your assessment that system time will change the tracking rate of the mount. This is not the case. The tracking rate is handled within the mount and driver. Generally that is siderial rate and is not a variable. Where the benefits of accurate time come in is for accurate GoTo. But being a few seconds off our more is not a show stopper.

The degree of accuracy you get from PPS is however very desirable for capturing and time-stamping footage of transient events such as occultations.

Jabian - I'll try to round up some links and post them tomorrow (not at the PC that has them)
. You're right about conflicting info. I'll give thought to a howto, but in the meantime, be ready to reburn it a time or two


Answering question, no, GPSd only processes the GPS data and streams. NTP turns that into time you can use.

The hardware connects to the kernel (which has PPSIO enabled) which creates two devices - a serial stream, and a PPS stream timestamped by the kernel itself. You configure GPSD to use the two devices. GPSD creates a space in shared memory for other processes to monitor. You then clean up the crappy Pi time software, and install NTP. Other software like chrony can do it, but everyone supports NTP, and NTP is rock solid software. It'll run as long as your server does. Its easy to configure also. Just configure with at minimum two sources - the NMEA serial stream, and the PPS tick from the kernel. NTP then monitors those two streams, and whatever other servers it is listening to, and uses rough time from the NMEA stream, and the PPS source to condition the start-of-second. Once NTP adjusts the system time to match the PPS/GPS derived time, the PPS time is promoted to refclock status, and the NTP server is moved to Stratum 1 statusWhich is cool, but not really relevent . What is relevent is that your system time (system tick counters), which software uses to set up rates) are being actively changed/conditioned by NTP.

lhoujin - Am I overthinking the whole thing? Absolutely! I'm a nerd. And that's what nerds do.

However, tracking rates weren't really the point of my post. My point was, that GPS dongles generally just add problems, but don't improve your astro rig the way consumers are led to believe, and damn sure not worth spending money for more error and potential driver/software headaches.

But sorry, can indeed improve tracking rates in a mount, but not all mounts are equal. The typical consumer mount board and motors benefit from the initial startup start-of-second time from your timesource, and any additional timesetting you can push into them by hook or by crook helps further. One of the reasons I'm switching to Onstep (well, converting my old CGEM to belt/pulleys/steppers (.9deg/400step/128microstep is probably the main reason!) drive, is it's ability to have it's local oscillator conditioned by the same pps signal I use to condition Indi.

In your message uou referred to the mount being like a clock, and that's right, so indeed it makes sense to improve it's timing. But is that really the bottle-neck of the mount? I think the mechanisms and the alignment are more urgent matters.
I think you'll get better tracking from removing the belt drive and couple the motor to the worm via a torsionally stiff coupling such as a bellows coupling.
The small variations in time will get evened out by guiding anyway, in part also the mechanism will be corrected, but the less hysteresis/ backlash is has, the better.
Belts are like rubber bands (sure they have a fiber core, but even then) so will have hysteresis depending on how much friction the worm encounters, which varies due to excentricity errors.
Also, there are better choices for belts compared to maybe stock ones. HTD is old fashioned. Genuine Gates GT3 is much better.
Direct drive (for example NSK megatorque motors) is the ultimate

By the way, thanks for writing about the interaction of GPS with Rpi, it's really educational

Bart,

It's mostly a matter of improving the spur gear drive the CGEM came with. The case is cast to fit the spur drive, which really stunk. I can squeeeeeeze a belt drive system in there, Using high quality belts, shouldn't be too much trouble with backlash, but what is there, can be adjusted out in Onstep.

Frustratingly, I'm down to printing the final set of brackets, and blew up my 3d printer doing a firmware update. So battling that right now.

Just to restate the important points:

Alignment is the process of correcting time and location error in your mount.

1. Pay more attention to keeping the time synchronized between all the parts of your gear
2. If you have a GPS dongle, use it to set time/location once BEFORE alignment, then unplug it. Align AFTER timeset.
3. If you have networked gear, use it to coordinate time. NTP is your friend.
4. If you want to improve your timekeeping, add a DS3231 chip to your stellarmateOS pi, and use the DS3231 in the Stellarmate Pis.
5. Don't waste your money on dongles, and never let one update your mount after alignment

Yes, Guiding can compensate for small time errors - but the less a guider has to intervene, the better. Breaking your alignment just pushes you that much closer to quiding failure.

About Point 2:
I have my astro system working remote; unplugging a dongle is a hassle to say the least.
A better solution would be to ask Kstars / EKOS/ INDI to read time and position only once and refresh the data only if expressly requested.

- How Kstars / EKOS/ INDI works in this respect ?
- Do they refresh location and time data periodically from the GPS ? (there is a 'refresh period' entry in INDI for the GPSD driver)
- If the system periodically refresh location and time datat from GPS, is there a way to ask INDI to do it just once ? (maybe setting 'refresh period' to zero or to a very high number)

Hi jabian,
In the GPS NEMA driver, there is a refresh parameter that tells the driver how often to refresh. If you set it to 0 (zero), then the driver won't refresh the position and time from the nema source again.