NTP PPS

[chrisprt]

Thanks, got the source and I'll try a compile. By the way, after running the (Raspbian stock, non-PPS) ntpd process for a while, the ntp statistics log for frequency offset ranges between -37 to -38 ppm for my particular R-Pi. If I simply kill the ntpd process, does the Linux kernel still maintain that -37 ppm correction for the system time, or does it revert to an uncorrected clock?

Once the ntpd process is killed, your clock ticks normally without the guiding hand of ntpd. The process of slight, constant corrections to time by slewing the clock will stop.

Another question: with the 3.1.9-pps+ kernel and the pps_gpio module installed and the PPS signal connected, I am getting two lines added to the 'dmesg' log file every second, as below. How can I turn this off? I want to use dmesg to see other things like USB device connections, etc. and a lot of megabytes are accumulating in the /var/log directory.

edit: googling around, it looks like "PPS DEBUG" is an option compiled into the kernel, unfortunately.... Looks like I'll need to learn how to compile my own kernel!

Yep, sorry about that. I'm having problems getting it stable, so I've been using PPS debug. I can compile a version of the kernel without it for you if you'd like.

In case of interest I attach a graph of the drift of the R-Pi clock (with NTP turned off) relative to a more stable external PPS signal. You can see that the delay is variable but always positive (on time or late, but never early.) Superimposed on that is the longer-term drift.

A slight drift is okay though, that's what ntp is designed to mitigate, especially with the help of an external syncing source (PPS).

Are you saying that you've got PPS working successfully with the Pi?

[jbeale]

I have not yet compiled the NTP source to get NTP-PPS. But just logging the PPS timestamps, it behaves as expected when I do not have any NTPD process running, both from a free-running OCXO source and a GPS input. I don't have an actual GPDSO, yet. I am using this "Sure Electronics" GPS board
http://www.sureelectronics.net/goods.php?id=99
which has a 3.0 V level PPS signal output on 0.1" header pins, easy to connect to the R-Pi. The antenna is indoors, and the house is under some trees and it still (most of the time) gets a signal.

If you could cook up a kernel version without the PPS-DEBUG option that would be great!

[chrisprt]

If you could cook up a kernel version without the PPS-DEBUG option that would be great!

http://www.4shared.com/archive/OkXP-b5g ... debug.html

There you go. Just ungzip it and rename it to kernel.img.

