[chrony-users] Trouble with PPS

[Alvaro Gamez]

Hi!

I'm trying to make chrony sync against a GPS and PPS signal, but it seems
like the PPS is being ignored.

I run gpsd attached to the serial console which has the GPS connected, and
for PPS I want to use chrony, so this is the configuration I've set:

# cat chrony.conf
refclock SHM 0 refid GPS
refclock PPS /dev/pps0 lock GPS refid PPS
makestep 100 5
logdir /tmp/logs
log measurements tracking statistics refclocks

I got in-kernel pps debug enabled, so when I start chronyd I can see on the
console that the PPS signal is arriving and that there's someone (chronyd)
accesing /dev/pps0:

pps pps0: PPS_FETCH
pps_core: ACCESS OK: READ at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: timeout 0.000000000
pps pps0: PPS event at 1523615280.496954999
pps pps0: capture assert seq #902
pps_core: ACCESS OK: WRITE at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: PPS event at 1523615281.472931499
pps pps0: capture assert seq #903
pps pps0: PPS_FETCH
pps_core: ACCESS OK: READ at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: timeout 0.000000000
pps_core: ACCESS OK: WRITE at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: PPS event at 1523615282.472780341
pps pps0: capture assert seq #904
pps pps0: PPS_FETCH
pps_core: ACCESS OK: READ at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: timeout 0.000000000
pps_core: ACCESS OK: WRITE at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: PPS event at 1523615283.472628439
pps pps0: capture assert seq #905

However, chrony doesn't seem to understand /dev/pps0 output, because this
is what 'sources' command reports:

210 Number of sources = 2
MS Name/IP address Stratum Poll Reach LastRx Last
sample
===============================================================================
#* GPS 0 4 377 22 +50ms[ +59ms] +/-
8042us
#? PPS 0 4 0 - +0ns[ +0ns] +/-
0ns

As such, refclocks.log shows only entries for GPS Refid, but none for PPS,
as it seems even though it's connected, it isn't able to decipher what is
being sent to it.

Any ideas?

Thanks, best regards!

[Miroslav Lichvar]

Post by Alvaro Gamez
I'm trying to make chrony sync against a GPS and PPS signal, but it seems
like the PPS is being ignored.
I run gpsd attached to the serial console which has the GPS connected, and
# cat chrony.conf
refclock SHM 0 refid GPS
refclock PPS /dev/pps0 lock GPS refid PPS

If you add an NTP server to the config, what does chronyc sourcestats
print? The PPS would be ignored if the SHM source was too far from
the true time. The config might need to specify an offset for it. With
an NTP server we should see the offset.

Also, it might help us to see the debug output, which can be enabled
by chronyd -d -d if it was compiled with --enable-debug.

[Simon Haines]

Here is the configuration I use for a device that is not network-connected,
and uses GPS+PPS to derive accurate time. Note the offset for the GPS clock
so that the PPS signal can be aligned to the correct GPS time message.

refclock PPS /dev/pps0 poll 4 refid PPS lock GPS
refclock SHM 0 poll 4 offset 0.1 refid GPS
makestep 0.001 -1
maxupdateskew 1
lock_all
log refclocks
logdir /var/log

Simon.

