Differences between the csv's for AirData and PhantomHelp logviewer for logs from fly app 1.3 & or 1.4.8

[sar104]

At the end of the day - I regard that specific sport mode flight as a bump in the night and have moved on.

The issue I'd like to understand better is why the HOME altitude is changing during flight. I know the land isn't moving up and down, and I know the GPS signal is variable, but everyone swears the drone mainly is using the barometer, and a 10' barometric change seems plausible over hours, but not 15 minutes: and the fact the GPS agrees with the barometer makes me think the height and altitude numbers are less reliant on the barometer than some will lead you to believe. At least in the Mavic Air 2 flight controller.

Anyway - perhaps I am beating that proverbial dead horse.

ps: next time I'm out I'll take my barometer and check the start-finish pressures.

A GPS height drift of 5 ft is also very small, but you didn't plot GPS height so I'm not sure what to say about how well it might agree with the OSD height. And whether you want to believe it or not, a 5 ft change in the barometric height over 15 minutes is perfectly normal (in fact rather good) on any of these platforms.

Furthermore - comparison with another barometer will demonstrate significant changes in atmospheric pressure, but will not tell you much at all about sensor drift.

 

[eEridani]

Post 17 has the two height & altitude numbers available. OSD:height I assume to be the barometric reading based on PF's comments, and OSD:altitude the gps reading. Yes, I did normalize the altitude columns relative to HOME altitude so they are comparable on the same scales (subtracted about 2259 feet, clipped the maximum elevation to 33.5 feet, and ensured there was a -7.9 foot data point).

https://mavicpilots.com/attachments/djiflightrecord_2021-09-09_-15-40-41-aircraft-3-png.136309/

 

[Zbip57]

Height above ground and ground elevation are computed values, using the aircraft location and a DEM. They are not data fields from the aircraft.

I don't know what a DEM is, but it suspect it's as follows below.

[...] the fact the GPS agrees with the barometer makes me think the height and altitude numbers are less reliant on the barometer than some will lead you to believe.

The CSV file generated by Phantomhelp has columns for;

• OSD.height,
• OSDvpsHeight, and
• OSD.altitude.

OSD.height and OSD.vpsHeight both show as zero at startup. The OSD.height is the barometric altimeter. It is subject to changes in local barometric pressure and temperature changes and will drift. It's common to see it register a non-zero value upon landing again back at the same spot.

OSD.vpsHeight is measured by the VPS system and is an accurate measure of height above ground only when the VPS system is within its operating range.

OSD.altitude is not actually measured or recorded by the aircraft. It is generated during the Phantomhelp analysis, taking the drone's GPS current location and comparing it to something like Google Earth's database, which has an elevation database for any GPS location. It then adds the drone's recorded barometric altimeter reading to the elevation data for that particular GPS location.

For example, let's say your Homepoint takeoff location is recorded as 0ft at a lat/long position for which Google Earth knows the elevation is 100ft. Take off, fly around, come back and land. Maybe your barometric altimeter has drifted by 10ft, so when you land back at the same spot OSD.height will now show +10ft. Phantomhelp will take that number, add it to the 100ft elevation that its database shows for that location, and the CSV file will now show the OSD.altitude at the landing location as 110ft.

That's why those two height measurements remain so consistent with each other, and they're both equally reliant on the barometer. The earth hasn't actually raised itself by 10ft.

 

[sar104]

Post 17 has the two height & altitude numbers available. OSD:height I assume to be the barometric reading based on PF's comments, and OSD:altitude the gps reading. Yes, I did normalize the altitude columns relative to HOME altitude so they are comparable on the same scales (subtracted about 2259 feet, clipped the maximum elevation to 33.5 feet, and ensured there was a -7.9 foot data point).

https://mavicpilots.com/attachments/djiflightrecord_2021-09-09_-15-40-41-aircraft-3-png.136309/

No - OSD:height is barometric height above the home point, and OSD:altitude is OSD:height plus the estimated home point elevation. GPS is not involved in either.

 

[Zbip57]

No - OSD:height is barometric height above the home point, and OSD:altitude is OSD:height plus the estimated home point elevation. GPS is not involved in either.

Of course. Thanks, that makes more sense.

Ignore my previous nonsensical ramblings.

 

[eEridani]

@Zbip57; @sar104

Makes a bit more sense now. Still going to take my digital barometer with me on my next flight; and this is adding to my "need" for a reasonably accurate altitude reading GPS.

ps: Is the home altitude simply based on a sea level reference pressure?

 

[Deleted member 103366]

DEM got me too, a bit of googling found Digital elevation model - Wikipedia

Ditto eEridani question about home altitude.

 

[sar104]

DEM got me to, a bit of googling found Digital elevation model - Wikipedia

Yes - those are the (large) datasets based mostly on LIDAR data of varying resolution that define terrain elevation.

 

[Deleted member 103366]

eEridani's concerns about the variation of indicated height at the home point go me to thinking.
I have the programs to scan, via their csv, every .txt flight log in my possession.
I can add code to add the last flying OSD:height entry of each flightlog to the output of my programs but at the moment I am struggling to see what I can use to determine which line of a csv corresponds to the last line before the drone touched down.
From the csv's I have so far looked at OSD:height is always 0 zero in the last line of the csv so I can not use that line and I do not think it will be as simple as using the last line minus some number of lines.

Is there a column in the csv or "signal"? that indicates whether or not the drone considers itself airborne?
I do not think "OSD.groundOrSky" will work as it is "Sky" up to and including the penultimate line of the csv and by that time the drone would surely be on the ground or in my hand etc.

 

[eEridani]

