Will HDOP cause "GPS Glitch" message? "Error: Subsys GPS ECode (x)"

This evening I made my first test of RTK operation using HereLink.

I tested in my yard where I’ve tested before - not great sky access due to trees - but its been OK for previous RTK connectivity tests.

With a UDP connection between Mission Planner and HereLink, the RTK corrections seemed to work well with the copter in Float and Fixed mode. So I think the connectivity issue will be just fine - but will test further in better conditions.

I did get two warning messages - first was something like “horizontal position inconsistent” - but I can’t find it in the message log.

I also got a “GPS Glitch” message - a minute or two later - and it cleared after about 15 seconds.

In my previous RTK tests, I found the F9P GNSS receiver couldn’t meet the 5HZ frequency of messages that ArduPilot requires when using four constallations. So I fixed that by going to just two constellations and increasing the frequency to 10Hz. That fixed the problem then - and in this test the GPA.DELTA stats are good.

But I did notice that HDOP got poor - about the time of the “GPS Glitch” warning.

In the MavLink message log there’s also two messages: “Error: Subsys GPS ECode 2” and “Error: Subsys GPS ECode 0” Maybe these are associated with the two warning messages that were displayed on the HUD - the one about horizontal position and the GPS glitch.

I googled the docs and couldn’t find anything specific on the “Error: Subsys GPS ECode(x)” messages.

Can someone help me decipher these codes - and perhaps let me know if they’re related to the poor HDOP I was experiencing?

Many thanks!

1 Like

HDOP is related to satellite position geometry. It is not something that you can change.
But you can change the min horizon elevation of the satellites considered for the calculations.

To improve GPS signal you need to increase the distance from the antenna to any interfering electronics. And increasing the height overall will reduce signal multi-path issues.


With Rover (at ground level) RTK worked well at the big circuit, but rarely worked at the small circuit, surrounded by trees.

Thank you @amilcarlucas

Unfortunately, that doesn’t answer my question.

I’m trying to find out what caused the messages: “Error: Subsys ECode(x)”.

While these messages are correlated with moments of high HDOP, I don’t know if HDOP is the cause.

I do recall reading somewhere that if HDOP ever exceeds 1.0 then something in AdruPilot is triggered - I can’t remember exactly what.

And in my sample flight, HDOP never actually reaches 1.0 - but comes close.

In my previous work with RTK I learned that GPS.DELTA exceeded a required threshold of 200. I’ve corrected that.

Now I need to find out what is causing this issue.

If I could find out the cause of the messages “Error: Subsys GPS ECode(x)” that would be a good start.

Can you suggest where to find what triggers these messages?

Thank you.

Thanks @Webillo -

Yes - my front yard has too many trees for normal RTK operation. But I have conducted a lot of testing here - mostly for connectivity issues. And when climbing about 20 meters, the copter is above the trees.

I typically can get HDOP of about 0.6 or 0.7 in my yard.

My question is what caused the GPS glitch and the messages “Error: Subsys GPS ECode(x)”. I need to find the cause of those errors and correct them.

Thank you.

The glitch are caused by electromagnetic interference and/or bad signal strength.

OK -

There has to be a way to know exactly what triggers:

I’m guessing that GPS ECode 2 represents a problem resulting in the glitch and GPS ECode 0 only indicates the problem is cleared. But I’d like to know for sure.

Surely these codes exist for diagnostic purposes. But you have to be able to look up the codes to do the diagnostics.


@amilcarlucas - I found this in the docs.

Unfortunately it doesn’t say what caused the glitch.

So now I need to find out all the things that trigger a GPS Glitch.

In my previous RTK tests I found that if GPA.DELTA exceeded a threshold it would trigger a GPS Glitch. I’ve check that for this test - and that’s not the cause.

So now I have to find out what other things trigger the GPS Glitch error.

I’ve found this in the forum regarding the cause of a GPS Glitch:

Assuming this is true, How would the copter know it’s position apart from what the GPS reports?

Also - would this display from the BIN file reflect the problem?

