domschl / raspberryntpserver Goto Github PK

Hello

Thank you for your help in setting up this nice solution.

I have implemented most of your code for the LCD output of the chronyc status, and everything works as expected. I have a few remarks.

-In latest Linux distributions, in particular on Debian 12, you cannot "pip install" a package system wide anymore in standard.
You must restrict the installation of python packages to a venv. The proposed way to circumvent this is to use pipx to install packages system wise, but pipx only accepts programs pacakges, not libraries (which is the case for gpsd-py3 and smbus).
So the only possible solution is to manually delete the file "EXTERNALLY-MANAGED" located in /usr/lib/python3.xx/.
Considering that this venv constraint will be more and more widespread as systems get updated, you should consider updating your installation documentation.

-Considering the display itself, I believe it would be useful to replace some static information which takes some room, or to switch the content of a line every once in a while, in particular for one missing very important information, which is the STRATUM status of the server.
If you have a synchronization issue of any kind (like a process unable to access SHM) your server can be degraded to a higher stratum level without any notice. It will still serve time internally on your LAN, but as a lower grade reference. So I believe it would be nice to have the current stratum level directly displayed as well.

I have fiddled with the code that would allow this, but haven't been successful in doing so. It would be nice to complete this ntp_offset() function to parse the stratum level as it processes the chronyc tracking output.
You could then alternate the second line of the display every 5 seconds or so with NTP: X.XXXXXXXXXsec / Stratum level : X
Or any other useful info such as RMS offset and Frequency, both of which have a slow evolution and have some level of importance.
Sorry I am not good enough in Python to work this out myself and also it would be valuable for the community.

Thanks!

Snipet of the current function below

def ntp_offset():
    cmd = ["chronyc", "tracking"]
    ret = exec_cmd(cmd)
    for line in ret:
        pars = line.split(":", 1)
        if len(pars) == 2:
            if pars[0].strip() == "System time":
                sub_pars = pars[1].strip().split(" ")
                if len(sub_pars) > 2:
                    val = float(sub_pars[0])
                    if "slow" == sub_pars[2]:
                        val = -1.0 * val
            return "NTP: {:+12.9f}sec".format(val)

With a recent update to Raspbian, it's necessary to add arm_64bit=0 to /boot/config.txt and reboot in order to get the pps working

Hi, I know you recommend a Pi 4/5 but I tried this out on a Pi Zero W and did manage to get stratum 1 with it, which is cool. However, I noticed something interesting which is that when checking the sources, PPS will always have exactly +/-1000ns of latency. Is this a hardware limitation you think? Just a curiosity and not a real issue. Feel free to close whenever.

210 Number of sources = 10
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#x NMEA                          0   4   377    11    -70ms[  -70ms] +/-  397us
#* PPS                           0   4   377     9    -32ns[  -36ns] +/- 1000ns
^- 192.168.1.1                   3   5   377    16    -25ms[  -25ms] +/-   40ms
^- 65.73.197.211                 3   6   277    48  -9501us[-9501us] +/-   80ms
^- 152.70.159.102                2   6   337    48    -11ms[  -11ms] +/-  112ms
^- 104.167.241.197               2   6   377    49  +5777us[+5777us] +/-   26ms
^- 135.148.100.14                2   6   377    49  -4120us[-4120us] +/-   41ms
^- 168.61.215.74                 3   6   377    54    -24ms[  -24ms] +/-   92ms
^- 17.253.20.125                 1   6   337    56    +57ms[  +57ms] +/-   74ms
^- 132.163.96.1                  1   6   277    50  +9676us[+9677us] +/-   38ms

chronyc> tracking
Reference ID    : 50505300 (PPS)
Stratum         : 1
Ref time (UTC)  : Sat Jan 13 02:44:03 2024
System time     : 0.000000122 seconds slow of NTP time
Last offset     : -0.000000128 seconds
RMS offset      : 0.001089404 seconds
Frequency       : 6.724 ppm fast
Residual freq   : +0.000 ppm
Skew            : 0.023 ppm
Root delay      : 0.000000001 seconds
Root dispersion : 0.000013824 seconds
Update interval : 16.0 seconds
Leap status     : Normal

Hi,

I'm fairly certain the Adafruit modules (or any Mediatek MTK3339 based modules) are a poor choice for clock applications. The timing of the NMEA output relative to the PPS signal is very unfortunate as it hovers around 500ms. Since it moves around the 500ms mark the applications have trouble determining what second to round to. You might up with a time that has very high accuracy for the rollover to the next second (since PPS drives that), but end up being off by a full second from the correct time.

