pps-client and NTP - Githubissues

Hello @betourneyb,

I saw the issue you opened in the PPS-Client HERE. I am also trying to setup a Raspberry Pi as a NTP server, and have some success with PPS and GPSD. I'm using 3B+ and Adafruit Ultimate GPS HAT. I'd like to contact you to see if you've had any success in getting a stable / reliable GPS based NTP using your Pi. As there are no communication mechanisms via Github, please reach out via either Twitter or LinkedIn. Twitter: @luischanu LinkedIn: https://www.linkedin.com/in/luischanu/

Hopefully you get this, as maybe we can help each other.

Luis Chanu

Luis:

We will see if you get this reply via GITHUB. If I don't see a response within a few days will add you to Linkedin and contact you there.

I tried 99% of the PPS solutions I could find posted from every portal (Arduino, Pi, Github). All would programatically'function', but each had a critical flaw that would eventually cause the PPS to fail as the primary time source. I was ready to quit until I stumbled on this source: []http://www.gregledet.net/computers/building-a-stratum-1-ntp-server-with-a-raspberry-pi-4-and-adafruit-ultimate-gps-hat/(url). It was written in 2020, so the source material was current with today's Pi hardware/software, and the author takes a different approach from the other 100 DIY methods I found (most of which are just copied material).

I knew I was at the right place when the author stated
"I’m going to be honest with you. There’s a lot of posts on the internet on how to do this, but there’s a lot of misinformation out there to. My goal in this post is to give you what you need to get this setup, explain why you need to do what you need to do, and give you the tools you’ll need to study up if you want to know more."

Now, that said, I didn't implement precisely the same, I used the latest 2021 version of PI, and I left off some of logs. I also used different hardware, my PPS source is a Dragino GPS board mounted on a Arduino UNO. The PPS signal is fed into PIN 12 on the PI's GPIO header, but that shouldn't matter as the PPS signals would be the same from the Adafruit hat. This solution has been in continual use as my stratum station master clock for almost two months without a glitch. I've restarted the Pi several times, the GPSD/NTP daemons snap up within 30 seconds and the PPS is quickly restored as the primary time source.

Please give that a try, I will remain subscribed if you need to reply or hit a snag with the code.

Brian

Hello @betourneyb,

Yep, received your message "loud and clear".. :-)

I've read through the link you provided, and he does a really nice job of going over it. I've mainly been using these two posts, but still ran into some issues with NTP not being available: http://www.unixwiz.net/techtips/raspberry-pi3-gps-time.html https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

FYI, I'm using a Raspberry Pi 3B+ and Adafruit Ultimate GPS HAT, as I wanted to put it in a nice case, and I was told that there were heat issues with doing that with a RPi 4. I'd be interested in learning what case and heat related issues, if any, you've run into.

BTW, if you are a slack user, I can add you to my slack channel, and we can chat there... If you want to include your e-mail address here, I can create a Slack channel for us.

With that, I have a few work items to complete, then I'll be going through the blog you provided. Thank you for sharing that, it looks very complete.

Luis

Hello @betourneyb,

I've gone ahead and built one of my Raspberry Pi 3B+ units using the procedure above. I set the "time1 0" setting in ntp.conf, and am will let it run for a couple days with the following command:

watch -n0.5 "ntpq -pn | grep '.GPS.' | tee --append ~/GPSD_Offset.txt"

I will then dump the GPSD_Offset.txt file into Excel, figure out the average Offset, and then update. My hope is that the NTP will stay synch'd after that. Right now, I'm still getting time from Internet NTP servers, which is probably why my PPS has a "*" next to it. The issue I had before is that the ".GPS." server would jump between "+" and "x". Right now, because of the large Offset, it's primarily "x".

On your setup, are you able to maintain "*" and "+" with PPS and GPS, respectively, without any Internet NTP servers? If you do a "ntpdate -q" against your RPi w/o any Internet NTP servers, does it give reliable time?

Luis

Luis:

Don't try to overthink it too much; that's the mistake I made. I used that guy's code exactly as posted, it's critical to follow every step; don't skip anything. I don't remember even requiring an offset; If I did I used his. The only possible change I made was to the GPIO pin reference, that was done because I was sourcing PPS from an external device. Once you have everything programmed, it will be spot-on accurate assuming you have a good antenna. Mine has been running for months and has never failed, and reflects a .001 jitter every time I check with NTPQ... This is the antenna I'm using, perhaps overkill, but it pulls in all birds in the visable sky with a low SNR : https://www.amazon.com/gp/product/B08B837TH8/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

