[ntp:questions] ntpd connect gpsd shared memory driver

Richard Cagley rcagley at gmail.com
Wed Jun 19 14:58:31 UTC 2013


On Tue, Jun 18, 2013 at 10:14 PM, David Taylor <
david-taylor at blueyonder.co.uk.invalid> wrote:

> To distinguish between 1 and 2, run the PPS test, which shows the
> transition times.  I saw this:
>
> $ sudo ppstest /dev/pps0 # press Ctrl-C to cancel..
> trying PPS source "/dev/pps0"
> found PPS source "/dev/pps0"
> ok, found 1 source(s), now start fetching data...
> source 0 - assert 1351501153.999956346, sequence: 47481 - clear
> 0.000000000, sequence: 0
> source 0 - assert 1351501154.999954601, sequence: 47482 - clear
> 0.000000000, sequence: 0
> source 0 - assert 1351501155.999951856, sequence: 47483 - clear
> 0.000000000, sequence: 0
> ^C
>
> Sorry about the wrap!  The "some software" refers to the Raspberry Pi I'm
> using, where a 3rd-party program supplies the PPS data to the gpsd memory
> segment number 1.  I don't know whether gpsd can time the DCD line or not -
> it's outside the scope of my experience.  If it can, use 28.1, if not, use
> 22.0.
>

Thanks. It appears it may have just been a patience issue on my part. I let
it run overnight with this
server 127.127.20.0
fudge 127.127.20.0
server 127.127.22.0
fudge 127.127.22.0 flag3 1
and got this
/ # ntpq -p
     remote           refid      st t when poll reach   delay   offset
 jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l   29   64  377    0.000  140.035
0.002
xPPS(0)          .PPS.            0 l   28   64  377    0.000  -129.94
0.002

Now, I guess I need to figure out why the date is so off...
/ # date
Sat Jan  1 14:26:50 UTC 2000


More information about the questions mailing list