Aftr looking at a few logs, nothing stands out except to search upwards for non-zero in the OSD.zSpeed [MPH] column.

Another qualifier might be OSD.isMotorOn turns FALSE after touchdown. But even that isn't present in every log - go figure. And, my some of my logs are non-zero in the last line - any that have the offset.

Here's three of my logs ... please don't ask why one of the logs shows I landed under P-GPS; my head is already swimming with the altitude stuff.

 

[Deleted member 103366]

Fly app TXT files are not decodable by TXTlogToCSVtool,

Uuuum I am guessing you mean it can not process logs from App version 1.2 and later but TXTlogToCSVtoolMM https://phantompilots.com/attachments/txtlogtocsvtoolmm-zip.116879/ can process pre ver1.2 FLY app txt logs,

 

[sar104]

Uuuum I am guessing you mean it can not process logs from App version 1.2 and later but TXTlogToCSVtoolMM https://phantompilots.com/attachments/txtlogtocsvtoolmm-zip.116879/ can process pre ver1.2 FLY app txt logs,

Correct. It cannot decode logs created by the current version, or anything from 1.2.2 or later.

 

[Deleted member 103366]

I choose to, for each flight, subtract the 'first' OSD:altitude from the last OSD:altitude. There are some interesting results notably with a mid air CSC and restart with a Phantom 3 and what maybe in-flight disconnects with my Mavic Mini.

I will have to look at 'a few' of the actual csv's to check that my coding is not causing spurious results.

 

[eEridani]

I've asked this in another thread - but wonder if you guys have a link to the CSV glossary. Something that explains the columns and sources of data for each. It comes out of the yaw and yaw360 columns: are they different data or simply scaled differently?

 

[sar104]

I've asked this in another thread - but wonder if you guys have a link to the CSV glossary. Something that explains the columns and sources of data for each. It comes out of the yaw and yaw360 columns: are they different data or simply scaled differently?

Yaw is -180° – 180°, Yaw360 is 0° – 360°.

 

[eEridani]

Here's another one:
-- I'd guess sqrt(x^2+y^2+z^2) would equal h... but that's not working out. What do these numbers really mean?

OSD.hSpeed [MPH] 1.1
OSD.xSpeed [MPH] 0.9 (northward)
OSD.ySpeed [MPH] -1.6 (westward)
OSD.zSpeed [MPH] 0 (downward)

ps: I've asked over at FlightReader, here's the link Mike provided:

DJI Mobile SDK Documentation

I was searching DJI earlier today looking through stuff I could find, even went down the github rabbit hole looking for defines in the beta code that's available ... so that link is a bonanza for me! But doesn't explain why my math isn't working.

Package: dji.common.flightcontroller
SDK Key: FlightControllerKey.VELOCITY_X

Description:
Current speed of the aircraft in the x direction, in meters per second, using the N-E-D (North-East-Down) coordinate system.

Return:
float A float value of the current speed of the aircraft in the x direction.

 

[sar104]

Here's another one:
-- I'd guess sqrt(x^2+y^2+z^2) would equal h... but that's not working out. What do these numbers really mean?

OSD.hSpeed [MPH] 1.1
OSD.xSpeed [MPH] 0.9 (northward)
OSD.ySpeed [MPH] -1.6 (westward)
OSD.zSpeed [MPH] 0 (downward)

ps: I've asked over at FlightReader, here's the link Mike provided:

DJI Mobile SDK Documentation

I was searching DJI earlier today looking through stuff I could find, even went down the github rabbit hole looking for defines in the beta code that's available ... so that link is a bonanza for me! But doesn't explain why my math isn't working.

Package: dji.common.flightcontroller
SDK Key: FlightControllerKey.VELOCITY_X

Description:
Current speed of the aircraft in the x direction, in meters per second, using the N-E-D (North-East-Down) coordinate system.

Return:
float A float value of the current speed of the aircraft in the x direction.

In principle that would be correct, of course, but OSD.hSpeed is actually just the horizontal speed derived from the GNSS Doppler velocity data, while OSD.xSpeed and OSD.ySpeed are the IMU data fusion solution for velocity that incorporates the accelerometers, rate gyros, VPS and GNSS if available. They should generally be close, but not identical.

 

[eEridani]

In principle that would be correct, of course, but OSD.hSpeed is actually just the horizontal speed derived from the GNSS Doppler velocity data, while OSD.xSpeed and OSD.ySpeed are the IMU data fusion solution for velocity that incorporates the accelerometers, rate gyros, VPS and GNSS if available. They should generally be close, but not identical.

That may explain the minor differences I get from Airdata CSVs. But PhantomHelp is off (reported, too).

So @sar104 - where are you finding these details? Are they in the DJI toolkit? Or is there some third party tool that can be purchased?

 

[sar104]

That may explain the minor differences I get from Airdata CSVs. But PhantomHelp is off (reported, too).
View attachment 136442
So @sar104 - where are you finding these details? Are they in the DJI toolkit? Or is there some third party tool that can be purchased?

Just by inspection - I've not seen anything official. OSD.hSpeed comes and goes with the GNSS solution - when the satellite count falls too low it isn't present. And I would expect that kind of slightly loose correlation between the fusion and GNSS values.

 

[eEridani]

The vendor reported back that they're just reporting what the SDK provides ... not quite a satisfactory answer, but is what it is. Odd that two different users of a similar SDK come up with something different, though. I can accept 10.026 vs 10.0215 -- but the 9.30 for the same flight log - same time stamp - especially when X and Y correlate, H is definitely off. If it were just one value, no biggy - but this anomaly seems to permeate the PH CSVs.

...