> I do not use gpsd for the pps. I use the serial port to read the interrupt > modprobe ppl-ldisk > ldattach 18 /dev/ttyS0
This is very interesting, thank you very much for mentioning it. I'll try it out when I get the moment. > Sticking another program (gpsd) between the device and the kernel does not seem like a great idea to me. You are absolutely correct, but in my/our defense, it is what's recommended everywhere and it does provide some nice overview of what's going on with the GPS + it can configure it. > (USB emulation of a serial port?) Physical serial port with only TX-RX on the Pi hardware. Ports with such a name are usually USB though, yes. On Wed, Sep 16, 2020 at 2:59 AM Bill Unruh <un...@physics.ubc.ca> wrote: > I do not use gpsd for the pps. I use the serial port to read the interrupt > modprobe ppl-ldisk > ldattach 18 /dev/ttyS0 > > Now I have no idea what kind of device a ttyAMA0 is (USB emulation of a > serial > port?) Sticking another program (gpsd) between the device and the kernel > does > not seem like a great idea to me. > > But then I do not use something like a Rasberry. > > > > 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 ______|_ www.theory.physics.ubc.ca/ > > On Tue, 15 Sep 2020, Ryan Govostes 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 > > > > 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%2Fgps > > > d%2Fgpsd-time-service-howto.html%23_feeding_chrony_from_gpsd&data=02%7C01%7Crgovos > > tes%40whoi.edu > %7C86536cbb401c44a3c5cc08d859b6a884%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7 > > > C0%7C0%7C637357988356257028&sdata=N%2B8IAnmUrjXdPylbVOLjEXRfEGbG1QrLbGrToTbRHLU%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.p > > hysics.ubc.ca%2F&data=02%7C01%7Crgovostes%40whoi.edu > %7C86536cbb401c44a3c5cc08d859b > > > 6a884%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637357988356257028&sdata=EkXZPl > > > y9ps2U3qVb7qot7CxssLBlwUCyqTblGkx8FKo%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???ʊ > > > > > > > >
