DJI Mavic, Air and Mini Drones
Friendly, Helpful & Knowledgeable Community
Join Us Now

Incorrect EXIF GPS and Elevation

Just to clarify - you are saying that the aircraft was at around 10 meters AGL, but only 2 meters AMSL? So the ground elevation at that location is 8 meters below mean sea level?
Thanks for your reply SAR....

Whoops!!!! My Bad!!..... I misread the height GPS(0):heightMSL: 13.754 as being AT MSL.... and thought No Way!! this spot (ie, the takeoff spot), really is actually around 2m MSL.

In actual fact (of course), the 13.375 is AT the above takeoff height, ie RelativeAltitude(from XMP-drone-dji): +10.2
So, 13.754 MSL (as recorded in the .DAT file), minus the 10.2 height AGL, gives 3.554... still out by over 1.5 metres compared to the true MSL elevation of this location, but maybe acceptable given that the M2P is not a true surveying machine!
A calculated (by me), MSL of 3.554 is way better than the recorded (Exif data) MSL of minus 26.01!

And now all that remains is for me to do is to get a few more tests in, get the process together in say, Phil Harveys Exif program, and finally to say:
  1. I humbly apologise for wasting your time there,
  2. Thank you for taking to time to reply to a demonstrated idiot like me
  3. I will now go and stand in the corner with my pointed hat on :) :):)
 
Thanks for your reply SAR....

Whoops!!!! My Bad!!..... I misread the height GPS(0):heightMSL: 13.754 as being AT MSL.... and thought No Way!! this spot (ie, the takeoff spot), really is actually around 2m MSL.

In actual fact (of course), the 13.375 is AT the above takeoff height, ie RelativeAltitude(from XMP-drone-dji): +10.2
So, 13.754 MSL (as recorded in the .DAT file), minus the 10.2 height AGL, gives 3.554... still out by over 1.5 metres compared to the true MSL elevation of this location, but maybe acceptable given that the M2P is not a true surveying machine!
A calculated (by me), MSL of 3.554 is way better than the recorded (Exif data) MSL of minus 26.01!

And now all that remains is for me to do is to get a few more tests in, get the process together in say, Phil Harveys Exif program, and finally to say:
  1. I humbly apologise for wasting your time there,
  2. Thank you for taking to time to reply to a demonstrated idiot like me
  3. I will now go and stand in the corner with my pointed hat on :) :):)

Nothing to apologize for. In terms of the residual 1.5 m discrepancy, that's within the expected vertical GPS accuracy, which is generally around 1.5x worse than the horizontal accuracy for a typical constellation distribution. The other question, however, would be how well you know the local geoid zero elevation for the vertical datum in use - i.e. how accurate is your 2 m AMSL assumption?
 
Nothing to apologize for. In terms of the residual 1.5 m discrepancy, that's within the expected vertical GPS accuracy, which is generally around 1.5x worse than the horizontal accuracy for a typical constellation distribution. The other question, however, would be how well you know the local geoid zero elevation for the vertical datum in use - i.e. how accurate is your 2 m AMSL assumption?
Thanks yet again SAR....
yes, I am fairly sure that the 2 meter MSL is accurate, but of course, I will chase it down......... So, that being the case then, by using the GPS(0):heightMSL: field from the .DAT file, I think I can correct the starting point for images captured when using the DJI apps (Go 4 or maybe GS Pro as well).
I now need to see if I can find the equivalent when using a different flight app (eg MME, Drone Deploy, Litchi, Pix4D etc).

All this number crunching and file analysis is making my brain melt..... it would be so much better if DJI could just change their SDK/firmware to fix this up..... for the life of me, I don't know why they cant get this fixed...
 
Thanks yet again SAR....
yes, I am fairly sure that the 2 meter MSL is accurate, but of course, I will chase it down......... So, that being the case then, by using the GPS(0):heightMSL: field from the .DAT file, I think I can correct the starting point for images captured when using the DJI apps (Go 4 or maybe GS Pro as well).
I now need to see if I can find the equivalent when using a different flight app (eg MME, Drone Deploy, Litchi, Pix4D etc).

All this number crunching and file analysis is making my brain melt..... it would be so much better if DJI could just change their SDK/firmware to fix this up..... for the life of me, I don't know why they cant get this fixed...

I was also slightly puzzled by their engineering department's response to me on that point - not a priority. It seems like it would be very little work to change the source of that EXIF
field. The options while using other control software will depend on how they implemented logging via the SDK. Those GPS data are available via the SDK if they choose to log them.
 
ohhhhhh..... doesn't look like any of the other control software records the DAT file MSL..... seems like they just use whatever is in the image EXIF data.
Bummer.... There has got to be a reason why DJI wont address this., since it should be simple enough to do.... if they would only tell us, we could move on, rather than lots of people spending lots of time trying to pick this needle out of this haystack.
Maybe they want us to get the Phantom RTK, but I for one don't want to carry around a box the size of a coffin every time I go out.
 
Still trying to work on this elevation thing for the M2P (must be the masochist in me :):))

Can anyone tell me what the figure in the .DAT file is for barometric readings.... what is this expressed in (not too concerned about what the difference is between Raw and Smooth at this stage, but would be interested if there is a definition)????
The main question I have is in relation to what the actual number value in the field represents.

For example, I have a .DAT file record where the field, barometer:Raw = -52.370777 (negative), in both the IMU_ATTI(0) and IMU_ATTI(1) fields (ALL baro fields in the file are negative)
This is certainly not the pressure in hPa (which at my location was 1018 for that day @19C / 67F), and neither is it inHg (30.05 in this case).

Any ideas????? the Phantom is looking better by the day for me, but I don't want to go there.
 
Still trying to work on this elevation thing for the M2P (must be the masochist in me :):))

Can anyone tell me what the figure in the .DAT file is for barometric readings.... what is this expressed in (not too concerned about what the difference is between Raw and Smooth at this stage, but would be interested if there is a definition)????
The main question I have is in relation to what the actual number value in the field represents.

For example, I have a .DAT file record where the field, barometer:Raw = -52.370777 (negative), in both the IMU_ATTI(0) and IMU_ATTI(1) fields (ALL baro fields in the file are negative)
This is certainly not the pressure in hPa (which at my location was 1018 for that day @19C / 67F), and neither is it inHg (30.05 in this case).

Any ideas????? the Phantom is looking better by the day for me, but I don't want to go there.

That's barometric height AMSL computed from a standard atmospheric model, in meters. The smoothed value should be the same as the EXIF field incorrectly labelled "GPS altitude".
 
SAR.... Thanks yet again...
at this point, I think I should just give up...... With 1hPa meaning a difference of more than 8.5 metres, there is no way I can come up with a process to address this issue.
The MSL in the .DAT file is the closest we can get, but even this may be suspect...., eg 16 m in one test, when it should be closer to 3 m.
Oh well....... bugger, as we say here in Oz.
 
SAR.... Thanks yet again...
at this point, I think I should just give up...... With 1hPa meaning a difference of more than 8.5 metres, there is no way I can come up with a process to address this issue.
The MSL in the .DAT file is the closest we can get, but even this may be suspect...., eg 16 m in one test, when it should be closer to 3 m.
Oh well....... bugger, as we say here in Oz.

In terms of the DAT file, the data that you want are the GPS height MSL record (GPS_0__heightMSL).
 
Seems CSV logs from Phantomhelp doesn't contain GPS height or it is named differently.
 
Lycus Tech Mavic Air 3 Case

DJI Drone Deals

New Threads

Forum statistics

Threads
131,120
Messages
1,560,020
Members
160,095
Latest member
magic31