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

[jan hugo prins]

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.
***@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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Artek Manuals]

Jan

IS the GPS antenna "outside" with a clear view of the sky say at least
down to 20 degrees elevation or is it "inside" the building?

Dave

Post by jan hugo prins
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.
Raspberry PI 3
Adafruit GPS head: ADA-2324
External GPS antenna with 5 meter cable.
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.
|awk '{print $5}'| tail -n 1500 | awk 'NR == 1 { max=$1; min=$1; sum=0 }
%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

--
Dave
***@ArtekManuals.com
www.ArtekManuals.com

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[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.)

Post by jan hugo prins
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.
Raspberry PI 3
Adafruit GPS head: ADA-2324
External GPS antenna with 5 meter cable.
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.
|awk '{print $5}'| tail -n 1500 | awk 'NR == 1 { max=$1; min=$1; sum=0 }
%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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Nick Sayer via time-nuts]

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).

Post by 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.)

Post by jan hugo prins
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.
Raspberry PI 3
Adafruit GPS head: ADA-2324
External GPS antenna with 5 meter cable.
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.
|awk '{print $5}'| tail -n 1500 | awk 'NR == 1 { max=$1; min=$1; sum=0 }
%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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

--
Chris Albertson
Redondo Beach, California
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[a***@gmail.com]

NMEA spec says only that seconds in the sentence need to apply the second in which they appear this means there could be half or even full second error they need not be synchronized with the second tick.

Most GPS receivers do better then the standard that they don't have to

The generic NMEA GPS driver knows about this standard and does the right thing using to reference clocks one for TPS one for GPS cereal they don't coordinate

Post by Nick Sayer via time-nuts
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).

Post by 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.)

Post by jan hugo prins
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.
Raspberry PI 3
Adafruit GPS head: ADA-2324
External GPS antenna with 5 meter cable.
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.
|awk '{print $5}'| tail -n 1500 | awk 'NR == 1 { max=$1; min=$1; sum=0 }
%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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

--
Chris Albertson
Redondo Beach, California
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Orin Eman]

Post by 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".

I would assume that's because the Pi3 uses /dev/ttyAMA0 for Bluetooth.
Here is how to route ttyAMA0 back to the IO pins on the Pi3. It is useful
information for any device trying to use ttyAMA0 on the Pi3.

Remove all references to ttyAMA0 from /boot/cmdline.txt (as on a Pi2)

To disable bluetooth:

systemctl disable hciuart
Add "dtoverlay=pi3-disable-bt" to /boot/config.txt

Finally, perhaps unnecessary, use raspi-config to disable login on the
serial port. (Serial under Advanced Options.)

The above worked for me porting code that worked over ttyAMA0 on the Pi2 to
the Pi3.

It was a poor decision IMO to usurp ttyAMA0 for Bluetooth on the Pi3. They
broke just about every device that uses serial IO out there. By default,
they now route the IO pins to /dev/ttyS0 which is useless for most purposes
_as its baud rate depends on CPU core frequency, which is variable_!
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[David J Taylor]

-----Original Message-----
From: jan hugo prins
Sent: Sunday, April 24, 2016 7:51 PM
To: time-***@febo.com
Subject: [time-nuts] Raspberry PI 3 NTP server with GPS time data.

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.
***@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
===================================

Jan Hugo,

I wrote up some notes on using a GPS/PPS source with the Raspberry Pi,
including the RPi-3 here:

http://www.satsignal.eu/ntp/Raspberry-Pi-quickstart.html

You can certainly get good enough performance if your antenna provides a
good view of the GPS satellites, as shown in the plots here (all RPi-3):

http://www.satsignal.eu/mrtg/raspi11_ntp.html
http://www.satsignal.eu/mrtg/raspi12_ntp.html
http://www.satsignal.eu/mrtg/raspi13_ntp.html
http://www.satsignal.eu/mrtg/raspi14_ntp.html

and in summary here:

http://www.satsignal.eu/mrtg/performance_ntp.php

Note that the sudden changes around 12 UTC and RasPi-11 and -12 are due to
them being on an open bench which became sunlit around that time. For best
performance, an unheated cupboard is recommended. All these have a puck
antenna, indoors, but placed as near to a wall or window as possible. You
can see the number of available and used GPS satellites here:

http://www.satsignal.eu/mrtg/performance_gps.php

so temperature is the prime cause of the drift, not lack of satellites in
view. As you can see +/- 20 microseconds is relatively easy to achieve.
The RPi-3 can serve thousands of clients.

I use this GPS:

https://store.uputronics.com/index.php?route=product/product&path=60_64&product_id=81

which has the respected ublox MAX M8Q module.

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-***@blueyonder.co.uk
Twitter: @gm8arv

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[Mike Cook]

Post by jan hugo prins
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.
Raspberry PI 3
Adafruit GPS head: ADA-2324
External GPS antenna with 5 meter cable.
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

Your preferred server is just giving you the PPS. With this ref clock you need a preferred server which names the second. So you should move the prefer directive to either your shared memory source , or another local or remote server.

Post by jan hugo prins
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.
|awk '{print $5}'| tail -n 1500 | awk 'NR == 1 { max=$1; min=$1; sum=0 }
%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
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

"The main function of a modern police force is filling in forms."
_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.