On Wed, 31 Dec 2008 18:49:22 -0800 (PST),
[email protected] wrote:
>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
Chris:
Does indeed sound familiar to me here.
I'm working also but with a slightly different fix.
Not using PPS kernel patch as its difficult to add in to the RPM based
kernels here on Fedora Core 9 so I'm just using the shm driver and
plain old ntpd. My solution was to fudge the NMEA data time about 700
ms here and now I'm also working with just ntpd and the shm driver
running and no gpsd. Running gpsd at all totally messes this thing up.
I don't have the time or energy to keep hacking at why, or the need to
be running gpsd actually it turns out-nothing else needs the data so
why run it-just another daemon to need to make sure its running.
Relevant ntp.conf beloe and output:
# LinuxPPS: GPS
server 127.127.20.0 minpoll 4 mode 1
fudge 127.127.20.0 time1 0.700 flag2 0 flag3 1
# SHM: PPS filtered mean
server 127.127.28.0 minpoll 4 prefer
fudge 127.127.28.0 refid PPS flag2 0 flag3 1
# ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
+GPS_NMEA(0) .GPS. 0 l 5 16 377 0.000 25.349
9.221
*SHM(0) .PPS. 0 l 14 16 377 0.000 2.953
0.176
eagle-local 192.168.1.7 2 u 731 1024 377 0.160 -2.518
0.152
apollo-local .STEP. 16 u 725 1024 376 0.236 -8.591
0.809
-clock.trit.net 164.67.62.194 2 u 40 128 377 154.590 44.455
215.345
+64.247.17.255 129.6.15.28 2 u 4 128 377 45.530 -13.520
252.661
-kiri.nonexiste. 69.10.36.2 3 u 11 128 377 9.470 -12.775
1.132
--
===[George R. Kasica]=== +1 262 677 0766
President +1 206 374 6482 FAX
Netwrx Consulting Inc. Jackson, WI USA
http://www.netwrx1.com
[email protected]
ICQ #12862186
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions
