| Re: [chrony-users] Time from gpsd via socket |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Thu, 23 Jul 2020, David Glover-Aoki wrote:
I’m trying to setup a Pi to be a home NTP server, getting both time and PPS from GPS. I have the Adafruit Ultimate GPS hat. There are plenty of guides for this on the web, but they all seem to be for Debian 9, and “Raspberry Pi OS”, as Raspbian is now known, is now based on Debian 10, and things have changed.
gpsd is connected to /dev/ttyS0 (in Debian 9, it was called ttyAMA0) and /dev/pps0. “gpsmon” shows time, position, and PPS offset, so I believe it is setup correctly.
My chrony.conf is as follows:
server router.home iburst noselect
keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
logdir /var/log/chrony
log refclocks
maxupdateskew 100.0
rtcsync
makestep 1 -1
allow
refclock SOCK /run/chrony.pps0.sock refid GPS
“chronyc sources” shows this:
210 Number of sources = 2
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#* GPS 0 4 377 16 -489ns[ -565ns] +/- 421ns
^? router.home 2 8 377 210 -2535us[-2536us] +/- 39ms
Is this setup correctly? Originally, I was following this guide:
https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html#_feeding_chrony_from_gpsd
The proof of the pudding.... It is disciplining your clock to the hundreds of
nanoseconds level. It is doing fine.
And I had two “refclock” lines, one for “GPS” pointing at ttyS0, and one for “PPS” pointing at “pps0”, but I could not get this to work. The PPS line returned data, but the GPS line always had a “Reach” of 0.
Yes, the other line is for delivering the seconds. The interrupt has no time
attached to it, all the system knows is that it occurs at the top of the
second ( to witin a few nanoseconds, or microseconds once one has taken into
account all the interrupt latencies etc). To know which second that top of the
second refers to, it uses the system time. Thus you have to get the system
time good to within half a second before you hand it over to the PPS timing.
It does not matter how you do that (wrist watch, gpsd, ntp from a pool server,
....). but you have to do tht before you start using the PPS.
The usual way is to use the time that the gps receiver also delivers, probably
via the serial port or via a usb port, or sometimes the parallel port,
Once the PPS starts, the system rapidly discovers it is by far the best clock
and uses it.
However if the system is started without it being within half a second of the
true time, then the system could decide to grab whatever time it is at, and
assume that is the true times to within a second. Thus your system will be
terribly precise, but may be out by 47 sec, or 3hr 7min and 26 sec exactly.
In my configuration above, does the single “refclock” line return time *and* PPS? Or just PPS? How can I tell?
If I do need two refclocks for time and pps, how can I determine why the original “GPS” refclock wasn’t working?
Linux does not need gpsd. It has the serial port driver which can also read
the time. Test to see if the ttyS0 is getting the NMEA sentences from the gps.
(eg run minicom on the /dev/ttyS0 to see if sentences are coming in.) If they
are, then you can setup gpsd to read them, extract the time, and place it
where chrony can find it (eg an SHM memory location).
Thanks.
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.