Post by Alvaro Gamez
Hi!
I'm trying to make chrony sync against a GPS and PPS signal, but it seems
like the PPS is being ignored.
I run gpsd attached to the serial console which has the GPS connected, and
# cat chrony.conf
refclock SHM 0 refid GPS
refclock PPS /dev/pps0 lock GPS refid PPS
makestep 100 5
logdir /tmp/logs
log measurements tracking statistics refclocks
I got in-kernel pps debug enabled, so when I start chronyd I can see on
the console that the PPS signal is arriving and that there's someone
pps pps0: PPS_FETCH
pps_core: ACCESS OK: READ at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: timeout 0.000000000
pps pps0: PPS event at 1523615280.496954999
pps pps0: capture assert seq #902
pps_core: ACCESS OK: WRITE at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: PPS event at 1523615281.472931499
pps pps0: capture assert seq #903
pps pps0: PPS_FETCH
pps_core: ACCESS OK: READ at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: timeout 0.000000000
pps_core: ACCESS OK: WRITE at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: PPS event at 1523615282.472780341
pps pps0: capture assert seq #904
pps pps0: PPS_FETCH
pps_core: ACCESS OK: READ at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: timeout 0.000000000
pps_core: ACCESS OK: WRITE at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: PPS event at 1523615283.472628439
pps pps0: capture assert seq #905
However, chrony doesn't seem to understand /dev/pps0 output, because this
210 Number of sources = 2
MS Name/IP address Stratum Poll Reach LastRx Last
sample
===============================================================================
#* GPS 0 4 377 22 +50ms[ +59ms] +/-
8042us
#? PPS 0 4 0 - +0ns[ +0ns]
+/- 0ns
As such, refclocks.log shows only entries for GPS Refid, but none for PPS,
as it seems even though it's connected, it isn't able to decipher what is
being sent to it.
Any ideas?
Thanks, best regards!
--
Álvaro Gámez Machado

[Alvaro Gamez]

Hi!

I've tried your configuration (main difference was only the offset values).
It sometimes seems to work, but not always.

Here's a series of 'sources' requests output:
#* GPS 0 4 77 18 +90ms[ +306ms] +/-
6773us
#? PPS 0 4 6 39 -290ms[ -74ms] +/-
1622us

#* GPS 0 4 77 21 +90ms[ +306ms] +/-
6985us
#? PPS 0 4 6 42 -290ms[ -74ms] +/-
1834us

#* GPS 0 4 77 24 +90ms[ +306ms] +/-
6985us
#? PPS 0 4 6 45 -290ms[ -74ms] +/-
1834us

#* GPS 0 4 177 10 +176ms[ +131ms] +/-
22ms
#? PPS 0 4 14 56 -245ms[ -74ms] +/-
1841us

#* GPS 0 4 377 28 +51ms[ +140ms] +/-
7070us
#? PPS 0 4 30 90 -334ms[ -74ms] +/-
1863us

#* GPS 0 4 377 21 -33ms[-8808us] +/-
14ms
#? PPS 0 4 140 127 -436ms[ -74ms] +/-
1970us

#* GPS 0 4 377 11 -6962us[ -53ms] +/-
6869us
#? PPS 0 4 200 155 -396ms[ -74ms] +/-
2138us

