Expose u-Blox min elevation and min SNR for RTK Fix Improvement

[wrsolichin]

This PR increases the minimum elevation for u-Blox GPS from 10 (default) to 15, which is useful for RTK Fix improvement as discussed in the following articles: https://mowerproject.com/2020/07/06/an-even-better-rtk-fix/ and https://discuss.cubepilot.org/t/here-does-not-hold-rtk-fixed-status-reliably-help-please/1056/64. The configuration item address is defined as below.

Currently, I have only set the hard coded value for the u-Blox GPS for the minimum elevation, but if it is useful we can expose it to PX4 autopilot, and also optionally expose the CFG-NAVSPG-INFIL_MINCNO for further improvement as discussed in the article.

[dakejahl]

Thanks for this! We should definitely make this configurable with PX4 parameters. Can you make the minimum elevation a member variable and add it the constructor? I'd also add the SNR while we're here and thinking about it. For now let's leave them at their previous default and once we do some testing with the new values (elevation 15, SNR 35) we can decide on if it's an overall improvement.

[wrsolichin]

Thanks for this! We should definitely make this configurable with PX4 parameters. Can you make the minimum elevation a member variable and add it the constructor? I'd also add the SNR while we're here and thinking about it. For now let's leave them at their previous default and once we do some testing with the new values (elevation 15, SNR 35) we can decide on if it's an overall improvement.

Thanks for the review. I've updated the u-Blox parameters to include the SNR, and added a member variable with the default constructor. I've set the default based on the F9 interface description as shown below.

Looking at the datasheet, the default for the minimum elevation for the M9 and F10 are slightly different, which is 5 degrees instead of 10 as shown below.

Once this is merged, should I create another PR in the https://github.com/PX4/PX4-Autopilot repository to expose the parameters to PX4? Or is there any workflow that I should follow?

[dakejahl]

Looking at the datasheet, the default for the minimum elevation for the M9 and F10 are slightly different, which is 5 degrees instead of 10 as shown below.

Hmm that's a good observation. F10 going from 5 to 15 seems significant. At the very least we should test this on all our ublox based GPS products to verify it doesn't inadvertently degrade performance @AlexKlimaj

[dakejahl]

Once this is merged, should I create another PR in the https://github.com/PX4/PX4-Autopilot repository to expose the parameters to PX4? Or is there any workflow that I should follow?

Go ahead and create the PX4 PR and link to this one, once this is merged you'll just update the submodule PX4 side before merge.

[dagar]

This looks like a good start, but we really shouldn't be force setting it across all modules.

Can we make the entire thing optional so it's only configured if a user explicitly configures it?

[dakejahl]

Good idea. How about we use value 0 as a special case to not configure?

[wrsolichin]

that sounds good, I've updated the default to be 0, and set them to only configure if it's not 0.

[dakejahl]

Any testing updates to share? Improvements with RTK lock?

[wrsolichin]

Any testing updates to share? Improvements with RTK lock?

I have done a different SNR and elevation testing with the u-Blox F9P, although quite subjective, i.e. only checking the RTK fix type after changing the parameters.

Using the default u-Blox parameters (SNR default at 6 dBHz, and elevation at 10 deg), I got RTK float as shown in QGC below.

Updating the SNR to 35 dBHz and elevation satellites to 15 deg, I got RTK fix as shown in QGC below.

Are there any better testing process to validate? Or is this sufficient?

[wrsolichin]

Sorry, I have just got back to looking at the u-Blox RTK fix improvements / avoid jump with RTCM drop outs, as I was working with other work before. Another issue we also encounter is this: PX4/PX4-Autopilot#21555, when our radio comms that broadcast RTCM corrections are poor. Looking at the u-Blox parameters, the only option I can find is delay reverting the RTK correction timeout as mentioned in this article (NAVSPG-CONSTR_DGNSSTO): https://support.thingstream.io/hc/en-gb/articles/8515724887964-When-my-rover-loses-RTK-fix-and-goes-into-3D-DGNSS-I-experience-a-sudden-meter-jump-in-position-DGNSSTO?auth_token=eyJhbGciOiJIUzI1NiJ9.eyJhY2NvdW50X2lkIjo5NDAyNzEwLCJ1c2VyX2lkIjpudWxsLCJ0aWNrZXRfaWQiOjk1NjksImRlZmxlY3Rpb25faWQiOjIzODcyNzEzMTU5MzI0LCJhcnRpY2xlcyI6WzEwNTM5NzMyNjAwNDc2LDg1MTU3MjQ4ODc5NjQsMjE4OTg3NTkyODM3NDBdLCJ0b2tlbiI6bnVsbCwiZXhwIjoxNzY2ODM2MjgyfQ.6NDb1DvAFjtZzwWIeat6jQjBahsm2JBjWWFz69_A7ok&solved=0. What do you think of adding this? I have done a quick test with the default of 60 s, and the plots are as shown below (interval of ~30 s of screenshots).

Delaying to 255 (4 mins and 15 seconds), it stays on RTK fix for longer period with the drift as shown in the plots below (similarly, with interval of ~30 s of screenshots).

The issue seems to be if the correction drops for a long time, and the RTCM correction is recovered after, it will not recover to RTK fix again.