[LinuxPPS] Fwd: Attaching PPS to kernel
Alvarez, Ralph
ralph.alvarez at windriver.com
Fri Apr 1 22:35:52 CEST 2011
Resubmitting to mailing list....
-----Original Message-----
From: Alvarez, Ralph
Sent: Friday, April 01, 2011 12:13 PM
To: 'Paul Lavender'; 'hart at ntp.org'; 'udovdh at xs4all.nl'; 'plyatov at gmail.com'
Cc: linuxpps at ml.enneenne.com
Subject: RE: [LinuxPPS] Fwd: Attaching PPS to kernel
Hey Guys,
Thanks for the assistance. I think I have my setup working now. Here's a summary of what I did:
I probably should of mentioned that I'm using an older kernel (2.6.27) with the PPS patch applied. I tried NTP DEV version ntp-4.2.7p7xx but quickly reverted back to the most stable version (ntp-4.2.6p3) after Igor's comments that ntp-4.2.7p7xx wasn't stable with PPS.
My NTP GPS/PPS setup is for an embedded system that has 8 networked hosts. One of the hosts acts as the NTP server while the others act as clients. Here's what I did to get things going:
1. Applied PPS patch (ntp-pps-2.6.27-rc3-bis-diff) to 2.6.27 kernel.
2. Built latest stable NTP (ntp-4.2.6p3) as follows:
a. ./configure --without-ntpsnmpd --disable-all-clocks --disable-parse-clocks --enable-ATOM --enable-NMEA --enable-LOCAL-CLOCK
b. Modified config.h.in to include these macros: HAVE_PPSAPI, HAVE_TIMEPPS_Hand CLOCK_ATOM.
c. Copied over timepps.h file to ntp/include folder (from pps-tools tarball).
3. Verified that kernel PPS was working as expected (see my notes below)
4. Setup for NMEA driver:
a. "ln -s /dev/ttyS0 /dev/gps0"
b. "ln -s /dev/pps0 /dev/gpspps0"
5. Setup NTP config file with this line:
a. server 127.127.20.0 mode 1 minpoll 4 prefer fudge 127.127.20.0 time1 0.0 flag1 1 flag2 0 flag3 0 stratum 1 refid NMEA
6. Restarted all hosts in sync.
Questions:
1. Should I be worried that I'm not getting the PPSSIGNAL status from the ntptime output below?
2. is it possible to build NTP with the macros above without having to modify config.h.in ?
3. What command do I use in udev.conf to auto-create /dev/gps0 and dev/gpspps0 links
After running my setup overnight, I came up with the following sync times between NTP clients and server:
remote refid st t when poll reach delay offset jitter
==============================================================================
*CLN1-A19 GPS_NMEA(0) 2 u 5 16 377 0.039 0.029 0.001
remote refid st t when poll reach delay offset jitter
==============================================================================
*CLN1-A19 GPS_NMEA(0) 2 u 8 16 377 0.040 0.047 0.002
remote refid st t when poll reach delay offset jitter
==============================================================================
*CLN1-A19 GPS_NMEA(0) 2 u 123 256 377 0.042 -0.064 0.009
remote refid st t when poll reach delay offset jitter
==============================================================================
*CLN1-A19 GPS_NMEA(0) 2 u 32 128 377 0.039 -0.043 0.003
remote refid st t when poll reach delay offset jitter
==============================================================================
*CLN1-A19 GPS_NMEA(0) 2 u 12 16 377 0.034 0.075 0.002
remote refid st t when poll reach delay offset jitter
==============================================================================
*CLN1-A19 GPS_NMEA(0) 2 u 12 16 377 0.034 0.061 0.003
remote refid st t when poll reach delay offset jitter
==============================================================================
*CLN1-A19 GPS_NMEA(0) 2 u 12 16 377 0.040 0.048 0.003
remote refid st t when poll reach delay offset jitter
==============================================================================
oGPS_NMEA(0) .NMEA. 1 l 2 16 377 0.000 0.042 0.001
ntp_gettime() returns code 0 (OK)
time d0a801f2.bc0a0000 Tue, Dec 7 2010 0:44:34.734, (.734528),
maximum error 1275 us, estimated error 0 us
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 41.000 us, frequency 7.534 ppm, interval 1 s,
maximum error 1275 us, estimated error 0 us,
status 0x1 (PLL),
time constant 4, precision 1.000 us, tolerance 500 ppm,
Thanks again for your help,
- Ralph
-----Original Message-----
From: linuxpps-bounces at ml.enneenne.com [mailto:linuxpps-bounces at ml.enneenne.com] On Behalf Of Paul Lavender
Sent: Friday, April 01, 2011 5:19 AM
To: linuxpps at ml.enneenne.com
Subject: Re: [LinuxPPS] Fwd: Attaching PPS to kernel
Re: the assert/clear
I don't know about your GPS unit, but one I played with outputted an
assert followed by a clear 25.6 mS. later. So I guess the true PPS is
the first and the second was generated using an internal 10000Hz. clock
- counting to 2^8 So even if you allowed for the 25.6 mS. offset it
wouldn't be quite as accurate.
A small point and probably swallowed up by other errors.........
Still I always use the 'first' transition.
Paul
djch-pps at whabbit.demon.co.uk wrote:
> Ralph
>
> I may be able to help - I've been watching all the hard work that's got the pps code into the mainstream kernel. ( I used the old old pps patches, back around 2.6.16...)
>
> Yesterday I took the plunge, and succeeded in getting pps lock. My setup is
>
> -gentoo kernel 2.6.38 No patches beyond what gentoo applies
>
> -ntp v4.2.6
>
> -a trimble SVeeSix GPS, which gives an RS-232 output (TSIP protocol). It also provides a 1 PPS signal, which I have level-shifted to RS-232. The data goes to my serial port (/dev/ttyS1), and the 1PPS to carrier detect on the same port
>
> I use the PPS driver in NTP - which takes a 1PPS signal, and uses that to lock the kernel. It has to have some other source to tell it which second it's in, and this is the slightly tricky part. You use the prefer keyword to tell NTP to use the GPS as that time source. (I see now that there's pps support in the clock drivers themselves - I will try this later. However, this older config does work, and may help you get going...)
>
> One other 'feature' - if there's much jitter on the GPS serial (NMEA for you, TSIP for me), NTP will sometimes decide to ignore the GPS. Then it has no refclock available, and it drops the PPS... I have ADSL internet, so I declare another server locked to my ISP, so that NTP always knows the time of day. You may not need this, but it cured occasional drop-out here
>
> -----
> OK, config
>
> ntp.conf
>
> # omitted the restrict etc not relevant to refclocks
>
> # to break the ambiguity, use household server slaved to demon
> server 192.168.69.12 iburst
>
> #the gps TSIP feed - the prefer is essential for the PPS driver below
> server 127.127.8.0 mode 10 prefer burst
> fudge 127.127.8.0 refid TSIP time1 0.040
>
> # the gps PPS, on the assert edge...
> server 127.127.22.0 iburst minpoll 4 maxpoll 4
> fudge 127.127.22.0 refid PPS0 flag2 0
>
> driftfile /etc/ntp/ntp.drift
>
> --
> System Setup
> ntp has fixed device names - so I use a udev rule to symlink /dev/ttyS1 to /dev/refclock-0, which the TSIP driver needs. (Since your system sees your GPS I suspect you have this ok)
>
> The pps kernel driver creates /dev/pps0, which is what the PPS driver needs. (I note that the pps support for the NMEA looks for /dev/gpspps0, so that might be your problem). ntp needs to read the pps device, hence
>
> SUBSYSTEM=="pps", MODE="0664", GROUP="ntp"
>
> --
> You then need to tell the kernel where the PPS for /dev/pps0 come from.
>
> ldattach 18 /dev/ttyS1
>
> where 18 is the pps line discipline for the serial port. This ought to be run by udev, but I haven't automated it yet...
>
> --
> With this in place, ntp should see the GPS serial data and then switch to using the PPS. If you try with the PPS driver, you see a slightly odd output in ntpq
>
> ntpq
>
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> +portage.burrowm 158.152.1.76 3 u 52 64 377 0.160 3.461 0.076
> *GENERIC(0) .TSIP. 0 l 7 64 377 0.000 2.639 5.665
> oPPS(0) .PPS0. 0 l 11 16 377 0.000 0.363 0.035
>
> Here the first line is the household server (at stratum 3), the second is the GPS serial, and the third the pps. Note the o and *, which denotes pps control using the GPS as the 'prefer peer' - the source of the complete time
>
> ----
> Good luck - my guess is that either you haven't got the symlink that NTP looks for the pps on (I think it's /dev/gpspps0 for you), or that you haven't run ldattach to link the serial port to the pps driver. I will try switching away from using the PPS driver, and report whether m setup still works.
>
> NB: the current serial code only seems to generate assert events - I need to put a scope on my clock to check I am triggering on the rising edge. Some gps units have jitter on the PPS falling edge, so poor sync might occur if the level shift to RS-232 causes assert to come from the falling edge.
>
> --David G8SQH
>
> ------------------------------------------------------------------
>
> On Thu, 31 Mar 2011 04:35:14 +0200
> Udo van den Heuvel<udovdh at xs4all.nl> wrote:
>
>
>> Please help out with this problem:
>>
>> -------- Original Message --------
>> Subject: Attaching PPS to kernel
>> Date: Wed, 30 Mar 2011 19:07:49 +0000
>> From: Alvarez, Ralph<ralph.alvarez at windriver.com>
>> To: udovdh at xs4all.nl<udovdh at xs4all.nl>
>>
>>
>>
>>
>>
>> Hi,
>>
>>
>>
>> Your email was referenced in the
>> http://wiki.enneenne.com/index.php/LinuxPPS_NTPD_support article on
>> setting up PPS support with NTPD. I’m hoping you’ll be able to help me
>> with getting my NTPD to sync on the kernel’s PPS signal/event.
>>
>>
>>
>> I was able to verify that my kernel is getting PPS events by:
>>
>> 1. Checking dmesg log to ensure that “PPS event on source 0 at
>> 1291626009.999782403” messages were being logged.
>>
>> 2. Using PPS-TOOLS “pps-test /dev/pps0” to verify that I’m getting
>> “source 0 - assert 1291623265.999472205, sequence: 894 - clear
>> 0.000000000, sequence: 0” messages.
>>
>> 3. Using NMEAD simulator to send “GPRMC” sentences at 1PPS
>> intervals (synced to PPS interrupts).
>>
>>
>>
>> From what I can tell, the kernel PPS framework is in place and
>> functioning as expected. The problem that I’m having is that I’m not
>> sure how to “hook” up the PPS signal to the NTPD daemon. From all the
>> NTPD configuration documentation I’ve read, I believe that I’m properly
>> referencing the correct NMEAD/PPS device “127.127.20.0“ in the ntd.conf
>> file. I’ve list the following details below:
>>
>>
>>
>> 1. NTPD command used to build NTPD
>>
>> 2. The output from NTPQ
>>
>> 3. The output from NTPTIME (note that there’s no PPSIGNAL bit set)
>>
>> 4. NTP configuration file
>>
>> 5. NTPD log output.
>>
>>
>>
>> Any idea what I’m missing here?
>>
>>
>>
>> Any help you can provide would be greatly appreciated !!
>>
>>
>>
>> -Ralph
>>
>>
>>
>>
>>
>> NTPD Build options:
>>
>> -----------------------------
>>
>> ./configure --without-ntpsnmpd --disable-all-clocks
>> --disable-parse-clocks --enable-NMEA --enable-LOCAL-CLOCK
>>
>>
>>
>> NTPQ output:
>>
>> ----------------------
>>
>> remote refid st t when poll reach delay offset
>> jitter
>>
>> ==============================================================================
>>
>> *GPS_NMEA(0) .GPS. 1 l 9 16 377 0.000 0.224
>> 0.164
>>
>> Mon Dec 6 08:10:02 GMT 2010
>>
>>
>>
>>
>>
>> NTPTIME output:
>>
>> ----------------------
>>
>> ntp_gettime() returns code 0 (OK)
>>
>> time d0a718da.ecc4b000 Mon, Dec 6 2010 8:10:02.924, (.924876),
>>
>> maximum error 5185 us, estimated error 226 us
>>
>> ntp_adjtime() returns code 0 (OK)
>>
>> modes 0x0 (),
>>
>> offset 216.000 us, frequency 7.567 ppm, interval 1 s,
>>
>> maximum error 5185 us, estimated error 226 us,
>>
>> status 0x1 (PLL),
>>
>> time constant 4, precision 1.000 us, tolerance 500 ppm,
>>
>>
>>
>>
>>
>> NTP CONF output:
>>
>> ----------------------
>>
>> #
>>
>> # NTP configuration file (ntp.conf)
>>
>> #
>>
>> server 127.127.20.0 mode 1 minpoll 4 # PPS from GPS2
>>
>> fudge 127.127.20.0 time1 0.126 flag1 1 flag2 0 flag3 1 stratum 1 refid GPS
>>
>>
>>
>> #
>>
>> # Access control stuff
>>
>> #
>>
>> restrict default noserve # default deny
>>
>> restrict 127.0.0.1 # allow local host
>>
>> restrict 128.4.0.0 mask 255.255.0.0 # allow DCnet clients
>>
>> restrict 128.175.0.0 mask 255.255.0.0 # allow UDel clients
>>
>> restrict 140.173.0.0 mask 255.255.0.0 # allow DARTnet/CAIRN clients
>>
>>
>>
>> broadcastclient # broadcast client
>>
>>
>>
>>
>>
>> #
>>
>> # Miscellaneous stuff
>>
>> #
>>
>> statsdir /var/log/ntp/server
>>
>> filegen loopstats file loopstats type day enable
>>
>> driftfile /var/log/ntp/server/drift
>>
>> logfile /var/log/ntp/server/messages
>>
>>
>>
>>
>>
>> Output from NTPD:
>>
>> root at EDU1-A19:/root> /usr/bin/ntpd -Adng -c /etc/server.ntp.conf
>>
>> ntpd 4.2.6p3 at 1.2290 Tue Mar 29 22:46:51 UTC 2011 (1)
>>
>> 6 Dec 08:33:09 ntpd[7309]: proto: precision = 1.000 usec
>>
>> event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
>>
>> Finished Parsing!!
>>
>> 6 Dec 08:33:09 ntpd[7309]: ntp_io: estimated max descriptors: 1024,
>> initial socket boundary: 16
>>
>> 6 Dec 08:33:09 ntpd[7309]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
>>
>> 6 Dec 08:33:09 ntpd[7309]: Listen and drop on 1 v6wildcard :: UDP 123
>>
>> 6 Dec 08:33:09 ntpd[7309]: Listen normally on 2 lo 127.0.0.1 UDP 123
>>
>> restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags
>> 00000001
>>
>> 6 Dec 08:33:09 ntpd[7309]: Listen normally on 3 eth0 10.10.11.189 UDP 123
>>
>> restrict: op 1 addr 10.10.11.189 mask 255.255.255.255 mflags 00003000
>> flags 00000001
>>
>> 6 Dec 08:33:09 ntpd[7309]: Listen normally on 4 lo ::1 UDP 123
>>
>> restrict: op 1 addr ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
>> mflags 00003000 flags 00000001
>>
>> 6 Dec 08:33:09 ntpd[7309]: Listen normally on 5 eth0
>> fe80::827f:2cff:fe31:d600 UDP 123
>>
>> restrict: op 1 addr fe80::827f:2cff:fe31:d600 mask
>> ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags 00003000 flags 00000001
>>
>> 6 Dec 08:33:09 ntpd[7309]: peers refreshed
>>
>> 6 Dec 08:33:09 ntpd[7309]: Listening on routing socket on fd #22 for
>> interface updates
>>
>> restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 00000002
>>
>> restrict: op 1 addr :: mask 0.0.0.0 mflags 00000000 flags 00000002
>>
>> restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags
>> 00000000
>>
>> restrict: op 1 addr 128.4.0.0 mask 255.255.0.0 mflags 00000000 flags
>> 00000000
>>
>> restrict: op 1 addr 128.175.0.0 mask 255.255.0.0 mflags 00000000 flags
>> 00000000
>>
>> restrict: op 1 addr 140.173.0.0 mask 255.255.0.0 mflags 00000000 flags
>> 00000000
>>
>> 6 Dec 08:33:09 ntpd[7309]: io_setbclient: Opened broadcast client on
>> interface #3 eth0
>>
>> io_setbclient: Opened broadcast clients
>>
>> peer_clear: at 0 next 1 associd 25578 refid INIT
>>
>> 6 Dec 08:33:09 ntpd[7309]: refclock_open /dev/gps0: No such file or
>> directory
>>
>> Connection from 127.0.0.1 at Mon Dec 6 08:33:09 2010
>>
>> 6 Dec 08:33:09 ntpd[7309]: GPS_NMEA(0) serial /dev/gps0 open at 4800 bps
>>
>> event at 0 GPS_NMEA(0) 8011 81 mobilize assoc 25578
>>
>> newpeer: 127.0.0.1->127.127.20.0 mode 3 vers 4 poll 4 4 flags 0x9 0x1
>> ttl 1 key 00000000
>>
>> event at 0 0.0.0.0 c016 06 restart
>>
>> event at 0 0.0.0.0 c012 02 freq_set kernel 7.554 PPM
>>
>> refclock_transmit: at 1 127.127.20.0
>>
>> event at 1 GPS_NMEA(0) 802b 8b clock_event clk_no_reply
>>
>> nmea: gpsread 70
>> $GPRMC,083311,A,3426.7827,N,11838.4318,W,000.0,218.8,061210,013.7,E*6A
>>
>> nmea: timecode 70
>> $GPRMC,083311,A,3426.7827,N,11838.4318,W,000.0,218.8,061210,013.7,E*6A
>>
>> nmea: gpsread 70
>> $GPRMC,083312,A,3426.7827,N,11838.4318,W,000.0,218.8,061210,013.7,E*69
>>
>> nmea: timecode 70
>> $GPRMC,083312,A,3426.7827,N,11838.4318,W,000.0,218.8,061210,013.7,E*69
>>
>> nmea: gpsread 70
>> $GPRMC,083313,A,3426.7827,N,11838.4318,W,000.0,218.8,061210,013.7,E*68
>>
>> nmea: timecode 70
>> $GPRMC,083313,A,3426.7827,N,11838.4318,W,000.0,218.8,061210,013.7,E*68
>>
>> nmea: gpsread 70
>> $GPRMC,083314,A,3426.7827,N,11838.4318,W,000.0,218.8,061210,013.7,E*6F
>>
>> nmea: timecode 70
>> $GPRMC,083314,A,3426.7827,N,11838.4318,W,000.0,218.8,061210,013.7,E*6F
>>
>> nmea: gpsread 70
>> $GPRMC,083315,A,3426.7827,N,11838.4318,W,000.0,218.8,061210,013.7,E*6E
>>
>> nmea: timecode 70
>> $GPRMC,083315,A,3426.7827,N,11838.4318,W,000.0,218.8,061210,013.7,E*6E
>>
>> nmea: gpsread 70
>> $GPRMC,083316,A,3426.7827,N,11838.4318,W,000.0,218.8,061210,013.7,E*6D
>>
>>
>>
>>
>>
>> Ralph Alvarez
>>
>> Member of Technical Staff
>>
>> Wind River Systems
>>
>> 895 Dove Street #315
>>
>> Newport Beach, CA 92660
>>
>> Phone: 949-851-4689 Fax: 949-851-4677
>>
>> Email: ralvarez at windriver.com<mailto:ralvarez at windriver.com>
>>
>>
>> _______________________________________________
>> LinuxPPS mailing list
>> LinuxPPS at ml.enneenne.com
>> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
>> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
>>
>>
>
>
_______________________________________________
LinuxPPS mailing list
LinuxPPS at ml.enneenne.com
http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support
More information about the LinuxPPS
mailing list