GPS glitches - what can be the reason?

Hello everyone,
I upgraded my pixhawk1+ u-blox m8n to Holybro Pixhawk4 running Ardupilot 4.0.5 + f9p.
But since then, I am experiencing a lot of GPS glitches, causing my drones (all 4 of them) to get out of control (moving to land mode and even get into toilet bowl). It happens often but not in every flight (before the upgrade I didn’t experienced those glitches at all).

looking at the logs it seems that the GPS location is correct, I also recorded the GPS directly from the f9p and there are no glitches.

example from my last flight:

I suspect there is an issue with other sensor (maybe the compass?) causing the EKF estimate a wrong position.
I also looked at the vibrations and they look ok, getting higher but still in spec.

link to the log file: 16112021 - Google Drive

I really appreciate any clue for what can be the reason

Ardupilot reports GPS Glitch when the calculated path and GPS path diverge, most typically because the GPS update rate is poor - amongst other reasons.
Your vibrations look very good, and there’s no clipping so that’s not a problem.

You have 30 sats, so that could be overwhelming and the GPA Delta is less than ideal. The Delta is the update rate. Most GPS units are able to do 10Hz with 2 constellations. By default they try for ALL constellations, so update rate suffers.

Set this and see if it helps

I see you’ve done the Compass/Motor calibration, and I think you’ve got the correct compass enabled. Can’t hurt to check and be sure.
Mag1 seems unaffected by throttle (current) but Mag2 is definitely affected.

Not related to the GPS glitch/position errors
The tuning is not perfect and could be a little bit better, but it’s a long way from being bad.
I would definitely set these:
and connect to MissionPlanner and press Alt A, or use the new Setup → Initial Parameters
Put in you battery cells and prop size, accept all the params it wants to update.
This will fix the MOT_BAT and filter params.

Now do a 1 or 2 minute hover flight in AltHold and lets see that log. We will be able to set the rest of the Harmonic Notch Filter params and run a new Autotune. Tuning should be very good if all goes well.

@xfacta tnx so much for your analysis and help!

Regarding the GPS update rate, current configuration GPS_RATE_MS parameter is set to 200 milliseconds (5hz). Changing it to 100 milliseconds (10hz) could help? Or the f9p can’t handle this with all constellation?

And only for my understanding, why the GPS rate affects the POS while the GPS recording seems to be continuous? I assume it is because the EKF doesn’t get the GPS in time so it doesn’t get into its position estimation, right?
So is Ardupilot 4.0.5 using EK2 is more sensitive to the GPS location than older versions? (Asking because in previous logs before upgrading my pixhaw, I also see the GPA delta acting the same and didn’t get the GPS glitches) maybe upgrading to 4.1.1 version can solve this?

I dont think changing the update rate of the GPS unit or Ardupilot would be the correct action. My suggestion of changing GPS_GNSS_MODE,65 limits the number of constellations allowing the GPS unit to update as well as it possibly can and still give you good position info. This is selecting GPS and GLONASS which will both have good coverage in your area, and I believe GLONASS has more sats covering the poles which is handy if you are a long way south.

It’s possible that an earlier Ardupilot version wasn’t reporting the issues in the same way, but that doesnt mean the same issues didn’t exist.
That earlier M8N may have only been picking up a limited range of sats and updating at a nice rate, and now the F9P can see extra constellations and is being overwhelmed even though it is much newer.
Or it could have been that there wasn’t the same GPS/environmental conditions at the time.
For example where I am we have lots of Beidou sats visible but if we select to use everything (defaults) HDOP and update rate is worse and it takes ages to get a good 3D fix.

The Arducopter 4.0 versions are very well tested and reliable. As far as I know there isnt a version that is more or less sensitive to GPS glitches (except possibly for increased CPU load on older FC’s).
In fact it would be best to update to latest stable which uses EKF3. Parameters are automatically converted where required so it will be a seamless direct upgrade for you.

Start with the other suggestions I made to improve the tuning (although not directly related) and that will also give you test flights with GPS_GNSS_MODE,65 set and we’ll see if that helps.

Thanks for your explanation, I finally get to it and tried the GPS_GNSS_MODE =65 you suggested, but only checking it connected to a laptop.

