[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: Wed, 16 Sep 2020 10:59:00 -0700

Yo Marek!

On Tue, 15 Sep 2020 18:32:53 +0200
Marek Szuba <> wrote:

> >> with the only change to its
> >> default configuration being that I have disabled BeiDou and enabled
> >> Galileo  
> > 
> > Why?  
> Because I live in Europe and would rather use Galileo, hardware
> limitations of this receiver mean it can only simultaneously work with
> no more than three different frequencies, and since I would rather
> keep both GPS and GLONASS enabled BeiDou was the odd one out. BTW. I
> have since reset the received to factory settings to make sure there
> was nothing odd there and it only had GPS+QZSS and GLONASS enabled
> afterwards, I guess BeiDou must have been enabled by the unit vendor.

GLONASS has the worst timing of the big-4.  Galileo has the worst outage
record.  But most will never notice any difference.

> >> (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.  
> I saw this message while running gpsd in debug mode:
> KPPS:/dev/pps0 missing PPS_CAPTURECLEAR, pulse may be offset

That is telling you about a known bug in the pps-gpio driver.  It
only passes on edge, so clients can not auto-detect the proper
PPS edge.

If you pick the wrong edge, you are off by the pulse width (often 100 ms),
not by a whole second. 

> So I did pass capture_clear to pps-gpio.

WHich may, or may not be the correct edge.

> > Before starting gpsd, have you confirmed that /dev/pps0 has good
> > data?  
> Yes, that's what I meant when I said "'ppstest /dev/pps0' works fine".
> When I first tested it it looked exactly like
> > source 0 - assert 1600105457.964698936, sequence: 1587031 - clear
> > 0.000000000, sequence: 0  

Well, fine, except for missing "clear'.

> and after enabling capture_clear I began seeing non-zero values for
> clear as well.

How did you do that?

> > What does the SHM data look like?  Here is a sample:
> > 
> >  # ntpshmmon
> > ntpshmmon: version 3.21.1~dev

Looks good to me.

> Yes, almost exactly like this - except NTP1 lines show higher
> precision (-30) and there are way, way fewer of them than NTP0 ones.

The "precision" is a joke.  It is just a constant someone pulled out of
air air.  Itgnore it.

> >>  - while I do not see PPS lines in gpsmon output  
> > 
> > gpsmon is not really supported anymore.  
> I see. Might be worth not mentioning it in the Time Service HOWTO any
> more, then.

Eric wrote the howto, he likes gpsmon, so unlikely to happen soon.

> > 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.  
> That's the weird thing, last time I checked ppstest looked okay (i.e.
> a burst of quite a number of lines, haven't counted how many, every
> second) both at the beginning of a run and when ntpd had long stopped
> receiving samples from gpsd.

Well, that would be a harware or kernel problem.  Hard to say since it
is gone.

So far, looking good, do you have any questions?

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: pgpfqJpxy3udh.pgp
Description: OpenPGP digital signature

reply via email to

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