[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
pgp6h4kSYlsB4.pgp
Description: OpenPGP digital signature