[ntp:questions] fudge time1 for gps-18x-LVC?

Dave Hart davehart at gmail.com
Sun Feb 7 17:06:51 UTC 2010


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




More information about the questions mailing list