Reading the replies by Gary E. Miller it seems that your only options are to either rewire your PPS output 🙄 or patch gpsd to fix the wrong association. I personally went with rewiring my PCB because it was less effort than building my own gpsd.
On Wed, Sep 16, 2020 at 1:56 AM Ryan Govostes <rgovos...@whoi.edu> wrote: > Here is the bug I filed: https://gitlab.com/gpsd/gpsd/-/issues/103 > > Specifying /dev/pps0 on the gpsd command line works to an extent in that > it causes gpsd to start publishing to chrony.pps0.sock. However, it still > has trouble in that it refuses to publish to chrony.ttyAMA1.sock because > there’s some issue with /dev/pps1 (I think). > > Ryan > > On Sep 15, 2020, at 6:54 PM, Avamander <avaman...@gmail.com> wrote: > > > I’ll file a bug against gpsd for this case. > > Well no need, this behaviour was deemed "correct" already. > > > sudo gpsd -n -N -D3 -F /tmp/gpsd.sock /dev/ttyAMA1 > > Manually specifying /dev/pps0 here doesn't help? > > > > On Wed, Sep 16, 2020 at 12:49 AM Ryan Govostes <rgovos...@whoi.edu> wrote: > >> Seems like gpsd hardcodes /dev/ttyAMA0 as “oh you’re using a Raspberry Pi >> HAT” and then uses /dev/pps0, which would be the GPIO PPS source. Otherwise >> it searches sysfs to find the PPS device for the given NMEA device. >> >> The reason it has to have that hardcoded is because the kernel pps-gpio >> driver does not populate the `path` for the corresponding serial device >> with the NMEA feed. (Perhaps it should let you override it if that GPIO PPS >> source corresponds with a separate device.) >> >> >> https://github.com/torvalds/linux/blob/master/drivers/pps/clients/pps-gpio.c >> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fblob%2Fmaster%2Fdrivers%2Fpps%2Fclients%2Fpps-gpio.c&data=02%7C01%7Crgovostes%40whoi.edu%7C783f37e18dca4f007cb208d859ca50ce%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637358072779884574&sdata=L2Kik9OpWKOyFujF7h4CfucsKNCT45gxH24%2FjRYRPKU%3D&reserved=0> >> >> Since I’m using /dev/ttyAMA1, that hack doesn’t trigger. >> >> I’ll file a bug against gpsd for this case. >> >> Ryan >> >> >> On Sep 15, 2020, at 4:33 PM, Ryan Govostes <rgovos...@whoi.edu> wrote: >> >> 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgpsd.gitlab.io%2Fgpsd%2Fgpsd-time-service-howto.html%23_feeding_chrony_from_gpsd&data=02%7C01%7Crgovostes%40whoi.edu%7C86536cbb401c44a3c5cc08d859b6a884%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637357988356257028&sdata=N%2B8IAnmUrjXdPylbVOLjEXRfEGbG1QrLbGrToTbRHLU%3D&reserved=0 >> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgpsd.gitlab.io%2Fgpsd%2Fgpsd-time-service-howto.html%23_feeding_chrony_from_gpsd&data=02%7C01%7Crgovostes%40whoi.edu%7C783f37e18dca4f007cb208d859ca50ce%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637358072779894569&sdata=fGVNsCxbFvFLGpAXhcbgE37poR9Keu4TA23%2Bgj%2FnaKw%3D&reserved=0> >> >> 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%7C86536cbb401c44a3c5cc08d859b6a884%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637357988356257028&sdata=EkXZPly9ps2U3qVb7qot7CxssLBlwUCyqTblGkx8FKo%3D&reserved=0 >> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.theory.physics.ubc.ca%2F&data=02%7C01%7Crgovostes%40whoi.edu%7C783f37e18dca4f007cb208d859ca50ce%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637358072779894569&sdata=NiQW4SXKjvekB8CV9roLWcQ3x5VVYrAl7Sr2dao1D0I%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? >> >> >> >> >> >> >> ��칻 �&�zf���k�|�����z�\��'�۱}���*+� ���칻 �&ފ{az˛��- ��zZ^���r >> �+�z�+z����!����_jh�ʊ��+a��i�{az˛��-N�.nW�����+-��-z�!����_jh�ʊ >> >> >> >