So up to now, it seems like PPS is being read correctly, although it really
takes some time for it (shouldn't LastRX be never bigger than 1 second?).
And then, suddenly:
#* GPS 0 4 377 27 +19ms[ +39ms] +/-
6878us
#? PPS 0 4 0 193 -393ms[ -74ms] +/-
2336us

Reach turns to 0.

I've restarted all daemons (gpsd, chronyd), and it's been now like this for
a while:
#* GPS 0 4 377 22 -1160us[-1267us] +/-
6691us
#? PPS 0 4 0 - +0ns[ +0ns] +/-
0ns

So in this instance it hasn't received any PPS signal, but I know that's
false, because I see kernel messages showing pps0 access.

Post by Simon Haines
Here is the configuration I use for a device that is not
network-connected, and uses GPS+PPS to derive accurate time. Note the
offset for the GPS clock so that the PPS signal can be aligned to the
correct GPS time message.
refclock PPS /dev/pps0 poll 4 refid PPS lock GPS
refclock SHM 0 poll 4 offset 0.1 refid GPS
makestep 0.001 -1
maxupdateskew 1
lock_all
log refclocks
logdir /var/log
Simon.

Post by Alvaro Gamez
Hi!
I'm trying to make chrony sync against a GPS and PPS signal, but it seems
like the PPS is being ignored.
I run gpsd attached to the serial console which has the GPS connected,
# cat chrony.conf
refclock SHM 0 refid GPS
refclock PPS /dev/pps0 lock GPS refid PPS
makestep 100 5
logdir /tmp/logs
log measurements tracking statistics refclocks
I got in-kernel pps debug enabled, so when I start chronyd I can see on
the console that the PPS signal is arriving and that there's someone
pps pps0: PPS_FETCH
pps_core: ACCESS OK: READ at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: timeout 0.000000000
pps pps0: PPS event at 1523615280.496954999
pps pps0: capture assert seq #902
pps_core: ACCESS OK: WRITE at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: PPS event at 1523615281.472931499
pps pps0: capture assert seq #903
pps pps0: PPS_FETCH
pps_core: ACCESS OK: READ at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: timeout 0.000000000
pps_core: ACCESS OK: WRITE at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: PPS event at 1523615282.472780341
pps pps0: capture assert seq #904
pps pps0: PPS_FETCH
pps_core: ACCESS OK: READ at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: timeout 0.000000000
pps_core: ACCESS OK: WRITE at 0xbf85eb6c (size 0x3c), seg 0xbfffffff
pps pps0: PPS event at 1523615283.472628439
pps pps0: capture assert seq #905
However, chrony doesn't seem to understand /dev/pps0 output, because this
210 Number of sources = 2
MS Name/IP address Stratum Poll Reach LastRx Last
sample
============================================================
===================
#* GPS 0 4 377 22 +50ms[ +59ms] +/-
8042us
#? PPS 0 4 0 - +0ns[ +0ns]
+/- 0ns
As such, refclocks.log shows only entries for GPS Refid, but none for
PPS, as it seems even though it's connected, it isn't able to decipher what
is being sent to it.
Any ideas?
Thanks, best regards!
--
Álvaro Gámez Machado

[Miroslav Lichvar]

Post by Alvaro Gamez
I've tried your configuration (main difference was only the offset values).
It sometimes seems to work, but not always.
#* GPS 0 4 77 18 +90ms[ +306ms] +/-
6773us
#? PPS 0 4 6 39 -290ms[ -74ms] +/-
1622us

It seems the offset between the two refclocks is still too large to
allow a reliable lock of the PPS. Try increasing the offset of the SHM
refclock to 0.5.

[Simon Haines]

Also note that gpsd can sometimes erroneously create a second PPS source,
thinking that the GPS device is connected with the serial line discipline
exposing the PPS on a serial port pin. You can cross-check with ppstest,
but your kernel debug seems to suggest that the source is indeed pps0.
Simon.

Post by Alvaro Gamez

Post by Alvaro Gamez
I've tried your configuration (main difference was only the offset

values).

Post by Alvaro Gamez
It sometimes seems to work, but not always.
#* GPS 0 4 77 18 +90ms[ +306ms] +/-
6773us
#? PPS 0 4 6 39 -290ms[ -74ms] +/-
1622us

It seems the offset between the two refclocks is still too large to
allow a reliable lock of the PPS. Try increasing the offset of the SHM
refclock to 0.5.
--
Miroslav Lichvar
--
with "unsubscribe" in the subject.
with "help" in the subject.

[Alvaro Gamez]

Post by Simon Haines
Also note that gpsd can sometimes erroneously create a second PPS source,
thinking that the GPS device is connected with the serial line discipline
exposing the PPS on a serial port pin. You can cross-check with ppstest,
but your kernel debug seems to suggest that the source is indeed pps0.
Simon.

Yes, there's only one PPS source and gpsd is behaving as it should.

Post by Simon Haines

Post by Alvaro Gamez

Post by Alvaro Gamez
I've tried your configuration (main difference was only the offset

values).

Post by Alvaro Gamez
It sometimes seems to work, but not always.
#* GPS 0 4 77 18 +90ms[ +306ms] +/-
6773us
#? PPS 0 4 6 39 -290ms[ -74ms] +/-
1622us

