fidaforever
Posts: 14
Joined: Tue Mar 21, 2017 8:33 am

How to lock GPS (with pps) in Rpi!

Tue Jul 18, 2017 12:58 am

Hi,
I understand there are two daemons (ntp and chrony, along with gpsd) that can be used to lock (fix) GPS (along with pps for precise time) in linux based Rpi. Is there have any other ways to lock a GPS with Rpi?
In case of ntp, it performs some adjustment complex computation to furnishing time which is not controllable. Therefore, I just want to get rid of it by using some other ways to lock time from GPS.

Any idea would be greatly appreciated.

mfa298
Posts: 1386
Joined: Tue Apr 22, 2014 11:18 am

Re: How to lock GPS (with pps) in Rpi!

Tue Jul 18, 2017 9:14 am

fidaforever wrote:Hi,
I understand there are two daemons (ntp and chrony, along with gpsd) that can be used to lock (fix) GPS (along with pps for precise time) in linux based Rpi. Is there have any other ways to lock a GPS with Rpi?
In case of ntp, it performs some adjustment complex computation to furnishing time which is not controllable. Therefore, I just want to get rid of it by using some other ways to lock time from GPS.

Any idea would be greatly appreciated.
AIUI you need the pps pin from the gps to get the accurate timing for when a second starts, the gps itself will spit out the time information (and lots of other stuff) over the serial port but there's nothing in that data stream to say when the second started or how long the data might be buffered for.

NTP is a standard protocol for syncronising time around a set of machines, with an ntp service it can either get it's time from other machines (most common method) or be connected to a true source of time (like a gps), each device taking part in ntp will have a stratum value which is a measure of how close it is to a true time source.

It's not entirely clear what your trying to achieve or want to know so I'm not sure if that fairly generic information is going to be of much help.

gordon77
Posts: 6885
Joined: Sun Aug 05, 2012 3:12 pm

Re: How to lock GPS (with pps) in Rpi!

Tue Jul 18, 2017 9:23 am

What are you trying to lock to the GPS ? Are you trying to set the time on the Pi ?

Here's an example in python to set the time from GPS...

https://www.raspberrypi.org/forums/view ... ps#p748408

beta-tester
Posts: 1554
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: How to lock GPS (with pps) in Rpi!

Tue Jul 18, 2017 10:44 am

i don't understand exactly what you want.
do you have trouble with ntp and gps to get the time?

i use NTP, but the default ntp of raspbian jessie is not compiled with pps option for some reason. (i hope it will be in the new upcoming raspbian stretch).
take a look to my Stratum One project at github.

Code: Select all

$ ntpstat; ntpq -p -crv;

synchronised to atomic clock at stratum 1
   time correct to within 1 ms
   polling server every 8 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l    2    8  377    0.000    0.005   0.002
*SHM(0)          .NMEA.           0 l   12   16  377    0.000   -9.894  34.173
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd 4.2.8p10@1.3728-o Mon Jun 12 16:45:04 UTC 2017 (1)",
processor="armv6l", system="Linux/4.9.35+", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=1.015, refid=PPS,
reftime=dd1863ad.8a0988d9  Tue, Jul 18 2017 10:38:37.539,
clock=dd1863af.1a8c5dda  Tue, Jul 18 2017 10:38:39.103, peer=13964, tc=3,
mintc=3, offset=0.004875, frequency=-20.377, sys_jitter=0.001948,
clk_jitter=0.003, clk_wander=0.002

Code: Select all

$ cgps;

