Re: need help: have issues with gpsd-client under python

[Gary E. Miller]

Yo Beta!

On Fri, 1 Jul 2022 09:02:15 +0200
Beta Tester <alpha-beta-release@gmx.net> wrote:

> > > no, the email button isn't working for me    
> >
> > Huh?    
> 
> i have no email application installed and firefox does not provide
> "webmail" for GMX.DE - there is only a third party "GMX MailChecker"
> add-on available i don't use  

Surely you can install an email client?  Or just open a gpsd issue
here, and do everythong on the web:
    https://gitlab.com/gpsd/gpsd/-/issues

> > > > for some reason some emails arrivey me with a huge delay.
> > > > this email i still not got yet - not in inbox nor in spam
> > > > folder. i try to use copy-n-paste from the thread index of the
> > > > mailing list.    
> >
> > Nothing we can do about nongnu.org email server speed.
> >    
> 
> oops, i noticed that some emails were stored in the "newsletter"
> section  

Not smething gpsd eople ever use.

> > You could run two copies of one program, one for each client.  Put
> > that database to good use.    
> 
> i thought threads are the most elegant/correct way to do this.  

In C, yes.  In Python, No.  Python has no real threading ecause of the
Global Inter Lock (GIL), and other issues.

> everything sound to me like a bad hack. does nobody use gpsd + python
> to monitor live their own fleet (delivery, logistic, ...) ?  

Lots of people do.  But commercial users of gpsd dont talk much.

> > > > gotcha, i have a poor WiFi connection.    
> >
> > Nothing we can do about that.    
> 
> this i thought the reconnect=True option is good for, that the
> gpsd-server does not close the connection to a gpsd-client when is is
> vanished for a short time/during transmission. and/or on client side,
> when the connection isn't able to "recycle/recover" that it tries to
> start a new connection to the gpsd-server without need of action from
> the application.  

gpsd client reconnect is new, and only meant for the rate, long term,
outage.  Not for frequent short outages.  Use gps2udp for bad connections
like yours.

> > > > i the tests i used the -n but in the normal use i forgot that
> > > > option. maybe it was going under may other silly sleep() issues.
> > > > i will add -n to the normal start as well.    
> >
> > Write a startup shell script, then you will not forget.    
> 
> startup script has now that option. but can't see any difference.  

That is a good thing.  You want every run to work the same.

> and
> i thought it is only for the gpsd-server side to not wait for a gps
> device in case of USB device.  

Well, not only, but nothing but good comes from "-n".

> how does that option affects the
> gpsd-client when it add the option reconnect=True ?  

Reconencts will be much, much faster.  Every reconnect does not need to
wait for the connection to the GPS receiver to complete.


> > I'm talking about the other direction.  Data from gps.read() is
> > often not set.  So you need to check it is valid before using it.
> > As per the example code previously discussed.    
> 
> i hope now i understand what you mean.  

Not yet.

> i added `get_finite(dict, key)` to my code, that only returns the
> float value, when it is a finite value, otherwise it returns `None`.  

As you say, only works for floats.  You gotta check the flags as well to
get the integers working.

> > > > that was my thought. anf in gps.gps(),
> > > > received gives time.time().    
> >
> > time.time() is unrelated to the time in the TPV and SKY messages.
> > They are not the current time, they are the times of the
> > measurements.    
> 
> i was looking in the gps.next(), gps__next__() and
> gps.client.gpscommon.read(), when it can happen that i get always the
> same data.  

Very common.

> only when gps.client.gpscommon.read() returns 0 at  

Return of 0 means OK.

> https://gitlab.com/gpsd/gpsd/-/blob/master/gps/client.py#L162 when
> "poll: partial message: returning 0." gps.data is filled with some
> data, but gps.response gets not to a point, where is will be set
> newly.  

Sorry, lost me...

> does the `linebuffer` keeps the same data, while the gpsd-server
> vanishes during transmission?  

Nope.

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

pgpWahrnpRvx3.pgp
Description: OpenPGP digital signature