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

Get the wind data from Mavic 2 Zoom?

Ok thank you for the help :) Then reading the other parameters and using either 3rd party solutions or our own calculations to wind speed and direction might be our best option to get high frequency data.
Getting higher frequency wind data is tough. I was working on this a while back. My approach was to derive air speed from the tilt inclination. Wind speed and direction are simple to compute once the air speed, tilt direction, ground speed and ground direction are known. However, the air speed vs tilt inclination relationship is only valid if the AC is not accelerating in X, Y and Z and the tilt inclination and direction are also stable. In fact, most of my effort was centered around determining when the wind calcs are valid. Although, instantaneously, the calcs can be valid they won't be valid for very long. I think that the M2 wind calcs are actually the result of a low pass filter which, in turn, presents as lower frequency wind data. Probably same is true for AirData.
 
Last edited:
@BudWalker ... I flew a shorty today, the wind & especially the gusts were a bit on the higher side so it was only a shorter lap around the neighborhood at 30 meters height.

The winds were approx south westerly on ground... so negative wind_x(North) & wind_y(East).

On the 65sec mark in the chart:

Angle from west=tan−1(-6,3/-8,59)≈ -36,26 degrees
Angle from north=270-36,26 = 233,74 degrees

... this is pretty consistent throughout the lap. It differs a bit from Airdata indication which is 218 degrees at that point, but match better Airdatas average direction of 223 degrees. The magnetic declination where I live is 5,53 degrees east.

Have attached the DAT log


View attachment 94006

View attachment 94007
OK, I'll take this as a positive confirmation and slide this into the next version. :)
 
  • Like
Reactions: slup
Did as @BudWalker said, went into DatCon Parsing options & ticked Engineered & Datdefined ... & then I got those signals. the Airdata & those frome the DAT differs but can't say which is more accurate.

View attachment 94022

Interesting - I didn't realize that "Engineered and DatDefined" produced additional fields versus "Engineered then DatDefined".

However, now I don't understand what these data mean. I cannot see a consistent relationship between the wind_x and wind_y data and the AirComp_AirSpeedBody_X and AirComp_AirSpeedBody_Y data. @BudWalker?
 
Interesting - I didn't realize that "Engineered and DatDefined" produced additional fields versus "Engineered then DatDefined".

However, now I don't understand what these data mean. I cannot see a consistent relationship between the wind_x and wind_y data and the AirComp_AirSpeedBody_X and AirComp_AirSpeedBody_Y data. @BudWalker?
You've managed to uncover a design flaw that's existed since day one. It's never been a problem until now and will be a major undertaking to fix. It has to do with how DatCon goes about deciding which parser to user for each record type. The AirComp parser being used here actually came from a P4Pro. Please ignore the AirComp data found here.

Back in post #14 I speculated that wind_X and wind_Y are actually wind_N and wind_Y respectively. I.e. windDir would be atan2(wind_Y, wind_X). Based on @slup 's confirmation are you comfortable with that.
 
  • Like
Reactions: sar104
You've managed to uncover a design flaw that's existed since day one. It's never been a problem until now and will be a major undertaking to fix. It has to do with how DatCon goes about deciding which parser to user for each record type. The AirComp parser being used here actually came from a P4Pro. Please ignore the AirComp data found here.

Back in post #14 I speculated that wind_X and wind_Y are actually wind_N and wind_Y respectively. I.e. windDir would be atan2(wind_Y, wind_X). Based on @slup 's confirmation are you comfortable with that.

For the data presented, wind_x and wind_y are both negative - i.e. the resulting wind velocity vector points to the SW. AirData calculates wind out of the SW, so a wind velocity vector pointing NE. What am I missing? Are wind_x and wind_y actually the negative wind velocities? Then the wind velocity and direction agree pretty well with AirData.

Graph8.png
 
Are wind_x and wind_y actually the negative wind velocities? Then the wind velocity and direction agree pretty well with AirData.

With Engineered and Datdefined in CsvView looking at the signal group "air_compensate_data" ...

I made just that assumption from the AC counter force point of view (north & east) & made some calculations around the lap I took yesterday & the wind direction that came out was pretty consistent the whole way around and matched Airdata "good enough". Also the wind_spd signal were in the same ballpark as Airdata ...

Couldn't get any logic from the signal group "Aircomp"
 
@slup, @sar104
The design flaw that I mentioned was actually not that difficult to overcome. It had been about a year since I initially looked at this and punted. Having forgotten my failed approach I now managed to stumble on to something much easier.

Anyway, what do you guys want to do about the wind calcs? Do you wanna try this
Wind:dir == atan2(-wind_y, -wind_x)
Wind:dirFrom == atan2(wind_y, wind_x)
 
  • Like
Reactions: slup and sar104
@slup, @sar104
The design flaw that I mentioned was actually not that difficult to overcome. It had been about a year since I initially looked at this and punted. Having forgotten my failed approach I now managed to stumble on to something much easier.

Anyway, what do you guys want to do about the wind calcs? Do you wanna try this
Wind:dir == atan2(-wind_y, -wind_x)
Wind:dirFrom == atan2(wind_y, wind_x)

If wind_x and wind_y are the negatives of the wind velocity vector, then that seems completely appropriate. I don't really understand why that would be the case though, based on the notation.
 
