3.4.1 reporting altitude Above Sea Level

3.4.1 is reporting ASL instead of AGL.
I had one issue fixed with DroneLogbook.com, couldn’t even upload a 3.4x log.
Now DroneLogbook says the only altitude reporting is ASL…which is useless for me.
Prevents showing the FAA rather easily that I am within 400’ (120m) AGL.

Can you post your log so we can verify. This doesn’t seem to make any sense. I am not seeing this issue with 3.4.1 or 3.4.2-rc2

2016-11-11 17-44-53.bin (3.0 MB)
There you go sir!
3.4.1 DJI 450 Quad.
Maximum recorded altitude 2142.39 feet according to DroneLogbook.com where my 3.3.3 DJI 550 HEX recorded 400.26 feet

DroneLogBook may not be current on the 3.4.1 log format.

You altitude in the log is reported correctly. The log format is self describing, and though there are some changes. none have been to the Alt. I suspect the log parser in DroneLogbook has an issue. I’d contact them. See graph below for confirmation of max Alt Relative and GPS AMSL

PS: you can load logs and make pretty graphs like that using APM Planner 2.0.

Check OP, did that. Couldn’t even upload 3.4x

They were contacted and the reply was no data for AGL:

“Sure it was AGL before. But it seems that in the new
version, they changed that to sea level…

I’ll send them the AltLog you derived.

Nothing has changed in the logging in ArduPilot, it seems that DroneLogbooks reporting is different. You should also note that the alt shown ‘baro alt’ is relative to the position of the craft home. it’s also not AGL. For a valid AGL you need a rangefinder to report the distance or correlate the data against the terrain data.



Hope that helps :thumbsup:

Much like what has been done with VCC (which now renders MP autoanalysis and the analyzer itself semi-useless) it’s possible the parameter has moved to a different node. The new version has moved VCC from the CURR node to POWR. Autoanalysis now on MP always reports WARN with a variance of around 3V when there no variance that large.

However, looking at the BARO Alt part of the log on mine, it does appear to be reporting AGL, not ASL.

And @billb,

I kind of figured it is them. Always is. Just hope they can find it.
Like I said, make is so much easier to report to the FAA if needed.

And agreed Big Tulsa, has to be AGL. How else does the “verify height” work to maintain a predetermined altitude in an auto mission?

I appreciate the assistance.

I look at the BARO>Alt param in your log and it looks correct to me.

As long as your top height was about 120 meters AGL.

Also, I went back to my older logs from 3.3.3 and the Alt parameter is in the same place and reports the same way (AGL). I think this is a DroneLogBooks issue.

BaroAlt is not AGL. It’s relative to the home point where you took off from. Take a look at this elevation profile as an example of a mission with 120m relative alt set for the waypoints.

SonAlt in the CTUN message would be the only clear indicator of AGL. (requires a LIDAR or other rangefinder)


OK, I stand sort of corrected then. My point is, Baro Alt doesn’t use ASL, because in my case where I live and fly it would always be reporting around 180m plus my altitude in the vehicle.

But I understand it does use the reference from home point. I was making the case that it definitely didn’t use ASL.

Roger that. It’s not ASL.

Supervisor at the site is looking into the issue.

This issue can now be closed. It was indeed a DroneLogbook.com issue.
Now works with 3.4.1

Great this got sorted out. Thanks @billb for helping out.

By the way, the CTUN.BAlt is actually the altitude above the EKF origin which is normally very close to the vehicle’s take-off location but doesn’t have to be. For example if the vehicle lands on top of a hill, disarms, arms and takes off again then the home alt will be quite different from the baro altitude.

6 posts were split to a new topic: Can we fix RCOUT ch3 delay?

I do now understand why the issue has occurred. The Relative Alt parameter was removed from the GPS dataflash message

see https://github.com/ArduPilot/ardupilot/commit/7ab1367ec44bd256d419f36ad9c6854b8aacc712#diff-ac82c96e8d58cd0e3fb578ef71766122

It’s still reported in other messages, but lots of parsers probably relied on that field being there. (I know since the KML export in AP2 was broken and this was the issue)