You can see this issue in your examples with the 512ms offset reported my chrony sources.

To show it's actual effect on the time on your system, run:
watch -n 1 date +"%T.%3N"

I've found some other reports on this issue. Somebody mentioned this being a navigation GPS chip vs a chip that is designed with timing in mind. Timing chips place the NMEA string at a specific offset to the PPS and prefer high in the sky satellites to reduce multipathing.

To take any Linux OS issues out of the mix, I tested this on a microcontroller with a very basic test program to show PPS timing vs NMEA timing, and it confirms the consistent ~ 500ms offset. Interestingly it seems to always be around 500ms, it's not different for every boot

Excellent guide, very well written and extremely helpful, thank you.

I'm trying to tweak everything to get the most accurate time on my system and I'm a little confused as to why we include the delay of 0.2 in the following line from chrony.conf:

refclock SHM 0 refid GPS precision 1e-1 offset 0.01 delay 0.2 noselect

Chrony docs describes the 'delay' option as:

delay delay This option sets the NTP delay of the source (in seconds). Half of this value is included in the maximum assumed error which is used in the source selection algorithm. Increasing the delay is useful to avoid having no majority in the source selection or to make it prefer other sources. The default is 1e-9 (1 nanosecond).

Presumably we're not doing this to influence the source selection as we also have 'noselect' defined for this reflock so I was wondering why we include the option and how you arrived at the value 0.2.

Hey,

as written in the title, the offset value of 0.0 for the GPS refclock stored in /etc/chrony/chrony.conf (which seems to be the newer path for the config) prevents the usage of GPS as reference time. The same was discussed here.

Setting it to 0.1 fixed it, I'm not sure if that breaks something or lowers the accuracy, but afterwards it at least worked for me. Maybe you want to include this in your Readme?

Addition after writing this: I saw that you mentioned correcting the offset in the config later, but for me the problem was that the GPS didn't get selected as reference clock in the first place (as it should have been as described in https://github.com/domschl/RaspberryNtpServer#setting-up-chrony-as-time-server), and the Last sample shown for PPS was always 0. The linked section is where I got stuck, and I didn't even get to the point of having GPS selected as the main time source.

Also, while we're at it, it would be nice to have the corresponding udev rules included (as figuring out how to do it when you've never worked with them before is quite pain). Just as quick reference (if you want to copy it): /etc/udev/rules.d/pps-sources.rules should contain

KERNEL=="pps0", OWNER="root", GROUP="_chrony", MODE="0660"
KERNEL=="ttyS0", RUN+="/bin/setserial -v /dev/%k low_latency irq 4"

This assumes the user of the chronyd process to be _chrony, which can be found out using ps aux | grep chronyd. Also, I'm using the serial connection here, otherwise ttyS0 probably needs to be changed. To reload udev rules without reboot, run

sudo udevadm control --reload-rules && sudo udevadm trigger

Both cost me quite some time figuring out, so I would be happy if you include both improvements in your Readme File.

Hi Tks for your project
I have one small problem using Adafruit module and Rpi3 64bib Rasberian OS All good
with one exception Not sure what I am doing wrong But for SATS I just get [ -- ] when I have + 20 connected
Running
"Debian GNU/Linux 11 (bullseye)"
6.1.21-v8+ aarch64
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110]

??

Hi,
i've tried to follow the setup as close as possible with a CM4 but i wanted to use the SYNC_IN pin on the CM4 breakout port since i've got a LEA-M8F Board from Timebeat (https://store.timebeat.app/products/gnss-raspberry-pi-cm4-module?variant=42280855699627).

My problem is that i still get timeouts with ppstest on pps0 and i cannot figure out why:

$ sudo ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)
time_pps_fetch() error -1 (Connection timed out)

With test ptp i do not get a problem:

$ sudo ./testptp -d /dev/ptp0 -L 0,1
set pin function okay
$ sudo  ./testptp -d /dev/ptp0 -e 5
external time stamp request okay
event index 0 at 9036.169914149
event index 0 at 9037.169893564
event index 0 at 9038.169871992
event index 0 at 9039.169849439
event index 0 at 9040.169825905

also if i hook up a logic analyzer on the physical pin i get a clean 1pps signal as soon as the GPS locks.

here some extra info:

