[time-nuts] ˜NEO-M8N vs. NEO-M8T

[Hal Murray]

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 
offset.

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 
delays.


-- 
These are my opinions.  I hate spam.