If wind_x and wind_y are the negatives of the wind velocity vector, then that seems completely appropriate. I don't really understand why that would be the case though, based on the notation.
I think I agree with sar104 :)

I mean, you always express wind direction as from the direction it's blowing from ... so in my previous test it was blowing from SW, meaning that if wind_x is North & wind_y is East, SW should be negative wind_x & _y.

How will you build the signal ... based on 360 degrees from North?
 
I think I agree with sar104 :)

I mean, you always express wind direction as from the direction it's blowing from ... so in my previous test it was blowing from SW, meaning that if wind_x is North & wind_y is East, SW should be negative wind_x & _y.

How will you build the signal ... based on 360 degrees from North?

Right - just to make sure we are in the same frame of reference, the wind_x and wind_y values during your flight were both negative. If those were wind velocity vectors (as might be expected) then that would have been a NE wind. But AirData indicates a SW wind. I don't understand why wind_x and wind_y would be vectors pointing into the wind.
 
Right - just to make sure we are in the same frame of reference, the wind_x and wind_y values during your flight were both negative. If those were wind velocity vectors (as might be expected) then that would have been a NE wind. But AirData indicates a SW wind. I don't understand why wind_x and wind_y would be vectors pointing into the wind.
I reasoned like this first when @BudWalker revealed this secret in the log ;) ...

It's the AC that measures the forces by how much & in what direction it have to put in counter forces ... all from a AC perspective. To counter a velocity vector to NE then the AC needs to push towards negative East & negative North... making it pushing towards a wind coming from SW.

With this calculating the values I get roughly a wind direction of 225-230 degrees ... which is pretty close to what Airdata shows.

Or do I misunderstand you?
 
I reasoned like this first when @BudWalker revealed this secret in the log ;) ...

It's the AC that measures the forces by how much & in what direction it have to put in counter forces ... all from a AC perspective. To counter a velocity vector to NE then the AC needs to push towards negative East & negative North... making it pushing towards a wind coming from SW.

With this calculating the values I get roughly a wind direction of 225-230 degrees ... which is pretty close to what Airdata shows.

Or do I misunderstand you?

No - you understood what I was trying to say. And it does look like that's possibly the case. But I'm not very satisfied by the explanation, since wind_x and wind_y really sound like they should be the wind velocity vector, not some resistance vector that the FC uses to combat the wind, especially if their units are m/s.

Air velocity minus ground velocity would give those values, but that would be a rather perverse calculation, since wind velocity is ground velocity minus air velocity.
 
No - you understood what I was trying to say. And it does look like that's possibly the case. But I'm not very satisfied by the explanation, since wind_x and wind_y really sound like they should be the wind velocity vector, not some resistance vector that the FC uses to combat the wind, especially if their units are m/s.

Air velocity minus ground velocity would give those values, but that would be a rather perverse calculation, since wind velocity is ground velocity minus air velocity.
Mmm... so are you saying that we actually doesn't know what the wind values are showing?
 
Getting higher frequency wind data is tough. I was working on this a while back. My approach was to derive air speed from the tilt inclination. Wind speed and direction are simple to compute once the air speed, tilt direction, ground speed and ground direction are known. However, the air speed vs tilt inclination relationship is only valid if the AC is not accelerating in X, Y and Z and the tilt inclination and direction are also stable. In fact, most of my effort was centered around determining when the wind calcs are valid. Although, instantaneously, the calcs can be valid they won't be valid for very long. I think that the M2 wind calcs are actually the result of a low pass filter which, in turn, presents as lower frequency wind data. Probably same is true for AirData.
We are unable to find any .DAT files in the DJI Go 4 app (as in inside the tablet folder). It doesn't seem to store any of the .DAT files from our flights using our Mavic Pro 2 Zoom, we can find the .TXT files however and we can find flight logs from previous flights from a Mavic Pro AC but not from our Mavic Pro 2... any suggestions?
 
We are unable to find any .DAT files in the DJI Go 4 app (as in inside the tablet folder). It doesn't seem to store any of the .DAT files from our flights using our Mavic Pro 2 Zoom, we can find the .TXT files however and we can find flight logs from previous flights from a Mavic Pro AC but not from our Mavic Pro 2... any suggestions?

Uninstall the GO 4 app and delete all its directories, then reinstall.
 
  • Like
Reactions: slup and BudWalker
We've installed a fresh version of DJI Go 4 on an Android device. I plug my smartphone into a computer, go to "xxxx\xxxxx\smartphone_directory\DJI\dji.go.v4\FlightRecord" but all I can find is a .txt file, nothing else. This is with a new device also so there should be nothing wrong with the phone. We have firmware version V01.00.0510 on the AC and controller.
 
Last edited:
We've installed a fresh version of DJI Go 4 on an Android device. I plug my smartphone into a computer, go to "xxxx\xxxxx\smartphone_directory\DJI\dji.go.v4\FlightRecord" but all I can find is a .txt file, nothing else. This is with a new device also so there should be nothing wrong with the phone. We have firmware version V01.00.0510 on the AC and controller.

So there is no folder named MCDatFlightRecords in DJI » dji.go.v4 » FlightRecord?
 
Lycus Tech Mavic Air 3 Case

DJI Drone Deals

New Threads

Forum statistics

Threads
131,096
Messages
1,559,815
Members
160,080
Latest member
KevinStudent