┌───────────────────────────────────────────┐┌─────────────────────────────────┐
│    Time:       2017-07-18T10:38:41.000Z   ││PRN:   Elev:  Azim:  SNR:  Used: │
│    Latitude:    ###########               ││ ###    ##    ###    ##      Y   │
│    Longitude:   ###########               ││ ###    ##    ###    ##      Y   │
│    Altitude:   #######                    ││ ###    ##    ###    ##      Y   │
│    Speed:      #######                    ││ ###    ##    ###    ##      Y   │
│    Heading:    ######## (true)            ││ ###    ##    ###    ##      Y   │
│    Climb:      ### m/min                  ││ ###    ##    ###    ##      Y   │
│    Status:     3D FIX (#######)           ││ ###    ##    ###    ##      Y   │
│    Longitude Err:   +/- # m               ││ ###    ##    ###    ##      Y   │
│    Latitude Err:    +/- ## m              ││ ###    ##    ###    00      N   │
│    Altitude Err:    +/- ## m              ││ ###    ##    ###    00      N   │
│    Course Err:      n/a                   ││ ###    ##    ###    00      N   │
│    Speed Err:       +/- ## kph            ││ ###    ##    ###    00      N   │
│    Time offset:     #####                 ││ ###    ##    ###    00      N   │
│    Grid Square:     ######                ││                                 │
└───────────────────────────────────────────┘└─────────────────────────────────┘
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

fidaforever
Posts: 14
Joined: Tue Mar 21, 2017 8:33 am

Re: How to lock GPS (with pps) in Rpi!

Sun Jul 23, 2017 11:50 pm

AIUI you need the pps pin from the gps to get the accurate timing for when a second starts, the gps itself will spit out the time information (and lots of other stuff) over the serial port but there's nothing in that data stream to say when the second started or how long the data might be buffered for.

NTP is a standard protocol for syncronising time around a set of machines, with an ntp service it can either get it's time from other machines (most common method) or be connected to a true source of time (like a gps), each device taking part in ntp will have a stratum value which is a measure of how close it is to a true time source.

It's not entirely clear what your trying to achieve or want to know so I'm not sure if that fairly generic information is going to be of much help.[/quote]


Hi,
You are right. This is the principle technique of NTP to attain time into the system. My primary objective is to synchronize my system with GPS, and only, for this reason, I wanted to use NTP. So, NTP is able to fetch servers both from the networks, and/or refclock from GPS. So, I am keen only on GPS as a source and I don't bother other modules of NTP to play any part essentially.
Moreover, NTP performs some adjustment calculation by creating feedback paths to attain stability and accuracy. Sometimes this calculation puts additional adjustment times that are not the actual time.
Primarily I made little experiments where I sync two systems with GPS. I used NTP daemon which says individually each of them is synchronized at an accuracy of 1 micro second with UTC, however, when I compare them I found they are 30 micro sec apart from each other. But if both of them were 1 micro synch with UTC, there offset should be in a range of 2 micro, not 30 micro. It implies that NTP puts some additional adjustment ticks which need to be stopped.
Therefore, I was wondering whether there have any other daemons that only help to bind GPS-PPS with the system and will not do any excessive works on it.
Thanks.

fidaforever
Posts: 14
Joined: Tue Mar 21, 2017 8:33 am

Re: How to lock GPS (with pps) in Rpi!

Mon Jul 24, 2017 12:20 am

gordon77 wrote:What are you trying to lock to the GPS ? Are you trying to set the time on the Pi ?

Here's an example in python to set the time from GPS...

https://www.raspberrypi.org/forums/view ... ps#p748408
Hi Gordon,
This is an interesting development. Do you think along with NMEA through serial port whether it is possible to lock PPS from GPIO pin to attain more accuracy?
Is there have any code/direct for that?

Regards,
Fida

fidaforever
Posts: 14
Joined: Tue Mar 21, 2017 8:33 am

Re: How to lock GPS (with pps) in Rpi!

Mon Jul 24, 2017 12:29 am

Thanks everyone.
Last edited by fidaforever on Mon Jul 24, 2017 3:36 am, edited 1 time in total.

fidaforever
Posts: 14
Joined: Tue Mar 21, 2017 8:33 am

Re: How to lock GPS (with pps) in Rpi!

Mon Jul 24, 2017 3:35 am

beta-tester wrote:i don't understand exactly what you want.
do you have trouble with ntp and gps to get the time?

i use NTP, but the default ntp of raspbian jessie is not compiled with pps option for some reason. (i hope it will be in the new upcoming raspbian stretch).
take a look to my Stratum One project at github.

Code: Select all

$ ntpstat; ntpq -p -crv;

synchronised to atomic clock at stratum 1
   time correct to within 1 ms
   polling server every 8 s
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l    2    8  377    0.000    0.005   0.002
*SHM(0)          .NMEA.           0 l   12   16  377    0.000   -9.894  34.173
associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd 4.2.8p10@1.3728-o Mon Jun 12 16:45:04 UTC 2017 (1)",
processor="armv6l", system="Linux/4.9.35+", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=1.015, refid=PPS,
reftime=dd1863ad.8a0988d9  Tue, Jul 18 2017 10:38:37.539,
clock=dd1863af.1a8c5dda  Tue, Jul 18 2017 10:38:39.103, peer=13964, tc=3,
mintc=3, offset=0.004875, frequency=-20.377, sys_jitter=0.001948,
clk_jitter=0.003, clk_wander=0.002

Code: Select all

$ cgps;

┌───────────────────────────────────────────┐┌─────────────────────────────────┐
│    Time:       2017-07-18T10:38:41.000Z   ││PRN:   Elev:  Azim:  SNR:  Used: │
│    Latitude:    ###########               ││ ###    ##    ###    ##      Y   │
│    Longitude:   ###########               ││ ###    ##    ###    ##      Y   │
│    Altitude:   #######                    ││ ###    ##    ###    ##      Y   │
│    Speed:      #######                    ││ ###    ##    ###    ##      Y   │
│    Heading:    ######## (true)            ││ ###    ##    ###    ##      Y   │
│    Climb:      ### m/min                  ││ ###    ##    ###    ##      Y   │
│    Status:     3D FIX (#######)           ││ ###    ##    ###    ##      Y   │
│    Longitude Err:   +/- # m               ││ ###    ##    ###    ##      Y   │
│    Latitude Err:    +/- ## m              ││ ###    ##    ###    00      N   │
│    Altitude Err:    +/- ## m              ││ ###    ##    ###    00      N   │
│    Course Err:      n/a                   ││ ###    ##    ###    00      N   │
│    Speed Err:       +/- ## kph            ││ ###    ##    ###    00      N   │
│    Time offset:     #####                 ││ ###    ##    ###    00      N   │
│    Grid Square:     ######                ││                                 │
└───────────────────────────────────────────┘└─────────────────────────────────┘

Hi,
Thanks for your the sharing. This seems a very organized way to develop stratum 0. I have gone through some blogs developed ntp server using gps but they did not use bash script like you did. Good one.

I was actually focusing on understanding the possibility to fix gps-pps with node without any additional influences by the software. It seems, NTP puts some adjustment calculative results to develop the logical clock of the system. Therefore, though on the system clock is developed with an accuracy of 1 or 2 microseconds with GPS time showing by NTP, literally they are not. Therefore, when you brought two systems that are sync with GPS in a comparison, their offsets are large like 25-30 microseconds.
I was thinking, whether any other daemon available to fix the GPS-PPS with the system, or somehow I can tell NTP to stop its adjustment module to work.
Thanks.
Fida

mfa298
Posts: 1386
Joined: Tue Apr 22, 2014 11:18 am

Re: How to lock GPS (with pps) in Rpi!

Mon Jul 24, 2017 7:26 am

fidaforever wrote: Primarily I made little experiments where I sync two systems with GPS. I used NTP daemon which says individually each of them is synchronized at an accuracy of 1 micro second with UTC, however, when I compare them I found they are 30 micro sec apart from each other. But if both of them were 1 micro synch with UTC, there offset should be in a range of 2 micro, not 30 micro. It implies that NTP puts some additional adjustment ticks which need to be stopped.
Therefore, I was wondering whether there have any other daemons that only help to bind GPS-PPS with the system and will not do any excessive works on it.
Thanks.
First I'd check the datasheet for the gps module and check what that says about the accuracy of the PPS pin. However a measured difference of 30µS could be down to a number of factors.

Firstly I'd suspect an issue in how you're calculating that difference, that timing difference could easily come from network latency, context switching or instruction overheads.

Secondly whilst NTP and the GPS might be able to get 1µS accuracy, you've also got the Linux kernel in the middle, this could quite easily add some lag between the pps pin firing and the NTP daemon picking it up.

If you really need a clock with that level of precision then I suspect a cheap Pi and GPS setup isn't really the solution and you should look at getting a GPS disciplined NTP server designed for that level of precision (and pay the associated price tag).

beta-tester
Posts: 1554
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: How to lock GPS (with pps) in Rpi!

Mon Jul 24, 2017 10:22 am

fidaforever wrote:though on the system clock is developed with an accuracy of 1 or 2 microseconds with GPS time showing by NTP, literally they are not. Therefore, when you brought two systems that are sync with GPS in a comparison, their offsets are large like 25-30 microseconds.
I was thinking, whether any other daemon available to fix the GPS-PPS with the system, or somehow I can tell NTP to stop its adjustment module to work.
1..2 uS is way too optimistic. the pps pin has a jitter + the computers input pin has jitter + jitter of the kernel + ...

in the statistic log of my GPS-PPS-NTP i can clearly see, when i open my window - specially in the winter. the tiny temperature drop of the room is clearly visible in the statistice as a bump in the jitter.

and this it the RPI it self. when other devices try to sync to that RPi then it generates additional stress to the RPi that causes rising the jitter of the RPi itself.
i think with a RPi+GPS-PPS you get a jitter of about 10uS. and from the point of view of an device in your local network that sync to the RPi it will be even worse.
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

fidaforever
Posts: 14
Joined: Tue Mar 21, 2017 8:33 am

Re: How to lock GPS (with pps) in Rpi!

Fri Jul 28, 2017 8:45 am

mfa298 wrote:
Mon Jul 24, 2017 7:26 am

First I'd check the datasheet for the gps module and check what that says about the accuracy of the PPS pin. However a measured difference of 30µS could be down to a number of factors.

Firstly I'd suspect an issue in how you're calculating that difference, that timing difference could easily come from network latency, context switching or instruction overheads.

Secondly whilst NTP and the GPS might be able to get 1µS accuracy, you've also got the Linux kernel in the middle, this could quite easily add some lag between the pps pin firing and the NTP daemon picking it up.

If you really need a clock with that level of precision then I suspect a cheap Pi and GPS setup isn't really the solution and you should look at getting a GPS disciplined NTP server designed for that level of precision (and pay the associated price tag).
Hi,
Thank you for your elaboration on the possible reasons behind this result. Yes, the ethernet itself is a jitter and delay network, and also the kernel is another layer, therefore, it is difficult to control the offsets unless hardware time stamping being used. As this GPS integration directly synchronizes the System Clock of the system, I presume in Ethernet layered structure it is considered as Application Layer integration. So, the jitter will be reduced if somehow this clock is being synchronized with the physical layer.

I still don't know, whether there are any straightforward ways available to do it. But GPS integration with Rpi is even better if you going to integrate it with Laptop or Desktop PC. Because Rpi comes with less complexity with exclusive GPIO support. Although some dedicated servers which essentially use special hardware can have the better result is not something to argue with.

wiley1st
Posts: 1
Joined: Wed Aug 16, 2017 12:17 am

Re: How to lock GPS (with pps) in Rpi!

Wed Aug 16, 2017 1:17 am

If you are trying to get a single RPi to get +/- 5us accuracy you can do this with a GPS module and NTP in NMEA user mode. Many have already done this (I have) and posted on the forums on how to get it set up. You can probably get +/- 2us for a single RPi if you use kernel mode in NTP, but it's more complicated to install and maintain.

If you're trying to get a network of machines to all have the same accuracy of +/- 2us referencing a time server it's a different matter entirely. For one, the ethernet delays are 1.5e5 higher than the GPS accuracy and there's no way NTP's distributed time algorithms can make that work. FWIW, my NTP clients are about 30-50us off from my GPS server. That's OK for my application, but you'll have to determine your own threshold.

You mentioned hardware time stamps, which indicates you've also looked at PTP. I looked at the hardware requirements for PTP and it seems that hardware time stamps for send and receive are required and last I checked, only one is supported in the current raspbian. PTP is hierarchical (vs NTP's distributed architecture) and specifically designed for keeping accurate time across multiple machines. Obviously PTP has trade-offs compared to NTP - NTP is more robust to single machine failure but less accurate across multiple machines. Too bad RPi hardware support for this isn't there yet.

Both NTP and PTP using GPS will be sensitive to temperature changes. My offsets wobble +/- 10-20us or more when the AC cycles on/off. An easy fix is to put your GPS RPi in a location where the temperature varies the least - like on the floor of the basement, away from HVAC vents. And put a fan on it as all cooler temps reduce the temperature variation even more. I'm currently working on a DIY low-variability temperature chamber, just so I can improve my NTP offsets. Why? "Because it's there" :D

Cheers.

Smilash
Posts: 1
Joined: Wed Jan 24, 2018 11:35 am

Re: How to lock GPS (with pps) in Rpi!

Wed Jan 24, 2018 11:45 am

wiley1st wrote:
Wed Aug 16, 2017 1:17 am
If you are trying to get a single RPi to get +/- 5us accuracy you can do this with a GPS module and NTP in NMEA user mode. Many have already done this (I have) and posted on the forums on how to get it set up. You can probably get +/- 2us for a single RPi if you use kernel mode in NTP, but it's more complicated to install and maintain.

If you're trying to get a network of machines to all have the same accuracy of +/- 2us referencing a time server it's a different matter entirely. For one, the ethernet delays are 1.5e5 higher than the GPS accuracy and there's no way NTP's distributed time algorithms can make that work. FWIW, my NTP clients are about 30-50us off from my GPS server. That's OK for my application, but you'll have to determine your own threshold.

You mentioned hardware time stamps, which indicates you've also looked at PTP. I looked at the hardware requirements for PTP and it seems that hardware time stamps for send and receive are required and last I checked, only one is supported in the current raspbian. PTP is hierarchical (vs NTP's distributed architecture) and specifically designed for keeping accurate time across multiple machines. Obviously PTP has trade-offs compared to NTP - NTP is more robust to single machine failure but less accurate across multiple machines. Too bad RPi hardware support for this isn't there yet.

