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

[albertson . chris]

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



> On Apr 24, 2016, at 8:47 PM, Nick Sayer via time-nuts  
> wrote:
> 
> 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  
>> 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  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@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>> %d\tMax: %d\tAverage: %f\n", min, max, sum/NR}'
>>> Min: 0Max: 0Average: 

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

[Orin Eman]

On Sun, Apr 24, 2016 at 4:15 PM, Chris Albertson 
wrote:

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

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

[Mike Cook]

> Le 24 avr. 2016 à 20:51, jan hugo prins  a écrit :
> 
> 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

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.

> 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@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 %d\tMax: %d\tAverage: %f\n", min, max, sum/NR}'
> Min: 0Max: 0Average: 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@febo.com
> 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-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[David J Taylor]

-Original Message- 
From: jan hugo prins

Sent: Sunday, April 24, 2016 7:51 PM
To: time-nuts@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.
root@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

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

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


> On Apr 24, 2016, at 4:15 PM, Chris Albertson  
> 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  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@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> %d\tMax: %d\tAverage: %f\n", min, max, sum/NR}'
>> Min: 0Max: 0Average: 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@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@febo.com
> To unsubscribe, go to 

Re: [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  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@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 %d\tMax: %d\tAverage: %f\n", min, max, sum/NR}'
> Min: 0Max: 0Average: 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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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

[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


On 4/24/2016 2:51 PM, jan hugo prins 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@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