[ntp:questions] First attempt GPSD/PPS ->NTP time server

Erik Soosalu esoosalu at hotmail.com
Fri Jan 25 15:17:01 UTC 2008


How do you have your wiring done up?  I found that when I just twisted the wire together and wrapped them in electrical tape for testing, I had very bad serial port behaviour.  Doing a "cat /dev/gps1" I saw a lot of garbarge in stream and I was sometimes only seeing every third or fourth NMEA sentence. Soldering everything together snapped everything together.

Erik.




> Date: Thu, 24 Jan 2008 10:23:18 -0500
> From: ntplist at lakedaemon.net
> To: questions at lists.ntp.org
> Subject: [ntp:questions] First attempt GPSD/PPS ->NTP time server
> 
> All,
> 
> This is my first attempt to build an 'accurate' GPS-based time server.
> There is no Internet connectivity, so the GPS (and it's PPS) are the
> only sources of timing data.
> 
> I'm using a San Jose Navigation FV-M8 [1].  As a GPS, it works great.  I
> piped the PPS signal to the CTS line (gpsd-2.36 supports this) and with
> a minor tweak to gpsd (until I can find the sentence to change the pulse
> length), gpsd finds the pulse and hands everything off to ntpd as per
> the gpsd man page [2].
> 
> Watching ntpd from 'ntpq -p' appears to work as expected.  When the
> offset (SHM(0), average gps) is less than 1 second, gpsd sends the
> appropriate info to SHM(1) (gps pps), which ntpd uses ('ntpq -p' SHM(1)
> reach changes from 0 to positive values).
> 
> Basically, I think I have the hardware set up right.  However, I left it
> running over night because I kept seeing the following:
> 
> # watch -n3 ntpq -p
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
> *SHM(0)          .GPS.            0 l    -   16  377    0.000  1831.01
> 771.100
>  SHM(1)          .GPS1.           0 l   86   16   40    0.000    0.000
>  0.004
> 
> Sorry if it's line wrapped.  The offset of SHM(0) will wander from less
> than a second (< 1000.00) to around 8 seconds.  Each time it gets close
> (< 1000.00) the numbers for SHM(1) start changing, which tells me it's
> trying to use the PPS to pull it in tight.  But, then SHM(0) will wander
> off again.
> 
> What is normal?  How long should it take a stand alone GPS time server
> to lock in?  What should I tweak to fix this?  Any insight would be
> appreciated.
> 
> /etc/ntp.conf appended.
> 
> Note: I tried deleting the drift file, and changing the time1 value, to
> no avail.  (I'm shooting in the dark with that one ;-) )
> 
> thx,
> 
> Jason.
> 
> 
> [1] - http://www.sanav.com/gps_engine_board/FV-M8.htm
> [2] - http://gpsd.berlios.de/gpsd.html
> 	Section: "Use with NTP"
> 
> 
> ######## /etc/ntp.conf ###############################################
> [snipped commented out stuff]
> 
> # Added 20080122 to sync to GPS
> server 127.127.28.0 minpoll 4 maxpoll 4
> #fudge 127.127.28.0 time1 0.420 refid GPS
> fudge 127.127.28.0 time1 0.320 refid GPS
> 
> server 127.127.28.1 minpoll 4 maxpoll 4 prefer
> fudge 127.127.28.1 refid GPS1
> 
> [snipped out more comments]
> 
> # you should not need to modify the following paths
> driftfile       /var/lib/ntp/ntp.drift
> 
> [snip]
> 
> # To deny other machines from changing the
> # configuration but allow localhost:
> restrict default nomodify nopeer
> restrict 127.0.0.1
> 
> ######################################################################
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions

_________________________________________________________________




More information about the questions mailing list