Sorry, just had dental surgery today, so a bit loopy. Please give it another try and let me know what happens. If needed I can go into my GPSD.conf, and login scripts to verify. Also--make sure your firewall is not blocking anything; I also had some initial DNS issues and had to manually create hostname mappings for the pi to 127.0.0.1. I can assure you that this guys script WILL work, it may take a few minor tweaks, but once you get it working you won't ever have to touch it again.

PS...Im responding on GITHUB for a reason, Im a fairly new user and hoping I will get some brownie points for my online contributions.

Luis...Scrap those other two links...I wasted weeks trying to make those scripts work and always ended up in the same place you have. Most of these posted scripts are ancient and have not been updated, dont waste your time like I did. This guys script WILL work....One note, I am using a PI4 with a lot of RAM, so your correction factor may need a small tweak to overcome any buffering latency, but that should be minimal unless you need absolutely full Stratum 1 accuracy. If you dont need the Pi3 for any other function, I would disable all the unneeded services and kill the logs except for critical errors. Make sure you turn off ALL the IPv6 statements, including those in DHCPD.conf (the instructions are included on the guys website), this DOES matter.

Brian

Sorry for the multiple replies...Like I said I'm still loopy from surgery

on the "" and +"+" ... when correct you will ALWAYS have the PPS as "", but your will never get the GPS source to reflect "+", and it DOESNT matter! The GPS only reflects the NMEA messages which are informational, its the PPS pulses that sync the clock for digital station devices.

I do use the Pi'a NMEA messages to sync my homebrew Desk clock which operates at Stratum 3; that clock also tracks the number of Satellites Seen, Satellites Locked, and SNR. I can post the Arduino file for that clock if you interested.

If you have a windows box and want to see some cool graphics using NMEA data, download this free program: Visual GPS It requires a Serial to USB adapter, but that's a $5 item on Amazon. I doubletapped tapped the USB adapter directly from the Pi's GPIO input from the GPS module, it doesn't seem effect the GPS clock signal at all.

@betourneyb, this RPi was built from scratch, following the instructions EXACTLY as they were written. Only difference from what he has is: 1) Ran into issues with the various "server X.us.pool.ntp.org" statements he had, as those resolved pools of servers. I moved them down to a single Pool 2) He mentioned using "time1 0.500" as a starting point, and adjusting later. I've started with 0, as it will be easier to determine the proper value in a day or so. 3) I'm running Raspberry Pi 3B+.

Next, for reference, here is my /etc/ntp.conf file:

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Leap seconds definition provided by tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list

# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/
logfile  /var/log/ntp.log

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

# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example
server time.nist.gov      iburst minpoll 5 maxpoll 5
server tick.usno.navy.mil iburst minpoll 5 maxpoll 5

# GPS PPS reference (NTP2)
server 127.127.28.2 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.2 refid PPS

# GPS Serial data reference (NTP0)
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0 refid GPS

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
#pool 0.debian.pool.ntp.org iburst
#pool 1.debian.pool.ntp.org iburst
#pool 2.debian.pool.ntp.org iburst
#pool 3.debian.pool.ntp.org iburst
pool us.pool.ntp.org  iburst minpoll 5 maxpoll 5

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Needed for adding pool entries
restrict source notrap nomodify noquery

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust

# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

and, here is my "ntpq -p" output:

pi@ntp:~ $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*SHM(2)          .PPS.            0 l   12   16  377    0.000   +0.001   0.003
xSHM(0)          .GPS.            0 l   11   16  377    0.000  -390.61  16.876
 us.pool.ntp.org .POOL.          16 p    -   32    0    0.000   +0.000   0.002
+time-a-b.nist.g .NIST.           1 u   22   32  377   31.749   +0.313   0.618
 192.5.41.40     .INIT.          16 u    -   32    0    0.000   +0.000   0.000