Both NTP and PTP using GPS will be sensitive to temperature changes. My offsets wobble +/- 10-20us or more when the AC cycles on/off. An easy fix is to put your GPS RPi in a location where the temperature varies the least - like on the floor of the basement, away from HVAC vents. And put a fan on it as all cooler temps reduce the temperature variation even more. I'm currently working on a DIY low-variability temperature chamber, just so I can improve my NTP offsets. Why? "Because it's there" :D

Cheers.
Hi,

Could you kindly give me the details and links as how I can use only NMEA to achieve your claimed accuracy of +/- 5 microsends.

Thank you so much in advance.

beta-tester
Posts: 1554
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: How to lock GPS (with pps) in Rpi!

Thu Jan 25, 2018 7:18 am

Smilash wrote:
Wed Jan 24, 2018 11:45 am
Hi,

Could you kindly give me the details and links as how I can use only NMEA to achieve your claimed accuracy of +/- 5 microsends.

Thank you so much in advance.
when i take a look to my GPS + PPS setup and compare the raw NMEA source with its PPS variant,
i don't see a accuracy of +/-5us it is more like +/- 100ms
(ok, it may depend on the serial port speed, the GPS dongle and settings you use, the OS installation, the RPi version, ...)

i would recommend to use chrony instead of ntpd, because ntpd is more restrict in to accept a time source to be relaiable,
when there is only one single time source available on your environment.
chrony is more like - "making the best of what you have".

