Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

[Robert L. <rob...@gp...>]

That's two of us that have failed to get an actionable question from you.

Apart from that, now I'm working on using a high resolution gps, such as
> the U-Blox EVK-M91, to perform surveys via QGIS and QField (which is the
> android version of QGIS). Basically, I have to use the U-Blox as a mouse :)
>

We're not an Android app. Becoming an Android app is non-trivial.

You probably want a GPS logger and not an eval board. Carrying a laptop and
trying to catch the bits live is an unnecessary distraction. I'd suggest
finding one of these that writes the NMEA sentences to a memory card so you
can read plain old NMEA files - either with GPSBabel or whatever parser
arouses you.

We don't do uBlox binary protocol, either streamed or logged.


> I tried to use the standard QGIS functions to read the coordinates from
> gps, but it doesn't work. Investigating, I saw that QGIS simply uses
> gpsBabel to take a single point at a time.
>
> So, I installed a gpsBabel and I went to analyze why gpsBabel returns
> error, and what were the right parameters
>

If you're a programmer yourself, you know that data like the contents of
that error are pretty important. Taking your car to the shop and saying "it
makes a funny sound" is less productive than "it makes a funny sound while
accelerating up a hilll in a sharp left turn". Those details matter a LOT.


 ]

>
>> You are sure because
>>   1) you read the documentation and it says it is NMEA, and if so which
>> version?
>>   2) you looked at the data stream and it looks like NMEA?
>>   3) something else?
>>
>
> none of this. Perhaps I have simply misunderstood the data in my
> possession.
>

Our guesses can be no better than yours.


>
>
>> I don't think GPSBabel supports this.
>>
>
It's not really in scope for our project. The only reason we do it at all
is because Google contracted me to add it years ago for Earth. :-)



>   gpsd (works well on u-blox F9, should be fine on M9)
>>     https://gpsd.io/
>
>
This is certainly closer to GPSD's bag of tricks than ours.



>
>>   [Note that if you start down the gpsd path, and want to ask for help,
>>    make sure that 1) you are not using systemd and 2) you are using the
>>    latest release or git master.   Requests for help with the version
>>    that shipped in some ancient long-term stable will not go well.]
>>
>
We have the same problem with Linux. They ship an ancient version, strip
off all the support information, then ship their support problems to us.
But that's not a rant I'm prepared to have right now.




>
>>   https://github.com/semuconsulting/PyGPSClient
>>   [I haven't tried this, but it looks interesting.]
>>
>
That's closer to what we do with our realtime tracking module, but our
per-format support is spotty. Since we lean on consumer-facing hardware,
things like RTCM3 protol just doesn't register for us.

Re: QGis, they actually use GPSBabel for most of their realtime tracking.
YOu can see the commands they build up in the doc at
https://docs.qgis.org/3.22/en/docs/user_manual/working_with_gps/plugins_gps.html

https://docs.qgis.org/3.22/en/docs/user_manual/working_with_gps/plugins_gps.html

Their examples use everything but NMEA, but that works in the "obvious"
(once paired with the links I sent yesterday) command lines.

This is also, not coincidentally, how realtime GPS tracking works in Google
Earth.

RJL