Note that I believe all you need is the kernel, and not the firmware or module updates (there shouldn't have really been any, I just disabled PPS debugging). If you encounter any issues, I'll upload those as well.

[jbeale]

Thanks for the new kernel, I will try it! Meanwhile I did this (takes over 2 hours!)

Code: Select all

mkdir build                # make a convenient working directory
cd build
wget http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.6p5.tar.gz
tar xvfz ntp-4.2.6p5.tar.gz
cd ntp-4.2.6p5/
./configure --enable-ATOM  # takes about 45 minutes
make                       # takes over 1 hour 
sudo apt-get remove ntp    # get rid of previously existing install of ntpd
sudo make install	   # puts ntpd in /usr/local/bin/ntpd

...and then this:

Code: Select all

sudo reboot  [...and login...]
sudo modprobe pps-gpio
  [edit /etc/ntpd.conf to add:  server 127.127.22.0 minpoll 4 maxpoll 4 ]
sudo ntpd
  [wait for a while...]
ntpdc -c peers
     remote           local      st poll reach  delay   offset    disp
=======================================================================
=ns4000149.ip-19 192.168.10.101   2   64  377 0.09148 -0.000556 0.03432
=PPS(0)          127.0.0.1        0   16  377 0.00000  0.000265 0.01530
=vps1.bbnx.net   192.168.10.101   2   64    0 0.00000  0.000000 3.99217
*208.87.120.127  192.168.10.101   2   64  377 0.06464  0.000360 0.05936

So it appears the PPS input is detected, although it is not actually being used (I think '=' is standby, '*' is selected)? Is there some way to indicate that the local PPS signal is more reliable than the network NTP servers?

[jbeale]

I have the same problem as you, my PPS is marked as falseticker.

Code: Select all

pi@raspberrypi:~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+w1-wdc.ipv4.got 10.0.77.54       4 u   49   64  377   83.647   -0.760   0.234
*name1.glorb.com 128.252.19.1     2 u   60   64  377   80.594    0.540   0.362
xPPS(0)          .PPS.            0 l   12   16  377    0.000   -0.652   0.017
pi@raspberrypi:~$ ntpq -c as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 45651  943a   yes   yes  none candidate    sys_peer  3
  2 45652  963a   yes   yes  none  sys.peer    sys_peer  3
  3 45653  9124   yes   yes  none falsetick   reachable  2

Meanwhile I did try your new kernel.nodebug, but the lines in dmesg keep appearing. With 'ntpd' running there are four lines added every second, instead of two. Maybe I need the "nodebug" version of the pps-gpio module also.

Code: Select all

[  816.160072] pps pps0: PPS_FETCH
[  816.160191] pps pps0: timeout 0.000000000
[  816.870428] pps pps0: PPS event at 1344178564.000499432
[  816.870455] pps pps0: capture assert seq #570
[  817.160264] pps pps0: PPS_FETCH
[  817.160331] pps pps0: timeout 0.000000000
[  817.870477] pps pps0: PPS event at 1344178565.000512316
[  817.870504] pps pps0: capture assert seq #571
[  818.160554] pps pps0: PPS_FETCH
[  818.160635] pps pps0: timeout 0.000000000

[jbeale]

By the way, could this 2003 post from David Mills (inventor of NTP) be relevant to the ATOM falsticker issue? http://lists.ntp.org/pipermail/question ... 00320.html

Right now I'm using just a PPS signal by itself. I wonder if I also need the serial input from the GPS to determine the YY-MM-DD HH:MM:SS time for NTP to consider it a real clock?

...ok, I see from the below page I should be able to use just PPS, in conjunction with a regular outside NTP server for the absolute time reference.
http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3716

Progress! needed an additional line in /etc/ntp.conf:

Code: Select all

server 127.127.22.0 			# ATOM(PPS)
fudge 127.127.22.0 flag3 1		# enable PPS API

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 vps1.bbnx.net   192.5.41.209     2 u   47   64    0    0.000    0.000   0.000
*mirror          204.9.54.119     2 u   51   64    1   69.967    2.131   0.163
 PPS(0)          .PPS.            0 l    2   16   17    0.000   -0.790   0.244

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 59672  8011   yes    no  none    reject    mobilize  1
  2 59673  963a   yes   yes  none  sys.peer    sys_peer  3
  3 59674  9024   yes   yes  none    reject   reachable  2
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd [email protected] Sun Aug  5 02:15:17 UTC 2012 (1)",
processor="armv6l", system="Linux/3.1.9-pps+", leap=00, stratum=3,
precision=-20, rootdelay=72.719, rootdisp=1015.185, refid=208.53.158.34,
reftime=d3c91e24.9a0c71c1  Sun, Aug  5 2012  9:30:28.601,
clock=d3c91e61.39e30683  Sun, Aug  5 2012  9:31:29.226, peer=59673, tc=6,
mintc=3, offset=2.194, frequency=-37.050, sys_jitter=0.000,
clk_jitter=0.776, clk_wander=0.013

[jbeale]

Looks like it is now working. I went back to ntpd 4.2.6p3 due to a report that the current 'production' version on http://www.ntp.org/downloads.html/ which is version 4.2.6p5 may have a PPS driver bug causing the falseticker status always: http://lists.ntp.org/pipermail/question ... 33068.html

These are the relevant parts of my /etc/ntp.conf:

Code: Select all

server 0.debian.pool.ntp.org iburst prefer	# PPS needs a 'prefer' server
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst
server 127.127.22.0 minpoll 4 maxpoll 4    # ATOM (PPS)
fudge 127.127.22.0 flag3 1                 # I am not sure what this does

Code: Select all

pi@raspberrypi:~$ /usr/local/bin/ntpq -c peer -c as -c rl

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*stratum-2-core- 129.7.1.66       2 u   65   64  377   63.603   -1.320   0.612
+four10.gac.edu  18.26.4.105      2 u   52   64  377   59.169    1.183   0.208
+sola-dal-09.ser 64.250.177.145   2 u    5   64  377   46.849    3.102   0.323
+tick.tadatv.com 10.0.22.49       2 u    -   64  377   10.029    2.538   0.410
oPPS(0)          .PPS.            0 l    5   16  377    0.000    0.070   0.005

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 46881  963a   yes   yes  none  sys.peer    sys_peer  3
  2 46882  9424   yes   yes  none candidate   reachable  2
  3 46883  9424   yes   yes  none candidate   reachable  2
  4 46884  9424   yes   yes  none candidate   reachable  2
  5 46885  973a   yes   yes  none  pps.peer    sys_peer  3

associd=0 status=011d leap_none, sync_pps, 1 event, kern,
version="ntpd [email protected] Mon Aug  6 02:06:19 UTC 2012 (1)",
processor="armv6l", system="Linux/3.1.9-pps+", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=0.385, refid=PPS,
reftime=d3c9df71.3153d0be  Sun, Aug  5 2012 23:15:13.192,
clock=d3c9df76.4d18287b  Sun, Aug  5 2012 23:15:18.301, peer=46885, tc=4,
mintc=3, offset=0.070, frequency=-37.682, sys_jitter=0.005,
clk_jitter=0.000, clk_wander=0.021

[jbeale]

This plot shows the difference in R-Pi clock error between regular NTP using network servers (via 12 Mbps DSL line) and using local PPS from GPS receiver. The PPS discipline was turned on just after the 15 hour mark. In this case the peak error gets about 30x smaller, from 2 msec down to 0.06 msec. the accuracy limitation with PPS is the variable interrupt latency on the R-Pi. I recorded the reported GPS PPS timestamp at 10 minute intervals, so there are 6 data points every hour.

NTP-PPS-error.png (17.41 KiB) Viewed 24082 times

PPS-error.png (16.27 KiB) Viewed 24082 times

[Paul Kennedy]

Hi, A very interesting project. Well done. I had a look at Spark fun, but it was not clear which GPS unit you are hooking up to the Pi. Coule you please let me know so I get the same unit?

many thanks

[chrisprt]

Looks like it is now working. I went back to ntpd 4.2.6p3 due to a report that the current 'production' version on http://www.ntp.org/downloads.html/ which is version 4.2.6p5 may have a PPS driver bug causing the falseticker status always: http://lists.ntp.org/pipermail/question ... 33068.html

I was JUST reading about this today after googling. That's so frustrating if that's the reason why I've torn apart my setup 10x

fudge 127.127.22.0 flag3 1 # I am not sure what this does

I believe this actually turns on kernel disciplining. From (http://doc.ntp.org/4.1.2/driver22.htm):
flag3 0 | 1
Controls the kernel PPS discipline: 0 for disable (default), 1 for enable.

I'd actually be interested to see if the setup still works with that disabled.

[chrisprt]

In this case the peak error gets about 30x smaller, from 2 msec down to 0.06 msec. the accuracy limitation with PPS is the variable interrupt latency on the R-Pi.

60 microseconds sounds pretty good right about now. Congrats!

One more thing, here's the tar file for all the modules gathered from the nodebug build:
http://www.4shared.com/archive/TGxbiMzj ... ugtar.html

[jbeale]

Looks like it is now working. I went back to ntpd 4.2.6p3 due to a report that the current 'production' version on http://www.ntp.org/downloads.html/ which is version 4.2.6p5 may have a PPS driver bug causing the falseticker status always: http://lists.ntp.org/pipermail/question ... 33068.html

I was JUST reading about this today after googling. That's so frustrating if that's the reason why I've torn apart my setup 10x

Well, I can't yet confirm that's the problem, as when I was working with the p5 version I had neglected to set a "prefer" server in my ntp.conf, which apparently is needed with PPS. Although apparently you can hack the NTP code to remove that requirement, as per a post from agcarver on the ntp list: http://lists.ntp.org/pipermail/question ... 33096.html
Also, thank you very much for the nodebug modules! Will look forward to reducing the size of my accumulated log files .

I am using a "dev board" type GPS unit, specifically this one from Sure Electronics in China: http://www.sureelectronics.net/goods.php?id=99
Here is a detailed technical review of its performance for timing applications: http://www.leapsecond.com/pages/MG1613S/

[jbeale]

fudge 127.127.22.0 flag3 1 # I am not sure what this does

I believe this actually turns on kernel disciplining. From (http://doc.ntp.org/4.1.2/driver22.htm):
flag3 0 | 1
Controls the kernel PPS discipline: 0 for disable (default), 1 for enable.

I'd actually be interested to see if the setup still works with that disabled.

Having just installed the nodebug modules you kindly provided, I discover that PPS will now only work with that 'fudge' line commented out (otherwise, the 'PPS(0)' device shows up in the NTP list, but is always marked 0-unreachable).

[jbeale]

Drat! More trouble, when I thought everything was working. ntpd with PPS enabled was running ok for almost 24 hours. I accidentally bumped the power connector to the R-Pi, and the system rebooted. Everything still works OK after reboot, except that ntpd silently quits about 10 seconds after it is started, either manually or through sudo /etc/init.d/ntp restart
I checked /var/log/syslog after it dies, but nothing of interest:

Code: Select all

Aug  7 21:49:17 raspberrypi ntpd[2084]: ntpd [email protected] Mon Aug  6 02:06:19 UTC 2012 (1)
Aug  7 21:49:17 raspberrypi ntpd[2085]: proto: precision = 1.000 usec
Aug  7 21:49:17 raspberrypi ntpd[2085]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Aug  7 21:49:17 raspberrypi ntpd[2085]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Aug  7 21:49:17 raspberrypi ntpd[2085]: Listen normally on 1 lo 127.0.0.1 UDP 123
Aug  7 21:49:17 raspberrypi ntpd[2085]: Listen normally on 2 eth0 192.168.10.101 UDP 123
Aug  7 21:49:17 raspberrypi ntpd[2085]: peers refreshed
Aug  7 21:49:17 raspberrypi ntpd[2085]: Listening on routing socket on fd #19 for interface updates

network connectivity is OK. What could cause this?

Seems like it cannot connect to itself via loopback(?) wonder why that could be...

Code: Select all

pi@raspberrypi:/etc$ sudo /etc/init.d/ntp restart
Stopping NTP server: ntpdstart-stop-daemon: warning: failed to kill 1675: No such process
.
Starting NTP server: ntpd.
pi@raspberrypi:/etc$ ntpq -p
localhost: timed out, nothing received

[jbeale]

at least part of my problem was that the system clock somehow was 45 minutes slow, and when the system clock is too far wrong, it seems that ntpd just silently quits (at least, as I have it configured). Some sort of useful error message might be helpful, but if there was one, I don't know where it went.

[Paul Kennedy]

Hi
any chance you can outline the model of the GPS from sparkfun? I saw the entry for the sure electronics board, but it does not appear to be a positing from yourself, so I am a little confused right now. many thanks

[jbeale]

any chance you can outline the model of the GPS from sparkfun? I saw the entry for the sure electronics board, but it does not appear to be a positing from yourself, so I am a little confused right now. many thanks

I'm not sure who you are addressing as several people have posted to this thread... Personally I'm using the Sure Electronics GPS device which is relatively inexpensive. I don't know who, if anyone is using a SparkFun GPS with NTP on the R-Pi, although any device with 3.3V PPS output should work. -John Beale

[chrisprt]

I've been on vacation, but came back and after some fiddling I may have it working!

Due to the problems encountered while using the ATOM driver, I decided to take the advice of others and purchase a serial port to USB adapter. Using the adapter, I was able to successfully retrieve the GPS time sentences.

I created a symlink from /dev/ttyUSB0 to /dev/gps0 and /dev/pps0 to /dev/gpspps0.

Code: Select all

pi@raspberrypi /usr/src/ntp-4.2.6p5/ntpd $ ls /dev/gps*
/dev/gps0  /dev/gpspps0

With those in place, I switched from the troublesome ATOM driver to the Generic NMEA driver with PPS support.

I used these settings in ntp.conf:

Code: Select all

#GPS source
server 127.127.20.0 minpoll 4 maxpoll 4 mode 1 prefer
fudge 127.127.20.0 flag1 1 time2 0.600 stratum 0
#mode 1$GPSRMC sentence
#flag1 enables PPS
#time2 used for my GPS device, since the GPS sentences coming over serial are quite lagged.

After letting ntpd run for an hour, here are the results:

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+resnet1.resnet. .GPS.            1 u   20   64  377   42.105   -5.409   4.690
*tick.usno.navy. .IRIG.           1 u   29   64  377   51.918    6.032   5.340
-ntp-s1.cise.ufl .GPS.            1 u   27   64  377   61.594  -12.821   0.629
+navobs1.gatech. .GPS.            1 u   17   64  377   65.802    6.440   3.627
oGPS_NMEA(0)     .GPS.            0 l   14   16  377    0.000    0.013   0.001

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+resnet1.resnet. .GPS.            1 u   22   64  377   41.995   -5.562   3.654
*tick.usno.navy. .IRIG.           1 u   29   64  377   50.877    5.783   4.582
-ntp-s1.cise.ufl .GPS.            1 u   28   64  377   61.594  -12.821   0.875
+navobs1.gatech. .GPS.            1 u   19   64  377   65.757    6.615   0.861
oGPS_NMEA(0)     .GPS.            0 l    6   16  377    0.000    0.008   0.003

$ ntpdc -c kern
pll offset:           6.77e-06 s
pll frequency:        -27.011 ppm
maximum error:        0.008244 s
estimated error:      4e-06 s
status:               2001  pll nano
pll time constant:    4
precision:            1e-09 s
frequency tolerance:  500 ppm

$ ntpq -c rv
associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version="ntpd [email protected] Sat Jul 21 21:14:36 UTC 2012 (1)",
processor="armv6l", system="Linux/3.1.9-pps+", leap=00, stratum=1,
precision=-20, rootdelay=0.000, rootdisp=0.420, refid=GPS,
reftime=d3d6c49c.50c95c2a  Wed, Aug 15 2012 21:00:12.315,
clock=d3d6c4a8.e346e05d  Wed, Aug 15 2012 21:00:24.887, peer=38554, tc=4,
mintc=3, offset=0.003, frequency=-26.951, sys_jitter=0.004,
clk_jitter=0.005, clk_wander=0.001

Note that the o prefix specifies that the peer is synced via pps, which is a good sign.

[aquarat]

Hi

I tried installing chrisrpt's pps kernel and modules. I also compiled ntp 4.2.6p3 .

PPSTest works, but unfortunately the output from PPSTest is erratic (it skips pulses) :

Code: Select all

ppstest /dev/pps1
trying PPS source "/dev/pps1"
found PPS source "/dev/pps1"
ok, found 1 source(s), now start fetching data...
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
source 0 - assert 1345156645.344964879, sequence: 9509 - clear  0.000000000, sequence: 0
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
source 0 - assert 1345156651.344989422, sequence: 9510 - clear  0.000000000, sequence: 0
source 0 - assert 1345156653.344997603, sequence: 9511 - clear  0.000000000, sequence: 0
time_pps_fetch() error -1 (Connection timed out)
source 0 - assert 1345156657.345012965, sequence: 9512 - clear  0.000000000, sequence: 0
source 0 - assert 1345156659.345022146, sequence: 9513 - clear  0.000000000, sequence: 0
source 0 - assert 1345156660.345025744, sequence: 9514 - clear  0.000000000, sequence: 0
source 0 - assert 1345156661.345029326, sequence: 9515 - clear  0.000000000, sequence: 0

I checked the manual for my Trimble Thunderbolt it states that the PPS voltage is 2.7 V... what is the triggering threshold for the Pi's GPIO pins when used as inputs ?

[chrisprt]

I checked the manual for my Trimble Thunderbolt it states that the PPS voltage is 2.7 V... what is the triggering threshold for the Pi's GPIO pins when used as inputs ?

The GPIO pins expect 3.3v, but I don't know the exact triggering threshold for the pin. I did a little googling but couldn't find anything on the subject.

It sounds like you may need a boost converter, something like http://www.dimensionengineering.com/products/lvboost
To be honest though, I don't know a lot about EE, so there may be a more simple means of achieving what you need.

[aquarat]

Hey chrisprt

Thanks for checking, LVBoost looks cool.

I connected an LED to the PPS output and it emits a very dim light.

Does it sound sane connecting a 0.5V power source in series with the PPS output and then running the result into the Pi ? The result would be 0.5V at rest and 3.2v when pulsing. I'd get the additional 0.5V from a separate 5V transformer+rectifier (voltage divider) connected to the same 240VAC line as another 5V transformer powering the Pi.

[jbeale]

Yes, you could use a resistive divider to DC bias at 0.5 V and a capacitor to the weak PPS source to give you the AC portion of the signal. I'd expect the Pi input logic threshold to be at 3.3/2 = 1.65 volts, so if you are really getting 2.7 V I'd expect it to work consistently. Although the threshold would be higher if there is a Schmitt-trigger input. You can also use a separate bipolar or fet amplifier.

[chrisprt]

Yes, you could use a resistive divider to DC bias at 0.5 V and a capacitor to the weak PPS source to give you the AC portion of the signal. I'd expect the Pi input logic threshold to be at 3.3/2 = 1.65 volts, so if you are really getting 2.7 V I'd expect it to work consistently. Although the threshold would be higher if there is a Schmitt-trigger input. You can also use a separate bipolar or fet amplifier.

Now I know how my friend feels when I start talking about memory pointers.

Were you able to resolve the earlier issues you were having jbeale?

[chrisprt]

For those interested, I ran the pi while being synced to my GPS unit for a 24 hour period. Here's the results:

It stayed pretty stable throughout the day, only drifting around 20 microseconds max in either direction. The room that the pi in has pretty large heat fluctuations, so that may explain the frequency shifts. If the room was temperature controlled, the results would probably be even more precise.

A machine on the same LAN was using the pi as it's primary syncing source, and it didn't do quite as well as I had hoped:

it fluctuated heavily throughout the day, anywhere from +11 ms to -13 ms from 0. I was under the impression that syncing over LAN should be able to get it ~1ms offset in either direction. This may be happening due to the shared USB bus problem. That's just speculation though.

Here's the album if the pictures seem blurry: http://imgur.com/a/LI2Rm

[jbeale]

Were you able to resolve the earlier issues you were having jbeale?

Yes, it worked again after I manually set to the clock to be more approximately correct. It seems NTP just quits if the initial difference is too great. As you may have seen in threads elsewhere, the R-Pi USB subsystem has some known glitches, for example higher than reasonable interrupt latency, and it may work better as a NTP server once those are fully ironed out.