[ntp:questions] Linux, Garmin GPX-18X LVM & PPS
Paul Duncan
pdu at noc.ac.uk
Tue Dec 6 17:14:12 UTC 2011
Hello Miguel,
On 6 Dec 2011, at 16:00, Miguel Gonçalves wrote:
> Beware: long e-mail ahead!
LOL! Wasn't that long :-)
>
> On 6 December 2011 14:49, Paul Duncan <pdu at noc.ac.uk> wrote:
> Hi Miguel,
>
> Thanks very much for getting back to me.
>
> No problem. I've been helped before so I'll do my best to help you.
Thanks!
>
> 1) The peer line just needs to be another NTP server somewhere, right?
>
> Peer creates a symmetric relationship with another NTP machine. We
> can get the time from them and they can get the time from us. I am a
> time nut and I have three different GPS receivers that peer with
> each other:
>
> backup# ntpq -pn
> remote refid st t when poll reach delay
> offset jitter
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> +192.168.111.1 .GPS. 1 u 16 16 377 0.255
> -0.041 0.011
> +192.168.111.2 .GPS. 1 u 11 16 377 0.258
> -0.051 0.006
> *192.168.111.3 .PPS. 1 u 13 16 377 0.269
> -0.065 0.009
Ah, didn't know that. Thanks!
>
> 2) What does the line starting "tos" do?
>
> It allows a difference of 250 ms between the PPS and the NMEA
> string. Sometimes the NMEA output from the receiver has a bit of
> jitter and the PPS is decoupled from the NMEA data. The default is
> 10 ms. It should be increased in situations like this. It's not
> advisable to set it to a large number: as low as possible is the best.
Right that makes sense, I did hear something about the PPS signal
being up to 600ms away from the associated NMEA message.
>
> Either way, it does not seemed to work. Output from ntptime and ntpq
> below:
>
> oot at darkstar:/etc# ntpq -p
>
> remote refid st t when poll reach delay
> offset jitter
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> *GPS_NMEA(0) .GPS. 0 l 15 16 377 0.000
> -67.594 13.658
> root at darkstar:/etc# ntptime
>
> Apparently the NMEA data is being received. I am not familiar with
> Linux and PPS but I believe your kernel should have a PPS patch
> applied. Did you do it?
>
> ntp_gettime() returns code 0 (OK)
> time d288a989.f40bfde0 Tue, Dec 6 2011 14:47:37.953, (.953308550),
> maximum error 8175995 us, estimated error 13079 us, TAI offset 0
>
> ntp_adjtime() returns code 0 (OK)
> modes 0x0 (),
> offset -64.840 us, frequency -0.564 ppm, interval 1 s,
> maximum error 8175995 us, estimated error 13079 us,
> status 0x2001 (PLL,NANO),
> time constant 4, precision 0.001 us, tolerance 500 ppm,
> root at darkstar:/etc#
>
> Definitely no PPS there. I have a machine that has GPS receiver and
> I configured it differently:
>
Yeah, thats what I figured.
>
> So, I'm now thinking that the mistake must be in the way I have run
> the configure script when building the software. I think I just used
> --enable-NMEA. Should I have done something else?
>
> --enable-NMEA is enough. My configuration uses kernel PPS and that
> should be enabled in the kernel.
Oh drat. There goes another idea. The Kernel is recent (2.6.37.6) so
it should not need any patching. I have put the ldattach and soflinks
in /etc/rc.d/rc.local, so there is the /dev/pps0 device created during
boot, along with the symbolic links to /dev/gps0 and /dev/gpspps0.
The /dev/pps0 device appears to work because I can run ppstest, as
shown below:
root at darkstar:/usr/src/pps-tools# ./ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1323188242.404786216, sequence: 95913 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188243.404792241, sequence: 95914 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188244.404799987, sequence: 95915 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188245.404805164, sequence: 95916 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188246.404804639, sequence: 95917 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188247.404726196, sequence: 95918 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188248.404539131, sequence: 95919 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188249.404347855, sequence: 95920 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188250.404158109, sequence: 95921 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188251.403975379, sequence: 95922 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188252.403793377, sequence: 95923 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188253.403613763, sequence: 95924 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188254.403437177, sequence: 95925 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188255.403266841, sequence: 95926 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188256.403092759, sequence: 95927 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188257.402925868, sequence: 95928 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188258.402759572, sequence: 95929 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188259.402593551, sequence: 95930 - clear
1323092403.022424958, sequence: 73
source 0 - assert 1323188260.402432068, sequence: 95931 - clear
1323092403.022424958, sequence: 73
^C
root at darkstar:/usr/src/pps-tools#
>
> In FreeBSD it's quite easy: I just add a line OPTIONS PPS_SYNC to
> the kernel configuration file, recompile and reboot. I believe the
> most recent Linux kernels already have this patch but you should
> look for it. Did you read http://time.qnan.org/?
Yes, in fact we copied the circuitry to connect the GPS up, with the
exception of the LED's - since we read about the possible jitter
problems and decided we could do without them.
I think it is something to do with stuff not being setup by udev. Been
doing some more reading... I will definitely make my build
instructions for Slackware 13.37 Linux available when I'm finished...
I'm convinced this has been more frustrating than it really need be :-)
TTFN!
Paul.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the questions
mailing list