-45.83.234.123 ( 10.1.105.4       2 u   26   32  377  154.324   +2.261   0.825
-50-205-244-109- 50.205.244.28    2 u   19   32  377   58.311   -1.434   0.574
+time.cloudflare 10.4.3.52        3 u   14   32  377    4.669   +0.203   0.613
-clock.nyc.he.ne .CDMA.           1 u    1   32  377   64.807   +0.099   0.882
-138.68.19.10 (n 128.194.254.9    3 u   12   32  377    5.979   +1.964   0.816

and, here is my "cgps -s" output:

+-------------------------------------------++------------------Seen 22/Used 12+
| Time:        2021-12-22T00:56:01.000Z (0) ||GNSS   PRN  Elev   Azim   SNR Use|
| Latitude:        XXX.XXXXXXXX N           ||GP  1    1  17.0   90.0  17.0  Y |
| Longitude:       YYY.YYYYYYYY W           ||GP  7    7  36.0  110.0  34.0  Y |
| Alt (HAE, MSL):     39.400,     65.200 m  ||GP 13   13  51.0  293.0  17.0  Y |
| Speed:             0.54 km/h              ||GP 15   15  23.0  309.0  25.0  Y |
| Track (true, var):   303.6,  13.1     deg ||GP 17   17  56.0  172.0  24.0  Y |
| Climb:             0.00 m/min             ||GP 19   19  31.0  191.0  36.0  Y |
| Status:         3D DGPS FIX (175 secs)    ||GP 21   21  14.0   60.0  30.0  Y |
| Long Err  (XDOP, EPX):  0.50, +/-  1.9 m  ||GP 30   30  65.0   92.0  16.0  Y |
| Lat Err   (YDOP, EPY):  0.58, +/-  2.2 m  ||GL  3   67  20.0  213.0  20.0  Y |
| Alt Err   (VDOP, EPV):  0.81, +/-  4.5 m  ||GL 14   78  48.0  327.0  24.0  Y |
| 2D Err    (HDOP, CEP):  0.76, +/-  3.6 m  ||GL 23   87  44.0   81.0  16.0  Y |
| 3D Err    (PDOP, SEP):  1.11, +/-  5.1 m  ||GL 24   88  34.0  139.0  32.0  Y |
| Time Err  (TDOP):       0.86              ||GP  5    5   2.0  256.0   0.0  N |
| Geo Err   (GDOP):       1.79              ||GP  8    8   2.0   37.0   0.0  N |
| ECEF X, VX:              n/a    n/a       ||GP 14   14  72.0  347.0   0.0  N |
| ECEF Y, VY:              n/a    n/a       ||SB138   51  44.0  156.0  32.0  N |
| ECEF Z, VZ:              n/a    n/a       ||GL  4   68  37.0  269.0  19.0  N |
| Speed Err (EPS):       +/- 15.7 km/h      ||GL  5   69  19.0  324.0   0.0  N |
| Track Err (EPD):        n/a               ||GL 12   76   2.0   86.0   0.0  N |
| Time offset:            1.002840104 s     ||GL 13   77  41.0   54.0   0.0  N |
| Grid Square:            CM97ag76          ||GL 15   79   9.0  287.0   0.0  N |
+-------------------------------------------++More...--------------------------+

The problem is if I remove all the Internet reachable servers from my ntp.conf, then both PPS and GPS both go to "x" after a short amount of time, and I then time can't be obtained, and NTP requests to the RPi fail. If I adjust the "time1" value to get GPS offset closer to 0, then it's "close enough" to the PPS, and NTP then accepts it...at that point, PPS goes to "*", and time is delivered again.

FYI, I am using this Adafruit GPS Antenna, along with their Ultimate GPS HAT.

OBSERVATIONS: 1) One thing I've noticed that seems odd is that sometimes doing a "sudo cat /dev/AMA0" displays the NMEA output, and sometimes it doesn't. If I run "gpsmon", it shows the NMEA messages scrolling by w/o issue. So, although odd, I think is OK in that the GPSD process may be using /dev/ttyAMA0.

QUESTIONS: 1) When you say "turn off all IPv6 statements", do you mean within DHCP.CONF, or completely disable IPv6 on the RPi? 2) I've been running my RPi inside (antenna at a window). Given it sees 12+ satellites, have to imagine I'm fine in terms of reception...would you agree?

Luis

Luis, YES, you must have several other public servers, or NTP won't trust the PPS time source; there is a workaround for that, but it's not a bad idea to keep a few public servers in the list anyways.

Your PPS input is selected as primary and looks good! Forget about the "X" next to NMEA; they are just informational packets from the GPS; they are not precise and will be ignored. NTP WANTS the PPS, not the NMEA packets, so if your PPS remains primary, you are good to go!

I did take screenshots of all my .conf files, they are pasted below.

