GPA.Delta message spikes downward in flight

[Brianoconner (Brian)]

Hello everyone,
I am using F9P GPS. I am using 2 constellations GPS and Beidou. Baudrate is 230400. Update rate is set to 200ms (5Hz). My RTK is also sending corrections only for these two constellations only. However in the flight i can see the downward spikes in entire flight.
GPS_TYPE=1 and I have configured the GPS with u-center.
Can someone explain me why am I getting these spikes then?
Is it because I have kept parameters in FC at default and configured my GPS with u-center. Because even though I have set GPS and Beidou from u-center the parameter “GPS_GNSS_MODE” is at default 0.

Log- 00000017.BIN - Google Drive

Thank you

[amilcarlucas]

Spikes downwards are fine, and cause no big issues.
Spikes above 200ms are bad.

[Brianoconner (Brian)]

@amilcarlucas
I also believed this but last time when I flew I got high inaccuracy in GPS data (HAcc, VAcc, SAcc) this is the same time when Delta went very low from 200ms to 185ms.

00000016.BIN

I am unsure if this happened due to shift in RTK fix to float or GPS Delta went really low.
If it was RTK shift, the moment at which this diversion occurred it can be seen that RTK corrections were still getting received. Now is it the quality of corrections was bad? Or did the GPS got overwhelmed as it was using all 4 constellations. I have reduced the constellations to 2 now.

[Brianoconner (Brian)]

@jstroup1986 i have read and followed your article and discussion related to this topic. If possible can you have a look at these logs.

[YupsUAV]

As you’ve been told before: The spikes are downward, so the F9P is sending its messages a little bit earlier than 200ms which is nothing to worry about.

This has nothing to do with Fix or Float!

Just refering to your screenshot, didn’t do log analysis.

[jstroup1986 (Joseph G Stroup Jr)]

Hello Brian -

I’ve taken a look at log file you uploaded. Here’s the graph of GPA.DELTA

I haven’t taken a look at this for a couple of years - so thank you for the opportunity to refresh my memory. My comments below will be more lengthy than necessary - as I work to remember details.

The ArduPilot Extended Kalman Filter (EKF3) looks to receive GPS position messages every 200 ms - 5hz. If it fails to get messages at that rate for a long enough period of time, Ardupilot will report a “GPS Glitch” message. If it continues long enough - you may get an EKF failsafe.

As a side note: The default failsafe action for EKF Failsafe is to land. I think this is unwise - as you don’t know where the aircraft might be. Instead, I like to use ALT-Hold as the failsafe for EKF Failsafe. If the aircraft is in sight, you can then visually fly it to a safe location at that altitude - and then land safely. If the aircraft is not in sight, you have a chance to get close enough to see it.

The problem I experienced two years ago was that with the latest F9P firmware, the F9P could not send messages faster than 7hz if more than two constellations were used. (You can verify this by searching the comments in the uBlox forum - you should be able to find my post there)

In order to ensure Ardupilot receives message at the 5hz rate, I like to set my F9P to 10hz - which reduces the number of constellations to two. I see you’re in Chennai India. The best two constellations to choose may be different than the ones used in the USA.

Your graph shows messages arriving mostly at 200ms - 5hz. Only one spike shows a longer time. This shouldn’t cause a problem with EKF. The “downward” spikes show messages arriving at faster than 5hz - this is good.

From your information above in this thread - I’m not exactly sure what problem you’re experiencing. But if your concern is the downward spikes in the GPA.DELTA data, you should not worry - this shows good GPS performance.

One additional comment - you noted that you use a baud rate of 230400. I can’t remember if this is the default baud rate for F9P receivers. But I expect it is faster than required - and that 115200 should be plenty fast. The faster the baud rate, the greater the chance of data errors that cause re-transmissions - and more uncertain performance. I always like to use the slowest baud rate that gets the job done.

I hope this is helpful. Please feel free to reach out if I can help further.

BTW - I’ve been to India four times - I enjoyed being there.

[Brianoconner (Brian)]

Thank you @jstroup1986 for looking at log and providing your comments.
IF you see 0016.BIN file, the RTK message was missed for only 2 seconds and in that time the GPS Status changed from 6 to 4 immediately. Earlier I believed and tested that even if RTK corrections stop coming it takes a while for GPS status to change from 6 to 4 and eventually 3.
In this situation the error “GPS Glitch” was also not registered. I can see the effect of the event that is EKF normalized innovation going over 1 and followed by lane switch and then EKF failsafe. But I am not understanding the root cause of this. The GPS satellites are also 26 and more.
I am only trying to find out why did GPS Status changed from 6 to 4 all of a sudden even when RTK messages were incoming. There were 9 other drones flying with it and this didnot occur in any of those drones.
There is a possibility that voltage dropped in the GPS board which caused this issue but I am not sure as I cannot verify it.
I will try to do more flights to see if this can be captured again. However I use to have all 4 constellations ON earlier but now I use only 2.

Indeed India is great country to visit!

[jstroup1986 (Joseph G Stroup Jr)]

Brian -

I took another look at your bin file. Here’s the GPA.DELTA along with the GPS.STATUS:

Here are the messages from this flight’s bin file:

brian messages.txt (4.2 KB)

The incident occurred here:

There are several things going on. The “emergency yaw reset” suggest that your compass is not calibrated properly. I ran the bin file through MAVExplorer’s MAG-FIT utility and indeed, it needs calibration:

There’s also a message about “Vibration compensation off” - I’m not familiar with that message. I checked your vibe stats, and they look OK to me.

It’s hard to know exactly what the cause of your problem might be - so I suggest working through all the normal tuning procedures - like getting your compass properly calibrated, setting a notch filter, and tuning your PID’s. (they also look good)

One suggestion: After takeoff, I always insert a “delay” command usually 15 to 20 seconds. This gives the copter time to sort things out - like a yaw reset.

One flight isn’t really enough data to do a good analysis. I recommend you get the compass calibrated using the MavExlorer MAGFIT function, and do more test flights.

I hope this is helpful!

[YupsUAV]

The reason for GPS Glitch could be a position jump introduced from the GPS status change vom Fixed to Float (or even DGPS? not sure what 4 is?)
Please solve the other problems first before digging deeper in the GPS problems thing.

@jstroup1986 Good analysis, thumbs up!
230k is default baudrate for ardupilot GPS today.