NTP PPS

[aquarat]

Very cool chrisrpt. I've decided to rather connect my Trimble GPS to a PC Engines Alix Board via serial (due to the erratic PPS).

ADAFruit makes an interesting GPS module : http://adafruit.com/products/746 . It runs off 3.3V to 5V and it runs TTL for rx/tx and pps. It only uses 20ma when running. I've ordered a couple of these for my Pis.

[chrisprt]

ADAFruit makes an interesting GPS module : http://adafruit.com/products/746 . It runs off 3.3V to 5V and it runs TTL for rx/tx and pps. It only uses 20ma when running. I've ordered a couple of these for my Pis.

If I had a clear view of the sky without having to hang my GPS up in my window I'd be all over that.

[aquarat]

If I had a clear view of the sky without having to hang my GPS up in my window I'd be all over that.

It has an external antenna port, you can connect a higher-gain outside antenna like that .

[aquarat]

I tried the voltage-divider + GPS-PPS in series idea and... it works . I've been running ppstest for a few minutes and it hasn't shown any dropped pulses.

[chrisprt]

I tried the voltage-divider + GPS-PPS in series idea and... it works . I've been running ppstest for a few minutes and it hasn't shown any dropped pulses.

Nice! You'll have to get the ntpd source and build it for the type of driver support you'll need, but it should be smooth sailing from here.

[aquarat]

Hi

I don't know why but I've been unable to get ntpd to recognise the PPS device.

PPSTest indicates a good PPS on /dev/pps0 and I've configured ntp.conf as suggested in previous posts, but for some reason NTPd doesn't see the PPS.

I installed GPSd and added "server 127.127.28.0 minpoll 4 maxpoll 4" to the ntp.conf file. NTP recognised that, but not the PPS. Incidentally, if GPSd loads before the pps-gpio module is loaded, /dev/pps0 then belongs to gpsd and /dev/pps1 becomes the GPIO PPS device.

I compiled ntp-4.2.6p3.tar.gz (as someone suggested p5 gave them issues) with the --enable-ATOM configure flag.

The kernel and modules I'm using were chrisrpt's compilation (thanks ). dmesg also shows the PPS being detected.

