[ntp:questions] Odd offset for PPS DCD w/ Garmin GPS 18x LVC

lellis larry.ellis at gmail.com
Sat Apr 23 17:52:36 UTC 2011


On Apr 17, 10:03 am, lellis <larry.el... at gmail.com> wrote:
>
> With the help of several radio-controlled clocks in my office, I
> noticed that the local clock on my machine was occasionally off by
> exactly one second (sometimes slow, sometimes fast).
>
> While I'm not sure this is the definitive answer, the following
> changes seem to have helped:
>
> 1. I configured the Garmin to output both an RMC and a GGA sentence.
>
> 2. Using a small com port test program I wrote, I determined that the
> GGA end-of-line is received about 850 ms after the leading edge of the
> DCD pulse
>
> 3. I then modified my configuration file to include a time2 value of
> 850 ms:
>
>         server 127.127.20.1 mode 2 minpoll
> 4                            #mode 2, use GPGGA
>         fudge 127.127.20.1 flag1 1  time2
> 0.850                         #time2 compensates for GGA offset
>
> I also deleted my drift file before restarting.
>
> I am now using a very recent build (4.2.7.p150) without apparent
> problems.
>
> Larry Ellis

As what will probably be a final update to this issue, the +125ms
difference I reported initially *did* reoccur with 4.2.7p150.

After several days of running with low milliseconds of difference
between all reference sources, the +125s for the Atom PPS driver
reappeared.  Note, that the positive offset did not effect the user-
mode PPS timing, which was still spot on:

     remote           refid      st t when poll reach   delay
offset  jitter
==============================================================================
*GPS_NMEA(1)     .GPS.            0 l    9   16  377    0.000
0.981   0.016
 PPS(1)          .PPS.            0 l   10   16  377    0.000
126.063   0.16
(other offsets < 5 ms)


In effect, this tells me the offset between the user-mode PPS and the
serialpps.sys PPS driver is about .125s (I was using flag1=0 to
disable use of the kernel mode PPS).

Since this odd recurrence was using software which heretofore had
*not* shown the issue.  I tried rebooting my system.  It did not solve
the problem (.125 offset still presented itself).  I then cold-started
the system, and the user-mode PPS and kernel-mode PPS offsets reverted
to sub-millisecond range.

So while the reason for this is unclear, a simple cold-start of the
system accomplished what a warm reboot did not.  This leads me to
believe what I was seeing is likely a quirk of some kind in my
hardware configuration.

Thanks again to everyone who tried helping me with this.









More information about the questions mailing list