Flight height minus

[Ken K]

Thanks @sar104 and @FoxhallGH for your input. I've just added a little more knowledge to my muddled mind.

 

[kilomikebravo]

FWIW, early on in flight training, many folks are taught this rule...

"High to Low, look out below." Obviously, this is more critical in a faster moving, larger aircraft but the principle is the same and since drones do not have an adjustable altimeter setting, it can be the difference between flying and crashing when you get close to the ground because, the drone thinks it's actually higher than it is, at least until it can adjust to the pressure change via the baro sensor.

 

[djaco]

RTH altitude needs to be higher than any object, trees, structures, hills, mountains etc. to set the return to home at 20 meters is asking for trouble. Any variation in barometric, or gps readings can lead to a crash, even minor crashes can lead to an expensive repair.

 

[Jonathan Atkin]

May I jump in here..for a minute?..as my concern with Altitude is related but not directly to this discussion. But maybe some of you can chime in. Myself and several other pilots in NYC and VA Beach and elsewhere have experienced a difficulty of Adobe Lightroom's interpretation of the altitude metadata from the info provided by the aircraft. On the GOAPP, our altitude has regularly been correct ..doing dozens of tests with Inspire2 and Mavic2 Pro in a variety of flight situations, often with 14-17 sats and minimal wind. The Go4App generally has shown accurate altitude. But when the files are ingested into ADOBE LightRoom the altitude info can vary from 48 feet underground to wildly wrong numbers. DJI support sends totally erroneous communcations about "Fusion" altitude readings...and they simply don't get it. DJI engineers need to talk with Adobe engineers and find out what the hell is going on. DJI sends notes saying Sorry for the inconvenience. It is NOT an inconvenience. It is a potential law suit and liability. And an FAA issue. While all my friends are are responsible 107 pilots, the potential of being cited for flying over 400 feet is real in this litigious world...and if we cannot prove easily with the transfer of data into ADOBE LIGHTROOM then Houston, we have a big *** problem. DJI support writes, that I may be flying with too few sats or too windy..Bull. I am flying with 14-18 sats and no wind. Can anyone at DJI really step up and stop this disingenuous inability to own up to a software glitch and simply get in touch with ADOBE and figure it out? I mean really. Myself and others have documented with photographs of our Crystal Sky Monitors showing proper altitude and then we have submitted screen captures of the same image with LIGHTROOM metadata etc etc...its very clear. DJI needs to react in a professional manner, not kicking the can down the road. Its a potential legal liability to not have the DJI info properly translate into standard digital processing software.

 

[sar104]

May I jump in here..for a minute?..as my concern with Altitude is related but not directly to this discussion. But maybe some of you can chime in. Myself and several other pilots in NYC and VA Beach and elsewhere have experienced a difficulty of Adobe Lightroom's interpretation of the altitude metadata from the info provided by the aircraft. On the GOAPP, our altitude has regularly been correct ..doing dozens of tests with Inspire2 and Mavic2 Pro in a variety of flight situations, often with 14-17 sats and minimal wind. The Go4App generally has shown accurate altitude. But when the files are ingested into ADOBE LightRoom the altitude info can vary from 48 feet underground to wildly wrong numbers. DJI support sends totally erroneous communcations about "Fusion" altitude readings...and they simply don't get it. DJI engineers need to talk with Adobe engineers and find out what the **** is going on. DJI sends notes saying Sorry for the inconvenience. It is NOT an inconvenience. It is a potential law suit and liability. And an FAA issue. While all my friends are are responsible 107 pilots, the potential of being cited for flying over 400 feet is real in this litigious world...and if we cannot prove easily with the transfer of data into ADOBE LIGHTROOM then Houston, we have a big *** problem. DJI support writes, that I may be flying with too few sats or too windy..Bull. I am flying with 14-18 sats and no wind. Can anyone at DJI really step up and stop this disingenuous inability to own up to a software glitch and simply get in touch with ADOBE and figure it out? I mean really. Myself and others have documented with photographs of our Crystal Sky Monitors showing proper altitude and then we have submitted screen captures of the same image with LIGHTROOM metadata etc etc...its very clear. DJI needs to react in a professional manner, not kicking the can down the road. Its a potential legal liability to not have the DJI info properly translate into standard digital processing software.

