gpsd-users
[Top][All Lists]
Advanced

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

Re: gpsd Example2.py


From: Dirk Beer
Subject: Re: gpsd Example2.py
Date: Thu, 22 Sep 2022 00:22:33 +0000

Thanks again, Gary

------- Original Message -------
On Wednesday, September 21st, 2022 at 11:58 AM, Gary E. Miller <gem@rellim.com> 
wrote:
> 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.
I was unsure if the Python iterator was doing something different than read(), 
I did understand it was not a complete code example. I thought in my testing 
that the iterator ran much faster and produced more duplicates than read(), but 
that was a mistake on my part - I just tested again and as you suggest they 
produce the same speed & output.

> > 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.
Understand now, thanks for explaining.

> > 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?
>
I don't know, trying to track this down now. gpscsv does show times, so not 
sure why example2.py isn't for me.

> > 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".
OK, great, this is exactly what I'll do once I get time working.

> next() and _next() are just shims over read(), to allow Pythin iterators.
>
> No other difference, no idea what doc migh give that impression.
My mistake/misunderstanding, nothing wrong with the docs.

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

Sorry if I missed a comment, if you mean your question about why I am using 
both the device and socket, it's because I didn't know any better. 

So now I've switched to just using the device, and the way I start gpsd is now 
in the root crontab like so (taking out the -s that doesn't have any effect): 

    @reboot /usr/bin/sleep 5 && /usr/local/sbin/gpsd -n /dev/ttyACM0

Hopefull this is right, please let me know if I am still missing something.

Cheers,
Dirk



reply via email to

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