subject:"Re\: \[chrony\-users\] Synchronizing clock with GPS with PPS"




William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics _|___ 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 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  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 _|___ 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  
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  
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 

  >       wrote:
  >       I’m not sure. Its logs look OK, but it prints out:
  >
  >

Re: [chrony-users] Synchronizing clock with GPS with PPS

Just as a side note here, I am on /dev/ttyAMA1 because the Raspberry Pi 4 has 
additional UARTs that can be configured with other device tree overlays.

> On Sep 15, 2020, at 9:02 PM, Hal Murray  wrote:
> 
>> But then I do not use something like a Rasberry.
> 
> On a Pi, the built in serial port is /dev/ttyAMA0
> It doesn't have any pins for the modem control signals.
> At least with the typical setup.
> 
> On a Pi and similar SoC chips, there are not enough pins for all the 
> potential 
> uses.  There is a layer of muxing between the pins and the built in I/O 
> devices.  The normal setup assigns lots of pins to GPIO.  With some work, you 
> could probably activate the modem control signals.  I think device-tree is 
> the 
> buzz word.
> 
> On a Pi, the usual way is to turn one of the GPIO pins into a PPS.  gpsd 
> normally sets up a /dev/pps to go with a serial port.  There should be a 
> way to tell GPSD to use /dev/pps0 rather than set up a new one.  I don't know 
> how to do that, but that's what you should be looking for what scanning the 
> gpsd documentation.

From the brief flamewar that seems to have ensued from my asking the question, 
such a feature would be implemented over the maintainer’s dead body… A simple 
symlink of /dev/pps1 to the one you want it to use seems to work, though it is 
a clearly a hack.

> 
> If gpsd is setting up /dev/pps1, it won't work.  That internal signal doesn't 
> go anywhere.
> 
> -
> 
> My notes from setting up a Pi, non gpsd:
> 
> # PPS via gpio
> #  
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.satsignal.eu%2Fntp%2FRaspberry-Pi-NTP.html%23easydata=02%7C01%7Crgovostes%40whoi.edu%7C39146838a40e4910e20208d859dc39b0%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637358150270275800sdata=yKWT9t33FvblBfKuufUPTCIL8aoqVxFvDmpS%2F6jqTeE%3Dreserved=0
>  vi /boot/cmdline.txt
>remove the chunk(s) with ttyAMA0
>  vi /boot/config.txt
>add new line: dtoverlay=pps-gpio,gpiopin=18
>pin 4 on Adafruit GPS HAT
>  vi /etc/modules
>add new line: pps-gpio
>  vi /etc/inittab
>run raspi-config Interfacing-Options/Serial
>comment out getty line for ttyAMA0 (at bottom)
> 
> The GPIO pin numbering is different from the chip/hardware pin numbering.
> 
> When this gets sorted out, somebody should write a HOWTO for using chrony and 
> gpsd on a Pi.
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> 
> -- 
> To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
> with "unsubscribe" in the subject.
> For help email chrony-users-requ...@chrony.tuxfamily.org 
> with "help" in the subject.
> Trouble?  Email listmas...@chrony.tuxfamily.org.
>

Re: [chrony-users] Synchronizing clock with GPS with PPS

2020-09-15 Thread Hal Murray

> But then I do not use something like a Rasberry.

On a Pi, the built in serial port is /dev/ttyAMA0
It doesn't have any pins for the modem control signals.
At least with the typical setup.

On a Pi and similar SoC chips, there are not enough pins for all the potential 
uses.  There is a layer of muxing between the pins and the built in I/O 
devices.  The normal setup assigns lots of pins to GPIO.  With some work, you 
could probably activate the modem control signals.  I think device-tree is the 
buzz word.

On a Pi, the usual way is to turn one of the GPIO pins into a PPS.  gpsd 
normally sets up a /dev/pps to go with a serial port.  There should be a 
way to tell GPSD to use /dev/pps0 rather than set up a new one.  I don't know 
how to do that, but that's what you should be looking for what scanning the 
gpsd documentation.

If gpsd is setting up /dev/pps1, it won't work.  That internal signal doesn't 
go anywhere.

-

My notes from setting up a Pi, non gpsd:

# PPS via gpio
#  http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#easy
  vi /boot/cmdline.txt
remove the chunk(s) with ttyAMA0
  vi /boot/config.txt
add new line: dtoverlay=pps-gpio,gpiopin=18
pin 4 on Adafruit GPS HAT
  vi /etc/modules
add new line: pps-gpio
  vi /etc/inittab
run raspi-config Interfacing-Options/Serial
comment out getty line for ttyAMA0 (at bottom)

The GPIO pin numbering is different from the chip/hardware pin numbering.

When this gets sorted out, somebody should write a HOWTO for using chrony and 
gpsd on a Pi.


-- 
These are my opinions.  I hate spam.




-- 
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org 
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org 
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-users] Synchronizing clock with GPS with PPS

> 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  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 _|___ 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 
> 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 
> 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  >
> >   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
> >

