Re: PPS stopped once => stopped forever?

[Gary E. Miller]

Yo Ulrich!

On Fri, 11 Oct 2024 10:06:36 +0000
"Wielant, Ulrich" <U.Wielant@leonardogermany.com> wrote:

> Attached you find the output of the gpsdebuginfo script at a point of
> time when everything was running well.

Thanks.

> + gpsd -V
> gpsd: 3.25 (revision 3.25)

Still on old gpsd...  Newer gpsd handles serial drops better.

> + python -c 'import gps; print(gps.__version__)'
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> ImportError: No module named gps

The python parts of gpsd are missing!

> 33292 ?        S<sl   0:10 /usr/sbin/gpsd -G -s 38400 -n /dev/ttyS0

Looks good.  Except:

> # To allow gpsd remote access, start gpsd with the -G option and
> # uncomment the next two lines:
> # ListenStream=[::]:2947
> # ListenStream=0.0.0.0:2947

You are running under systemd(umb) which is configure to not allow -G.

> crw------- 1 root root    249,  0 Oct  8 12:51 /dev/pps0

Note that pps0 is root only!

> I configured the baud rate with -s 38400 to avoid the hunting.
> Attached you find the log of a case when a bad checksum was received.
> gpsd was now able to reconnect correctly. But PPS was removed.

Wrong order.  PPS was removed on the disconnect, before the reconnect
try.  

I need the entire log, from startup, to see what I need to see.  Without
that not much I can see in the gpsd_stop_pps.log

Anything in dmesg after the failure?

> Writing the time info to shm stopped although gpsd received NMEA data
> again. I would expect that SHM 0 is still updated because as far as I
> understand the SHM 0 time info is taken from he NMEA data.

Note that SHM(0) and SHM(1) are root only, but your gpsd has already
dropped root.  So gpsd can no longer open pps, SHM(0) or SHM(1).

> I am fine with using the -s parameter to configure a constant baud
> rate. I vote for continuing to update the time information to the
> shm, even if the PPS signal fails.

Can't vote against your OS permissions.

> I will try to find out if the hardware is buggy or if the cabling
> leads to faults.

You clearly have a bug in the path from the receiver to /dev/ttyS0.
Can yuo tell us something about that path?  Receivers come in various
voltage versions and a mistmatch causes issues like this.

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