gpsd-users
[Top][All Lists]
Advanced

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

AW: PPS stopped once => stopped forever?


From: Wielant, Ulrich
Subject: AW: PPS stopped once => stopped forever?
Date: Mon, 28 Oct 2024 06:28:53 +0000

Hi Gary!

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

Yea, I will put that on my TODO list to check the latest git code.

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

I don't use python so does it matter to me?

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

Ok, I may remove -G because I use local connections only.
Anyhow where would I have to uncomment the lines? The gpsd man page does not 
mention the ListenStream config.

>
>> crw------- 1 root root    249,  0 Oct  8 12:51 /dev/pps0
>
>Note that pps0 is root only!

I can change that to 666. Does that mean that gpsd can use PPS again when the 
GPS is back again?

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

The entire logs are *big* because the problem does not occur often. Is there 
any good way to strip down the logfile so that all interesting things remain?

>
>Anything in dmesg after the failure?

No, just:
[1279323.350188] pps pps0: removed
[1279473.387246] pps pps0: new PPS source serial0 [1279473.387273] pps pps0: 
source "/dev/ttyS0" added

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

Ok, understood. Is there any way to change that?
I am using chrony. Does this problem disappear by using sockets instead of SHM?
I have found /@RUNDIR@/chrony.XXX.sock and /@RUNDIR@/chrony.clk.XXX.sock in the 
documentation.

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

The receiver accepts 8-32Vdc and is connected with 24Vdc. So that's ok.
But I am more and more convinced that the GPS firmware is buggy and the GPS 
sometimes resets.

>
>RGDS
>GARY

Thanks!
Ulrich


-----Ursprüngliche Nachricht-----
Von: gpsd-users-bounces+u.wielant=leonardogermany.com@nongnu.org 
<gpsd-users-bounces+u.wielant=leonardogermany.com@nongnu.org> Im Auftrag von 
Gary E. Miller
Gesendet: Freitag, 11. Oktober 2024 22:15
An: 'gpsd-users@nongnu.org' <gpsd-users@nongnu.org>
Betreff: Re: PPS stopped once => stopped forever?



+++++
VORSICHT: Externe E-Mail. Seien Sie besonders vorsichtig beim Öffnen von 
Anhängen und Links unbekannter Absender.
CAUTION: External email. Be especially careful when opening attachments and 
links from unknown senders.
+++++


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
LEONARDO Germany GmbH
Sitz der Gesellschaft / Registered Office: Neuss
Registergericht / Register Court: Neuss HRB 17453
Geschäftsführer / Managing Director: Andrea Gaggelli

reply via email to

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