GPS altitude, distance to home recovery issues after GPS satellites briefly lost

[CharlViljoen]

Current Behavior

INAV 8.0.1
During maiden of Chupito the GPS lost connection for a short time. The altitude went to zero and same for distance to home. The total flight distance went to 214 km. Even after the GPS recovered these values remained for the rest of the flight.
The GPS was mounted inside, to the underside of the battery bay cover. Observing maximum of 8 satellites during the flight.
In comparison with the Dolphin and the Dolphin Pro where the GPS was mounted outside on top where 28 satellites observed on the same morning. All using same GPS module (HGLRC Mini M100)
I can solve the reduced satellites by mounting the GPS outside and potentially avoid GPS connection lost.

However, Please if Dev team can investigate and address the recovery scenario.

Steps to Reproduce

1. Simulate GPS loss and re-connection.
2. Observe altitude
3. Observe distance to home
4. Observe total flight distance

Expected behavior

Altitude and distance to home to recover.
Total flight distance leaving for your discretion as this might not be possible to solve accurately.

Suggested solution(s)

For your discretion.

Additional context

CLI diff not relevant. What I do have is the video recorded by my DJI03 Goggles.

---

INAV/SPEEDYBEEF405WING 8.0.1 Mar 28 2025 09:52:26 (ee47bcba)

• FC Board name and vendor:
  FC Board: SpeedyBee F405 WING MINI Fixed Wing Flight Controller
  Vendor: SpeedyBee

[Jetrell]

@CharlViljoen This issue has been reported by others. And could lead to bad results. But more information is required to find what is causing the issue. So it would help if you could provide a log.

[breadoven]

Did total flight distance remain stuck on 214 km or increase after the GPS returned and what value did it have before the glitch ?

[ABLomas]

I can solve the reduced satellites by mounting the GPS outside and potentially avoid GPS connection lost.

Don't think this is doable, GPS loss is not (so far, based on 4x observed events) related to mounting, signal quality - probably parsing error (in details: #10893 (comment) )
So far, until this is fixed - workaround is to downgrade to INAV 7.

[Jetrell]

Don't think this is doable, GPS loss is not (so far, based on 4x observed events) related to mounting, signal quality - probably parsing error (in details:

I tend to agree with you. It doesn't seem to be an interference issue. But something to do with GPS communications handling.
@ABLomas It is interesting that many of these issues have a lot in common with your testing reports from the dead reckoning PR. I wonder if a bug is still lingering there.

[breadoven]

I had a look at this again and it really isn't obvious what the problem is which is why a log would help a lot. In order for home distance to remain stuck at 0 you'd have to think that home position is being constantly reset which is the only thing in the code that sets home distance to 0. The other possibility is the GPS origin is being constantly reset but it's hard to see why that would happen when armed.

Or it could be an overflow situation. The fact that trip distance jumped to 214km is significant given trip distance is calculated simply as velXY * dT accumulated over time. Given dT is pretty well constant between iterations a large jump in trip distance could only occur if a velXY was very large momentarily. But then if trip distance became stuck on 214km it indicates some other more fundamental problem especially of velXY continued to update correctly.

[ABLomas]

many of these issues have a lot in common with your testing reports from the dead reckoning PR

Ummm, yes and no - i flown dead reckoning version (manually built) from it's early days on another plane and did not noticed anything similar, so if dead reckoning patch is a problem - then it's surfaced on latest version only.
Maybe somehow related to "GPS ON/OFF" with logical switch? But i'm pretty sure that i did not had anything close configured. On top of this - copter video linked in another issue - this is "on defaults" (if DR works on copters at all), +/- new build without logical switches, GPS ON/OFF configured.
Why i don't think it's related to DR patches - plane does not know it's location at all and it's kinda "soft disarm" - plane lost it's altitude data, plane lost it's orientation data (ANGLE/HORIZON does not work anymore), maybe related to UBLOX7 removal?

(i believe it's not hard to trigger this issue, so i will get another SD and log this in air, but now weather does not permit flights)

[sensei-hacker]

I notice in the videos attached to #11049 the distance to home starts reporting zero 10 seconds AFTER the GPS glitch. That's interesting.

[arvet333]

I have the same issue. Each time gps is lost (no matter for how long) dist to home, alt and spd isn’t recovering.

[breadoven]

I have the same issue. Each time gps is lost (no matter for how long) dist to home, alt and spd isn’t recovering.

A Diff and Log would be useful if you want developers to help fix this issue.

[breadoven]

I was looking at this again and realised that this is the same issue as #10360. Then realised that there is a log included in 10360 that shows the moment the home distance resets after the GPS recovers (LOG00030.TXT time = 3:09). Nav x,y Pos and Vel overflow at this point as mentioned in #10360 (comment). However, I missed that navEPH also overflows at unsigned 16 bit. Anyone understand these overflows given Nav x,y Pos and Vel and navEPH are all floats ?

Edit:
On checking further the overflows are occurring in Blackbox so I guess all you can conclude is the values are very large.

[breadoven]

I think I might have worked out what is going here with the exception of understanding why it gets stuck on 0 for position and velocity. However, I think the 0 issue might resolve itself if you fix the thing that's causing some sort of numeric run away in the first place. It's likely related to:

inav/src/main/navigation/navigation_pos_estimator.c

Line 663 in dbe338a

ctx->estPosCorr.x += posEstimator.gps.pos.x - posEstimator.est.pos.x;

and

inav/src/main/navigation/navigation_pos_estimator.c

Line 773 in dbe338a

vectorScale(&ctx.estPosCorr, &ctx.estPosCorr, 1.0f / posEstimator.imu.accWeightFactor);

The quad in #10360 is pretty noisy with high accVib levels. I'm guessing this results in posEstimator.imu.accWeightFactor dropping below 1 most of the time (it's not logged and I haven't tried to work it out so this is a guess). The problem when the GPS drops out and recovers is the pos and vel are reset to the GPS values but this is currently done through a correction. This can be a large correction in the case of velocity because velocity likely decayed toward 0 when the GPS dropped out and navEPH crept up to the 10m limit. Unfortunately this correction gets magnified by posEstimator.imu.accWeightFactor so you end up with an estimated velocity way higher than the GPS velocity (possibly almost 7 times ?). This causes a large residual on the next loop which results in another large correction which then gets magnified again by posEstimator.imu.accWeightFactor and very quickly it runs away from itself resulting in the massive numbers seen in the log in #10360. Still can't explain why it resets to 0 and stays there though, pretty bizarre especially since navEPH appears to continue updating. It's almost as if EST_XY_VALID is stuck on false.

One solution for a fix is simply to assign estimated pos and vel to the GPS values when the estimate is reset to the GPS. Doing it through a correction seems unnecessary and just causes problems with the current code. Having some sort of constraint on the magnitude of the corrections would probably help as well to stop a run away.