Altitude Drift over time when using GPS Altitude as Primary

I am trying to work out why, when GPS is set as the primary altitude sensor (EK3_SRC1_POSZ=3), the AHRS alt still follows the baro, leading to the alt estimate being inaccurate on landing if the baro has drifted. This can result in hitting the ground at LAND_SPEED_HIGH if the baro has drifted enough. We do very long flights where baro drift can be significant. Is there any way to make the vehicle use the GPS alt estimate to determine when to go to LAND_FINAL speed in the descent? Log screenshot and log file attached. In this log, the baro alt has drifted about 10m, leading to landing at -10m. Would appreciate any help. Arducopter 4.3.7, dual HERE3 GPS’s set to blend.

Log file:

1 Like

We got some help on this from Peter Barker and now realize that we had misunderstood this.
The drift is not coming from the Barometer, but from the GPS, as evidenced by the GPS reading -8m after landing, which is the same location that previously read 0m at takeoff.

This is possible due to our Here3 GPSs not reaching a GPS status of 4, which would provide a more accurate altitude estimate.

1 Like

A rangefinder is probably the best solution to avoid automated landing issues like this.

Agreed. Our particular application precludes rangefinders, but in general this is the best way.

You can use RTK either with own base station (very high prevision, accuracy at regular GPS level (not an issue unless you land at other place than you have started from)) or network correction with public or commercial NTRIP caster (high precision and accuracy).

1 Like