RPi 3b+ offline mode

[dlengerer]

Hi,

i want to use the raspberry with a gps as an offline time source. I just changed the pps pin on the script to 18.

Otherwise unchanged I had the following chronyc sources output:

? NMEA 0 3 177 11 -435ms[ -435ms] +/- 200ms

? PPS 0 3 0 - +0ns[ +0ns] +/- 0ns

* PPSx 0 3 177 10 +355ns[ +817ns] +/- 283ns

- PPSy 0 3 177 8 +430ns[ +430ns] +/- 258ns

With the changes in chrony.conf to the "offline only mode" of the following sources output:

x NMEA 0 3 77 9 -452ms[ -452ms] +/- 200ms

? PPS 0 3 0 - +0ns[ +0ns] +/- 0ns

- PPSx 0 3 77 10 -1078ns [-1078ns] +/- 319ns

- PPSy 0 3 77 8 -1172ns[-1172ns] +/- 329ns

as i understand it, it's good that chrony is using pps as their primary reference. But there shouldn't be any question mark with nmea, should there?

[beta-tester]

hi, your first status view looks more or less good... PPSx has a '*', that means that this PPSx is used. PPSx is coming from the gpsd -service and is a combination of NMEA and PPS pin. if only a NMEA is available, it will generate a synthetic PPS signal as long there is no real physical PPS signal on the pin.

for chrony, NMEA must have a maximum time difference of 200ms between receiving NMEA strings on serial port and PPS pin. otherwise it is assumed as falsetick.

it looks you are at around 435ms

try to adjust the offset 0.6 and/or delay 0.2 parameters of the NMEA settings to bring the diff under 200ms.

to measure the diff of NMEA, it is recommend to connect the RPi to the internet and make use of a ntp server, keep the RPi + GPS + internet running for at least 30 minutes and see what the differenc is between NMEA and the ntp server. bring the difference down under 200ms.

if you found the right offset / delay value then you should be able to use your RPi fully offline.

in offline/online settings i disabled NMEA and main PPS in chrony with noselect, because in my environment it was more reliable to use PPSx that is generated by GPSD (it is usinf the NMEA and PPS data as well) my GPS isn't sending a constant good PPS signal. GPSD is generating synthetic PPS information on PPSx, then there is no real PPS signal sent on the pin. PPSy is the same as PPSx only on a different way/socket/protocol.

by using only PPSx i also prevent chrony from switching wild beetween PPS, PPSx and PPSy and spamming the syslog file with informaions of those switchings. (because in reallity all three PPS sources are from one and the same gps device - so all are in a similar range of accuracy)

in full offline settings i expect a reliable pps signal on the pin and force to use only PPS with the parameter prefer

[beta-tester]

sometimes it will help, when you reboot the RPi, when the gps has a fix after a coldstart and is sending pps on the pin... it may happen, when the gps is doing a coldstart that it takes too long to give a pps signal to the pin, befor chony gives up to use pps. when you reboot the RPi without powering off, then the gps is giving pps signal just at boot time.

[dlengerer]

Thanks for your help.

Now my chrony sources look like this:

- NMEA 0 3 377 8 -9514us[-9513us] +/- 100ms

* PPS 0 3 377 8 +159ns[+1591ns] +/- 264ns

- PPSx 0 3 377 8 +125ns[ +125ns] +/- 265ns

- PPSy 0 3 377 6 +202ns[ +202ns] +/- 190ns

the adjusted conf: ## SHM(0), gpsd: NMEA data from shared memory provided by gpsd #refclock SHM 0 refid NMEA precision 1e-1 offset 0.2 delay 0.2 poll 4 trust require refclock SHM 0 refid NMEA precision 1e-1 offset 0.148 poll 3 trust require ## PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds refclock PPS /dev/pps0 refid PPS precision 1e-9 lock NMEA poll 3 trust prefer ## SHM(2), gpsd: PPS data from shared memory provided by gpsd refclock SHM 2 refid PPSx precision 1e-8 poll 3 trust ## SOCK, gpsd: PPS data from socket provided by gpsd refclock SOCK /var/run/chrony.pps0.sock refid PPSy precision 1e-7 poll 3 trust

Looks fine, right?

[beta-tester]

yes, * PPS 0 3 377 ... +/- 264ns looks good now. the * PPS means the PPS source is used, the 377 means that you got 8 polling intervals in a row a proper PPS signal from the pin, and the average offset is also nice low with 264ns. and all PPS, PPSx, PPSy values are in the same range of accuracy.

PS.: you can observe the status of your GPS and NTP server by typing this in your terminal:

# chrony status
watch -n 10 -p sudo chronyc -m tracking sources sourcestats clients;

# primitive python based GPSD client (maybe you need install python-cairo to see the gui)
xgps &>/dev/null &

[beta-tester]

@Dan0207 , if you have interest to find the "perfect" offset for your GPS device, you can try out my gnuplot script. i updated the RPi-GPS-PPS-StratumOne project.

you can install gnuplot by hand and enable logging for refclocks in your current chrony configuration. log refclocks

after that, you can run:

# stop gpsd, stop chony, delete all log files, restart chrony and gpsd
# wait some seconds to give time to create a log file,
# and start the histogram.

sudo systemctl stop gpsd.* && sudo systemctl stop chrony && \
sudo rm -r /var/log/chrony/*.log && \
sudo systemctl start chrony && sudo systemctl start gpsd && \
sleep 10 && \
gnuplot ~/RPi-GPS-PPS-StratumOne/gnuplot/99-calibrate-offset-nmea.gnuplot

keep it running for at least 30 minutes. the longer you keep it running, the better results you will get. (but not longer than 24h, after 24h a new log file will start and the histigram starts from zero)

the histogram will develop slowly a dominant spike. the histogram will update every 60 seconds. the x-value of this dominant spike will be the "perfect" offset-value for your GPS device. you can zoom in and point with the mouse to the top of the spike. the x-value (and y-value) will be displayed in the bottom left (in default setting).