Unfortunately, I haven’t had enough spare to time to tinker with my devices since I bought them. But today I got access to an usb gps dongle , so I decided to spent time trying to run one of my devices using GPS timing. I’ve noticed this usb dongle don’t work using the PPS option on ntp.conf file, so I tried it using GPS option. While playing with cgps I’ve realized that the Time Offset flag had a value of 0.50s. After 3 hours of running, I noticed this value is almost constant.
So guys three questions:
Does this time offset value affect the accuracy of the device’s timing? I think that it means raspberry clock is set 0.500s delayed of real GPS time.
I’ve notice after this 3 hours test, the output of ntpq shows an x on GPS server rather than a *. Does it this affect the timing accuracy too?
Not using the PPS device recommended on RS manual but GPS devices have an effect on timing? Does the advertised <10ms drift can be reached not using PPS?
Thanks in advance. Please continue with this excellent project.
I did some work using GPS source for NTP on Raspberry Pi a few years ago.
Regarding PPS, it is quite likely that your USB GPS is not exposing that signal to the Raspberry Pi.
Regarding the report of the GPS source from ntpq, since you have other sources, the NTP service can compare the quality of that source relative to the remote sources. The ‘x’ indicates that the service is rejecting that input as false. This is likely due to the offset you have noticed.
What I have done in the past is let the service run for a while and note the reported offset once the values stabilize. In the NTP configuration file there is a setting for the GPS source starting with fudge. The value you want to tweak is time1. It is likely near 0.500 now. You will want to reduce that by the current offset as reported by ntpq.
Once you have that, the NTP service should synchronize to the GPS signal.
The output of ntpq shows offest is less than 5.0 having the GPS doungle as source. But the set time is delayed by 0.5s as shown in cpgs -s. I tried the GPS antenna in a raspbian device and the cpgs flag Time Offset is near zero. Also I added this raspbian devices as ntp server to my RS device and I got a second GPS antenna running on the RS1D, so this device has two GPS based sources stratum 1 (raspbian device) and stratum 0 (plugged usb dongle). The output of ntpq shows an offset about 489 500 with respect of the raspbian server after more than 24 hours.
So I suspect this offset shown in cpgs -s is something set by the Raspberry shake OS not by the gps antenna. Before changing ntp.conf settings I would like to get feedback from RS team.
I think cgps is reporting values directly from the GPS source.
As for getting the connection from the GPS to ntpd, I’m going to refer to this document created by Eric Raymond as part of his work on the NTPSEC project.
The one thing I will mention here is that the offset in ntpq is in milliseconds(ms) and the fudge time1 value is in seconds(s). If you are seeing an offset of 489 ms in the ntpq output, you might try a time1 value of 0.011.
This document on the GPSD site has additional background, and a few different methods of calculating the time1 value that should be used.
reading through the thread so far, i can say this: Traveller is correct when he says that your GPS module is likely not exposing the PPS signal to the Pi. the reason for this is that is difficult for a manufacturer to guarantee that the PPS signal is able to be delivered accurately over the USB port over all time.
(the typical use of a GPS module connected through a USB port is primarily intended for location purposes as opposed to accurate timing, where the GPS time is meant to be a clock that is “close enough”, and not meant as an accurate PPS.)
Traveller is also correct when he suggests it might be possible to get the GPS clock closer to the real time by adjusting the fudge factor in the /etc/ntp.conf file, though it remains to be seen if this value would remain correct over all time.
while i don’t know your specific use-case, something to keep in mind: if the unit will have access to the internet under normal operations, then using a GPS module will not get you a more accurate time than a normal NTP server. in fact, if you are getting your time over the GPS memory slot, it will be worse since the jitter will likely be unstable.
in any case, this is exactly why we strongly suggest to use the GPS module offered at the Shake’s Shop Web-site, since it is configured to deliver the PPS signal over USB to the shared memory slot used by the NTP daemon.
If my memory is correct (could be wrong) most USB GPS devices don’t offer PPS due to inaccuracies caused by the inherent delay in the USB interface. When you DO have PPS you need to have the NMEA GPS info as “prefer” in Ntp.conf because the PPS pulse is just that, a pulse, with no other data. Something is needed to align that with a time signal, so the need for NMEA.
There is a Windows program called NMEAtime that MAY let you get enough precision on another computer to provide local time service to your shake, but it won’t be as precise.