On Thu, Aug 15, 2019 at 4:18 PM Gary E. Miller <
address@hidden> wrote:
Yo pisymbol!
On Thu, 15 Aug 2019 09:10:48 -0400
"pisymbol ." <address@hidden> wrote:
> Or I think what might be more lightly than all of the above is the
> sample() call is happening at irregular rates.
Duh. Of course it is irregular. No GNSS receiver outputs consistent
NMEA streams. gpsd just passes on what it gets, when it gets it.
Note: I sent you code in my last email, not sure why you didn't see get it?
The question is how irregular? But more importantly, looking at the gps/client.py and gps/gps.py files, it seems that the next iterator devolves into a sock.recv() (L115) of 8k. Question: Why isn't it using select I/O itself like gpspipe? Does that turn out to be slower? I suspect what is happening is occasionally on the Trimble side, it's takes a long time for it to emit NMEA strings for whatever reason. I'm still working out some metrics though.
> report: {'lat': 41.671888994, 'time': 1565874479.3, 'lon':
That is not gpsd code. I have no idea what that is. And without
source code I'll not look at it.
I sent it in the prior email. But basically 'report' is the TPV output from my for loop and sample is when a different thread grabs the most recent report.
> It seems I have thundering herd of sample() calls which is causing me
> grief! :-(
What do you expect at 10Hz?
Well, that's a good question. It seems the hardware will emit GGA and RMC strings at 10Hz but what it emits at the socket over the wireless seems to be quite another story.