Why home icon is flickering, not locked?

From the log GPS/Mag seems OK, why home icon is flickering, not locked?

Is there anyone can help to check the log for me?

Try GPS_GNSS_MODE,9 or 40
Use just two constellations, whichever combination gives you the lowest HDOP in the shortest reasonable time.

Thanks, I have checked GPS_GNSS_MODE, which is using default parameters in module (Maybe altered). It will get around 16 satellites.

@xfacta Do you mean the above log shows hdop is not low or precise enough for Home position lock? I thought HDOP < 1.5(The log shows it’s lower than 1.4 always) is acceptable.

So what might be the key issue here for HOME not locked, I suspect compass, but the mag.health = 1. I don’t understand its behavior right now.

What is the default behavior of GNSS chips? What data do they send if the default “ALL” is selected? Do they send only the best one or all of them?

I think @xfacta 's idea is from here: Do I change GPS_GNSS_MODE? - #4 by xfacta

Yes, it seem selecting 2 best constellations is optimal choice.

@xfacta It seems good for me(BN-880) here(Sunny/Rainy) Hangzhou/China.

@Paul_Paku It might be area dependent, and worth to try.

@xfacta And I have found that even if the HDOP is above GPS_HDOP_GOOD = 140, HOME still gets locked. Sometimes, it won’t be locked even if the HDOP is below 1.4.

What’s the trick to getting HOME locked? Besides the GPS HDOP, are there any other reference factors?

Here is a short video:

HDOP has to be generally below 1.0, but HDOP is not the sole dictator of setting home.
It is a good indicator though.
The GPS position (Lat, Long, velocity) all comes into it. Velocity must be below some small value and latitude and longitude should be quite stable.

Where I am Beidou gives a poor result, lots of Sats but high HDOP, but it might be the best option in some areas. Usually GPS is good everywhere, as GLONASS is meant to be, and Galileo would be too if it’s supported by your GNSS unit.

Small quads can have trouble getting a fix because they are so close to the ground. Holding the quad up or resting it on a table (or other structure) can help. Also nearby buildings can cause multi-pathing and other bad stuff.

Is it hard coded? Is there any configurations that can change the these smallest values, as FPV drone, we don’t need to be that accurate, we just need the copter to return, then we can take over. Or it’s hard for us to take off if we need RTL.

No, I was just checking the code and I cant see where any of that is hard coded. The Fix status comes from the GNSS unit itself → example: 2D fix, 3D fix and a few others.
So that fix will depend on what type of GNSS unit you have, how good it is, what constellations you have selected, plus local conditions.

The Home position comes from EKF, which decides what home position is based on a wide range of inputs. Home position cannot be set while armed and flying.

You could try increasing GPS_HDOP_GOOD but that might not help much.

Otherwise disable the Fence, arm and fly in Stabilise or AltHold until you get a good GPS 3D Fix, then land and disarm. When you next arm you should have a Home position and RTL would work - provided the GNSS signal didnt go bad when you landed.

1 Like

Well, then it’s the magic EKF with various inputs.

The above video gived 3D fix right after a few seconds (3~5 seconds) when I got video, as I have MP connected monitering the gpsstatus/hdop. compass is recalibrated with sucess.

OK, I will try.

Yeah, it’s a good idea. And I did try. But it seems no way, just as the short video above, which is a fix(no home flickering) a couple of minutes ago. I replug the battery to cold reboot the drone.

@xfacta Thanks for checking the code, I just don’t know what might be the root cause compass inference or what??? GPS 3D Fix or HDOP is not the cause.

Turn off the FPV video transmitter and re-test.

Analog VTX/Digital IPC didn’t affect the issue—I have checked that.

BTW, I have a Matek 3901 module on board. I’m not sure if it’s relevant, but I will check that tomorrow.