Altitude above sea level adjusted for barometric pressure

Agreed that converting between hPa and inHg isn’t a dealbreaker. I’ve spent years using those charts…

But a decimal error is a huge issue, so hPa should be the normal entry unit, at a minimum.

1 Like

So I haven’t come back to this in a bit as @rbeall has it on his list to get something like this working.

He knows more about it than I do…

But I do agree we should standardize as close as possible to the units used by local authorities.

1 Like

Currently, there is an issue with planes and how they report altitude in Mission Planner vs how say a certified ADBS out module reports altitude.

And thus when you contact ATC telling them your read out on Mission Planner you get obvious questions on why that doesn’t match your ADSB-out.

Definitely needs addressing, then!

I’m sure it’s a non-trivial task to get various baro sensors on widely varied autopilots to fall in line close enough to certified equipment. I don’t envy that one bit…

2 Likes

If it makes it simpler, ADS-B isn’t an issue for me. This will all be radio. But I need to know that my reference for altitude is the same as the traffic around me to maintain vertical separation.

I’ve been tracing this problem down for a few weeks now. The most important fix is the proper calculation of barometric pressure to indicated altitude being in accordance with general aviation standard (i.e. non-temperature compensated). The following commit will be submitted as a PR soon to fix the incorrect calculation of altitude from barometric pressure (from the perspective of general aviation).

This is the first step in solving the larger problem as described. It doesn’t allow for changing the barometric offset from say a METAR etc for landing later in the day when the pressure has changed or at a different landing spot physically further away with a different MSL field elevation.

I’ll focus on the barometric pressure change problem later… Technically this approach would cover the situation, but I’ve currently put in safe guards such that you can’t change it in flight because things can go very poorly if you get it wrong.

4 Likes

Speaking as a non-programer: Could some of the safeguards be relaxed if the plane has a long-range lidar rangefinder for AGL and landing? Hopefully this could prevent a finger issue entering in the wrong altimeter setting and going for a dirt dive. High to low, look out below…

Depending on the company/country rules and regs, instrument certified radar/sensor based altimeters are often used to supplement pressure altimeters at the extreme terminal portion of an approach, with critical decisions made based on their readings. You can read just how critical they are in the news lately re:5G interference.

In the ArduPilot ecosystem, rangefinding altitude sources could be leveraged similarly to build a “composite crosscheck.”

Hi @Allister

AFAIK until now the range finder in Arduplane is implemented just for the correction of the barometric altitude for automatic landings.

1 Like

I think you’re right. The landing page for ranger finders in the wiki does say “precision landings and altitude control” but the terrain following page doesn’t mention range finders at all. (For plane)

So the ranger finder is still valid for the landing portion of the flight, but won’t save a fat finger issue during cruise.

1 Like

My interest is for VFR traffic separation. At this point we are far from being allowed to have a drone fly an IFR approach in controlled airspace. When we get to that (and I hope we will), then we’ll be needing certified altimetry reporting devices, both for pressure altimetry and any supplementary sources such as radar altimetry.

Agreed. The process is there for copter and I think that’s why I got confused with plane.

A Lua script could be used to prevent (or warn against) a severe fat finger, but the rangefinder should not, as a matter of practice, adjust the pressure setting automatically.

1 Like

Yes, I want the ranger finder as a ground proximity warning.

1 Like

Lua can also be used to create a GCS message of high enough severity to trigger a voice warning at low altitude.

1 Like

Great, so what you’re saying is that i need to add “learn how to write and use LUA scripts” to my to do list. I new it would come to this one day. :slight_smile:

You need one fairly simple one for both discussed functions. It’s a good skill to have :slightly_smiling_face:

1 Like

I see samples of scripts like this: ardupilot/terrain_warning.lua at ArduPlane-stable · ArduPilot/ardupilot · GitHub

 -- get the height above terrain, allowing extrapolation
  -- this used the terrain database only, not considering rangefinders
  local terrain_height = terrain:height_above_terrain(true)

I noticed calls (?) such as height_above_terrain. So where is that getting it’s data from? Is there a way to specify the GPS altitude over the (potentially wrongly calibrated) barometer altitude? Again, I don’t need landing precision so GPS altitude should be accurate enough for a terrain warning with enough buffer set in.

Just as an interesting fact for you - QNH stands for Question - Nil Height? A leftover from the morse code days of aviation, where morse for QNH could be sent to someone, who can reply with the barometric pressure at MSL

2 Likes

In the context of this discussion, I want to point to ICARUS - a project developing a U-Space (UTM) service aiming to bridge this very gap between systems. https://www.u-spaceicarus.eu/

The various altitude references have also been the subject of some workshops and papers by Eurocontrol, as altitudes are often handled differently in manned vs. unmanned vehicles - and can cause serious confusion or issues as many here have noted.

1 Like

Hi Josh,
It would be advantageous for MP to report ADSB_VEHICLE altitude as uncorrected Baro altitude in line with crewed aircraft Mode C Baro Alt.
Within #246 is a field for Altitude type Baro=0 or GPS=1, is it possible for this to be configured in MP for reporting and display of ADSB Traffic altitudes?
It is my understanding that MAVLink protocol ADS-B receivers do output both altitude reports.
ADSB AVD would likewise require an uncorrected Baro alt of ownship, possibly derived from ADS-B transponder or EC device.
Clarification and development would be widely appreciated.
Regards
Luke