[4.4.1](MambaH743) GPS position lags 10 seconds behind when "GPS Rescue" is enabled as failsafe, causing a 100% flyaway in RTH situations

[Auge103]

Describe the bug

When "GPS Rescue" is enabled as stage 2 failsafe, the GPS position shown in the OSD and used for BF rescue mode has an offset of about plus 10 seconds to the real position of the H743 flight controller.
This causes
a) the home direction indicator and distance shown in the OSD to always point in the wrong direction
b) the aircraft to fly away uncontrolled in a random direction in a rescue situation (either forced through failsafe or through a manual RTH switch)

The shown GPS data (OSD and telemetry) is still matching the real aircrafts position, only 10 seconds delayed.
When loading the logged GPS telemetry data into Google Earth, the flightpath is 100% accurate.

When the stage 2 failsafe option is switched from "GPS Rescue" to just "Drop" (rescue disabled), the FC will then show its non-delayed position on the OSD and the home direction indicator and distance will work as intended, without any delay at all.

This bug will cause a non-recoverable flyaway when GPS Rescue is enabled and the failsafe gets triggered through signal loss.

To Reproduce

With my FC, just enabling the "GPS Rescue" in stage 2 of the failsafe is enough to trigger the delayed GPS data processing.
When manually triggering the RTH feature via switch, the aircraft will flyaway until abortion by the pilot.

Disabling the "GPS Rescue" will switch the GPS behavior back to real time processing.

Expected behavior

The GPS data should always be processed in realtime and not be delayed when GPS Rescue is enabled.
Flyaways should not happen.

!GPS Rescue was working 100% reliably in BF4.3 on the very same aircraft and hardware!

Support ID

0da0ee24-0f1a-45ba-8aa5-5ff71b1d0b78

Flight controller

Diatone Mamba H743

Configuration:

Other components

VTX & Camera: Caddx Vista
ESC: Diatone MAMBA F55_128K
GPS: iFlight FPV M8Q-5883-GPS Module V2.0
RX: BETAFPV ELRS Nano 868Mhz

How are the different components wired up (including port information)

GPS is wired to UART4
Caddx Vista is wired to UART 3
RX is wired to UART 1
ESC is wired to UART6

Add any other context about the problem that you think might be relevant here

To better visualize the bug: this is the view of the OSD during flight:

This is the GPS flight path from the telemetry logs. The path is accurate and does match the video. I've drawn the locations of the aircraft, indicated home point and real home point from the picture above into the flight path one:

The full flight video is here, the delayed GPS position is clearly visible in the OSD. A manually triggered RTH with flyaway is visible at 1:10 -> 1:18 , at which point I aborted the test.
The still frame from the two pictures above is taken at approx. 1:33

I'm available for additional testing if you need more data to debug this issue.

[chessfracas]

Similar experience here, although 50/50; sometimes behaving wonderfully, sometimes a drastic roll and lateral flight direction to somewhere else.

• BF 4.4.1 (LMNR/LUXAIO)
• Lumenier LUX HD AIO F7
• Goku GM10 Mini V3

Also available to collect data and or test.

[ctzsnooze]

@Auge103 sorry to hear it is unstable for you.

GPS data updates (altitude, position, etc) are not part of the 'GPS Rescue' code. They are acquired by other code that talks to the GPS module. GPS Rescue just asks for the latest values, repeatedly, and as soon as the GPS hardware code says, "yes, we have a new value", then the GPS Rescue code acts on those values.

GPS Rescue code is fairly CPU intensive. It could be that your CPU is getting overloaded by the additional overhead.

By default GPS Rescue requests Barometer code. If the Baro is slow (eg on i2c bus not SPI bus) then that could perhaps cause problems.

If the GPS Unit is connecting at a low baud rate, or failing to connect at 10Hz, the OSD display will be OK, but the data will not be sufficiently frequent, or be intermittent, when used for a GPS Rescue.

Are you able to make blackbox logs with this flight controller? If so please make a log with the debug set to gps_rescue_tracking and share via dropbox.

Do you have other GPS modules you can try? Most users find the GPS Rescue code works fine. The handful of people with difficulties usually find that a different GPS hardware module solves the problem. Some modules won't connect at higher speeds that we need for a GPS rescue.

[ctzsnooze]

In the video, the arrow is not quickly rotating to point back to home. It should turn and point back to home, when flying away, quickly and readily. It appears to not be updating properly. I expect you have an underlying issue with the GPS module.

There were changes in 4.4 that requested a faster update from the module, and if the module cannot deliver those, or connects at a very slow baud rate, we get this issue.

[Auge103]

GPS Rescue code is fairly CPU intensive. It could be that your CPU is getting overloaded by the additional overhead.

Possible, but unlikely? It runs on an H7 processor, which should be the fastest one currently supported by BF, no?

If the GPS Unit is connecting at a low baud rate, or failing to connect at 10Hz, the OSD display will be OK, but the data will not be sufficiently frequent, or be intermittent, when used for a GPS Rescue.

You might be onto something.
I've set the GPS settings in BF to use the UBLOX protocol and also enabled support for the GALILEO constellation, which is obviously working as the module got all 21 sats in sight - only possible with 3 constellations simultaneously.
But as I just found out, the U-Blox M8Q module only supports 10hz with two constellations, not with three.
1 Constellation = 18hz, 2 Const = 10hz, 3 Const = 1hz, afaik.

Is it possible that BF sets the GPS module settings to 10HZ and 3 constellations at the same time and causes these issues either in its internal GPS functions or in the GPS module itself? If thats the case, this shouldn't be possible to be set by accident. (I'll test it)

In the video, the arrow is not quickly rotating to point back to home. It appears to not be updating properly. I expect you have an underlying issue with the GPS module.

As I already said, when I disabled the GPS rescue mode in the failsafe settings, but left the general GPS function in BF enabled, the arrow and data started behaving as expected and the arrow was updating in realtime to the correct position. This was confirmed during the very next flight after my posted video one.
Does enabling RTH in failsafe also enable the 10hz update rate or change other settings in the GPS module that are not set without RTH?
Also I used GPS RTH in BF4.3 for a very long time and never experienced any issues - this started only after updating to 4.4.

Are you able to make blackbox logs with this flight controller? If so please make a log with the debug set to gps_rescue_tracking and share via dropbox.

Of course. I'll gladly do that in a few days when I'm able to fly the hardware again.
Also I'll test with 2 & 3 constellations to see if thats a factor.

[haslinghuis]

Please test: #12725

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[github-actions]

Issue closed automatically as inactive.