AC3.4-.2-rc2 SBF causes GPS horiz error

I have been chasing a few problems for a while but this has surfaced as a problem that happens with the Septentrio AsteRx-m UAS in SBF mode.

Recipe: GPS horiz error
New 3DR Pixhawk
Flashed with AC3.4.2-rc2
Calibrate accell’s/compass/radio_ set GPS_TYPE to 10 (SBF)
connected to only radio, external compass, Septentrio AsteRx-m UAS GPS
Arms in Stab.
GPS shows 3D Fix 12sats 0.7hdop
Will not arm in Loiter - GPS horiz error >5m
Replace Septentrio AsteRx-m UAS GPS with Ublox M8N and set GPS_TYPE to 1 (auto)
Was it for 3D Fix, arms in Loiter with hesitation.

Recipe: FS:No Terrain Data
As above, setup fresh Pixhawk.
Place a single waypoint (or many) and send to Pixhawk.
Switch to Auto - FS: No Terrain Data
Mission Planner set to Relative, waypoints are relative altitude, parameters for Terrain use turned off.
Replace Septentrio AsteRx-m UAS GPS with Ublox M8N, change GPS_TYPE
No errors.

This is not AC3.4 at fault, you simply didn’t have a good enough position. 12 satellites is actually very poor for a AsteRx-m, and I typically need to have at least a minute in clear sky to get enough satellites locked and dialed in (and I’m then seeing ~0.6m horizontal accuracy without any correction data other then SBAS). For reference I normally see at least 18 satellites. (As a rough estimate 12 satellites is usually ~50/50 GPS/GLONASS which means roughly 6 from each constellation, you should be seeing more then that). What antenna are you using?

What was the reported accuracy result? ( I can’t find any error that has >5m or formats like that in the code).

I’m pretty sure that error comes from the EKF.

@mboland I know you have posted logs before but if you can post a clean log with just these two issues it would be great (with LOG_DISARMED enabled please).

It seems there is 2 distinct problems here.

  1. The FS: Terrain data missing is generated whenever Auto is selected without an adequate GPS lock.
    This happens no matter what GPS you are using and whether or not you have Terrain use turned on or off.
    Have replicated this with a Ublox M8N and the Septentrio AsteRx-m UAS GPS.
    I am sure you could replicate it with the GPS disconnected, just put in a waypoint and select Auto mode.

  2. The GPS Horiz error happens with the Septentrio AsteRx-m UAS GPS whenever a GPS mode is selected and an attempt made to arm.
    Selecting a GPS mode while armed generates the reject notice ONLY in the log.
    I will raise this in the Mission Planner area as an issue and also see if APMPlanner does the same in the next days of testing.

My understanding was that the conversion error from SBF had been fixed in AC3.4.2-rc2
Is this correct?

Logs from this morning

Working at getting a clean SBF log from the Septentrio AsteRx-m UAS GPS this afternoon. (when the temp drops below 36degC :frowning:)

Actually 12 sats for a multi-frequency GNSS system is pretty good.
It’s not about quantity, it’s about quality.
My simple understanding from the mountain of information that is thrown at me by the GIS guys is that these GPS’s do a lot more filtering on the sat signals than good O’l L1 domestic GPS’s.
Hence they will reject a lot of sats they see, wheres an L1 single frequency GPS will report the sat whether it is good or bad.
I am sure there is a lot more too it, but thats the simple version.

In open sky we get 15 sats with a hdop of 0.7 but I am still getting the GPS horiz error xx.xm (must be <5) error message when attempting to arm in any GPS mode.

Are you using SBF or NMEA messages from your system?

It depends on what you are limiting the horizon to. I know that I get pretty poor results with 12 satellites in general on septentrio (SBAS helps a lot, but watching with the Septentrio tools shows poor performance as well, at least while its still locking the satellites). I’ve never stuck with just 12 satellites in view, I keep grabbing more. With the SBF log we could also check if you had actually locked it on multiple frequencies.

I don’t want to harp on this but HDOP != accuracy, and I really regret that early on HDOP was pushed at people more then estimated receiver accuracy.

I can attest that as of several weeks ago the reported accuracies for arming checks were matching what the Septentrio tools were seeing. Do you have the SBF file from the same time you were seeing the problem?

Thanks for the comments @WickedShell.
I don’t even mention hdop to the GIS guy here because he will jump on me for the same reasons you have mentioned, so I do get it.
I only use the term due to it being one of the criteria for GPS function in the parameters, no more than that.

The logs from today are here
Which includes the SBF and PH logs.

It is the GPS horiz error that I can’t seem to get around.

The Terrain error is a AC3.4.x problem I will raise as an issue now that I have verified it happens with a Ublox as well.

Got @meee1 to take a look since he wrote the SBF driver, there was a scaling error happening because the accuracy was multiplied by 2. He hadn’t noticed as he was flying with RTK which had given him a very good accuracy, and I hadn’t noticed as I was getting a much higher accuracy with SBAS.

The horizontal accuracy fix is here: https://github.com/ArduPilot/ardupilot/pull/5198

@mboland, the fix for the GPS that @WickedShell mentioned has been backported to 3.4.2, if you have a chance test it and let us know how it goes.

Thanks @OXINARF,
I am currently on the road until next week and the Octo in question is in pieces to replace everything to stop the FC crashes I have experienced.
We have a couple of Pixhawk 2’s on the way so it will be rebuilt next week with them and setup and tested with the new firmware.
I will report my findings then.

1 Like

Changed the name to remove the “Terrain Data Missing” as this was found to be a seperate problem.