On some of your other questions...... ACM0 reads packets from a USB dongle; I read mine directly from the GPIO pins, so look at ttyS0 and give that a try. It could be that the sudo cat command only pulls a slice of time, NMEA data is batched and sent in intervals, its possible that the cat command created a snapshot between intervals with no data present.

Overall your SNR looks pretty good on most of the satellites. Even a tiny window antenna will see a lot of satellites, but the shape of the antenna will not compensate for the pitch and roll of the spacecraft. The satellites transmit with a circular polarization, and most small antennas are designed using vertical polarization, the result is 'holes' in the data stream as the spacecraft yaws/rolls/pitches. However, the geostationary orbits that the GPS uses are pretty stable, and you DO have MORE than enough "good SNR" downlinks to produce accurate PPS signals, so it's not a problem.

Trying to track voice and telemetry downlinks from the LEO satellites is a whole other matter. It generally requires specialized antennas, Elevation-Azimuth antenna rotors with tracking software. Sometimes that's not even enough. Tracking the ISS is typically easy due to its size and large antennas, but most communications satellites are like tracking a tumbling washing machine across the sky.

I hope the info helps.. although it looks like you may have already found success!

Brian,AA5H my QRZ page: qrz.com/aa5h

boot config cmdline gpsd ntp_conf.txt Soem other commands to try.txt

Brian, I completely agree that it's a good idea to have Internet reachable NTP servers, but one of the goals I had with building this Raspberry Pi was to build a stand-alone, non-Internet connected, NTP Server. If you don't mind sharing, what is the "work around" that you're eluding to get to that state? My hope was to build a poor man's Symmetricom NTP Server. :-)

I was under the impression that as long as PPS was good, the NTP was good (for the same reasons you mentioned), but then I just keep thinking..."Then what's the purpose of having a GPS antenna if I still need Internet NTP?" Again, went against one of my goals...

In your /etc/default/gpsd file above, why are you including "/dev/ttyAMA0" and "/dev/pps0" in the GPSD_OPTIONS? I've always seen just the "-n" so that GPSD doesn't wait for a request. In my mind, that seems like a possible error given the devices are listed in the DEVICES option. Can you elaborate?

I will say, this little NTP Server project has been quite a journey... I've learned so much about NTP, the pseudo IPs, etc. It is amazing how many "experts" there are on how to build a Raspberry Pi NTP server on the Internet... hahaha...

I tried to reach your QRZ page, but it said page not found.

Thanks for all the explanations and info... Most of it made sense, as I've always loved physics and electronics. It also helps to be a fellow (non-practicing) ham radio guy, too. :-)

Luis KI6WGJ

Luis....will explain the whole AMA0 thing at a later date; it's a moot point anyway; your PPS is working, so you obviously have the hardware address statements correct for your configuration.

Now on to your more pressing issue....how to run NTPD as a standalone server, a poor man's SymmetriPI. Yes, it can be done, however it's not recommended by the protocol designer. The Public NTP servers provide a frame of reference, if the PPS drifts due to some thermal or latency event it can use the public servers to regain its cosmic footing. Its similar to what spacecraft experience when they enter Gimbal Lock, without an external point of reference a spacecraft cannot determine its 3-dimensional posture (unless your Tom Hanks and use the moon as reference)

Here is the direct quote from the NTP Bible (will provide the document link at the end of this post)

"NTP is a cluster protocol. It sorts time sources into clusters, picks the best cluster, then the best source in that cluster, for its time source. By default, NTPsec requires 3 "sane" time sources before serving time. This is set with the minsane option. Not at all recommended, but you can force ntpd to rely sole on your PPS source by adjusting minsane like this in your ntp.conf:

and here's the droid you are looking for:

# tos minclock 1 minsane 1

but wait, there's a catch!.....it appears that the "minsane" command is part of the newer NTPsec protocol stack. So you may need to delete NTP and reload with NTPsec. NTPsec is a much better and secure protocol anyway, and I am considering changing my own time server to NTPsec as well.

Now....the promised link to the NTP Bible, this document is a gold mine of accurate information kept up to date by the devs. It is written in reasonably plain language, provides examples, and has GREAT sections on fine-tuning your NTP PI for max accuracy. I believe that the author of the original link I sent you is one of the keepers of the website.

Here is the link (enjoy):

https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html

and here's the correct link to my ham website:

https://www.qrz.com/db/aa5h

Keep me posted on progress, I am stuck at home recovering from surgery for two weeks!

luischanu / TempRepoToContactBetourneyb

pps-client and NTP #1