THIS ARTICLE HAS BEEN DEPRECIATED AND INSTRUCTIONS CONTAINED BELOW NO LONGER WORK WITH LATEST RASPBIAN. HOWEVER GOOD NEWS – ITS MUCH EASIER NOW SEE HERE:
This is an article on making a network attached Stratum 1 NTP Server using a Raspberry Pi+ Model 2 or 3 and the Uputronics Raspberry Pi+ GPS Expansion Board. If you need a standalone ready to go solution or need more performance please consider the LeoNTP Networked Time server unit which is available here.
As of May 2016 this was heavily reworked due to a new version of Raspbian which did all sorts of wonderful things like disabling the serial ports etc. This guide assumes Raspbian Jessie Lite June 2017 2017-06-21. No other version or distribution is supported.
I’ve also removed the off grid/standalone instructions as NTP isn’t designed to work off grid using just the NMEA derived time and PPS to discipline it.
Uputronics Raspberry Pi+ GPS Expansion Board
Ideally rather than supplying a premade image I would have a set of concise instructions on making your own install from scratch so you could use the latest versions of the software. With assistance from David Taylor who did lots of background work on this here I present the following instructions on making a cheap PPS disciplined NTP Time server using one of the Raspberry Pi+ GPS boards sold on Uputronics.
The guide assumes you have a cursory knowledge of Linux, enough to install Raspbian and login should do.
You will need a Raspberry Pi 2 or 3 B+, the Uputronics Raspberry Pi+ GPS Expansion Board and a suitable GPS antenna.
This guide is assuming you’re using Raspbian Jessie Lite installed from the June 2017 image. Download and write this to an SD card (See http://www.raspberrypi.org/documentation/installation/installing-images/README.md). Other distributions may work but these instructions are known to work with Raspbian Jessie Lite.
Attach the Uputronics Raspberry Pi+ GPS Expansion Board to the Pi, insert the SD card, connect the antenna and network cable and boot the Pi up. Either connect locally or via SSH to the Pi. Follow the instructions carefully if you miss steps things won’t work.
Text in italics is what you type.
Text in red indicates editing inside a file.
Prerequisite Settings
sudo raspi-config
5 Interfacing Options
P2 SSH -> Would you like the SSH server to be enabled – YES (Recommended)
P6 Serial -> Login Shell (no) Hardware (yes)
Quit but no need to reboot at this point.
sudo nano /boot/config.txt
Add at the bottom :
# Allow the normal UART pins to work
dtoverlay=pi3-miniuart-bt
dtoverlay=pps-gpio,gpiopin=18
Save and Quit Nano.
sudo apt-get update
sudo apt-get dist-upgrade
sudo systemctl disable hciuart
sudo systemctl mask [email protected]
sudo apt-get install pps-tools
sudo apt-get install libcap-dev
sudo reboot
Verifying PPS Is Working
Ensure the GPS has a lock and the Green PPS LED on the Uputronics Pi+ GPS Expansion Board is blinking once a second.
dmesg | grep pps
Output should be similar to :
[ 2.443494] pps_core: LinuxPPS API ver. 1 registered [ 2.446699] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <[email protected]> [ 2.471796] pps pps0: new PPS source pps.-1 [ 2.471886] pps pps0: Registered IRQ 498 as PPS source [ 6.965166] pps_ldisc: PPS line discipline registered [ 6.966569] pps pps1: new PPS source ttyAMA0 [ 6.966664] pps pps1: source "/dev/ttyAMA0" added
sudo ppstest /dev/pps0
Output should be similar to:
trying PPS source "/dev/pps0" found PPS source "/dev/pps0" ok, found 1 source(s), now start fetching data... source 0 - assert 1418933982.998042450, sequence: 970 - clear 0.000000000, sequence: 0 source 0 - assert 1418933983.998045441, sequence: 971 - clear 0.000000000, sequence: 0
(Press CTRL+C to quit). This indicates the PPS Module is loaded (top example) and is working (bottom).
GPS board mounted in Geaux Robot Dog Bone Case for Raspberry Pi B+ also available from Uputronics
Enabling PPS/ATOM Support in NTPD
The supplied version of NTPD on the Raspberry Pi doesn’t support PPS so we need to recompile it (Please note that some of these steps may take up to 30 minutes).
wget https://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.8p10.tar.gz
tar zxvf ntp-4.2.8p10.tar.gz
cd ntp-4.2.8p10
./configure –enable-lcap
make -j4
sudo make install
sudo service ntp stop
sudo cp /usr/local/bin/ntp* /usr/bin/ && sudo cp /usr/local/sbin/ntp* /usr/sbin/
sudo nano /etc/ntp.conf
Add
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 flag3 1 refid PPS
Amend
server 0.debian.pool.ntp.org iburst prefer
You may also want to add your local lan to so you can query the NTP Server by adding:
restrict 192.168.1.0 mask 255.255.255.0
Note You MUST add a preferred server or PPS doesn’t work. Its worth at this point seeing if you’re ISP has its own NTP server you can use and adding that but for the purposes of this exercise adding prefer to the Debian pool one will do.
Save and close nano.
sudo nano /etc/init.d/ntp
Find the line NTPD_OPTS=”$NTPD_OPTS -u $UGID”
Amend it to say NTPD_OPTS=”$NTPD_OPTS”
sudo systemctl daemon-reload
sudo service ntp restart
After a few minutes run
ntpq –p
if you get oPPS(0) this indicates source selected, Pulse Per Second (PPS) used and everything is working.
If you aren’t seeing the settings its possible the NTP server is picking up the NTP information via DHCP which is over riding your settings above. Do this :
rm /etc/dhcp/dhclient-exit-hooks.d/ntp
rm /var/lib/ntp/ntp.conf.dhcp
At this point you have a NTP server which will use an external time source and use your local PPS to discipline it.
Setting Stationary Mode
Grab this small program code here : https://pastebin.com/YTc9Nd3D
Compile + link:
gcc -o gpsControl gpsControl.c
sudo ./gpsControl -p -d /dev/ttyAMA0 = Portable Mode sudo ./gpsControl -s -d /dev/ttyAMA0 = Stationary Mode
May take a few goes to set it.
pi@hypatia:~ $ sudo ./gpsControl -s -d /dev/ttyAMA0
Set GPS for stationary mode
Configuring device /dev/ttyAMA0
>>>>>>>>>>>>>>>>>>>>> SENDING >>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> SENDING >>>>>>>>>>>>>>>
GPS mode set OK
Static IP + Hostname
If you want to fix your LAN IP you do it by amending /etc/dhcpcd.conf adding the following lines:
interface eth0
static ip_address=192.168.1.7/24
static routers=192.168.1.254
static domain_name_servers=8.8.8.8 8.8.4.4
Amend your hostname by editing /etc/hostname and then adding this to /etc/hosts as well. I.e if you call your machine ‘eleanor’ add this after localhost in /etc/hosts:
127.0.0.1 localhost eleanor
Further Reading
David Taylor’s website here http://satsignal.eu/ntp/Raspberry-Pi-NTP.html goes into much further detail about the process above and covers graphing, remote access monitoring etc and I highly recommend you read it.
References from this draft document by Eric S. Raymond https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/
Hope this helps, let me know how you get on with these instructions and I’ll try keep them up to date.
Thanks to:
David Taylor
Dave Akerman
Chris Stenton for the new kernel fix.
Tris Mabbs for the DHCP issue heads up.
Michiel Kanis for testing DHCP fix.
Phil Heron for the GPSD Autostart fix.
Updated : 27/06/17 Fixed for new June 2017 Raspbian. Updated links to ntp-4.2.8p10.
Updated : 25/05/16 Fixed for Pi3/May Raspbian. Removed Standalone mode (NTP isn’t designed for this)
Updated : 22/03/16 Added Pi3/Standalone etc
Updated : 24/02/16 Added Code to set stationary mode.
Checked : 29/09/15 Works with Raspian Jessie – Thx Ciaran!
Updated : 03/07/15 NTP version and location amended – Thx Greg!
Checked : 13/06/15 Works with 2015-05-05-raspbian-wheezy.img
Updated : 13/04/15 ntp-4.2.8p2.tar.gz links updated.
Updated : 23/02/15 Verified these instructions are good with 2015-02-16-raspbian-wheezy.img as a base
Updated : 20/02/15 ntp-4.2.8p1.tar.gz links updated.
Updated : 28/01/15 DHCP Client can pick up NTP from DHCP server and override all your good work. See below.
Updated : 27/01/15 New kernel breaks previous instructions. Updated.
Updated : 26/12/14 Updated NTP to 4.2.8 and tested with Raspbian 2014-12-14
Okay, I set flag3 to 0 and restarted ntpd and still got the error:
25 May 05:10:33 ntpd[11859]: Listening on routing socket on fd #23 for interface updates
25 May 05:10:35 ntpd[11859]: refclock_params: time_pps_kcbind: Operation not supported
Okay, after a reboot I’m not getting the error with flag3 set to 0. So obviously something wasn’t getting reset on a restart of ntpd.
Hi guys I’ve extensively reworked the HOWTO have a go with it now and see if it works any better. The standalone/off grid setup has been removed as NTP isn’t designed to work like this.
I will consider doing a version of this using Chrony which can work off grid with an NMEA derived single clock.
Eric,
Those drivers will work in either kernel mode or user mode but kernel mode will only work if you recompile the kernel, which I have done. If ntp is running in kernel mode then you’ll see kern in the first line when you do a ‘ntp -crl’ eg:
associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
version=”ntpd [email protected] Fri Apr 29 10:05:19 UTC 2016 (1)”,
If kern isn’t there then it is running in user mode. I’ve noticed that kernel mode appears to have much lower jitter (always 0.000954 after stabilising) and the average offset is lower (almost always < 500ns). The only downside seems to be the frequency adjustment steps up and down rather than being a nice smooth curve. I suspect that the kernel mode doesn't use some of the fancy filtering present in the user mode code in ntp.
Recompiling the kernel is relatively easy, but does take a while to run and you need to redo it every time a new one is issued by the Raspberry Pi project as apt-get update/upgrade will overwrite it. I can post some brief instructions if you want to do it.
Anthony, I’ve taken the new GPS module I received a couple of days ago and a Pi 2 and set it up following your new instructions.
I still get the following error in the logs if flag3 is set to 1 except after a full powercycle:
refclock_params: time_pps_kcbind: Operation not supported
Do you see that error anywhere in your logs?
According to what Greg has posted the PPS driver is user mode and not kernel mode so flag3 should be 0 and not 1. I have debugging and statistics enabled. On a x86_64 system running Centos 7 I have a GPS connected and get the following in the logs when using PPS that I never get in the logs for the two Pi systems:
0.0.0.0 061d 0d kern PPS enable
I don’t even get that in the Pi logs after a full powercycle when I don’t get the error.
Greg, you posted your latest message while I was posting mine.
Here’s what I get with the older Jessie with John’s ntpd package:
root@pi1:~# ntpq -crl
associd=0 status=011d leap_none, sync_pps, 1 event, kern,
version=”ntpd [email protected]-o Fri Oct 16 04:02:28 UTC 2015 (1)”,
Here’s what I get with the latest Jessie and new build:
root@pi2:~# ntpq -crl
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version=”ntpd [email protected]-o Thu May 26 06:01:29 UTC 2016 (1)”,
I’m now going to try the latest Jessie and John’s ntpd package. Unfortunately there’s some issue with it not picking up the pps signal that I need to dig through tomorrow.
I’ve built kernels before but only recently on CentOS systems and I figure it’s different on Raspian so I’d appreciate the instructions.
I had an idea to change flag3 to 0 and now John’s ntpd package is working on the latest Jessie, and of course it’s not using kernel mode drivers:
root@pi2:/etc# ntpq -crl
associd=0 status=0114 leap_none, sync_pps, 1 event, freq_mode,
version=”ntpd [email protected]-o Fri Oct 16 04:02:28 UTC 2015 (1)”,
I don’t know why it didn’t fall back to user mode like normal.
Eric, Here’s the quick summary:
Navigate to General Setup –> Timers Subsystem
Disable/Uncheck [ ] Old Idle Dynticks config
Select Exit twice to get back to the top level then
Device Drivers –> PPS Support
Enable/Check [*] PPS kernel consumer support
Exit to go back to Device Drivers then select GPIO Support
Enable/Check Generic memory-mapped GPIO controller support (MMIO platform)
Save and Exit
This next command takes a long time…
If you have ‘flag3 1’ in your ntp.conf file then everything should be running in kernel mode when it reboots.
Thanks, Greg! I’ll give it a try later tonight.
Thanks, Greg, it worked:
root@pi2:~# dmesg | grep pps
[ 3.898159] pps_core: LinuxPPS API ver. 1 registered
[ 3.898182] pps_core: Software ver. 5.3.6 – Copyright 2005-2007 Rodolfo Giometti
[ 3.915407] pps pps0: new PPS source pps.-1
[ 3.915477] pps pps0: Registered IRQ 184 as PPS source
[ 14.156835] pps pps0: bound kernel consumer: edge=0x1
[ 16.095228] hardpps: PPSJITTER: jitter=799116, limit=0
root@pi2:~# ntpq -crv
associd=0 status=061d leap_none, sync_ntp, 1 event, kern,
version=”ntpd [email protected]-o Thu May 26 06:01:29 UTC 2016 (1)”,
processor=”armv7l”, system=”Linux/4.4.11-v7+”, leap=00, stratum=2,
precision=-20, rootdelay=3.485, rootdisp=2.565, refid=192.94.152.25,
reftime=daf51019.10e9bb92 Sun, May 29 2016 1:52:09.066,
clock=daf5102e.617f94b1 Sun, May 29 2016 1:52:30.380, peer=39578, tc=6,
mintc=3, offset=-0.108164, frequency=-6.744, sys_jitter=0.197250,
clk_jitter=0.004, clk_wander=0.204
What didn’t work is building the kernel on one Pi and then copying everything over to another. I’ll have to research that.
Eric,
Great!
I haven’t tried the the build local/copy to remote process. I’m not sure why it wouldn’t work. Assume they were the same RPi version?
Greg
The build Pi was a Pi 2 and the other Pi was a Pi 3. I thought the kernel was the same for the two.
I have one Pi 2 and one Pi 3 with the GPS modules and a separate Pi 2 that has Jessie running to use for builds. If the kernels are different then I need to replace the Pi 3 with a Pi 2 I have spare. I grabbed the Pi 3 by mistake but decided it wasn’t worth it to change it for the Pi 2.
On a related topic, my CentOS 7 x86_64 system I mentioned earlier that’s been running for three months with the kernel mode PPS driver suddenly decided it would only work in user model after I had to power cycle the GPS to move it, so it appears that kernel mode PPS support can be picky no matter what the platform.
why build a stratum 1 gps-pps based server, and then recommend pool.ntp.org as reference which tends to be stratum 2 and 3 ❓ not primary time sources. There are plenty of lists of publicly available stratum 1 servers.
Hi James,
“Exercise left to the reader” which is a cop out but my instructions were meant to be a very basic howto get PPS discipline. Past this point I fully agree you want to be picking public stratum 1 servers in your local region of which there are quite a few. If you’re in europe try ntp1.leontp.org. Most good ISP’s also run their own stratum 1/2 servers mail their support and ask.
I’m puzzled why one should use ntpd+gpsd to achieve what can be done with ntpd alone. Ntpd reference clock 20 combines NMEA and PPS processing, even with kernel pps consumer support. I fail to get the point of adding an extra component (gpsd) to achieve the same goal.
Hi Jan,
Copied from http://www.catb.org/esr/faqs/stratum-1-microserver-howto/
Why GPSD?
If you are already familar with ntpd and wonder why this recipe uses gpsd through SHM rather than ntpd’s native refclock 20 GPS driver, the answer is this: when refclock 20 is configured to use 1PPS, it mixes in-band time data with 1PPS in a way that causes it to behave badly, and possibly get rejected as a falseticker, when 1PPS is only occasionally available.
Cheers
Hi Anthony,
one could use type 22 PPS and 20 NMEA separately then, if there is any doubt in the PPS signal availabillity. PPS can be disabled on type 20, in fact it is off as default. Would make a nice addition, even if only used for monitoring. But your recipe of using just type 22 PPS and public NTP servers is probaly the best idea as an introduction point. Slapping in GPSD is only adding unnecessary complexity. But hey that’s what people like today I guess. 😉 BTW thanks for your effort and this nice guide. 🙂
Just my two cents,
Jan
HI,
My install seems to have come unstuck in the “Enabling PPS/ATOM Support in NTPD” section.
Here is the relevant section of the output log.
ntp-4.2.8p7/bincheck.mf
pi@raspberrypi:~$ cd ntp-4.2.8p7
pi@raspberrypi:~/ntp-4.2.8p7$ ./configure –enable-linuxcap
configure: WARNING: you should use –build, –host, –target
configure: WARNING: invalid host type: –enable-linuxcap
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
/home/pi/ntp-4.2.8p7/sntp/libevent/build-aux/missing: Unknown `–is-lightweight’ option
Try `/home/pi/ntp-4.2.8p7/sntp/libevent/build-aux/missing –help’ for more information
configure: WARNING: ‘missing’ script is too old or missing
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for gawk… no
checking for mawk… mawk
checking whether make sets $(MAKE)… yes
checking whether make supports nested variables… yes
checking whether make supports nested variables… (cached) yes
checking build system type… Invalid configuration `–enable-linuxcap’: machine `–enable’ not recognized
configure: error: /bin/bash sntp/libevent/build-aux/config.sub –enable-linuxcap failed
pi@raspberrypi:~/ntp-4.2.8p7$
pi@raspberrypi:~/ntp-4.2.8p7$ make -j4
make: *** No targets specified and no makefile found. Stop.
pi@raspberrypi:~/ntp-4.2.8p7$
Any idea what may be going wrong?
thanks
Bruce.
Hi, I think I may have figured out what was wrong.
In the instructions it says
./configure –enable-linuxcap
But I think the correct command is
./configure –enable-linuxcaps
right?
Correct I’ll fix the instructions.
Me again. Feel free to delete the previous posts which are still awaiting moderation… and delete this section of this post.
I was unable to get the ntpq -p and ntpq -crv commands to show a working NTP until I connected the Raspberry Pi to the Internet. Is it possible to get it working on a local network that does not have an internet connection?
Thanks,
Bruce
Hi Bruce,
Sorry about the delays in responding just on paternity at the moment and spending lots of time changing nappies.
NTP isn’t designed to work “standalone” it is designed to work on net with multiple time sources hence me removing the instructions on making it standalone. The fix is have multiple Raspberry Pi NTP servers synchronising with each other. If you need a reference clock we are working on a standalone unit which derives its time from GPS and works as a clock reference. Its going to be about £250 which is more expensive that the Pi based solution but the performance is a factor of 10 better on accuracy and it can handle 50 times the number of requests per second of a Pi : http://www.leontp.com/
https://www.dropbox.com/s/npknzlp9dkzcsgy/quickspecs_flyer.pdf?dl=0
Let me know if this is of interest.
The LeoNTP looks like a nifty device. Unfortunately a bit out of my price range for home.
I buy it, but when is UBOX 7 and by default is set to use only GLONASS
How to disable GLONASS and enable US GPS, My external Antenna is made for US GPS, and to much narow to use GLONASS sub channel and only see 1 Sat or MAX 3. like with GPS control should be cool!
Thank you!
d/.
I’m not sure which Ublox 7 you managed to get but by default they are GPS only. They can do GLONASS but they can’t do GPS and GLONASS at the same time. The Ublox 8 can do, and default to, concurrent GPS and GLONASS. You can control this via the CFG-GNSS command see :
https://www.u-blox.com/sites/default/files/products/documents/u-blox7-V14_ReceiverDescrProtSpec_(GPS.G7-SW-12001)_Public.pdf
Page 3.
There is an Arduino example on how to switch to GPS mode only here:
https://github.com/HABduino/HABduino/blob/master/Software/habduino_v4/habduino_v4.ino#L477-L496
Cheers
For static IP, it’s not necessary to use dhcpd.conf.
The easier way (which also supports IPv6) is to modify
/etc/network/interfaces.Here’s a sample (I removed the code for vlan and wwlan config, which doesn’t change):
Your addresses will, of course, vary.
I note the changes and comments regarding running in standalone mode. I am using a device I configured a while back using your previous instructions – standalone mode. Will I see or have any issues? So far (over a year) it seems fine as far as I can tell.
Thanks
Good question and I’m not sure. NTP isn’t designed to work without peers so I just removed it. I’d be interested to see how far (or not) your unit is out. Can you connect it to the internet ? I understand Chrony does work standalone.
Anthony, look RFC1305, where “NTP isn’t designed to work without peers”???
RFC1305 Network Configurations
“The synchronization subnet is a connected network of primary and secondary time servers, clients and interconnecting transmission paths. A primary time server is directly synchronized to a primary reference source, usually a radio clock. A secondary time server derives synchronization, possibly via other secondary servers, from a primary server over network paths possibly shared with other services. Under
normal circumstances it is intended that the synchronization subnet of primary and secondary servers assumes a hierarchical-master-slave configuration with the primary servers at the root and secondary servers of decreasing accuracy at successive levels toward the leaves.”
Ok, this document about NTPv3 🙂
Open RFC 5905 and read – “NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305”
Is my standalone (without peer) server with you NTP Board and GPS Antenna
Hi Alex,
The algorithm in NTPd is designed to fine tune the time based on multiple sources, it isn’t currently designed or optimized to work standalone. I understand there is some work going on in NTPSec to address this autonomous mode but at the moment it may be worth checking out Chrony. This is not to say it won’t work, your example proves this but that its not advised and may not give the true time when referenced to an external source.
Ok, is my second NTP server Cisco, first in list – RaspbNTP (without internet), second and third – government NTP servers, yes, 300 not perfect to run Trident missile, launch James Webb, but perfect for home and business use 😛
Hello,
Got the Uputronics GPS board installed and configured on my Pi 3 and it’s working great. I have a couple of questions though. I got the setup to work with the 20 driver and it’s working, and I managed to upgrade my NTP version to the new NTPSEC and keeping the driver, THAT works. What I’ve not been able to get working is the “feeding data from GPSD to NTPD” solution. I can’t seem to get GPSD to be happy, it bombs out saying the IPv4 port is in use. I built GPSD from source (v 3.16), the docs claim it should go figure things out automatically, but that rarely seems to be the case with Linux.
Just curious if anybody else has made this work?
Just wanted to thank you for writing up this guide. I got my Pi 3 running well with the Uptronics board. I really wanted to get seconds from the serial line of the GPS – but I just could not get GPSD to cooperate, so I sync with a few Stratum-1’s in the area. My offset with just S1’s was within 2ms, so I am certainly always on the right second. Having a GPS antenna providing me PPS signals has improved my offset to a 50us window, and I love it! Thank you so much.
Oh, another comment. Raspbian has moved on to the Jan 2017 build now. I could not get any of the ntpd builds to compile with ATOM support. However, I was able to get ntpsec 0.9.6 to build on the pi, so that is what I am using.
Thanks Michael,
I’ll review the instructions with regards to Raspbian. I was going to move over to NTPSec anyway so now is as good a time as any.
Cheers
Last Raspbian (12.03.2017 update) & ATOM – work fine )
So I got it working, thanks for the great guide. But my Windows server (running the Meinberg NTP daemon and monitoring tools) seems to be showing a +1ms offset, I was expecting it to be better than this. Have I done something wrong? 192.168.0.6 is my Raspberry Pi stratum 1 server.
C:\Users\Paul>ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 12 l 71h 64 0 0.000 0.000 0.000
-192.168.0.20 85.199.214.100 2 u 67 128 377 0.977 -1.352 0.977
*192.168.0.6 .PPS. 1 u 430 1024 377 0.977 1.024 2.146
-80.87.131.131 80.87.128.222 4 u 221 128 376 30.859 -3.138 0.977
-217.114.59.3 33.117.170.50 2 u 180 128 356 24.957 -2.115 0.977
+178.79.162.34 133.150.251.233 3 u 169 128 176 18.918 -2.329 0.977
-51.15.2.109 131.211.8.244 2 u 61 128 365 25.946 -3.685 0.977
+83.162.251.163 .GPS. 1 u 7 64 371 28.994 -2.504 17.321
Hi Alex,
Do you mind to share your system details and instruction guide to achieving 1-microsecond accuracy?
Do I need to have the kernel build to achieve that accuracy?
I am trying to compile a kernel with kernel PPS. The current kernel is 4.9.y, a few version above Greg Siemon instructions (he used 4.4.y)
On make menuconfig there is no PPS kernel consumer support on 4.9.
Any clue on how to compile/enable kernel pps on this version?
Or should we just use 4.4?
Claudio, I noticed that too. Without that option you can’t enable PPS in the kernel. I tried to add the compiler flags for PPS Kernel Consumer Support manually but It didn’t seem to work (Kernel compiled OK but no PPS Kernel Support). I haven’t had time troubleshoot beyond that yet. If you manage to figure it out please let me know.
Greg
This has changed in recent raspbian.
sudo raspi-config
Advanced Options -> Serial -> Would you like a login shell to be accessible over serial? -> Yes
Quit but no need to reboot at this point.
to
sudo raspi-config
5 Interfacing Options -> P6 Serial
Would you like a login shell to be accessible over serial? -> No
Would you like the serial port hardware to be enabled? -> Yes
And if you wonder why your gpsd wont start automatically, try this:
sudo ln -s /lib/systemd/system/gpsd.service /etc/systemd/system/multi-user.target.wants/
on recent raspbian, of course.
NTP not work witch last kernel-
And to get rid of the 200ms jitter from the PPS kernel driver I’ve had to set this kernel option:
CONFIG_NO_HZ=y
and recompile the kernel.
oPPS(0) .PPS. 0 l 15 16 377 0.000 0.003 0.004
it’s now stable at 4ms jitter instead of 200+ms
I’m stuck:
First of all I could not for the life of me find the version of Jessie you want us to use…..so Im using the latest Jessie Pixel….(most likely source of my problem) which is:
pi@sat-1:~ $ cd ntp-4.2.8p7
pi@sat-1:~/ntp-4.2.8p7 $ ./configure –enable-linuxcaps
configure: WARNING: you should use –build, –host, –target
configure: WARNING: invalid host type: –enable-linuxcaps
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
/home/pi/ntp-4.2.8p7/sntp/libevent/build-aux/missing: Unknown `–is-lightweight’ option
Try `/home/pi/ntp-4.2.8p7/sntp/libevent/build-aux/missing –help’ for more information
configure: WARNING: ‘missing’ script is too old or missing
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for gawk… no
checking for mawk… mawk
checking whether make sets $(MAKE)… yes
checking whether make supports nested variables… yes
checking whether make supports nested variables… (cached) yes
checking build system type… Invalid configuration `–enable-linuxcaps’: machine `–enable’ not recognized
configure: error: /bin/bash sntp/libevent/build-aux/config.sub –enable-linuxcaps failed
pi@sat-1:~/ntp-4.2.8p7 $ make -j4
make: *** No targets specified and no makefile found. Stop.
./configure -enable-lcap
Revised with latest Raspbian all working fine.
The stock build of Raspbian seems to result in a very low PPS jitter around what you have there. I’m not sure how you managed to get it up to 200ms ! I did try recompile the kernel but it ended up marking the PPS as a bad ticker so just left it with the stock one. This is the result of redoing that article today :
Had no problem following the instructions here and have turned my redundant Rpi2 into a stratum 1 time server with the uputronics GPS hat.
When I go the job done I thought the solution was odd. Only using the PPS from the ublox receiver and ignoring the local NMEA in favour of time from another NTP server. I read the comments about “Why GPSD” and took that to mean there’s a serious bug in the generic NMEA driver (type 20) in NTPD.
I decided to play….
I disabled the type 22 driver
#server 127.127.22.0 minpoll 4 maxpoll 4
#fudge 127.127.22.0 flag3 1 refid PPS
and enabled the type 20 driver
server 127.127.20.0 mode 0x10 minpoll 4 maxpoll 4
fudge 127.127.20.0 flag1 1
To work this also required a couple of symbolic links in /dev
gps0 -> ttyAMA0
gpspps0 -> pps0
Restart the NTPD and all seems to be well. After a few minutes I got the magic ‘o’ next to ‘GPS_NMEA(0)’.
I left it for a few hours and it settled down to 2 microseconds jitter.
Seems good to me!