[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
- gpsd Example2.py, Dirk Beer, 2022/09/20
- Re: gpsd Example2.py, Gary E. Miller, 2022/09/21
- Re: gpsd Example2.py, Dirk Beer, 2022/09/22
- Re: gpsd Example2.py, Dirk Beer, 2022/09/22
- Re: gpsd Example2.py, Gary E. Miller, 2022/09/22