Re: [chrony-users] Synchronizing clock with GPS with PPS


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 _|___ 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  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  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 
  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
 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
 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

Re: [chrony-users] Synchronizing clock with GPS with PPS

Wait a while. Your PPS is still catching up.

On Tue, 15 Sep 2020, Ryan Govostes 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 37716 +587us[ +587us]
+/- 100ms
#x PPS 0 4 16082 -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, +)
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 wrote:

William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics _|___ 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%2Fdata=02%7C01%7Crgovostes%40whoi.edu%7C054736ed4c39434c82db08d8599714d3%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637357852718387997sdata=qHAUE4iPB4YLvLVCtFetR33HnDjEowrOa%2FpWLANdNpE%3Dreserved=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. 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 37712 +128ms[ +128ms]
+/- 200ms
#* PPS 0 4 37712 +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

Re: [chrony-users] Synchronizing clock with GPS with PPS

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  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  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  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  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  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 
>> 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  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 
>> wrote:
>> Ah

Re: [chrony-users] Synchronizing clock with GPS with PPS

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 
mailto: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 
mailto: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

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 
mailto: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 
mailto: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 
mailto: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 
mailto: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 
mailto: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

Re: [chrony-users] Synchronizing clock with GPS with PPS

> 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  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  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  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  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  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  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  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

Re: [chrony-users] Synchronizing clock with GPS with PPS

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 
mailto: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 
mailto: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 
mailto: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 
mailto: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 
mailto: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 
mailto: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

Re: [chrony-users] Synchronizing clock with GPS with PPS

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  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  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  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  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  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  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,

Re: [chrony-users] Synchronizing clock with GPS with PPS

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  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  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 
> 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  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 
> 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   37722
> +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  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 
> wrote:
> > > > Thanks, I removed the offset and delay so the reference clock
> configuration

Re: [chrony-users] Synchronizing clock with GPS with PPS

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  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  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  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  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   37722  
> > +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  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  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

Re: [chrony-users] Synchronizing clock with GPS with PPS

> 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  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  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 
> 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   37722
> +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  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 
> 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   37716   +587us[
> +587us] +/-  100ms
> > > #x PPS   0   4   16082   -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, +)
> > > System clock synchronized: no
> > > systemd-timesyncd.service active: yes
> > > RTC in local TZ: no
> > >
> > > What appears

Re: [chrony-users] Synchronizing clock with GPS with PPS

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  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  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   37722  +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  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  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   37716   +587us[ 
> > +587us] +/-  100ms
> > #x PPS   0   4   16082   -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, +)
> > 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  wrote:
> > > 
> > > 
> > > 
> > > William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
> > > Physics _|___ Advanced Research _| Fax: +1(604)822-5324
> > > UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
> > > Canada V6T 1Z1 | and

Re: [chrony-users] Synchronizing clock with GPS with PPS

> 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  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   37722
> +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  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 
> 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   37716   +587us[
> +587us] +/-  100ms
> > #x PPS   0   4   16082   -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, +)
> > 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  wrote:
> > >
> > >
> > >
> > > William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
> > > Physics _|___ 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%2Fdata=02%7C01%7Crgovostes%40whoi.edu%7C054736ed4c39434c82db08d8599714d3%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637357852718387997sdata=qHAUE4iPB4YLvLVCtFetR33HnDjEowrOa%2FpWLANdNpE%3Dreserved=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

Re: [chrony-users] Synchronizing clock with GPS with PPS

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  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   37716   +587us[
> +587us] +/-  100ms
> #x PPS   0   4   16082   -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, +)
> 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  wrote:
> >
> >
> >
> > William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
> > Physics _|___ 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%2Fdata=02%7C01%7Crgovostes%40whoi.edu%7C054736ed4c39434c82db08d8599714d3%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637357852718387997sdata=qHAUE4iPB4YLvLVCtFetR33HnDjEowrOa%2FpWLANdNpE%3Dreserved=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. 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   37712   +128ms[
> +128ms] +/-  200ms
> >>  #* PPS   0   4   37712 +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

Re: [chrony-users] Synchronizing clock with GPS with PPS

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   37716   +587us[ +587us] 
+/-  100ms
#x PPS   0   4   16082   -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, +)
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  wrote:
> 
> 
> 
> William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
> Physics _|___ 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%2Fdata=02%7C01%7Crgovostes%40whoi.edu%7C054736ed4c39434c82db08d8599714d3%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637357852718387997sdata=qHAUE4iPB4YLvLVCtFetR33HnDjEowrOa%2FpWLANdNpE%3Dreserved=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. 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   37712   +128ms[ +128ms] 
>> +/-  200ms
>>  #* PPS   0   4   37712 +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?

Re: [chrony-users] Synchronizing clock with GPS with PPS




William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics _|___ 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:


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. 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   37712   +128ms[ +128ms] 
+/-  200ms
#* PPS   0   4   37712 +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?

Re: [chrony-users] Synchronizing clock with GPS with PPS