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

[Chris Albertson]

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