Re: gpsd time service: PPS-synchronised SHM samples rare, both sources gradually less and less frequent

[Gary E. Miller]

Yo Marek!

On Tue, 15 Sep 2020 18:32:53 +0200
Marek Szuba <scriptkiddie@wp.pl> 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?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

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

pgpfqJpxy3udh.pgp
Description: OpenPGP digital signature