The altitude issue has caused plenty of confusion, at least partly because of mislabeled fields in the EXIF data.

There are two altitudes listed in the EXIF data, in three fields. For example:

Absolute Altitude : +2849.93
Relative Altitude : +73.00
GPS Altitude Ref : Above Sea Level
GPS Altitude : 2849.9 m Above Sea Level

Note that "Relative altitude" is the barometric altitude relative to the takeoff point, and is the only one accurate enough to use. "Absolute altitude" and "GPS altitude" are the same quantity but, just to be confusing, are not derived from GPS data - they appear to be absolute barometric altitudes above MSL based on a standard atmosphere. Those are not reliably accurate since the atmosphere is rarely standard, and cannot be relied on at all.

The altitude shown in the GO 4 app is derived from sensor fusion but is basically the barometric relative height above the takeoff point, and is the same value as "Relative Altitude" in the EXIF data.

I have a current ticket open with DJI to see if I can get them to replace the "GPS altitude" data in the EXIF with the actual GPS altitude, which is generally accurate to within a couple of meters relative to the reference ellipsoid. That does differ from the geoid mean sea level, and the difference can be significant in some regions, but at least it is constant at any given location.

 

[sar104]

The altitude issue has caused plenty of confusion, at least partly because of mislabeled fields in the EXIF data.

There are two altitudes listed in the EXIF data, in three fields. For example:

Absolute Altitude : +2849.93
Relative Altitude : +73.00
GPS Altitude Ref : Above Sea Level
GPS Altitude : 2849.9 m Above Sea Level

Note that "Relative altitude" is the barometric altitude relative to the takeoff point, and is the only one accurate enough to use. "Absolute altitude" and "GPS altitude" are the same quantity but, just to be confusing, are not derived from GPS data - they appear to be absolute barometric altitudes above MSL based on a standard atmosphere. Those are not reliably accurate since the atmosphere is rarely standard, and cannot be relied on at all.

The altitude shown in the GO 4 app is derived from sensor fusion but is basically the barometric relative height above the takeoff point, and is the same value as "Relative Altitude" in the EXIF data.

I have a current ticket open with DJI to see if I can get them to replace the "GPS altitude" data in the EXIF with the actual GPS altitude, which is generally accurate to within a couple of meters relative to the reference ellipsoid. That does differ from the geoid mean sea level, and the difference can be significant in some regions, but at least it is constant at any given location.

The geoid/ellipsoid offset has been bothering me, since all the GPS units (including DJI aircraft) that I've checked locally seem to be reporting geoid (EGM96) AMSL heights rather than ellipsoid (WGS84) heights. The offset here is nearly 20 m, and so it's pretty easy to see the difference. It turns out that the modern GPS chips will output both, and so the GPS altitude data from the aircraft most likely is correct AMSL.

 

[Meta4]

But when the files are ingested into ADOBE LightRoom the altitude info can vary from 48 feet underground to wildly wrong numbers. DJI support sends totally erroneous communcations about "Fusion" altitude readings...and they simply don't get it. DJI engineers need to talk with Adobe engineers and find out what the **** is going on. DJI sends notes saying Sorry for the inconvenience. It is NOT an inconvenience. It is a potential law suit and liability. And an FAA issue. While all my friends are are responsible 107 pilots, the potential of being cited for flying over 400 feet is real in this litigious world...and if we cannot prove easily with the transfer of data into ADOBE LIGHTROOM then Houston, we have a big *** problem. DJI support writes, that I may be flying with too few sats or too windy. ... Its a potential legal liability to not have the DJI info properly translate into standard digital processing software.

You've found yourself stuck between not understanding the issue and DJI's inability to communicate accurate information effectively.
The real issue is that there's no issue.
There's no potential legal liability or FAA issue.
In the extremely remote case that you'd ever have to prove your flying height, your recorded flight data clearly shows that for every 1/10th of a second of each flight you make.
And as Sar104 says above, there are two altitude numbers shown in your exif data, not just the one which has alarmed you.
Here's an example;

Despite what you've assumed to be a big problem, surveyors use DJI drones every day for creating accurate surveys.
Here's some detail from a 0.25 metre contour survey of a 60 acre site for golf course development.
It's all done from images shot with a DJI Phantom that has the same "big *** problem ".

So it's not such a big problem after all.