"Dave Hart" <[email protected]> wrote in message
news:264438b3-7b1e-4808-8bc0-602a72203...@t34g2000prm.googlegroups.com...
[]
If, like me, you have your GPS
emitting a single sentence each second, configure NMEA without fudge
flag1, and have PPS/ATOM on the same port using ntpd on Windows with
serialpps.sys, the result is the NMEA driver is showing the "user
mode" PPS timestamps taken by ntpd when it notices the DCD transition
via normal Windows serial APIs (which do not depend on serialpps.sys
functionality), while the PPS/ATOM driver is showing the PPSAPI
timestamps originating in the serialpps.sys interrupt handler:
*GPS_NMEA(1) .uPPS. 0 l 8 16 377 0.000 -0.042 0.002
oPPS(1) .kPPS. 0 l 6 16 377 0.000 0.003 0.002
The ~40us difference is what I typically see, but it varies with the
load on the machine.
Cheers,
Dave Hart
OK, Dave, understood, I think. It is a requirement of using the
serialpps.sys (for its kernel-mode timestamps) that that you also use the
ATOM driver if you want the kernel-mode timestamps to be used. Right?
I also see the GPS time as indicating some tens of microseconds behind the
PPS time. with more offset on the slower PC, as would be expected.
However, my PPS line is the first in the billboard, and not the second.
Does that matter? Or is it just because in my ntp.conf I have:
server 127.127.22.1 minpoll 4 # PPS - serialpps.sys
server 127.127.20.1 minpoll 4 prefer # NMEA serial port
Would it make any difference if they were in the reverse order - I'm
guessing that it would not.
Cheers,
David
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
