On Win XP, I am seeing an odd positive offset of about 128ms on the
Atom driver, relative to other sources:


     remote           refid      st t when poll reach   delay
offset  jitter
==============================================================================
*GPS_NMEA(1)     .GPS.            0 l    6   16  377    0.000
0.373   0.919
xPPS(1)          .PPS.            0 l    5   16  377    0.000
125.447   0.830
-clock.team-cymr 172.16.65.22     2 u   39   64   77   12.989
-41.044  44.960
+ntp.okstate.edu .USNO.           1 u   42   64   77   28.906
-18.762  25.784
+navobs1.wustl.e .GPS.            1 u   38   64   77   19.133
1.819  19.599

Normally, I just use NMEA with fudge, but that was also showing the
odd offset so I removed fudge and added the Atom driver to help debug
this.

(Normally the status shows oPPS(1) but xPPS(1) is seen above for the
obvious reason.

ntpd is Dave Hart release 4.2.7p138;  I have a serialpps-ppsapi-
provider.dll dated 6/6/2009.

Any ideas or recommendations.

"lellis" <larry.ellis@gmail.com> wrote in message 
news:efc6e755-c213-4a10-90f9-420384001da3@s18g2000prg.googlegroups.com...
> On Win XP, I am seeing an odd positive offset of about 128ms on the
> Atom driver, relative to other sources:
>
>
>     remote           refid      st t when poll reach   delay
> offset  jitter
> ==============================================================================
> *GPS_NMEA(1)     .GPS.            0 l    6   16  377    0.000
> 0.373   0.919
> xPPS(1)          .PPS.            0 l    5   16  377    0.000
> 125.447   0.830
> -clock.team-cymr 172.16.65.22     2 u   39   64   77   12.989
> -41.044  44.960
> +ntp.okstate.edu .USNO.           1 u   42   64   77   28.906
> -18.762  25.784
> +navobs1.wustl.e .GPS.            1 u   38   64   77   19.133
> 1.819  19.599
>
> Normally, I just use NMEA with fudge, but that was also showing the
> odd offset so I removed fudge and added the Atom driver to help debug
> this.
>
> (Normally the status shows oPPS(1) but xPPS(1) is seen above for the
> obvious reason.
>
> ntpd is Dave Hart release 4.2.7p138;  I have a serialpps-ppsapi-
> provider.dll dated 6/6/2009.
>
> Any ideas or recommendations.

Larry,

You may want to revert to the 3.20 firmware for you GPS 18x LVC - see what 
others have written:

  http://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks#Section_6.1.12.2.

  http://support.ntp.org/bin/view/Support/ConfiguringGarminRefclocks

and there is a somewhat flawed analysis here:

  http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm#gps-18x

(flawed in that I was being helped by a UNIX person, and the Windows 
driver does not work in exactly the same way as we had assumed).

Cheers,
David 

On 2011-03-22, David J Taylor <david-taylor@blueyonder.co.uk.invalid> wrote:
>
> "lellis" <larry.ellis@gmail.com> wrote in message 
> news:efc6e755-c213-4a10-90f9-420384001da3@s18g2000prg.googlegroups.com...
>> On Win XP, I am seeing an odd positive offset of about 128ms on the
>> Atom driver, relative to other sources:
>>
>>
>>     remote           refid      st t when poll reach   delay
>> offset  jitter
>> ==============================================================================
>> *GPS_NMEA(1)     .GPS.            0 l    6   16  377    0.000
>> 0.373   0.919
>> xPPS(1)          .PPS.            0 l    5   16  377    0.000
>> 125.447   0.830
>> -clock.team-cymr 172.16.65.22     2 u   39   64   77   12.989
>> -41.044  44.960
>> +ntp.okstate.edu .USNO.           1 u   42   64   77   28.906
>> -18.762  25.784
>> +navobs1.wustl.e .GPS.            1 u   38   64   77   19.133
>> 1.819  19.599
>>
>> Normally, I just use NMEA with fudge, but that was also showing the
>> odd offset so I removed fudge and added the Atom driver to help debug
>> this.
>>
>> (Normally the status shows oPPS(1) but xPPS(1) is seen above for the
>> obvious reason.
>>
>> ntpd is Dave Hart release 4.2.7p138;  I have a serialpps-ppsapi-
>> provider.dll dated 6/6/2009.
>>
>> Any ideas or recommendations.
>
> Larry,
>
> You may want to revert to the 3.20 firmware for you GPS 18x LVC - see what 
> others have written:

A .128 or .3 second offset really seems strange for this cause.  I guess
it could be if the 1 second offset from the Garmin 18x only happens
occasionaly, and this is being averaged out. 


>
>   http://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks#Section_6.1.12.2.
>
>   http://support.ntp.org/bin/view/Support/ConfiguringGarminRefclocks
>
> and there is a somewhat flawed analysis here:
>
>   http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm#gps-18x
>
> (flawed in that I was being helped by a UNIX person, and the Windows 
> driver does not work in exactly the same way as we had assumed).
>
> Cheers,
> David 
>

Thanks to all.  I am using Garmin 3.20, as it it turns out.

However, I reverted to 4.2.5p233 of Dave Hart's builds, and it does
not appear to have the same strange behavior.  I had been using
4.2.7p138 (which I first installed only yesterday).

I'll try a few of Dave's other builds to see if I can see where the
boundary is.  I don't know how he numbers his builds so I don't know
whether this build is thought to be stable or not.  It was only built
a few weeks ago.

Thanks again.

> Thanks to all.  I am using Garmin 3.20, as it it turns out.
>
> However, I reverted to 4.2.5p233 of Dave Hart's builds, and it does
> not appear to have the same strange behavior.  I had been using
> 4.2.7p138 (which I first installed only yesterday).
>
> I'll try a few of Dave's other builds to see if I can see where the
> boundary is.  I don't know how he numbers his builds so I don't know
> whether this build is thought to be stable or not.  It was only built
> a few weeks ago.
>
> Thanks again.

I, for one, will be most interested in your results, Larry.

"stable" builds have even numbers
"development" have odd numbers

I believe some of the later changes relate to how multiple NMEA sentences 
are handled, but I can't give you exact version numbers where changes were 
made.

Cheers,
David 

On Wed, Mar 23, 2011 at 08:06 UTC, David J Taylor wrote:
> "stable" builds have even numbers
> "development" have odd numbers
>
> I believe some of the later changes relate to how multiple NMEA sentences
> are handled, but I can't give you exact version numbers where changes were
> made.

Use the source, Luke.  If I get my builds automated I'll include the
ChangeLog file in the Windows binaries .zips, but meanwhile:

http://ntp.bkbits.net:8080/ntp-dev/?PAGE=dir

Click on the underlined ChangeLog then search for NMEA...

(4.2.7p76) 2010/11/02 Released by Harlan Stenn <stenn@ntp.org>
[...]
 * [Bug 1691] Use first NMEA sentence each second.

Cheers,
Dave Hart

Well, I have used the ever-faithful binary search on the Windows
builds to try to find where the strange offset introduced itself.

The first build to show the odd offset (between NMEA and PPS ATOM) is
4.2.7p24.

4.2.7p23 seems to behave normally.

The offset difference between PPS and NMEA is about 125 ms  (e.g. NMEA
-10, PPS +115) on 4.2.7.p24, on p23 the offsets of the two drivers are
about the same.

Again, I am using the older Garmin firmware, v3.20.  I am not
particulaly keen to move to a different firmware version because this
version is working well, but I'll be happy to test any new builds on
this firmware, if helpful.


Larry

On Thu, Mar 24, 2011 at 04:17 UTC, Dave Hart <davehart@gmail.com> wrote:
> 4.2.7p24 came out in April 2009

Correction: 4.2.7p24 came out 13 April 2010.

> Nothing between p23 and p24 jumps out at me as likely related. I
> wonder if this cset from October 2010 (first included in 4.2.5p237-RC)

I need coffee.  4.2.5p237-RC came out 26 October 2009.

Cheers,
Dave Hart

On Mar 23, 11:21=A0pm, Dave Hart <daveh...@gmail.com> wrote:
> On Thu, Mar 24, 2011 at 04:17 UTC, Dave Hart <daveh...@gmail.com> wrote:
> > 4.2.7p24 came out in April 2009
>
> Correction: 4.2.7p24 came out 13 April 2010.
>
> > Nothing between p23 and p24 jumps out at me as likely related. I
> > wonder if this cset from October 2010 (first included in 4.2.5p237-RC)
>
> I need coffee. =A04.2.5p237-RC came out 26 October 2009.
>
> Cheers,
> Dave Hart

I can only reaffirm my willingness to try any build provided.

I would suppose this is somehow related to the Garmin's weird NMEA
message timing with respect to the PPS output.  I don't remember the
details, and I also know that things changed from the original GPS 18
model to the improved GPS 18x.  And then, there's 3.20 firmware vs
other firmware to bring into the mix.

I still have the older GPS 18 somewhere.   I'll try it to see if
there's a difference.

On 2011-03-24, lellis <larry.ellis@gmail.com> wrote:
> On Mar 23, 11:21?pm, Dave Hart <daveh...@gmail.com> wrote:
>> On Thu, Mar 24, 2011 at 04:17 UTC, Dave Hart <daveh...@gmail.com> wrote:
>> > 4.2.7p24 came out in April 2009
>>
>> Correction: 4.2.7p24 came out 13 April 2010.
>>
>> > Nothing between p23 and p24 jumps out at me as likely related. I
>> > wonder if this cset from October 2010 (first included in 4.2.5p237-RC)
>>
>> I need coffee. ?4.2.5p237-RC came out 26 October 2009.
>>
>> Cheers,
>> Dave Hart
>
> I can only reaffirm my willingness to try any build provided.
>
> I would suppose this is somehow related to the Garmin's weird NMEA
> message timing with respect to the PPS output.  I don't remember the
> details, and I also know that things changed from the original GPS 18
> model to the improved GPS 18x.  And then, there's 3.20 firmware vs
> other firmware to bring into the mix.

It delayed the nmea messages to just more than a second after the
associated PPS pulse ( ie the nmea sentence came more than a second
after the time it was reporting). This make the system seem to be out by
a second. It is a bug. 

>
> I still have the older GPS 18 somewhere.   I'll try it to see if
> there's a difference.
>

On Mar 22, 11:51=A0am, Dave Hart <daveh...@gmail.com> wrote:
>
> I think your PPS is probably right on, while your NMEA is off by
> nearly a second. =A0Make sure either the GPS is generating only the
> sentence you want each second, or use the mode option to the NMEA
> driver to select a sentence. =A0Try using the same value for fudge time1
> and fudge time2 for NMEA (one is used to offset NMEA end-of-line
> times, the other to offset PPS time. =A0Thanks to the user PPS hack in
> Windows ntpd, the "end of line" times should actually be PPS times
> with tens of microseconds offset and a bit more jitter than PPSAPI
> timestamps.
>

At the moment, and likely with the help of some suggested
configuration changes, the oddness has gone away.

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

On Apr 17, 10:03=A0am, lellis <larry.el...@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:
>
> =A0 =A0 =A0 =A0 server 127.127.20.1 mode 2 minpoll
> 4 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#mode 2, use GPG=
GA
> =A0 =A0 =A0 =A0 fudge 127.127.20.1 flag1 1 =A0time2
> 0.850 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
*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=3D0 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.