i don't know what link he meant, but in the meantime,
you can try to take a look to my project https://github.com/beta-tester/RPi-GPS-PPS-StratumOne and to remove the need of PPS:
comment out or remove lines:
153, 166, 221, 228,
{350, 351, 378, 379} ntpd,
{487, 490, 493} chrony.
and change line:
102 from

Code: Select all

DEVICES=\"/dev/ttyAMA0 /dev/pps0\"
to

Code: Select all

DEVICES=\"/dev/ttyAMA0"
(the line numbers are from commit https://github.com/beta-tester/RPi-GPS- ... 61311c37ad)

and as i said, ntpd will ignore NMEA if it is the only time source.
you have to take chrony
(use the moste actual Raspbian Stretch !)
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

Mikeymp66
Posts: 6
Joined: Thu Dec 12, 2019 11:03 pm

Re: How to lock GPS (with pps) in Rpi!

Mon Dec 23, 2019 8:49 pm

This is for Beta -Tester chrony and gps with the latest stretch made my Pi a stratum 1 clock with no network connected keeping 5ms timing. I use a pi 2b + with stretch an Adafruit ultimate gps hat and gpsd and was super easy to set up .Thank you to all who posted info it made this project easy.

beta-tester
Posts: 1554
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: How to lock GPS (with pps) in Rpi!

Tue Dec 24, 2019 2:21 pm

Mikeymp66 wrote:
Mon Dec 23, 2019 8:49 pm
... with the latest stretch made my Pi a stratum 1...
in the meantime raspbian buster is the actual version.
(the project RPi-GPS-PPS-StratumOne is working with raspbian buster as well)
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

Killertechno
Posts: 239
Joined: Wed Jan 02, 2013 8:28 am

Re: How to lock GPS (with pps) in Rpi!

Fri Dec 27, 2019 2:04 pm

Hi to all, I'm searching for a stand-alone ntp server to be used with GPS receiver and no network connection (except for ntp clients).
I haven't still found a working procedure searching on the net.

At the end I wollowed this guide (https://github.com/beta-tester/RPi-GPS-PPS-StratumOne) but I had to move to buster.

My questions are:

1) if I manually set wrong date (sudo date...) I have wrong date until reboot.... why if my GPS has time locked wrong system time isn't updated to correct value?

2) I spent much time to run the script and I need to move to buster (I have stretch on other Pi installations); is there available a working guide for stretch for GPS shield using PPS on GPIO18?