$ uname -a
Linux cm4 6.6.16-v8+ #1728 SMP PREEMPT Tue Feb  6 17:21:42 GMT 2024 aarch64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:        12
Codename:       bookworm

$ sudo chronyc
chrony version 4.3
Copyright (C) 1997-2003, 2007, 2009-2022 Richard P. Curnow and others
chrony comes with ABSOLUTELY NO WARRANTY.  This is free software, and
you are welcome to redistribute it under certain conditions.  See the
GNU General Public License version 2 for details.

chronyc> sourcestats
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
PPS0                        0   0     0     +0.000   2000.000     +0ns  4000ms
GPS                         7   4    97   +128.275    353.883   +646ms  4399us
185.13.148.71               7   5   25m     +0.141      1.468  -1105us   258us
vif1201.leaf2.network.pr>   6   3   773     -0.500      1.174   +264us    85us
nono.com                    7   4   453     -0.311      0.473   -479us    29us
ntp1.aew1.soe.as49436.net   6   3   21m     +0.339      3.956   +332us   423us
172.28.100.10              11   9   644     -0.188      0.097   +376us    14us
chronyc> sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#? PPS0                          0   4     0     -     +0ns[   +0ns] +/-    0ns
#? GPS                           0   4   377    23   +645ms[ +645ms] +/-  200ms
^+ 185.13.148.71                 2   8   377    90  -1429us[-1429us] +/-   12ms
^+ vif1201.leaf2.network.pr>     2   7   377    24   +332us[ +332us] +/-   16ms
^- nono.com                      2   6   377    24   -577us[ -577us] +/-   49ms
^* ntp1.aew1.soe.as49436.net     1   8   377    93   +297us[ +378us] +/-   11ms
^- 172.28.100.10                 3   6   377    30   +362us[ +362us] +/-   49ms

any suggestions ?

Can you add a link for a recommended 4x20 LCD display? You have a very comprehensive set of links for all the parts (thanks!) so it would be nice to include the LCD as well.

I've gotten everything working with Chrony, etc.

My question is - how can I be notified when something goes wrong? I.e., the PPS source is unreliable, GPS lock has been lost, etc.

I'm using Home Assistant and Uptime Kuma to track the availability of my (too many) servers, if that's helpful.

Great tutorial! I just got mine up and running. Here's a few suggestions:

• Typo - Several references (4) to systemctl ... chronyd. This should be just 'chrony', not 'chronyd'
• Typo - 'install gpsd via your packet manager.' should be 'install gpsd via your package manager.'
• Suggest including an example on how to install the first time an install is needed - 'sudo apt-get install gpsd'
• When adding allow 192.168/16 to chronyd.conf, one can omit the IP address and it will allow connections from any connected interface.
• A simple test from another computer can test connectivity. On a mac, sntp <ip address>, or verbose sntp -d <ip address> and it will show PPS0 being used.
• Documentation says 'If reception is ok, a led ("FIX" or "PPS") should start blinking on your GPS module.' On my Adafruit module, it blinks 1x/second if not fix and once every 10 seconds when there is a fix.

Hello. I had set up two separate servers for both the office and home. I did some operations on one of them, such as setting up a VPN server etc., but I never touched the other one. Suddenly they both switched to Saturn2 last night. When I want to see what's happening with the gpsmon command, I get the following image. It's like they both lost connection with the GPS module at the same time. Or did an update cause this?

I have been encountering this error recently, and the log generated by this error has unexpectedly expanded my syslog and user.log to 10GB (almost filling up my SD card). Does anyone know how to solve this error?

2024-07-30T22:26:45.183731+08:00 NHI-RaspberryPi-4B gpsd[748]: gpsd:ERROR: accept: fail: Too many open files in system
2024-07-30T22:26:45.183779+08:00 NHI-RaspberryPi-4B gpsd[748]: gpsd:ERROR: accept: fail: Too many open files in system
2024-07-30T22:26:45.183825+08:00 NHI-RaspberryPi-4B gpsd[748]: gpsd:ERROR: accept: fail: Too many open files in system
2024-07-30T22:26:45.183867+08:00 NHI-RaspberryPi-4B gpsd[748]: gpsd:ERROR: accept: fail: Too many open files in system
2024-07-30T22:26:45.183915+08:00 NHI-RaspberryPi-4B gpsd[748]: gpsd:ERROR: accept: fail: Too many open files in system
2024-07-30T22:26:45.183960+08:00 NHI-RaspberryPi-4B gpsd[748]: gpsd:ERROR: accept: fail: Too many open files in system
2024-07-30T22:26:45.184002+08:00 NHI-RaspberryPi-4B gpsd[748]: gpsd:ERROR: accept: fail: Too many open files in system
2024-07-30T22:26:45.184050+08:00 NHI-RaspberryPi-4B gpsd[748]: gpsd:ERROR: accept: fail: Too many open files in system
2024-07-30T22:26:45.184093+08:00 NHI-RaspberryPi-4B gpsd[748]: gpsd:ERROR: accept: fail: Too many open files in system
2024-07-30T22:26:45.184141+08:00 NHI-RaspberryPi-4B gpsd[748]: gpsd:ERROR: accept: fail: Too many open files in system

