> After instructing it to use a different baud rate, you have to
> reset the device for it to take effect, either by issuing a reset
> command, or by power cycling it.
OK, thanks. I'll try that. I gather that the Garmin GPS has some
flash RAM (or a builtin backup battery), so it retains its settings
even if power is removed?
> Also, once you have it talking at a rate other than 4800 bps,
> you'll need to inform ntpd to open the port at that rate by using
> an appropriate mode value on the server 127.127.20.1 line.
Right. I saw that in the NTP documentation. I tried it early on,
thinking that perhaps the driver would use the mode value to set the
GPS's baud rate -- but, of course, that didn't work.
Before I try resetting the baud rate, here's what the GPS currently
looks like on my test server (sixeyes.richw.org). The jitter values
have gone way down, but the GPS offset is still high (even with the
mode set to look at only $GPRMC), and the PPS offset still differs by
several msec from Stanford's clock.
remote refid st t when poll reach delay offset jitter
==============================================================================
xGPS_NMEA(0) .GPS. 9 l 9 16 377 0.000 -629.69 4.781
xPPS(0) .PPS. 8 l 6 16 377 0.000 3.811 0.055
+liberation.rich 10.0.229.53 5 u 3 16 377 2.196 -0.244 0.695
+whodunit.richw. 10.0.229.114 4 u 12 32 377 2.211 -0.264 0.423
*iknow.richw.org 171.64.7.55 3 u 9 32 377 9.242 -1.457 4.772
And on iknow.richw.org (the box my test server, sixeyes, is syncing to):
remote refid st t when poll reach delay offset jitter
==============================================================================
liberation.rich 10.0.229.53 5 u 10 32 0 7.388 0.785 0.000
whodunit.richw. 10.0.229.114 4 u 208 256 376 7.126 0.948 2.469
sixeyes.richw.o 127.0.0.1 13 u 16 32 376 9.375 1.419 1.033
+Avallone.Stanfo 171.64.7.87 2 u 241 1024 377 0.756 -0.648 0.192
*caribou.Stanfor 171.64.7.87 2 u 150 1024 377 0.796 -2.838 0.265
+dusk.Stanford.E 171.64.7.87 2 u 696 1024 377 0.774 -0.560 0.273
In case it matters here, iknow is on the campus network (in my office),
and it's linked via OpenVPN to my home LAN. I'm using interleaved mode
to compensate for the fact that Internet service to my home goes through
a cable modem infrastructure.
And, finally, the view from grandfather.stanford.edu (the stratum-1 server
which Stanford's stratum-2 boxes are syncing to):
remote refid st t when poll reach delay offset jitter
==============================================================================
*TRUETIME(1) .GPS. 0 l 8 64 377 0.000 -0.741 1.203
+bigben.cac.wash .USNO. 1 u 678 1024 377 21.687 9.502 0.177
+clock.isc.org .GPS. 1 u 688 1024 377 4.706 2.829 0.131
You might remember I brought up the issue, some time ago, of how the
University of Washington's server (bigben) appears to be way off.
--
Rich Wales / ri...@richw.org / ri...@stanford.edu
Wikipedia: http://en.wikipedia.org/wiki/User:Richwales
Facebook: http://www.facebook.com/richwales
_______________________________________________
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
