[Top][All Lists]

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

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

From: Gary E. Miller
Subject: Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent
Date: Mon, 14 Sep 2020 10:50:42 -0700

Yo Marek!

On Mon, 14 Sep 2020 13:37:00 +0200
Marek Szuba <> wrote:

>  - the GNSS receiver is an u-blox NEO-M8N,

What signals are you using?  3.3V serial and 3.3V PPS?

> with the only change to its
> default configuration being that I have disabled BeiDou and enabled
> Galileo


> (TIMEPULSE; the driver has got the
> capture_clear option set to avoid the possible one-second offset)

What is this one-second offset you mention?  gpsd prefers to get both
PPS edges.

Before starting gpsd, have you confirmed that /dev/pps0 has good
data?  Here is how to check

# ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1600105457.964698936, sequence: 1587031 - clear  0.000000000, 
sequence: 0
source 0 - assert 1600105459.890976341, sequence: 1587032 - clear  0.000000000, 
sequence: 0

>  - 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

What does the SHM data look like?  Here is a sample:

 # ntpshmmon
ntpshmmon: version 3.21.1~dev
#      Name Seen@                Clock                Real                 L Prc
sample NTP1 1600105612.072177652 1600105611.999999472 1600105612.000000000 0 -20
sample NTP0 1600105612.161914767 1600105612.161782423 1600105612.000355529 0 -20
sample NTP1 1600105613.001030853 1600105612.999998878 1600105613.000000000 0 -20
sample NTP0 1600105613.159546423 1600105613.159483037 1600105613.000355735 0 -20

>  - while I do not see PPS lines in gpsmon output

gpsmon is not really supported anymore.

> 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;

One PPS every 5 minutes is not good.  It should be every seconds.

You need to go back to the beginning and look at what ppstest shows
you.  No point at looking at gpsd, or ntpd, until ppstest looks good.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgphjC5gTl1Nx.pgp
Description: OpenPGP digital signature

reply via email to

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