On Tue, Jun 18, 2013 at 10:14 PM, David Taylor <
[email protected]> 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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
