Problem with rtk example

[Adam-Piech-BOT]

I seem to have an issue with RTK example. I'm trying to send NMEA so that the system can interpret position and send back proper data.
This work fine with GGAMODE=1. However when switched to GGAMODE=0, I cannot get any corrections. The GNGGA is being read correctly though. But it would seem that the call to send the NMEA to the mountpoint is never active.

[semuadmin]

Hi @Adam-Piech-BOT

Sorry you're having difficulties.

Apologies - please ignore my earlier responses. I've realised there's an issue with the example code (though the underlying GNSSNTRIPClient code is working fine). In order to use 'ggamode' = 0, the code needs to obtain the live navigation solution from the receiver. In order to do this, the calling application must implement a method of 'get_coordinates()' which returns the current connection status, lat, lon, height and separation from geoid.

In the case of the 'rtk_example.py' example, the calling application is set to 'None', which means there is no 'get_coordinates' method to invoke.

I'll need to amend the example to work with 'ggmode = 0'. In the meantime, it should as you say work fine with 'ggamode = 1'.

Apologies for the confusion. I'll get back to you with an updated example as soon as I can. In the meantime, the PyGPSClient GUI application uses the same underlying library and should work fine.

[Adam-Piech-BOT]

Well, I honestly just needed to write script that would connect to mountpoint which selects base automatically based on NMEA GNGGA/GNRMC and then redirect incoming data to USB port and then read UBX with that NAV message with high precision. So ultimately I just written it from the scratch. I do wonder if your lib allows for manual calibration of the chips with UDR?

[semuadmin]

Hi @Adam-Piech-BOT

FYI I've uploaded an updated version of the rtk_example.py script which should now work fine with GGAMODE = 0 (live) or 1 (fixed). I've added a couple of other improvements as well.

This is only intended to provide an example of how to use the GNSSNTRIPClient class - it's not intended to be a production-strength NTRIP Client, though it should function well enough.

Re. your final point, by 'UDR' I presume you're referring to Untethered Dead Reckoning using something like the ZED F9L or NEO-M9L? What exactly did you have in mind?

[Adam-Piech-BOT]

Indeed. I was using M8U with some success and wanted to move to F9 variant with this system embedded in the core as well. However, to my understanding the UDR is self-calibrating, and it's something that I've seen while doing tests. It requires somewhat significant acceleration differences to properly self-calibrate and it takes time. The issue I had with this is that I was trying to adapt it for low-velocity use and that caused the system to be stuck in self calibration loop. Apparently there is a way of forcing UDR by doing manual calibration?

[semuadmin]

This is probably more a question for the u-blox support forum - I'm not too sure of the answer myself and so-called "GAWT" solutions can be tricky to set up properly.

For devices with inbuilt IMUs, there are a few configuration options you could explore, e.g. for F9* devices:

CFG-MOT-GNSSSPEED_THRS - governs minimum speed recognised as 'motion'
CFG-MOT-GNSSDIST_THRS - governs minimum distance travelled recognised as 'motion'
CFG-NAVSPG-DYNMODEL - governs which 'dynamic model' the receiver uses for its navigation solution (e.g. Pedestrian, Automotive, Nautical, Aeronautical, etc.)

It's also worth referring to the Integration Manual for your particular device for the initial calibration requirements e.g, from the F9K Integration Manual:

"ZED-F9K produces a solution that combines GNSS signals with data from gyroscopes,
accelerometers and wheel tick sensors to compute a fused navigation solution. The solution type is
called GAWT, and it is described in the following sections.
To operate the ZED-F9K in GAWT mode with optimal performance, the following tasks need to be
completed:
• The IMU misalignment angles are also essential. It is recommended to enable automatic
alignment with the CFG-SFIMU-AUTO_MNTALG_ENA key, if misalignment angles are unknown.
The misalignment angles can also be configured manually with CFG-SFIMU-IMU_MNTALG
keys. Configuring misalignment angles manually speeds up the calibration procedure.
• It is mandatory to perform an initial calibration drive after flashing software, a cold start,
or changing sensor configuration keys (CFG-SFCORE-, CFG-SFIMU-* or CFG-SFODO-).
The calibration drive allows the software to detect and calibrate the sensors. See section
Accelerated Initialization and Calibration Procedure for additional information. Performance is
likely to be sub-optimal if the calibration drive is not performed correctly.
• If the maximum counter value of a wheel tick sensor cannot be represented as a power of 2
value, it must be configured manually. See section Odometer Types for additional information.
• It is strongly recommended that RTCM stream is available during the initial calibration drive, so
that the resulting calibration parameters can be estimated. more accurately."

The u-blox forum should be able to provide additional guidance.

[Adam-Piech-BOT]

Oh, okay. This is new. I don't recall those in the previous generation. Thanks.

[Adam-Piech-BOT]

[semuadmin]

apologies @Adam-Piech-BOT - I've amended my original response - see comments above (to avoid confusion I've removed your responses to my original incorrect response)