[time-nuts] Raspberry PI 3 NTP server with GPS time data.

Nick Sayer nsayer at kfu.com
Sun Apr 24 23:47:51 EDT 2016


In my own experience, using the PA6H (AdaFruit) with GPSD as an NTP source doesn’t work. By contrast, the PPS using the kernel module PPS timestamp driver works exceptionally well.

The issue with gpsd with this module is that the time reported in the NMEA sentences always has 0s for the sub-second digits of the time, but the sentences aren’t synchronized to the second or anything, so they’re all over the place. In principle, the sentences and PPS in concert gives you accurate time, but so far as I can tell, NTP isn’t plumbed to get *just* the seconds from NMEA and merge that with PPS to make a single source.

What that meant for me was that it was far more reliable to “bootstrap” ntpd using external servers and use only the kernel based PPS stuff to sync to GPS.

My own config is

pool us.pool.ntp.org iburst prefer

server 127.127.22.0
fudge 127.127.22.0 refid PPS
fudge 127.127.22.0 flag3 1 # enable kernel PLL/FLL clock discipline

At start, the PPS is ignored until NTPD gets a lock on an external server. At that point, it switches over to using PPS and becomes stratum 1. The result is as good an NTP server as you’re going to get with a Raspberry Pi (given it’s using a USB based Ethernet controller and the rest of the limitations of the platform).


> On Apr 24, 2016, at 4:15 PM, Chris Albertson <albertson.chris at gmail.com> wrote:
> 
> Did you see the notice on the adafruit 2324 web page that reads "Does
> not work with the Pi 3 at this time".
> 
> OK assume they have fixed the problem...
> 
> Try using the #20 reference clock.  It works with any generic GPS that
> outputs NMEA sentences and PPS.  Set the Flag1 to enable PPS.
> 
> What you have now is TWO clocks, one is the GPS via "gpsd" and the
> shared memory and the other is the PPS and I bet they don't exactly
> match.  Better to have one reference clock and that is the
> 127.127.20.0 type clack.
> 
> What is happening is that the NMEA standard only requires the NMEA
> sentences to be output during the second to which they apply.  So the
> time is only accurate to within a second. Compared to any other clock
> the NMEA-only GPS can be very poor.
> 
> GPS is one of the best reference clocks for NTP.  I'd use it as a
> first choice unless for some reason you can't (for example you have no
> way to install an antenna.)
> 
> 
> On Sun, Apr 24, 2016 at 11:51 AM, jan hugo prins <jhp at jhprins.org> wrote:
>> Hi,
>> 
>> To get a more stable NTP source into our production network I have
>> started exprerimenting with a Raspberry PI 3 with a GPS head. GPS data
>> is coming in fine, but the time is jumping around like a wild horse. The
>> result is that the only thing I get out of this experiment so far is a
>> more stable PPS signal in my NTP config but after some time both the GPS
>> time and the PPS are marked a false ticker and the only thing left is
>> the external reference clocks from outside our own network.
>> 
>> Parts used:
>> Raspberry PI 3
>> Adafruit GPS head: ADA-2324
>> External GPS antenna with 5 meter cable.
>> 
>> My NTP config looks like this:
>> 
>> logfile /var/log/ntpd.log
>> logconfig = all
>> driftfile /var/lib/ntp/ntp.drift
>> statsdir /var/log/ntpstats/
>> statistics loopstats peerstats clockstats
>> filegen loopstats file loopstats type day enable
>> filegen peerstats file peerstats type day enable
>> filegen clockstats file clockstats type day enable
>> server 127.127.22.0 minpoll 4 maxpoll 4 prefer
>> fudge 127.127.22.0 refid PPS flag3 1
>> server 127.127.28.0 minpoll 4 maxpoll 4 iburst
>> fudge 127.127.28.0 refid GPS time1 +0.550 flag1 1 stratum 4
>> server ntp0.nl.uu.net
>> server chime6.surfnet.nl
>> server chime5.surfnet.nl
>> server ntp1.virtu.nl
>> 
>> Now I got the idea that I might be able to use a DCF77 receiver to get a
>> stable timesource, but on the other hand, if the cause of my problem is
>> internal to the Raspberry PI setup then I might have exactly the same
>> problem with the DCF77 receiver.
>> 
>> The average on the NTP clocksource is close to 0.
>> root at raspberrypi:/var/log/ntpstats# cat peerstats |grep 127.127.28.0
>> |awk '{print $5}'| tail -n 1500 | awk 'NR == 1 { max=$1; min=$1; sum=0 }
>> { if ($1>max) max=$1; if ($1<min) min=$1; sum+=$1;} END {printf "Min:
>> %d\tMax: %d\tAverage: %f\n", min, max, sum/NR}'
>> Min: 0    Max: 0    Average: 0.001101
>> 
>> Could anyone give me some advice on how to get this working? Or is my
>> idea to use a GPS clock to create a stable NTP setup the wrong way to go?
>> 
>> Thanks for any advice.
>> Jan Hugo Prins
>> 
>> 
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



More information about the time-nuts mailing list