Re: Using non-PPS receiver for ntpd?

[Greg Troxel]

"Stein, Josh" <josh@anl.gov> writes:

>   I currently only have access to a USB GPS receiver connected to an
> rPi which does not supply PPS data. Despite the lack of PPS accuracy,
> I would like to use this receiver as a clock source to the ntp daemon
> running on that Pi. This Pi in turn will serve time to the other
> devices on my setup giving me a relative synchronization of their
> clocks. In this particular instance, I can tolerate some pretty
> egregious jitter - on the order of tens of seconds.
>
> My first question is fundamental - given the discussion in the guide
> here (https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html), is it
> even feasible to use a non PPS receiver in this role?

Yes, it is entirely feasible.    The time synchronization will have two
accuracy problems:

  a delay of very roughly 100 ms

  variance in that delay

You can calibrate the delay by observing other systems and using fudge
in the NTP config.

The resulting accuracy problems can be viewed as within specification or
terrible, depending on your requirements.  The HOWTO tends to take the
view that every microsecond must be right, or the apocalypse is at hand,
and doesn't really address the (common IMHO) situation of people with
non-PPS setups that would like time that is good to 100ms or maybe even
10 ms and works reliably without an internet connection.   My own view
is that time sync within 1s is vastly better than no time sync, even
though I tend to want better.

I don't have my notes handy, but I ran a Truetime XL-DC in non-pps mode
for years, and (separately) did calibrations for a few USB GPS (u-blox).
I remember delays in the 90-150 ms range.


If you don't care that your whole setup is 150 ms slow, you can just
ignore that.  But if you have internet sometime, I'd advise adjusting
fudge to make the local GPS-derived time line up with the Internet
sources.   Or just guess 100 ms, which is a better guess than 0.

signature.asc
Description: PGP signature