gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gpsd time service: PPS-synchronised SHM samples rare, both sources gradu


From: Marek Szuba
Subject: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent
Date: Mon, 14 Sep 2020 13:37:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

Hello,

I have run into a slightly odd problem while setting up gpsd-based time
source and I wonder if anyone here could give me some tips regarding
debugging this further.

Basic set-up:
 - the GNSS receiver is an u-blox NEO-M8N, with the only change to its
default configuration being that I have disabled BeiDou and enabled Galileo
 - the system is a single-board armhf computer (no, not a Raspberry Pi)
running Debian Buster + kernel 5.8 + gpsd-3.21. It receives data from
the received using its built-in UART (NMEA) and a dedicated GPIO pin
handled by the pps-gpio driver (TIMEPULSE; the driver has got the
capture_clear option set to avoid the possible one-second offset)
 - gpsd is invoked as root, with the options "-n /dev/ttyS1" (I have
confirmed using lsof that it after trying to assigning PPS line
discipline to the serial port and finding out there is no DCD there, it
picks up /dev/pps0 by itself)
 - ntpd (I started out with chrony but kept running into problems
regardless of which refclock mode I used so I decided to try to get the
more conservative option running first) uses SHM segments 0 and 1 as
refclocks, both configured exactly as described in the gpsd Time Service
HOWTO

Initial state:
 - hooking screen up to /dev/ttyS1 before starting gpsd shows correct
NMEA sequences coming in
 - given enough time after start-up the receiver gets a 3D fix, as
attested to by both cgps/gpsmon output and the fact its time-pulse LED
begins to blink every second
 - while I do not see PPS lines in gpsmon output (it seems that once
started, gpsd switches the receiver from NMEA to binary u-blox output),
I do see '"pps": "true"' in the status summary and there *are* TOFF
lines in 'gpspipe -wP' output. Moreover, 'ppstest /dev/pps0' works fine
and starting gpsd with '-D 5 -N' does show PPS- and KPPS-related information
 - ntpshmmon does show NTP samples in both SHM 0 and SHM 1

The problems:

1. Right off the bat, the PPS-synchronised time source pushes way fewer
samples to shared memory than the in-bound one: ntpshmmon shows NTP0
samples arriving every second but NTP1 only shows up every 5 minutes or
so. As a result, ntpd ends up considering SHM(1) as unreachable most of
the time;

2. As time passes, BOTH sources produce fewer and fewer samples.
Eventually they seem to stop altogether: having run the test system for
around 24 hours I saw 'ntpq -p' saying that it had last received
anything from the two refclocks 10 hours earlier. This is in spite of
cgps continuing to show an up-to-date 3D fix and 'ppstest /dev/pps0'
still working fine.

Any ideas how to proceed here? Any suggestions will be very much
appreciated, and of course do not hesitate to ask should you have any
questions.

Thanks in advance,
-- 
MS



reply via email to

[Prev in Thread] Current Thread [Next in Thread]