Re: [gpsd-users] Polling for GPS data using python3 API

[pisymbol .]

On Tue, Aug 13, 2019 at 4:15 PM Mike Tubby <address@hidden> wrote:

On 13/08/2019 20:19, pisymbol . wrote:

On Tue, Aug 13, 2019 at 3:09 PM Gary E. Miller <address@hidden> wrote:

Yo pisymbol!

On Tue, 13 Aug 2019 15:03:42 -0400
"pisymbol ." <address@hidden> wrote:

> > The samples are buffering because you are not reading them.  You
> > need to keep up with the incoming messages.
> > 
>
> Yes, I see that and now that is what I'm doing. I wrote a poller
> process that is just reading samples continuously (no sleep)
> and emits a sample into shared memory for other threads to pick up.
> The change is being tested as I write this to see if the "lag" issue
> disappears that I saw on 3.9.

You shoud neither sleep, nor poll continuously.  Use the gpsd API to
wait on data available.

And in Python this looks like?

My reader just does this:

create gpsd session (gps.gps() etc.)

for report in session:

    if we should still be doing this:

         store report somewhere for a thread to pick up

Is there other magic out there I'm not aware of I should be using? This seems to drain the Trimble sentences continuously. Right? And this does follow the man page guidelines AFAICT.

I think you should be reading with select()

    https://docs.python.org/3.7/library/select.html

or using the high-level selectors module:

    https://docs.python.org/3.7/library/selectors.html#module-selectors


and treating the GPS handling as event driven, i.e. handing on a select for IO events and up-calling your processing code each time you get a new record from gpds.

On what socket? But stepping back: Doesn't this defeat the whole purpose of the client API? I want gpsd to do this for me (manage the socket, sampling rate, etc.) otherwise I am rewriting gpspipe in Python. Right?

-aps