decrease timeout from RTK to DGNSS when no RTCM are available

[JonasPerolini]

Setup:

• Two F9P GNSS units with software HPG 1.30
• Baseline: 82.2 cm
• AP: PX4 v1.13
• dual GPS heading is enabled. (GPS_UBX_MODE = 1)

Experiment:

• Move the two GPSs at constant speed and at some point unplug the secondary GPS (repeat experiment 3 times)

Issue:

• When the secondary GPS is unplugged, the output rate of the primary GPS drops from 8Hz to 1Hz in QGC, more precisely in the MAVLINK inspector gps_raw field. After 1 minute, the primary GPS rate goes back up to 8Hz. After further experiments, I've observed that the time during which the output rate of the primary GPS drops to 1Hz corresponds to the value of the F9P GNSS unit param: CFG-NAVSPG-CONSTR_DGNSSTO
• U-blox manual p.18: The rover will stop using RTCM corrections that are older than 60s (default value) and will drop back to a 3D or 3D/DGNSS mode. This is meant to prevent the computation of grossly misleading differential solutions. If desired, this value can be changed through the CFG-NAVSPG-CONSTR_DGNSSTO configuration item
• Furthermore, when the secondary GPS is unplugged, the epv/eph measures instantly drop to a low value (similar to when we are in RTK fixed with a ground static-base sending RTCM corrections i.e. precise global position). However, the epv/eph should increase instead or at least remain more or less constant.

Explanation

• In this dual GPS heading setup, the secondary GPS sends RTCM to the main GPS. Once I disconnect the secondary GPS, the main GPS doesn't receive any new RTCM data. Therefore the main GPS uses the last RTCM data during 1 minute (and the fix type stays at 6).
• Now this does not explain why the rate drops in the MAVLINK console or why the epv/eph drop. Any ideas @dagar @bkueng ?

Proposed solution:

• Modify CFG-NAVSPG-CONSTR_DGNSSTO to 2 seconds
• Update the rate of RTCM message type 1005 from 0.2 Hz to 1 Hz accordingly. (To avoid dropping from RTK to DGNSS). A screen shot below from the U-blox manual shows that they set up RTCM 1005 at the same rate as other RTCM messages

• Note: we can't only modify CFG-NAVSPG-CONSTR_DGNSSTO to 2 seconds when in the dual GPS heading set up because it's possible to have both ground corrections and dual GPS heading in parallel.

Results:

• I've tested the proposed modifications once with CFG-NAVSPG-CONSTR_DGNSSTO = 15s and with CFG-NAVSPG-CONSTR_DGNSSTO = 2s (see plots below)
• We indeed observe that the epv/eph drops for 15 s (see purple rectangle) and roughly 2 seconds (see purple circles) when CFG-NAVSPG-CONSTR_DGNSSTO** = 15s and 2s respectively indicating that this solves the issue
• The rate drop is not visible in either plot. To be further investigated.

[bkueng]

I've seen the drop to 1Hz as well, and I believe it's trying to wait until it gets RTCM data with a 1s timeout. I did not see it being mentioned in the docs either.

btw you can log all gps samples by changing this: https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/logger/logged_topics.cpp#L191

[bkueng]

How much does this affect bandwidth?

[JonasPerolini]

Could you please test it? @bkueng (I won't have access to the F9P until September)

[bkueng]

I might be able to test it.

[bkueng]

Probably ok, but it means it will also fall out of RTK with base station quite quickly

[JonasPerolini]

From your experience, the RTCM data does not arrive at 1Hz?

The other options that I see are:

• set it to a higher value i.e. 3 (which is already much better than 60s)
• create a parameter for CFG_NAVSPG_CONSTR_DGNSSTO and let the user chose.

[bkueng]

From your experience, the RTCM data does not arrive at 1Hz?

Yes but the datalink might not always have perfect connectivity.

We can set it to 3. The other option would be to just set it to the one that gets the heading corrections (it does not get the RTK base station corrections at the same time).