RPi5 GPS offset issues

[vukpm]

Hi,

I realize that this has been somewhat mentioned in the previous two issues (#19 & #20) but it's inconclusive (to me at least) if anything can be done here, or is it totally a RPi 5 hardware / firmware issue.

GPS0 offset values are making the RPi5 totally unusable for the task - offset is all over the place with values going up to +/- 2 Sec(!). Which is a shame, as I was planning to use the PTP features of the new board..

I tested this on two different RPi5s boards (with 4 GB of RAM) and the results are the same.

Previously, the same NEO-M8T GNSS module setup on RPi4 consistently gets +/- 5ms offset values on average.

Both RPi4 and RPi5 are dedicated for the NTP service and are not doing anything else (99.9% of the time). I also keep the CPU clock frequency fixed (1.5Ghz on RPi5; 1.2Ghz on RPi4) to minimize power fluctuations and possible interference. Once booted and warmed-up, the temperature of the units stays within 1*C.

Many thanks in advance for your inputs!
Vuk

[beta-tester]

i do not own a RPi5 - i can not do any suggestions for that.

GPS0 is using NMEA information. this is the most inaccurate time source the GPS device is offering.

does the graph of PSM0 looks the same?

if you use the script/settings without changes, then only PSM0 is selected as time source.
GPS0, PPS0, PST0 are only as examples in there, only to show that possibility in case somebody really want to use these time sources.

PSM0 i the most robust source, handles NMEA + PPS by itself and does not need handmade offset calibration.

if you modified the script / settings so that all time sources can be selected (by removing noselect) is not a good idea, because PPS0, PSM0, PST0 sources have the same accuracy and the logic in NTPD or CHRONYD is continuously hopping between all those time sources what will disturb the time accuracy because the sync algorithm process never has the chance to relax.

[vukpm]

Thank you for your reply and inputs!

I forgot to attach the PSM0 values, but yes, those are even worse..

These are the typical RPi5 values over a 24h period on any given day - note the Y axis values which are in hundreds of milliseconds:

Whereas RPi4 is typically something like this - Y axis is in microseconds:

Similarly, PPS0 graphs:

RPi5:

RPi4:

I didn't change the script settings except for the GPS0 offset value of 0.200 which is what I use on RPi4. Of course, I tried a few different values with RPi5 but nothing here really makes any sense because of the erratic behavior of the offset.

root@chronos:~# cat /etc/chrony/stratum1/10-refclocks-pps0.conf 
# https://chrony.tuxfamily.org/documentation.html
# https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html#_feeding_chrony_from_gpsd
# gspd is looking for
# /var/run/chrony.pps0.sock


######################################################################
# PPS0

# PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds
refclock  PPS /dev/pps0                   refid PPS0  precision 1e-7  poll 3  trust  noselect  lock PSM0

# SHM(0), gpsd: NMEA data from shared memory provided by gpsd
refclock  SHM 0                           refid GPS0  precision 1e-1  poll 3  trust  noselect  offset 0.200

# SHM(1), gpsd: PPS0 data from shared memory provided by gpsd
refclock  SHM 1                           refid PSM0  precision 1e-7  poll 3  trust  prefer

# SOCK, gpsd: PPS0 data from socket provided by gpsd
refclock  SOCK /var/run/chrony.pps0.sock  refid PST0  precision 1e-7  poll 3  trust  noselect
root@chronos:~#

[beta-tester]

where is your GPS/GNSS antenna?
do you have a fix (PPS signal) for 24/7 (hours/days)?

i am on the ground floor and surrounded from high buildings and per day it happens that there are not enough satellites in view for a fix and the PPS signal drops at that time

(there is only one "bright" spot where the reception is "perfect")

you can record the GPS data with this python script:
https://github.com/beta-tester/python-gpsd-client

set HOST_1 to the IP of your RPi5 (and HOST_2 to the ip of your RPI4).
if you only use HOST_1, then delete the line 720 with HOST_2

let it run fpr at least 24h. then look for periods where your gps has no 3D fix:
sqlite3 -readonly gpsd-client-test.sqlite "select * from data_gps_tpv where mode < 3"

if all not giving a hint what can be improved, then i guess it maybe really an issue of RPi5 of maybe the used RasPiOS

[vukpm]

I'm relatively high off the ground and the antenna has a pretty good view of the sky (with some minor reflections). More importantly it doesn't move or change in any way between RPi5 tests and RPi4. I only have one GNSS module, so even that didn't change :-)
Both are also regularly being updated and running the latest bookworm 64bit release.

This is the general satellite availability I'm getting:

(edit, forgot that I have Fix-type and DOP graphs as well)

Fix-type (basically always 3, actually it's 3D DGPS because of SBAS, but never mind..):

Dilution of precision:

btw. I have a spare RPi5 that I can send your way. Interested?

[beta-tester]

btw. I have a spare RPi5 that I can send your way. Interested?

what ?! wait a moment... seriously ?
that sounds very very tempting, but even if it were, i don't have a stable GNSS reception at my position. and my room temperature is varying a lot over the day.

BTW: the RRDTOOL is new to me. how to use it to create the graphs like you did?

[beta-tester]

Send me your details on - ... (email deleted)

RRDtool is a well known open-source database tool for handling (and also graphing) time-series data. You can use it with your own scripts, or, if someone is lazy like me, with some existing network monitoring system like Cacti, LibreNMS... (I use LibreNMS mostly). Then together with SNMP data gathering you can have some pretty graphs.

In this case LibreNMS uses a SNMP extension script - https://raw.githubusercontent.com/librenms/librenms-agent/master/snmp/gpsd that pulls all gpsd relevant data from the host and you can easily add it to already discovered available modules for that particular host / system. It does the auto-discovery of many known systems, so you can spend time on something else 😄

I cannot take your offer. It's too costly or risky for you. You maybe will not getting it back.

PS: i deleted you comment with the eMail address to protect you from spams.

[tiagofreire-pt]

@vukpm , consider re-installing a fresh version of raspberry pi OS, lite version, 64 bit, and follow this recipe: https://github.com/tiagofreire-pt/rpi_uputronics_stratum1_chrony

@beta-tester , feel free to take some tips and ideas from the tutorial above.

[beta-tester]

let me know if the tutorial gives better results.

[vukpm]

consider re-installing a fresh version of raspberry pi OS, lite version, 64 bit, and follow this recipe: https://github.com/tiagofreire-pt/rpi_uputronics_stratum1_chrony

@tiagofreire-pt
Thanks for sharing, I will take a look and find the differences. It's probably going to take me a couple of days to pinpoint what exactly resolves the issue (if it does of course).

I cannot take your offer. It's too costly or risky for you. You maybe will not getting it back.

PS: i deleted you comment with the eMail address to protect you from spams.

@beta-tester
The email address was an alias, exactly for spam reasons, but that's considerate of you.
Let me know if you change your mind. I've been using your script with RPi4 for quite a while and it saved me a good deal of time initially.. I can not help with your room temperature, but maybe I can with an rpi board..