Re: [chrony-users] Issue with chrony dropping PPS signal

[Vincenzo Miceli <vincenzomiceli@xxxxxxxxxxx>]

Thanks Miroslav,

I want to make sure I understand... you are asking to run something like watch -n 1 'cat /sys/class/pps/pps0/assert'   next time I detect the issue and see if the result is changing to indicate PPS is still being issued by the GPS right?

I'll do that then.

Cheers,
Vincenzo

---

From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
Sent: Thursday 4 March 2021 11:23
To: chrony-users@xxxxxxxxxxxxxxxxxxxx <chrony-users@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: [chrony-users] Issue with chrony dropping PPS signal

 

On Thu, Mar 04, 2021 at 10:50:11AM +0000, Vincenzo Miceli wrote:
> I have seen a couple of times the Chrony server drift away from the ntpd server only to reset back hours later. I have enabled chrony logging and I was able to verify that when this happens, the PPS is not being logged in rfclocks.log while the GPS still is. This means that the GPS still has a lock as NMEA GPS has meaningful data, hence the PPS is still available, but it is not being picked or used by chrony. The way I have setup the ublox is that PPS is only sent out if there is a GPS lock.

The logs and configuration looks good to me.

It could be an issue with chronyd rejecting the samples if the offset
between PPS and GPS was larger, but in this case I suspect the GPS is
losing lock or switching to a degraded mode (2D only?). In the second
screenshot of the refclocks log there is a jump in the GPS offset when
PPS appears, which suggests there are more messages in the serial
data.

Can you please check whether /sys/class/pps/pps0/assert shows new
samples when chronyd stops receving PPS?

--
Miroslav Lichvar


--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.