gpsd-users
[Top][All Lists]
Advanced

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

Re: gpsd Example2.py


From: Gary E. Miller
Subject: Re: gpsd Example2.py
Date: Wed, 21 Sep 2022 11:58:54 -0700

Yo Dirk!

On Wed, 21 Sep 2022 06:34:57 +0000
Dirk Beer <rdbeer@pm.me> wrote:

> > > But https://gpsd.io/libgps.html shows:
> > > 
> > > session = gps.gps(host="localhost", port="2947")
> > > session.stream(flags=gps.WATCH_JSON)
> > > for report in session:
> > > process(report)
> > > del session  
> > 
> > 
> > That works too, except for the missing check that the proper message
> > got read.  
> Ok, good to know, thanks. Since example2.py is a more complete
> example, I'll work with that.

I guess I need to make it clearer in the doc that that libgps.html is just
a code fragment, to show off the Python iterator, and nothing more.

> > Try the latest example2.py, that should work. If it does not
> > then send a capture of your raw data: gpspipe -R -w 30 > raw.log  
> Ok, tried it (with gpsd started as root, and running the example as
> root or regular user) and now I do get lat, lons that change
> (great!). 
> 
> Follow up question: why is the output pairs of exact duplicates? 

Common question, it should be in our FAQ.  A GNSS receiver 

The GNSS receiver takes some measurements. Later the receiver takes some
time to calculate its postion.  Later the receiver sends the results of
it calcualtions (in unknown order) uut a slow serial connection  No way
to know what the receiver will send, or when it is done.  Data just
appears to gpsd.  Gpsd has to accept this data, process it, and pass
it on to its clints.

Gps could wait to get all the data for an epoch (measurement period)
but that would requite waiting for the next epoch data to appear, which
would add a lot of latency.  So, instead, gpsd passe sn data it receives
almost as soon as it gets it.  Since many protocols (like NMEA) repeat
the same data in many ways this leads to repeated data sent to the gpsd
clients.

No way around this.

>     root@pheromone:~# python3 example2.py
>     Mode: 3D(3) Time: n/a Lat 32.729173 Lon -116.993810
                        ^^^

What happened to your time?  Did you just start the receiver?

> If I set a measRate greater than the default 1000, I get more
> duplicates:

Yup, more data, more duplicates.  About the same number of "duplicates"
per epoch.

> Is there a way to get a single fresh reading each time the gps device
> produces it instead of these duplicates?

They are not really "duplicates".  And nopt, no way to change it.

>Ideally, I'd like to run
> code in response to a fresh gps output. 

Nothing stopping you.  If your time worked, you use that to tell when
you have a new epoch.  Then your choic: latency, versus "duplicates".

> This is the original reason I was comparing the two code examples, I
> thought that session.read() was supposed to be blocking and would get
> only fresh readings as they are output by the device, versus
> iterating on the session in the second example, which does not seem
> to be blocking.

next() and _next() are just shims over read(), to allow Pythin iterators.

No other difference, no idea what doc migh give that impression.

> I did try to get a raw log, but got this error after a few minutes:
>     root@pheromone:~# gpspipe -R -w 30 > raw.log

Sorry, my typo, this takes 30 seconds of data:

gpspipe -R -x 30

Note the -x, not 0w.

>     gpspipe: could not connect to gpsd 30:2947, can't connect to
> host/port pair(-6)

You hint is that it tried to connect to host "30".

> The attached raw.log is from running without the -w option and
> hitting ^C after 30 seconds.

Which is what the "-x 30" does.

> Haha, I misread "sock" as "lock". It's from an example somewhere on
> the web,

Almost every gpsd example on the web is wrong...

>     gpsd -s 115200 -n /dev/ttyACM0

You skipped over another one of my comments. ttyACM0 is a native USB
port.  Native USB ports have no "speed".  So the "-s 115200" has no
affect on anything. gpsd and Linux accept the "speed" and throw it away.

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


reply via email to

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