and looks it create log super fast, this is my first time encountering this situation, is there anything I should check first?

@aGGreSSiv : I've updated the documentation of the install process. If you are still having trouble, please open a new issue and describe at what step you're stuck, and we have a look at it!

I connected remotely and followed the steps one by one according to the instructions. First I updated the operating system, then I entered the commands one by one. None of the commands gave an error. The LCD is not plugged in right now, maybe that's why it gives an error, but when I check the chronotron service status to check, it gives the following output.

pi@raspberrypi:~ $ sudo systemctl status chronotron
● chronotron.service - Display chrony statistics on 4x20 LCD
     Loaded: loaded (/etc/systemd/system/chronotron.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2023-12-21 13:22:11 +03; 11s ago
    Process: 537 ExecStart=/opt/chronotron/bin/python /opt/chronotron/chronotron.py (code=exited, status=1/FAILURE)
   Main PID: 537 (code=exited, status=1/FAILURE)
        CPU: 422ms

Dec 21 13:22:11 raspberrypi python[537]: Traceback (most recent call last):
Dec 21 13:22:11 raspberrypi python[537]:   File "/opt/chronotron/chronotron.py", line 237, in <module>
Dec 21 13:22:11 raspberrypi python[537]:     main_loop()
Dec 21 13:22:11 raspberrypi python[537]:   File "/opt/chronotron/chronotron.py", line 151, in main_loop
Dec 21 13:22:11 raspberrypi python[537]:     lcd = LcdDisplay()
Dec 21 13:22:11 raspberrypi python[537]:   File "/opt/chronotron/i2c_lcd.py", line 8, in __init__
Dec 21 13:22:11 raspberrypi python[537]:     self.bus = smbus.SMBus(sm_bus)  # Rev 1 Pi: 0, Rev 2 Pi: 1
Dec 21 13:22:11 raspberrypi python[537]: FileNotFoundError: [Errno 2] No such file or directory
Dec 21 13:22:11 raspberrypi systemd[1]: chronotron.service: Main process exited, code=exited, status=1/FAILURE
Dec 21 13:22:11 raspberrypi systemd[1]: chronotron.service: Failed with result 'exit-code'.

Thank you very much for providing this setup! I have been running two Raspberry Pi 4 NTP server for a long time. When upgrading to Raspberry Pi 5, I did switch to Chrony. This does provide stratum 1 time in a reliable manner.

The time server works well in my LAN and even across LANs via VPN.

What strikes me very odd is that I cannot get the Raspberry Pi 5 running the native Chrony version included with Debian Bookworm to respond externally, when forwarding port 123/UDP via my pfSense router.

Running ntpdate -q [IP of Raspberry Pi NTP server] does work without any issues in the LAN and via VPN. When forwarding 123/UDP from WAN to the Raspberry Pi NTP server, it does time out ("no server suitable for synchronization found"). When forwarding 123/UDP to the pfSsense router itself (localhost), which does get its time from the Raspberry Pi NTP server, everything is fine - except for stratum being 2 instead of 1. When forwarding the 123/UDP to the most trivial device within the LAN providing NTP (for example a homematic IP CCU3 - which has a Raspberry Pi 3 inside), everything does work (stratum 3). Thus, it does not seem to be a router/pfSense issue.

My chrony.conf does include allow and cmdallow (tried with and without "all").

Do others make the same observation? Are there any recommendations to cure this? Thanks a lot!

I get something wrong like permission denied 、ModuleNotFoundError: No module named 'gpsd'、ModuleNotFoundError: No module named 'smbus'...

looks like somethin wrong between pip and pip3 ?

system: Pi OS 64 Lite