If so - I’d like to know how ArduPIlot “knows” vehicle position apart from what the GPS reports.

I posted a while ago a nice talk from Paul discussing sensor fusion and EKF filters.

Read more on https://elinux.org/images/1/11/Application_of_Data_Fusion_to_Aerial_Robotics.pdf





1 Like

I did more test flights today at my local test flight park - no issues.

Interestingly, the F9P firmware doesn’t allow 4 constellations at over 7Hz. So I use two (GPS and GLONASS) at 10Hz. One result is that HDOP is always a bit higher as only 13 or so satellites are locked. I typically get HDOP of 0.7 for RTK with two constellations as compared to 0.4 to 0.5 with four constellations for non RTK.

Thanks for the links!

As I told you before HDOP has to do with satellite constellation geometry. Read more about it on wikipedia or something.

HDOP is NOT the same as accuracy!!!

  • You can have a HDOP of 0.9 and a great accuracy.
  • And you can have a HDOP of 0.4 and bad accuracy!

My advise, look at accuracy and ignore HDOP

You can consult past and future theoretical HDOP’s at GNSS Planning. I try to test with low predicted HDOP, but that is not at all definitive.


I appreciate your guidance on this. I am familiar with HDOP - but it’s the only parameter I’ve seen referenced in various outlets regarding GPS performance.

I took a took a look at the horizontal and vertical accuracy parameters in the logs of the flight that got the GPS Glitch and one from yesterday that was a success. Quite a difference:

Plot of accuracy parameters on test flight that got GPS Glitch warnings:

Plot of accuracy parameters on test flight without GPS warnings.

I’d like to find out how these values are derived - and if they are specific to ArduPilot or if they follow an industry formula of some sort.

It’s common for ground control software, Qgroundcontrol and Yappu for example, to display the number of satellites and HDOP. Maybe for non-RTK operation that’s all that is required. Would you have any thoughts on that?

I can put these charted accuracy parameters as a user item on the Mission Planner HUD. But I’ll need help in understanding how to interpret the values.

Thank you.


I found some helpful discussion on this thread:

Unfortunately it doesn’t provide guidance on how to interpret these parameters. In fact, I’m not even sure what the units are.

The accuracy values come from the GPS receiver.
So you need to contact uBlox and ask them how they calculate it and which factors contribute to it.

Afaik their formula is proprietary, and very unique. Other manufacturers use other formulas.
As for the units, you need to ask them as well.

I’m sorry - I’m a bit confused.

You suggested I look at accuracy instead of HDOP in understanding what might be going on behind the GPS glitch I got a couple of days ago when testing RTK operation.

Is there some other accuracy parameter in the logs that I should have been looking for?

I’ve had good luck getting this sort of info from uBlox using their support portal. But unless it’s of value to determining GPS position integrity in ArduPilot - what would be the point? And if it is used in determining GPS position integrity in ArduPilot - wouldn’t there be a bit of documentation about it?

It is used in ardupilot to determine the integrity of the GPS position. But the EKF also does consistency checks on the GPS positions.

Did you see the entire EKF slides I posted above?
The source code is the documentation.

No - I’m afraid I haven’t yet dug into the docs and code you very kindly sent to me.

I’m still a bit confused. You seemed adamant that a check on GPS accuracy instead of HDOP is a better tool for understanding a GPS Glitch. That sounds reasonable. Yet I don’t see an explanation of what GPS accuracy (proprietary uBlox indicator) is or why it matters.

If I have to read the code, it’s probably not all that obvious.

From the practical standpoint - should we look at GPS accuracy before launching? If so - what should the values be.

If not - should we be looking at GPS accuracy for diagnosing a GPS glitch? If so - what should the values be.

Ideally - I’d like to avoid problems, rather than diagnose them. For that reason, I avoid flying if HDOP is below 1.0. (I think the docs suggest not flying if HDOP isn’t below 2.0.)

The point of all this is what can I look at that contributed to my GPS glitch so I can prevent it happening in the future.

Previously I had a problem with GPA.DELTA being too high. I found how to address that. I’m trying to work though this issue is a similar methodological way.