I’m trying to figure out how the GPS_GNSS_MODE affects the F9P? when I set it to 65, it didn’t change the F9P configuration (when connecting to U-center still show all constellations - including Beidou and Galileo)

Also I’m using an external logger to record RAWX and SFRBX directly from the F9P using the UART1 but it also connected to the pixhawk. That means the pixhawk gets NMEA from i2c connection and also RAWX and SFRBX from UART1. I guess the pixhawk is using only the i2c channel but maybe I was wrong and it reads also the uart and it affects the

Another parameter - GPS_DELAY_MS - can it help to compensate the deltas?

Is there a configuration file or recommended configuration for the F9P to work with pixhawk4? (i.e. Baud rate, frequency, messages etc)


There is no file, ArduPilot automatically configures the F9P if GPS_AUTO_CONFIG parameter is set to auto.

Yes I know the pixhawk can configure the f9p, but what is the recommended configuration?
And because i need to record the rawx and the sfrbx in external logger using uart1 i configure it using U-center (the logger max baud rate is 115200)

Wait a bit and connect to u-blox. the configuration should now be in the F9P

Ok I’ll try it cause when I set auto config to 1 and save config 1, I didn’t see the gpn_gnss change the constellations.

But what should be the configuration if I want to also record the rawx and sfrbx using the uart1 output from the f9p

After disabling GLONASS on my M9N equipped copter I got much better results. No glitches any more and the position in Mission Planner is much more stable, if the copter is left on a fixed position.
So currently I have only GPS, Galileo and Beidu and SBAS active.
But this is just my observation.
My copter is a compromize between functionality and design so it is susceptible for interferences and the environment is also not ideal, lots of trees and houses very close.
I did not try it on a F9P so far.

Thanks. What is your M9N configuration besides disabling Glonass?
I am using baud 115200, 200 ms (5hz) between samples, and in addition to the default configuration that sends NMEA on the i2c channel, I send RAWX on the UART1 channel

I did some tests today in order to find out if my external logger overload the F9P and causes the GPS glitches.
Just to remind, I am using pixhawk4 with f9p gnss module but I also added an external logger on the UART1 channel, in order to save RAWX and SFRBX for post flight PPK.
My F9P configuration:
Rate - 5Hz (200ms)
UART1 - baud rate - 115200 sending UBX only RAWX+SFRBX messages
I2C - NMEA messages

till today I thought the pixhawk is using the NMEA messages on the i2c channel for navigation, but when i physically disconnected the UART pins from the connector the pixhawk didn’t get location at all, so I understand that the pixhawk is only using the uart1 for navigation. can you confirm?
and what is the use of the i2c? only for compass?

If so, maybe adding the external logger on the uart and sending only the RAWX+SFRBX messages on UBX format is making the noisy?
maybe sending also the NMEA messages on the UART and setting GPS_TYPE to 5(NMEA) can solve the issue?

@xfacta can you help?

Yes, UART for all things GPS. i2c for all things compass.

Tnx for the quick response!

In standard configuration I assume the pixhawk is using the NMEA messages on the UART for navigation. Is this correct?

So any suggestions how can I log theUBX - RAWX and SFRBX messages without making the so bad causing GPS glitches?
I prefer not to reduce constellations at the moment, only if there is no other option…

Nope, the standard u-blox communication protocol is UBX over UART.
It only uses the inefficient NMEA if you explicitly configure it to do so.

I think there is no other workaround possible you need to reduce consteltions

Ok tnx

Do you know which messages are the standard on the ubx protocol for the pixhawk’s navigation?

And is there an Ardupilot version that can create ubx file including the 2 gnss channels L1+L2 and also record lli?

You can activate some kind of UBX logging, yes.

This was the first google hit I got:

Yes I know this parameter
But it doesn’t log thr 2 GNSS chanels L1+L2, only L1…
This is why I added an external logger, but I tought maybe in other Ardupilot versions it logs both channels

Take a look at:

I think it is the configuration for making ppk while in flight. I am doing ppk after flight, but maybe I’ll try using rtcm instead of rawx🤔