| Re: [chrony-users] Synchronizing clock with GPS with PPS |
[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]
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 |____ unruh@xxxxxxxxxxxxxx Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/ On Wed, 16 Sep 2020, Avamander 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 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.
I guess you could tie the pps to a GPIO and run an interrupt off of that. Mind you it would then need a driver for that interrupt. Do not know what the RPi linux has for that, whether there is one that will deliver the time to /dev/ppsx
On Wed, Sep 16, 2020 at 2:59 AM Bill Unruh <unruh@xxxxxxxxxxxxxx> 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 |____ unruh@xxxxxxxxxxxxxx
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 <rgovostes@xxxxxxxx> 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 <avamander@xxxxxxxxx> 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 <rgovostes@xxxxxxxx>
> 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
> <avamander@xxxxxxxxx> 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
> <rgovostes@xxxxxxxx> 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
> <avamander@xxxxxxxxx> 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 <rgovostes@xxxxxxxx> 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 <avamander@xxxxxxxxx>
> 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
> <rgovostes@xxxxxxxx> 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
> <unruh@xxxxxxxxxxxxxx>
> 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
> |____ unruh@xxxxxxxxxxxxxx
> 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???ʊ
>
>
>
>
| Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |