[ntp:questions] Garmin GPS 18LVC Setup but questions on best way

givemeafckingacctyoudouche at gmail.com givemeafckingacctyoudouche at gmail.com
Thu Jan 1 02:49:22 UTC 2009


George, You're experiencing the exact same problem as I am. I'll
probably make a more detailed thread in this group describing it
later, but basically the programs trying to match the NMEA data with
the PPS pin are locking our GPS units in one second behind the actual
time.
I purchased my 18xLVC pretty recently, did you as well?

I've patched my kernel with LinuxPPS and used gpsd, and both had about
-600ms offset in ntpd. gpsd would not function correctly when the time
was fudged as others are suggesting, it would instead give the error
"not in locking range:600123." This was especially frustrating because
the local time servers proved I was right on the money. After a lot of
fiddling, I figured out that the PPS correctly aligned in gpsd when I
set it 1000ms behind the remote timeservers.

My fix, although this is in no way a viable long-term solution, was to
open ntpshm.c and add this fix:

    (void)gettimeofday(&tv,NULL);
    microseconds = 1000000.0 * modf(fixtime,&seconds);

    //Added this to fix the off by 1 second bug with my garmin gps
    seconds++;

    shmTime->count++;
    shmTime->clockTimeStampSec = (time_t)seconds;
    shmTime->clockTimeStampUSec = (int)microseconds;

So, basically I'm manually adjusting the nmea second reading forward
by 1.  I recompiled, and am now running purely GPSD with pps pin
support (no shmpps driver needed) with the following values:
     remote           refid      st t when poll reach   delay
offset  jitter
==============================================================================
 SHM(0)          .GPSa.           0 l    4   16  377    0.000
-19.092  36.507
*SHM(1)          .PPSa.           0 l    6   16  377    0.000
-0.053   0.004
+csnserver.com   216.110.36.245   6 u   63   64  377   90.410
27.036   9.775
+ntp-s1.cise.ufl .GPS.            1 u   64   64  377   67.281
0.203   4.258

The SHM(0) gps is still fudged to account for normal lag w/ the time
given on qnan. Here's my conf with the modified gpsd:
#Garmin GPS 18x LVC 0
server 127.127.28.0 minpoll 4 noselect  #Local GPS serial
fudge 127.127.28.0 time1 -0.420 refid GPSa
#PPS pin
server 127.127.28.1 minpoll 4 prefer
fudge 127.127.28.1 refid PPSa

I'm going to probably post the gpsd list too, since it appears they've
had arguments before on the difficulties of syncing every units nmea
data to the pps pin. The nmea data offsets apparently vary widely
between models.

Hopefully we can find a solution to this together, since it appears
like we're in the same boat.
Chris




More information about the questions mailing list