[time-nuts] NEO-M8N vs. NEO-M8T
hmurray at megapathdsl.net
Mon May 21 17:07:53 EDT 2018
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.
gem at rellim.com said:
> 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
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.
More information about the time-nuts