It seems the offset between the two refclocks is still too large to
allow a reliable lock of the PPS. Try increasing the offset of the SHM
refclock to 0.5.

Ah! That seems to be doing the trick!

#- GPS 0 4 377 28 +11ms[ +11ms] +/-
9045us
#* PPS 0 4 377 27 +109us[ +105us] +/-
388us

Why is GPS marked as not combined, though?

Thanks!

[Miroslav Lichvar]

Post by Alvaro Gamez
#- GPS 0 4 377 28 +11ms[ +11ms] +/-
9045us
#* PPS 0 4 377 27 +109us[ +105us] +/-
388us
Why is GPS marked as not combined, though?

Because its distance (the +/- value) is significantly larger than the
PPS refclock's. Only PPS should be used for synchronization as it's a
much better time source.

You might want to add the noselect option to the GPS refclock
directive to not consider it for selection at all. Otherwise, it would
be good to at least increase its distance with the delay option to not
get two falsetickers if the offset between them changes. The example
in chrony.conf man page uses both.

[Alvaro Gamez]

Post by Miroslav Lichvar

Post by Alvaro Gamez
#- GPS 0 4 377 28 +11ms[ +11ms] +/-
9045us
#* PPS 0 4 377 27 +109us[ +105us] +/-
388us
Why is GPS marked as not combined, though?

Because its distance (the +/- value) is significantly larger than the
PPS refclock's. Only PPS should be used for synchronization as it's a
much better time source.
You might want to add the noselect option to the GPS refclock
directive to not consider it for selection at all. Otherwise, it would
be good to at least increase its distance with the delay option to not
get two falsetickers if the offset between them changes. The example
in chrony.conf man page uses both.

But PPS by itself can't provide datetime, only second synchronization.
What would happen if I don't let chrony select GPS clock? Would it know
what time is it?

PPS signal comes from the same device as GPS data, so their distance
shouldn't ever vary, right?

BTW, all your messages appeared on my spam folder, I don't know why!
That's why it may look like I ignored your previous messages, sorry!

[Miroslav Lichvar]

Post by Alvaro Gamez

Post by Miroslav Lichvar
You might want to add the noselect option to the GPS refclock
directive to not consider it for selection at all. Otherwise, it would
be good to at least increase its distance with the delay option to not
get two falsetickers if the offset between them changes. The example
in chrony.conf man page uses both.

But PPS by itself can't provide datetime, only second synchronization.
What would happen if I don't let chrony select GPS clock? Would it know
what time is it?

Yes. That's what the lock option is for. It allows a refclock to
provide another refclock with seconds, but otherwise be ignored for
synchronization.

Post by Alvaro Gamez
PPS signal comes from the same device as GPS data, so their distance
shouldn't ever vary, right?

This is about the NTP distance. It is the maximum assumed error of the
source. If the delay of the GPS messages is slowly changing over time
(which is not uncommon), the offset between the two sources will be
changing. If you don't increase the distance, you might get two
sources that don't agree with each other (their error intervals don't
overlap) and chronyd wouldn't which one should be trusted.

[Alvaro Gamez]

Post by Miroslav Lichvar

Post by Alvaro Gamez
But PPS by itself can't provide datetime, only second synchronization.
What would happen if I don't let chrony select GPS clock? Would it know
what time is it?

Yes. That's what the lock option is for. It allows a refclock to
provide another refclock with seconds, but otherwise be ignored for
synchronization.

Right!

Post by Miroslav Lichvar

Post by Alvaro Gamez
PPS signal comes from the same device as GPS data, so their distance
shouldn't ever vary, right?

This is about the NTP distance. It is the maximum assumed error of the
source. If the delay of the GPS messages is slowly changing over time
(which is not uncommon), the offset between the two sources will be
changing. If you don't increase the distance, you might get two
sources that don't agree with each other (their error intervals don't
overlap) and chronyd wouldn't which one should be trusted.

Understood, thank you very much! I was totally missing that.

Best regards!