˜NEO-M8N vs. NEO-M8T
(too old to reply)
Hal Murray
2018-05-21 21:07:53 UTC
See Marks recent message about whether the offset applies to the next or
previous PPS. For the rest of this, I'll assume next since it's simpler to
describe. We can discuss the other/harder case if you agree that the rest of
this makes sense.
Your concept of 'real time' does not match mine.
The correction message arrives before the PPS. What's not real-time about
that? You don't need any data from the future.
Also, how does that get me to the gola of a good PPS to feed into the Linux
PPS kernel module? I doubt Linux would accept a patch to put gpsd, and
more, into the kernel to read GPS and adjust the PPS.
You don't fix the PPS, you fix the software processing the PPS to use the

Assuming you are using gpsd, you fix the serial side of gpsd to save the
offset and the PPS side uses that offset to correct the PPS offset and then
pass the corrected value to ntpd rather than the raw value.

Linux/ntpd actually has two modes of PPS processing. The normal mode is that
ntpd tells the kernel how to adjust the drift and offset. In that case, the
gpsd processing described above would work.

There is another mode where the PLL is done in the kernal and ntpd sits off
to the side and watches, mostly doing a sanity check. This option, NTP_PPS,
is not included in most kernels since it conflicts with NO_HZ_COMMON which
saves power.

I haven't checked the code. ntpd has a refclock config option for the
offset. If that works for the kernel PLL, then the latest sawtooth
correction could be passed in each second. If that doesn't work yet, it
would be a small kernel mod to fix.


Another option would build some hardware to apply the correction. See Mark's
recent message and/or the archives. There are chips that do the adjustable
These are my opinions. I hate spam.

time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.