Thanks.

beta-tester
Posts: 1554
Joined: Fri Jan 04, 2013 1:57 pm
Location: de_DE

Re: How to lock GPS (with pps) in Rpi!

Fri Dec 27, 2019 2:29 pm

Killertechno wrote:
Fri Dec 27, 2019 2:04 pm
1) if I manually set wrong date (sudo date...) I have wrong date until reboot.... why if my GPS has time locked wrong system time isn't updated to correct value?
normally the wrong time will be adjusted very slowly to the correct time, because some applications will not work correctly, when the time will jump in a big step.
see Is chronyd allowed to step the system clock? and Can chronyd be configured to control the clock like ntpd?
you can allow chrony by doing/forcing big steps by adding the following options in /etc/chrony/chrony.conf

Code: Select all

## https://chrony.tuxfamily.org/faq.html#_can_code_chronyd_code_be_configured_to_control_the_clock_like_code_ntpd_code
minsamples 32
maxslewrate 500
corrtimeratio 100
maxdrift 500
makestep 0.128 -1
maxchange 1000 1 1
maxclockerror 15
or simply execute the following command to make step manually:

Code: Select all

sudo chronyc makestep
Killertechno wrote:
Fri Dec 27, 2019 2:04 pm
2) I spent much time to run the script and I need to move to buster (I have stretch on other Pi installations); is there available a working guide for stretch for GPS shield using PPS on GPIO18?
if your gps device uses GPIO 18, then change the parameter in the /boot/config.txt file.

