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.
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?
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.
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.
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.
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 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.
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:
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.
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?
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.
