[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PPS in GPSD vs Chrony
From: |
Miroslav Lichvar |
Subject: |
Re: PPS in GPSD vs Chrony |
Date: |
Tue, 7 Jul 2020 10:06:46 +0200 |
On Thu, Jul 02, 2020 at 03:45:27PM -0700, Gary E. Miller wrote:
> On Thu, 2 Jul 2020 09:57:49 +0200
> Miroslav Lichvar <mlichvar@redhat.com> wrote:
>
> > There is a median filter (in chrony, ntp and ntpsec I presume)
>
> I see no such thing in refclock_pps.c in ntpsec. Pretty much the same
> code as i NTP Classic.
In the classic code it's a feature common to all drivers. It's in the
refclock_sample() function in the ntp_refclock.c file.
> > > Hmm, how does the time daemon (gpsd, chonryd, ntpd) know which of
> > > the 32 pulses is the top of the second? NMEA time is very unlikely
> > > to be better than 30 ms.
> >
> > Yeah, that's tricky. The binary protocols should be more stable.
>
> Even then you would need a very fast serial port, which modern receivers
> can do, just not by default.
I suspect the biggest factor is the firmware. From what I have seen
the delay is not changing quickly, it's not like a jitter, but slowly
drifting all over the place. The ublox units I use (NEO-6M - probably
not genuine) have the message timing stable to about 30ms at the rate
of 115200, which is too much for 32Hz PPS, but might be ok for 16 Hz.
Are newer/different ublox models better?
--
Miroslav Lichvar