Code: Select all

#Name:   pps-gpio
#Info:   Configures the pps-gpio (pulse-per-second time signal via GPIO).
#Load:   dtoverlay=pps-gpio,<param>=<val>
#Params: gpiopin                 Input GPIO (default 18)
#        assert_falling_edge     When present, assert is indicated by a falling
#                                edge, rather than by a rising edge
# dtoverlay=pps-gpio,gpiopin=4,assert_falling_edge
dtoverlay=pps-gpio,gpiopin=18
my RPi-GPS-PPS-StratumOne should work with Raspbian Buster, when your take the actual version of the project.
it uses chrony as ntp server and it is intended to run without a network connection to the internet (once it is installed).


when you see, that PPSx is working reliable in your setup, then you can maybe also modify the /etc/chrony/chrony.conf file to use PPSx as main source.
this will have the advantage, that it first will take the NMEA time as soon it will appear, and later, when the gps device get a fix for PPS it will mix it to PPSx seemles. so you will faster get a time sync.

Code: Select all

# https://chrony.tuxfamily.org/faq.html#_using_a_pps_reference_clock
# SHM(0), gpsd: NMEA data from shared memory provided by gpsd
refclock  SHM 0  refid NMEA  precision 1e-1  offset 0.6  delay 0.2  noselect

# PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds
refclock  PPS /dev/pps0  refid PPS  precision 1e-9  lock NMEA  noselect

# SHM(2), gpsd: PPS data from shared memory provided by gpsd
refclock  SHM 2  refid PPSx  precision 1e-8  prefer

# SOCK, gpsd: PPS data from socket provided by gpsd
refclock  SOCK /var/run/chrony.pps0.sock  refid PPSy  precision 1e-7
PS.: as of my project is using chronyd instead of ntpd, all methods to check if the ntp server is running reliable must use chronyc.
i remember that some people were having problems to check if thier ntp server was running correctly, because they tried to use ntpd specific commands to check.
those ntpd specific commands are not available. you have to use chronyc commands instead.
e.g.:

Code: Select all

chronyc -m tracking sources sourcestats
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)

Return to “Advanced users”