On Feb 7, 16:43 UTC, "David J Taylor" wrote: > If I have understood what you say correctly, then I don't quite see what > use is served by specifying the ATOM driver in addition to the current > (4.2.6 or later) NMEA driver (with a PPS signal fed to the serial port).
There is not much use, and I don't recommend configuring PPS/ATOM alongside NMEA with PPS via serial, unless fudge flag1 is not given to NMEA, so that it does not attempt to use the PPS. On the other hand, if you want to use PPS via a parallel port and NMEA via serial, configuring both NMEA and ATOM/PPS is the only way to go. For the PPS via serial case, it's simply a matter of preference. If you want to keep an eye on your NMEA's serial timestamps, you should configure it without fudge flag1 and use PPS/ATOM on the same device for the PPS. For those on Windows, keep in mind the first serial end- of-line timestamp after each DCD PPS leading edge transition is replaced with the "user mode" PPS timestamp unconditionally and unrelated to PPSAPI configuration. 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 Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
