You need one fairly simple one for both discussed functions. It’s a good skill to have 
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