gpsd-users
[Top][All Lists]
Advanced

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

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


From: Beta Tester
Subject: Aw: Re: need help: have issues with gpsd-client under python
Date: Fri, 1 Jul 2022 09:02:15 +0200

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


> > > 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 - GMX 
call this new option "intelligent inbox" distributes emails in to subfolders.
i disabled that stupid new option.


> > > > Python sucks at threading, so I hope you dont really mean
> > > > threading. The python gpsd module is not tested for threading
> > > > either.
> > >
> > > unfortunately i am using threadding.Thread(). i also tried
> > > multiprocessing.Process(), but that was even more a fail.
>
> You are on your own with threading, you are the fist to try, and
> given Pythong "threading" I expect it to be a PITA.
>
> > > is there
> > > something else i can use from the console that let me run multiple
> > > gps.gps() sessions "parallel" ?
>
> I do not see why you could not open 2 conenctions with gpsd.open(), each
> its own class. AFAIK, the python gps class uses no statics or
> shared variables, but not tested.
>
> 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. everything sound 
to me like a bad hack.
does nobody use gpsd + python to monitor live their own fleet (delivery, 
logistic, ...) ?


> > > > > everything works well except:
> > > > >
> > > > > 1. `gps.next()` seems to get crazy from time to time in two
> > > > > ways. case 1: `gps.next()` blocks forever and never returns.
> > > > > case 2: `gpd.next()` returns the same gps record repeatly
> > > > > over and over.
> > >
> > > > I think you said later that you had a bad conenction, causing
> > > > that?
> > >
> > > 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.


> > > > > 3. when starting with `gps.gps(reconnect=True)`, when does a
> > > > > reconnect happen? i cannot see any difference between reconnect
> > > > > enabled or disabled. e.g., the gpsd-servers powers off and
> > > > > powers on again, gps.gps(reconnect=True) does not come back
> > > > > receiving gps data.
> > >
> > > > Souds like a missing "-n", but later you says you use "-n"
> > >
> > > 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. and i thought 
it is only for the gpsd-server side to not wait for a gps device in case of USB 
device.
how does that option affects the gpsd-client when it add the option 
reconnect=True ?


> That can work, but you are not checking that the new data is valid before
> using it to overwrite the NULL.
>
> > > > You are not always checking that items are set before trying to
> > > > save them to your DB.
> > >
> > > i use the conflict mechanism of the database - add new row is not
> > > already exist, if already exist, fill the missing columns.
>
> 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.
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`.


> > > > No one ever, ever, said the timestamps would be unique!
> > > > # DEBUG: detect running crazy (then receiving same timestamp
> > > > over and over)
> > >
> > > when the timestamp is exact the same for a very long time, then
> > > there is something wrong...
>
> Wrong, but not abnormal.
>
> > > 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.

only when gps.client.gpscommon.read() returns 0 at 
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.

does the `linebuffer` keeps the same data, while the gpsd-server vanishes 
during transmission ?
does `frag = soch.recv` does not notice that the gpsd-server is vanished ?
is there no check if `frag` contains no data ?
so every new call os `gps.read()` sends the same data over and over... doesn't 
it ?
so in that case i would get exactly the behavior receiving the same data and 
received timestamp over and over again.
what i "detect as running crazy".




reply via email to

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