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

[Gary E. Miller]

Yo Marek!

On Fri, 18 Sep 2020 14:39:56 +0200
Marek Szuba <scriptkiddie@wp.pl> wrote:

> Not really surprising given that they are the youngest of the Big 4
> and aren't even at full operational capacity yet. I'm mostly
> interested in it for testing purposes anyway, my list of active
> satellites on the stationary receiver consists on average of 2/3 GPS
> and 1/3 GLONASS regardless of whether the third enabled constellation
> is BeiDou, Galileo, or neither.

More important is how many of each, not what ratio.

> >> So I did pass capture_clear to pps-gpio.  
> > 
> > WHich may, or may not be the correct edge.  
> 
> I am afraid you have misunderstood me. The pps-gpio option which
> changes asserts from the rising to the falling edge is
> assert-falling-edge and I haven't touched that.

Are you sure you are on the correct edge?

> > How did you do that?  
> 
> This is what the capture_clear option of the pps-gpio DT overlay does!
> Mind you, it doesn't always seem to work correctly - if for instance I
> enable this on my Raspberry Pi 3 B+, clear values look okay at first
> but stop updating after a while (i.e. when I run ppstest, they are
> still non-zero but the same in every line).

Which sounds like a hardware problem on the gpio.  Nothing in gpsd
can make pulses on gpio go away.

> >> 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.  
> 
> I wish it were that simple...

I am sure I never said simple.

> Unfortunately what I meant by "ppstest
> looked okay" was that ppstest produced the expected output regardless
> of how gpsd was doing.

But just above you said " values look okay at first
> but stop updating after a while".  Which is it?

>  - having shut down gpsd with the receiver still powered and
> maintaining the fix (confirmed by looking directly at NMEA messages
> arriving at the serial port).

You keep saying you see things, but never show what you see. hard for
anyone to see what you are missing when we can't see what you see.

> I then cold-restarted the GNSS receiver, rebooted the Pi for good
> measure, waited for the time-pulse LED on the receiver to start
> blinking so that it has already established a fix, and launched
> chronyd and gpsd.

No need to wait to start gpsd and chrony.  Do you know you always
have a good fix?

> 1. cgps: shows a 3D fix with 13/30 satellites, reported UTC time is
> accurate. The initial set of messages (i.e. before "TPV" start
> showing up is

Which is the least intersting log output you could show us.

> OK, so it turns out that in spite of what it says on the box my
> receiver is actually a NEO-M8L rather than M8N.

Lucky you.  The M8L is a much more expensive part.

> Funny, I could have
> sworn that it said M8N here too before the factory reset... I don't
> think this will be a problem though, 'ubxtool -P 19.00 -p MODEL'
> reports the dynamic model as 0 (which IIRC is "portable", i.e. not
> automotive) and if I understand the documentation correctly M8L
> without automotive sensors connected to it will act like a M8N.

I dout that.  The only external connection to an M8L is the wheel pulse.

> 2. ppstest /dev/pps0: produces bursts of about 2,000 messages every
> second.

Once again, back to hardware problems.  If you can't make ppstest behave,
then software that uses PPS will of course fail.

> 3. ntpshmmon:

No point.  Always stop at the first failure.  If ppstest fails, not
point looking downstream.

> 4. 'ppstest /dev/pps0' continues to work fine.

Looks again like bad input to the gpio.  Maybe the gpio fails after
the CPU wamrs up.

> 5. The receiver's time-pulse LED continues to blink and connecting
> directly to the serial port (at 9600 bps) shows incoming NMEA
> messages.

Which you have never shared.

> Notice how 'bps' now reports 4,800 instead of the expected 9,600?

Either you rebooted, or something else touched the port.  That is not
the work of gpsd.

> Which gave me an idea for something to try - instead of restarting
> anything, I simply ran
> 
> stty -F /dev/ttyAMA0 9600
> 
> on another console. Et voila, cgps immediately began reporting having
> a 3D fix and NTP0 samples reappeared in ntpshmmon output.

Or, you could just wait for gpsd to autobaud.

> And all this time, 'ppstest /dev/pps0'
> continues to work.

And yet eariler you said it failed.

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

pgpe8tTAgCd5k.pgp
Description: OpenPGP digital signature