gpsd-users
[Top][All Lists]
Advanced

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

Re: gpsd tcp NMEA feed


From: Gary E. Miller
Subject: Re: gpsd tcp NMEA feed
Date: Mon, 26 Sep 2022 20:06:01 -0700

Yo Nick!

On Mon, 26 Sep 2022 12:13:33 +0100
Nick Taylor <nicktaylor@dataskill.uk> wrote:

> You may recall in the dim and distant past we hassled you for a
> change to make the tcp NMEA feed option more reliable and
> resilient... It has taken us a long long time to get approval to test
> this on our customer installations but we are now able to see how the
> option performs in the real world.

Taht took awhile...

> For some reason the feed works fine for a while and then gpsd stops 
> receiving feed - even though we can verify feed using telnet. I have 
> managed to setup a fail situation which may or may not be similar to 
> what's happening in the field, however I think this is still a valid 
> case where it would be nice if gpsd could reconnect to the feed.

Worth fixing no matter what.

> My test setup is as follows:
> 
> Machine A running std gpsd with feed from hardware device
> 
> Create tcp feed from machine A as per your docs:
> socat EXEC:'gpspipe -r' TCP-LISTEN:2948,reuseaddr,fork
> 
> Machine B run gpsd in debug mode:
> gpsd -D5 -n -N tcp://192.168.2.53:2948
> 
> All good so farnow interrupt the feed from machine A as follows:
> iptables -I OUTPUT -d 192.168.2.52 -j DROP; sleep 1200; iptables -D 
> OUTPUT -d 192.168.2.52 -j DROP

iptables is obsolete, but that works.  I might try:

    ip route add blackhole 192.168.2.52
    sleep 1200
    ip route delete blackhole 192.168.2.52

> 
> Machine A we see this:
> 2022/09/26 09:55:07 socat[16311] E write(7, 0x7f674db0, 8192): 
> Connection timed out
> 
> gpsd log on machine B loops as follows:
> gpsd:PROG: CORE: pselect: timeout
> gpsd:PROG: checking client(0)
> gpsd:CLIENT: <= client(0): ?WATCH={"enable":true,"json":true};
> 
> gpsd:PROG: awaken(0) fd 7, path tcp://192.168.2.53:2948
> gpsd:PROG: device 0 (fd=7, path tcp://192.168.2.53:2948) already
> active. gpsd:CLIENT: => client(0) len 278: 
> {"class":"DEVICES","devices":[{"class":"DEVICE","path":"tcp://192.168.2.53:2948","driver":"NMEA0183","a
> ctivated":"2022-09-26T09:37:29.345Z","flags":1}]}
> {"class":"WATCH","enable":true,"json":true,"nmea":false,"raw":0,"scaled":false,"timing":false,"split24":false,"pps":false}
>  
> 
> 
> gpsd:PROG: CORE: pselect: timeout
> gpsd:PROG: gpsd_multipoll(7) DEVICE_UNCHANGED for 5
> gpsd:PROG: checking client(0)
> gpsd:CLIENT: <= client(0): ?WATCH={"enable":true,"json":true};
> 
> gpsd:PROG: awaken(0) fd 7, path tcp://192.168.2.53:2948
> gpsd:PROG: device 0 (fd=7, path tcp://192.168.2.53:2948) already
> active. gpsd:CLIENT: => client(0) len 278: 
> {"class":"DEVICES","devices":[{"class":"DEVICE","path":"tcp://192.168.2.53:2948","driver":"NMEA0183","a
> ctivated":"2022-09-26T09:37:29.345Z","flags":1}]}
> {"class":"WATCH","enable":true,"json":true,"nmea":false,"raw":0,"scaled":false,"timing":false,"split24":false,"pps":false}
>  
> 
> 
> gpsd:PROG: CORE: pselect: timeout
> gpsd:PROG: checking client(0)
> gpsd:CLIENT: <= client(0): ?WATCH={"enable":true,"json":true};
> 
> gpsd:PROG: awaken(0) fd 7, path tcp://192.168.2.53:2948
> gpsd:PROG: device 0 (fd=7, path tcp://192.168.2.53:2948) already
> active. gpsd:CLIENT: => client(0) len 278: 
> {"class":"DEVICES","devices":[{"class":"DEVICE","path":"tcp://192.168.2.53:2948","driver":"NMEA0183","a
> ctivated":"2022-09-26T09:37:29.345Z","flags":1}]}
> {"class":"WATCH","enable":true,"json":true,"nmea":false,"raw":0,"scaled":false,"timing":false,"split24":false,"pps":false}
> 
> Feed can be seen on machine B using telnet, but it seems gpsd doesn't 
> notice the failed connection and the only way I found to recover is
> to restart gpsd

Looks to me like it sees the failed connection, otherwise why would
it try to awaken the device again?

I can work with that, but right now I'm beating my head on some more
Quectel Querks.  Both these bugs will be non-trivial, so I need to
focus.  Both look important to me...

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

Attachment: pgp6h4kSYlsB4.pgp
Description: OpenPGP digital signature


reply via email to

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