Normally I boot the device, then modprobe pps-gpio. I then start gpsd (I'd eventually automate this).

Am I missing something stupid ?

The two servers in the ntp.conf file are :

Code: Select all

server 127.127.28.0 minpoll 4 maxpoll 4 prefer # GPSd
fudge 127.127.28.0 refid NMEA

server 127.127.22.0 minpoll 4 maxpoll 4    # ATOM (PPS)
fudge 127.127.22.0 flag3 1                 

This is the output from ntpd -gdn :

Code: Select all

ntpd 4.2.6p3@1.2290 Thu Aug 23 15:30:57 UTC 2012 (1)
24 Aug 00:08:16 ntpd[9582]: proto: precision = 1.000 usec
event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
Finished Parsing!!
24 Aug 00:08:16 ntpd[9582]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
24 Aug 00:08:16 ntpd[9582]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
24 Aug 00:08:16 ntpd[9582]: Listen normally on 1 lo 127.0.0.1 UDP 123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags 00000001
24 Aug 00:08:16 ntpd[9582]: Listen normally on 2 eth0 10.0.0.21 UDP 123
restrict: op 1 addr 10.0.0.21 mask 255.255.255.255 mflags 00003000 flags 00000001
24 Aug 00:08:16 ntpd[9582]: peers refreshed
24 Aug 00:08:16 ntpd[9582]: Listening on routing socket on fd #19 for interface updates
restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 000005d0
24 Aug 00:08:16 ntpd[9582]: restrict: error in address '::' on line 65. Ignoring...
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags 00000000
24 Aug 00:08:16 ntpd[9582]: restrict: error in address '::1' on line 69. Ignoring...
24 Aug 00:08:16 ntpd[9582]: io_setbclient: Opened broadcast client on interface #2 eth0
io_setbclient: Opened broadcast clients
peer_clear: at 0 next 1 associd 18062 refid INIT
24 Aug 00:08:16 ntpd[9582]: refclock_newpeer: clock type 22 invalid
24 Aug 00:08:16 ntpd[9582]: 127.127.22.0 interface 127.0.0.1 -> (none)
peer_clear: at 0 next 2 associd 18063 refid INIT
event at 0 SHM(0) 8011 81 mobilize assoc 18063
newpeer: 127.0.0.1->127.127.28.0 mode 3 vers 4 poll 4 4 flags 0x29 0x1 ttl 0 key 00000000
event at 0 0.0.0.0 c016 06 restart
event at 0 0.0.0.0 c012 02 freq_set kernel -55.489 PPM
event at 1 SHM(0) 802b 8b clock_event clk_no_reply
refclock_transmit: at 2 127.127.28.0
refclock_transmit: at 18 127.127.28.0

I'm guessing the "refclock_newpeer: clock type 22 invalid" has something to do with this.

Thanks in advance .

P.S. The GPS in use is one of the Adafruit GPSs I spoke about in an earlier post. The PPS output is 3V and I've connected the 3.3V TTL serial lines to ttyAMA0.

[aquarat]

I tried ntp-dev-4.2.7p295 and now ntp is detecting the PPS yay .

[aquarat]

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l   14   16  377    0.000  -15.084   3.718
+SHM(0)          .NMEA.           0 l   45   64    7    0.000  -432.26   5.229
*41.216.193.26 ( 41.73.40.11      2 u   34   64   17   37.625  -10.666  11.477

[chrisprt]

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l   14   16  377    0.000  -15.084   3.718
+SHM(0)          .NMEA.           0 l   45   64    7    0.000  -432.26   5.229
*41.216.193.26 ( 41.73.40.11      2 u   34   64   17   37.625  -10.666  11.477

That definitely looks like what you want to see, but that offset should be much lower. I'm guessing it settled down later on?

[aquarat]

Hi Chris

In my experience the offset on the NMEA data has always been quite large. That 432.26 represents milliseconds, right ?

I ran into some fun with GPSd; the repository package kept giving segmentation faults. I tried compiling GPSd myself but it did the same thing. I have now switched to ntpd's built in NMEA driver, which seems to be quite happy.

I've noticed that the PPS is a couple of ms (between 3 and 14ms) off from a random selection of other ntp servers, but the NMEA offset seems to always be around 450ms (whether the data is fed to ntp via GPSd or the NMEA ntp driver). The GPS outputs NMEA data at 9600 bps and the configuration utility says that it currently uses about 80% of the available bandwidth to send the NMEA data, perhaps this is contributing to the offset ? The GPS supports speeds up to 115kbps.

My Trimble GPS also gives me quite a large offset between the PPS and NMEA data.

I'm testing revised configuration, I'll post an update in the morning (as to whether or not it has settled/improved).

[chrisprt]

Hi Chris
In my experience the offset on the NMEA data has always been quite large. That 432.26 represents milliseconds, right ?

Yes, offset is expressed in milliseconds. That's not too surprising from the NMEA serial side though. For example, my Garmin GPS 18x LVC NMEA data is 600 milliseconds early. When I first started configuring it, it was syncing on the wrong side of the PPS second! The fix for this is adding time2 to the fudge line for the NMEA data. For example:

Code: Select all

fudge 127.127.20.0 flag1 1 time2 0.600 stratum 0

I ran into some fun with GPSd; the repository package kept giving segmentation faults. I tried compiling GPSd myself but it did the same thing. I have now switched to ntpd's built in NMEA driver, which seems to be quite happy.

I've noticed that the PPS is a couple of ms (between 3 and 14ms) off from a random selection of other ntp servers, but the NMEA offset seems to always be around 450ms (whether the data is fed to ntp via GPSd or the NMEA ntp driver). The GPS outputs NMEA data at 9600 bps and the configuration utility says that it currently uses about 80% of the available bandwidth to send the NMEA data, perhaps this is contributing to the offset ? The GPS supports speeds up to 115kbps.

My Trimble GPS also gives me quite a large offset between the PPS and NMEA data.

I'm testing revised configuration, I'll post an update in the morning (as to whether or not it has settled/improved).

Being 3-14ms off from ntpd servers is fine. ntpd does a pretty good job of calculating delay, but over an internet connection, being consistently 3-15 ms off isn't surprising at all. That's the benefit of these devices - much more precise time.
My GPS unit is currently set at 4800bps. Although some people will tell you that it should be faster, the ntpd driver itself states as follows:

Using higher line speeds does not necessarily increase the precision of the timing device. Higher line speeds are not necessarily helpful for the NMEA driver, either. They can be used to accomodate for an amount of data that does not fit into a 1-second cycle at 4800 bps, but high-speed high-volume NMEA data is likely to cause trouble with the serial line driver since NMEA supports no protocol handshake. Any device that is exclusively used for time synchronisation purposes should be configured to transmit the relevant data only, e.g. one $GPRMC or $GPZDA per second, at a linespeed of 4800 bps or 9600 bps.

Most GPS manufacturers tend to send the next second data significantly early, to avoid missing the second if the line is busy. Mine is +0.6s, yours is what's more normally seen, ~+0.4s. Assuming that you're seeing a consistent x msec offset, nothing sounds out of the ordinary here, at least to me. Fudge the NMEA data driver so that it's closer to home as needed, and I think you're good.

[aquarat]

Hey Chrisrpt

Thanks for the info. It's surprisingly difficult finding information on some of the shm drivers for ntp. NTPd has been running for about 11 hours and this is the output :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l   54   64  377    0.000  -444.55  52.258
xPPS(0)          .PPS.            0 l   52   64  377    0.000    0.693   2.155
xsangoma.saix.ne 193.190.230.66   2 u   59  128  377   55.807    7.490   1.992
xsabela.saix.net 192.36.144.22    2 u   32  128  377   35.277    6.190   1.219
 10.0.0.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

and this is "server" portion of the ntp.conf file :

Code: Select all

server 127.127.20.0 mode 16 #sets baud
fudge 127.127.20.0 flag1 1

server 127.127.22.0 prefer
fudge 127.127.22.0 flag1 1

server 0.pool.ntp.org
server 1.pool.ntp.org

I'll try fudging the time as you suggest .

[aquarat]

NTPd has been running for a few hours with the fudge constant you suggested and this is the output of ntpq -p :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l   25   64  377    0.000  -93.407  50.441
xPPS(0)          .PPS.            0 l    -    8  377    0.000   27.127   1.071
xstratum1.neolog .PPS.            1 u    5   64  377   36.857   29.152  10.312
*orange.apolix.c 41.73.40.11      2 u   31   64  377   37.482   28.292   9.660
 10.0.0.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

Any idea why it dislikes three of the four sources ?

[aquarat]

and now :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l    8   64  377    0.000  -85.283  85.560
xPPS(0)          .PPS.            0 l    7    8  377    0.000    4.254   1.179
xstratum1.neolog .PPS.            1 u   39   64  377   36.674   10.515   5.234
xorange.apolix.c 41.73.40.11      2 u   65   64  377   37.236   23.014   9.684
 10.0.0.255      .BCST.          16 u    -   64    0    0.000    0.000   0.001

...lol

[Paul Kennedy]

Hi,
I have just popped my pi on the web. I do not yet have a GPS, but it is on the way. I already made a small website to expose some internals such as offset, freq and CPU load, and a realtime plot to boot.

http://121.221.94.250/

At present, I only have internet ref clocks, so less than ideal, but the basic principle remains. When I get my PPS, I hope it gets more stable.

I would appreciate any feedback on whats missing.

cheers

[Paul Kennedy]

Hi Aquarat,
NTP often gets a little narky if multiple ref clocks with similar stratums suggest vastly different times (vast means 10s of millisecs). It simply does not know who to believe, especially if the delay to your local ref clocks (pps and NMEA) are extremely low. NMEA is always a troublesome child. GPS receivers are designed primarily for computing position, not outputting time; that is a very cool side benefit. NMEA outputs often have different latencies depending on constellation in the sky, which trigger more / less complex position computations prior the NMEA outputs. RS232 also suffers from UART delays and a myriad of other weaknesses. Basically NMEA is not a particularly good time source. This is where PPS gets critical.

The best thing you can do to bring your GPS/NMEA into alignment is to apply a fudge in the ntp.conf file. The trick is knowing what fudge to apply. There is a mechanism to override the auto clock selection algorithm which helps determine what fudge to apply. I note you are using the 'prefer' keyword. You can also set the other servers to 'noselect', which means NTP should then settle on your PPS and merely monitor the external pool servers. you can then note the offset and apply it as a fudge to your NMEA data.

Edit your ntp.conf as follows:

Code: Select all

server 127.127.20.0 mode 16 noselect
fudge 127.127.20.0 flag1 1

server 127.127.22.0 iburst prefer
fudge 127.127.22.0 flag1 1

server 0.pool.ntp.org noselect
server 1.pool.ntp.org noselect

once you figure out your local latencies and apply fudges, you can probably remove the noselects.

hope this helps.

[Paul Kennedy]

oops, my isp just changed the IP to http://120.145.202.235
I just tested this and it is working fine. I also enabled port 123, and tested this from a different box.
I need to get with my isp and get a static IP (US$10 extra per month!)

[Paul Kennedy]

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

Hi John, it was yourself. Many thanks. I will order one of these, as they have the correct voltage for pps. pity they do not push out ZDA.

[aquarat]

Hey Paul

Thanks for the explanation... but I'm still having problems. I tried using your ntp.conf suggestions and weird stuff started to happen; NTPd started using the NTP Pool servers, the PPS offsets/jitter data wasn't populated in ntpq -p's output, even after an hour had elapsed. Eventually I removed the NTP Pool servers and restarted NTPd. ntpq -p then started showing the jitter and offset data for both the GPS and PPS. I left it alone, but several hours later the system time had drifted and ntpd still hadn't selected either of the time sources (even though the PPS source was marked as preferred and the NMEA source was marked as noselect).

This is the current ntpq -p output :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            1 l   58   64    7    0.000   -5.297   0.518
xPPS(0)          .PPS.            0 l    1    8  377    0.000   -5.249   0.010

And the corresponding ntp.conf file :

Code: Select all

#NMEA
server 127.127.20.0 mode 16
fudge 127.127.20.0 flag1 1 time2 0.400 stratum 1

#PPS
server 127.127.22.0 minpoll 1 prefer
fudge 127.127.22.0 flag1 1 flag3 1

I tried marking the NMEA source as str1 in the hope that NTPd would pay more attention to it. As you can see, the difference between the two sources is less than a few milliseconds and the jitter on the PPS is excellent. "minpoll 1" is a bit redundant (as the minimum is 3 I think)... it's more for testing.

The ARM's clock drifts surprisingly quickly, since I started writing this post it's drifted by 6ms relative to the PPS. It's probably taken me 5 minutes to write this post.

[aquarat]

I read in the ntp.conf man page that adding "true" to the server line of a source can force it past various protection algorithms so that the source will always be considered for selection (so adding "true" and "prefer" to a source should cause that source to always be selected?).

I added "true" to the PPS source and restarted ntpd. NTPd refused to read the source (wouldn't show offset or jitter). I then tried adding true to the NMEA source (so that both sources had "true" appended). The PPS source retained a "prefer" token.

This is the result :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            1 l   31   64   37    0.000   -5.662   0.493
xPPS(0)          .PPS.            0 l    6    8  377    0.000   -5.807   0.099

And the corresponding ntp.conf file :

Code: Select all

server 127.127.20.0 mode 16 true
fudge 127.127.20.0 flag1 1 time2 0.400 stratum 1

server 127.127.22.0 minpoll 1 true prefer
fudge 127.127.22.0 flag1 1 flag3 1

[Paul Kennedy]

Hi,
I think I can see your issue.

PPS provides a nice pulse, but it does NOT provide the actual time. NTP needs to get that from elsewhere (ie another refclock). you control this with the 'prefer' keyword.

ie

Code: Select all

server 127.127.20.0 mode 16 prefer
fudge 127.127.20.0 flag1 1 time2 0.400

server 127.127.22.0 minpoll 1 
fudge 127.127.22.0 flag1 1 flag3 1

check out Dave's info at:
http://www.eecis.udel.edu/~mills/ntp/ht ... ver22.html

btw, my site should have a stable ip at

http://secondthoughts.no-ip.org/

[aquarat]

Hi Paul

This is the output from an x86 machine running NTPd :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+SHM(0)          .NMEA.           0 l    8   16  377    0.000   20.047   1.267
*SHM(1)          .PPS.            0 l    7   16  377    0.000   -0.002   0.002
+tick.meraka.csi .GPS.            1 u   35   64  377   54.403   12.143   0.624
-tock.meraka.csi .PPS.            1 u   22   64  377   54.402   12.203   0.294

and this is the ntp.conf file :

Code: Select all

server 127.127.28.0 minpoll 4
fudge  127.127.28.0 refid NMEA
server 127.127.28.1 minpoll 4 prefer
fudge  127.127.28.1 refid PPS
server tick.meraka.csir.co.za
server tock.meraka.csir.co.za
server 10.0.0.11

In this configuration the GPS (plus OCXO) connects to the machine through an RS232 port. PPS is provided via the DCD pin. GPSd connects to the GPS and makes both the PPS and the NMEA data available to NTPd.

This configuration has been running for about 4 years now. In this scenario the PPS has been selected as the primary source and the NMEA as a secondary, why won't this same configuration work on the Pi (just with the relevant shm address swapped out) ? (just interested)

Your no-ip site looks cool btw. How did you generate the graph ? A bit unrelated but still involves a Pi and graphs; I've managed to get my Oregon Scientific weather station to work with a Pi : http://41.134.20.29 It's a very basic page, quickly written in nano. I'm logging pressure and temperature on the I2C bus but still have to implement graphing for that.

[Paul Kennedy]

Hi,
this x86 box looks very much like it is using the shared mem driver not the kernel disciplined PPS. GPSD is taking in both the NMEA and PPS pulse from pin1, and populating the shared memory segment. NTP picks them up as sources. you need to specify the prefer keyword to the 127.127.28.1 so NTP knows which one is the actual time. Without this intervention, NTP struggles to make a choice between the 2 shared mem ref clocks. this is because the 'singaround' principle does not work for shared mem (your delay will always be 0.000).

What you might well see is that this machine never agrees particularly well with other clocks. The more layers of software (ie gpsd) you go thru the more instability you will see. a real kernel PPS should beat it hands down.
http://www.eecis.udel.edu/~mills/ntp/ht ... ver28.html
Do to summarise, this is quite a different setup to where you (and I) are going with a pi.

Did you try the settings I suggested?

On the subject of the plots, in installed nginx + php on the pi. I then made a silly little php script to parse the standard ntp loopstats files and pass them to your browser. the html page you see contains the opensource flot plotting tool, which can consume the data I provide, and you get a neat little plot which the user can pan and zoom. not quite excel, but does the job. I will probably limit the data to a week or less to keep things tight.

the tables update with the realtime values every few seconds. I need to make a few more small pages for config, logs etc, then I should have a nice simple interface for 'regular' users. NTP is brilliant, but needs a better UI and a web page seems appropriate.

I would like to get to your stage (GPS and almost pps) asap so I can figure out if we can use these devices as low cost time servers at work where internet sources are not available. I can probably then assist some more. maybe you can document how you patched the kernel for pps?

[aquarat]

Hey Paul

The kernel I'm using was provided by chrisrpt. He uploaded them onto 4shared. I downloaded them and re-uploaded them to my Google Drive (4shared requires that you register and makes you jump through hoops). The files are available here :

Modules : https://docs.google.com/open?id=0B9fzQK ... 184NEgxa00
Kernel : https://docs.google.com/open?id=0B9fzQK ... WtWelAzQm8

The kernel tarball contains a file called "Image", it replaces "kernel.img" in the /boot directory. I moved kernel.img to kernel.img.old so I had a copy.

The modules file can be un-tarred to the root (/).

I thought I had implemented what you suggested but I left some tokens in by mistake... I'll quickly test.

Thanks for the explanation @ x86. I'm trying to move all the major functions away from that particular x86 machine to save power, reduce heat output and to get more time out of my UPSs during power failures (not that they occur often).

-edit-
Here's the result of your suggested config :

Code: Select all

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xGPS_NMEA(0)     .GPS.            0 l   50   64    3    0.000  -10.709   1.875
xPPS(0)          .PPS.            0 l    1    8  377    0.000   -8.577   1.129

It certainly brought the offsets closer together. This is about 2 minutes after startup, so it may still be settling.

[Paul Kennedy]

ok, this is progress. now lets speed it all up. as you have a local clock source, you can poll quicker than 64 secs. on my boxes we poll at a solid 8 secs. do this with minpoll and maxpoll (it is a pwr 2 thing). also set iburst, which polls quickly at startup and settles things faster

i remember some ntp versions limit to 4, but try 3 first

Code: Select all

server 127.127.20.0 mode 16 minpoll 3 maxpoll 3 iburst prefer
fudge 127.127.20.0 flag1 1 time2 0.400

server 127.127.22.0 minpoll 1 
fudge 127.127.22.0 flag1 1 flag3 1

thanks for the kernel links. i will grab them tomorrow. no rush as my cheap gps is not here yet