I can confirm that /dev/ttyAMA1 streams incoming NMEA messages. I can confirm /dev/pps0 is a working PPS device.
I can confirm that gpsd is configured to access /dev/ttyAMA1 and when I launch it with sudo gpsd -n -N -D3 -F /tmp/gpsd.sock /dev/ttyAMA1 I see it getting a satellite fix, suggesting it is receiving NMEA messages just fine, although it has the /dev/pps1 error messages as below. If I use `strace` on gpsd, then I see that it connects to /var/run/chrony.ttyAMA1.sock (/var/run being a symlink to /run it should be OK): connect(8, {sa_family=AF_UNIX, sun_path="/var/run/chrony.ttyAMA1.sock"}, 30) = 0 I never see it reading or writing file descriptor 8, so it clearly is not sending anything to chronyd. It appears that /dev/pps1 is created some time after gpsd starts. /sys/devices/virtual/pps/pps1 appears and the path file contains the text /dev/ttyAMA1. gpsd scans through all of these pps/*/path files to find the one matching the NMEA device it is configured for, so that’s why it ends on /dev/pps1. I still don’t know who exactly is creating /sys/devices/virtual/pps/pps1 — strace doesn’t put the blame on either chronyd or gpsd, but otherwise this is a vanilla system I installed just a few days ago. Ryan > On Sep 15, 2020, at 4:05 PM, Avamander <avaman...@gmail.com> wrote: > > Check what you have specified in the list of devices to be used. > > I personally couldn't convince gpsd to use pps1 instead of pps0, but you > might be having the opposite issue :S > > What actually is pps1 on your system? It might play a role. > > On Tue, Sep 15, 2020 at 11:02 PM Ryan Govostes <rgovos...@whoi.edu> wrote: > I’m not sure. Its logs look OK, but it prints out: > > gpsd:INFO: KPPS:/dev/ttyAMA1 RFC2783 path:/dev/pps1, fd is 9 > > Note that /dev/pps1 is _not_ the PPS device I expect to use. This device only > appears while gpsd is running so it appears to be created by it? ppstest only > reports timeouts for this one, while pps0 continues to work as expected. > > More context: > > gpsd:INFO: KPPS:/dev/ttyAMA1 RFC2783 path:/dev/pps1, fd is 9 > gpsd:INFO: KPPS:/dev/ttyAMA1 pps_caps 0x1133 > gpsd:INFO: KPPS:/dev/ttyAMA1 have PPS_CANWAIT > gpsd:INFO: KPPS:/dev/ttyAMA1 kernel PPS will be used > … > gpsd:INFO: KPPS:/dev/ttyAMA1 kernel PPS timeout Interrupted system > call > … > gpsd:INFO: KPPS:/dev/ttyAMA1 kernel PPS timeout Connection timed out > > Ryan > > > On Sep 15, 2020, at 3:57 PM, Avamander <avaman...@gmail.com> wrote: > > > > > However, `chronyc` does not report any updates being received from this > > > source. > > > > If you aren't seeing anything on SHM1 either, then gpsd still has issues > > with reading the PPS source. Check its logs. > > > > On Tue, Sep 15, 2020 at 10:56 PM Ryan Govostes <rgovos...@whoi.edu> wrote: > > Ah OK, I guess the part that was not clear to me was that chronyd _creates_ > > this socket when configured with refclock SOCK, rather than simply > > connecting to it. > > > > When I configured this and restarted chronyd and then gpsd, it did create > > the socket file. However, `chronyc` does not report any updates being > > received from this source. > > > > I did not find an AppArmor profile that is currently being enforced on gpsd. > > > > I did notice that AppArmor was preventing chronyd from creating > > /run/chronyd.pps0.sock, so I corrected that and switched the configuration > > to: > > > > refclock SOCK /run/chrony.ttyAMA1.sock refid GPS precision 1e-1 > > refclock SOCK /run/chrony.pps0.sock refid PPS precision 1e-7 > > > > However I still do not receive any updates. > > > > Ryan > > > > > On Sep 15, 2020, at 3:20 PM, Avamander <avaman...@gmail.com> wrote: > > > > > > > but also I don’t see that socket you’re referencing being created. > > > > I don’t see any AppArmor logs that seem to indicate anyone was > > > > prevented from creating this file. > > > > > > Have you actually told chrony to create it? > > > > > > > for a while but the PPS never updated: > > > > > > Yes, this is exactly why I suggested you check the AppArmor policy > > > itself. When the pps device is inaccessible gpsd gives some vague error > > > about the pps device and that's it. Open gpsd's log and verify it hasn't > > > thrown an error about the pps device during startup. > > > > > > > I couldn’t readily find much documentation on SHM 0 vs SHM 1. > > > > > > Yes, this is awfully documented online. > > > > > > > > > > > > On Tue, Sep 15, 2020 at 10:08 PM Ryan Govostes <rgovos...@whoi.edu> wrote: > > > Below Bill argued against using /var/run/chrony.ttyAMA0.sock, but also I > > > don’t see that socket you’re referencing being created. I don’t see any > > > AppArmor logs that seem to indicate anyone was prevented from creating > > > this file. Perhaps the version is too old? > > > > > > I couldn’t readily find much documentation on SHM 0 vs SHM 1. I did find > > > this, which suggests using SHM 1 instead of having chrony go directly to > > > the PPS device, as in: > > > > > > refclock SHM 0 refid GPS precision 1e-1 > > > refclock SHM 1 refid PPS precision 1e-7 > > > > > > https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html#_feeding_chrony_from_gpsd > > > > > > I restarted chronyd with this configuration and watched `chronyc sources` > > > for a while but the PPS never updated: > > > > > > 210 Number of sources = 2 > > > MS Name/IP address Stratum Poll Reach LastRx Last sample > > > > > > =============================================================================== > > > #* GPS 0 4 377 22 > > > +1104us[+4464us] +/- 100ms > > > #? PPS 0 4 0 - +0ns[ > > > +0ns] +/- 0ns > > > > > > I disabled systemd-timesyncd as you suggested, thanks. > > > > > > Ryan > > > > > > > On Sep 15, 2020, at 2:42 PM, Avamander <avaman...@gmail.com> wrote: > > > > > > > > First, disable systemd-timesyncd if you're using chrony: sudo systemctl > > > > disable --now systemd-timesyncd > > > > > > > > Second, enable chrony, pretty sure it isn't enabled by default after > > > > install: sudo systemctl enable chrony > > > > > > > > Why do you want to SHM 0 (non-PPS-corrected) NMEA time, instead of SHM > > > > 1 or /var/run/chrony.ttyAMA0.sock? > > > > > > > > On Tue, Sep 15, 2020 at 9:36 PM Ryan Govostes <rgovos...@whoi.edu> > > > > wrote: > > > > Thanks, I removed the offset and delay so the reference clock > > > > configuration is now: > > > > > > > > refclock SHM 0 refid GPS precision 1e-1 > > > > refclock PPS /dev/pps0 refid PPS > > > > > > > > My intention is to have GPS set the system date and time and then have > > > > the PPS signal keep it from drifting. > > > > > > > > After applying this, I ran again and am now getting: > > > > > > > > MS Name/IP address Stratum Poll Reach LastRx Last sample > > > > > > > > =============================================================================== > > > > #x GPS 0 4 377 16 +587us[ > > > > +587us] +/- 100ms > > > > #x PPS 0 4 160 82 -128ms[ > > > > -128ms] +/- 759ns > > > > > > > > The #x suggests that “time may be in error.” However I am still seeing > > > > gpsd work (monitored via cgps) and the PPS device still appears to be > > > > working (according to ppstest). > > > > > > > > Furthermore timedatectl suggests that the system clock is not > > > > synchronized: > > > > > > > > $ timedatectl status > > > > Local time: Tue 2020-09-15 18:34:48 UTC > > > > Universal time: Tue 2020-09-15 18:34:48 UTC > > > > RTC time: n/a > > > > Time zone: Etc/UTC (UTC, +0000) > > > > System clock synchronized: no > > > > systemd-timesyncd.service active: yes > > > > RTC in local TZ: no > > > > > > > > What appears to be the problem? > > > > > > > > Ryan > > > > > > > > > On Sep 15, 2020, at 12:47 PM, Bill Unruh <un...@physics.ubc.ca> wrote: > > > > > > > > > > > > > > > > > > > > William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273 > > > > > Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324 > > > > > UBC, Vancouver,BC _|_ Program in Cosmology |____ un...@physics.ubc.ca > > > > > Canada V6T 1Z1 ____|____ and Gravity ______|_ > > > > > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.theory.physics.ubc.ca%2F&data=02%7C01%7Crgovostes%40whoi.edu%7C054736ed4c39434c82db08d8599714d3%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637357852718387997&sdata=qHAUE4iPB4YLvLVCtFetR33HnDjEowrOa%2FpWLANdNpE%3D&reserved=0 > > > > > > > > > > On Tue, 15 Sep 2020, Ryan Govostes wrote: > > > > > > > > > >> Hi all, > > > > >> > > > > >> I am setting up chronyd on an embedded Linux device to synchronize > > > > >> the system clock using a GPS module. The GPS device sends NMEA > > > > >> strings over the character device /dev/ttyAMA1 and I have also > > > > >> configured /dev/pps0, both of which appear to be working OK. > > > > >> > > > > >> The system is running Ubuntu 18.04 and the latest package versions > > > > >> are chronyd 3.2 and gpsd 3.17. > > > > >> > > > > >> I configured gpsd to listen to the serial device and then added > > > > >> these lines to my chrony.conf: > > > > >> > > > > >> refclock SHM 0 refid GPS precision 1e-1 offset 0.9999 delay 0.2 > > > > > > > > > > Why those figures for ooffset? That is 1 sec offset. NMEA is not that > > > > > bad. > > > > > > > > > > > > > > >> refclock PPS /dev/pps0 refid PPS > > > > >> > > > > >> When I run `chronyc sources` they both seem to be kind of working: > > > > >> > > > > >> 210 Number of sources = 2 > > > > >> MS Name/IP address Stratum Poll Reach LastRx Last sample > > > > >> > > > > >> =============================================================================== > > > > >> #- GPS 0 4 377 12 +128ms[ > > > > >> +128ms] +/- 200ms > > > > >> #* PPS 0 4 377 12 +6ns[ > > > > >> +119ns] +/- 203ns > > > > >> > > > > >> However it looks like the GPS source is “not combined”. Is this a > > > > >> degraded state, e.g., it is using one of these two sources? > > > > > > > > > > Why would one want to combine GPS with PPS. PPS is good to the > > > > > nanosecond > > > > > level. GPS toabut 100 ms -- that is almost a million times worse. It > > > > > would be like combining your wristwatch with some clock which says > > > > > "its > > > > > spring so it must be April". > > > > > > > > > >> > > > > >> Also, I am not sure why the LastRx from the PPS (or frankly either) > > > > >> ticks upwards so long—shouldn’t it constantly be receiving updates? > > > > > > > > > > Yout tell it that POLL is 4 which means 16 seconds. So every 16 > > > > > seconds that > > > > > clock is read. The driver massages the input ( once a second) to get > > > > > rid of > > > > > obvious outliers but reports to chrony once every 16 seconds. Note it > > > > > is a bad > > > > > idea to reduce the poll even further. Then obvious ouliers are not > > > > > thrown out, > > > > > and the ability to determine the rate of the clock is degraded. > > > > > > > > > >> > > > > >> I am just using the precision / offset / delay figures that several > > > > >> examples use. Is there documentation on calibrating these values? > > > > > > > > > > Get rid of the offset and delay. The GPS is useless except for > > > > > setting actual > > > > > number of the seconds. > > > > > > > > > >> > > > > >> Finally, I read that using Unix sockets rather that shared memory is > > > > >> preferable, but my chronyd does not seem to create those sockets. > > > > > > > > > > Why is it better? Leave things as they are. With PPS your time will be > > > > > accurate to microseconds just as things are now. Do you need any > > > > > better time? > > > > > If you do need time to nanoseconds, then you will really have to > > > > > throw away > > > > > your computer (its ability to read interrupts is only at the > > > > > microsecond > > > > > level) and begin compensating for propagation delays in your gps > > > > > unit, and > > > > > also the sawtooth offset on the ns level due to your gps receiver > > > > > innards. But > > > > > then, why would you want to know the time to 1 billionth of a second? > > > > > > > > > >