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 <[email protected]> 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@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@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@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@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@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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
