Another Flyaway

[RichT]

looks like the trees to me its very congested on the link you posted

 

[Oliver_I]

looks like the trees to me its very congested on the link you posted

Yes it is, but if P-GPS is on and everything seems fine... it wasn't even the first time I started there and I never had a problem before.

 

[sar104]

Thank you very much for your detailed analysis! Fantastic!

The yaw part makes sense to me. I usually point the mavic away from me during start up, so that would have been NW. Sometimes also towards me (SE), so when I saw SE on the map I thought that's correct. Might have been wrong though.
What I don't understand is: If the direction is not correct, why doesn't the mavic just turn around instead of speeding in eastern direction?

Also I turned it on right on the spot where I started, I don't see any source for magnetic interference there. That's a bit strange.
And the GPS thing... the "health" is not shown in the App, or is it? I just saw P-GPS mode and 9 or 10 sats locked and thought that's fine.

Thank you again!
Oliver

So to clarify - did you power up the aircraft at that exact location or did you power it up and then move it to the takeoff location? And if it was that location, did you have anything potentially magnetic close to it at power up - your phone for example? Something caused the IMU yaw to be incorrectly initialized making it think it was pointing east when it was really pointing NW. It doesn't seem like it could have been magnetic distortion at the launch point itself, or at least it went away before launch because as the aircraft takes off and climbs the magnetic heading doesn't change - that suggests that at this point it is correct.

The firmware does seem to have the capability to respond to a yaw discrepancy by turning the aircraft while holding the yaw value constant until the yaw and magnetic yaw agree - we've seen examples of that. It didn't happen here - maybe it did not have time before the drift started, maybe the discrepancy is too large, or maybe something else is happening. Strangely, IMU0 yaw, which was also incorrect, but different from IMU1 yaw, was adjusted to match the magnetic yaw after takeoff (see post #36), but it was not the active IMU so that didn't help. The fact that the two IMUs were initialized with different headings perhaps suggests that the magnetic interference at startup was very local - such as a nearby phone, but I'm just guessing now.

If you want to try an interesting test - take the aircraft out to that same location and start it after starting the RC and the app so that the data are logged as early as possible in the startup process.

 

[sar104]

Yes it is, but if P-GPS is on and everything seems fine... it wasn't even the first time I started there and I never had a problem before.

It was at 8 satellites at motor start. That's a bit marginal. It would likely have been fine if it were not for the yaw errors on top of the marginal GPS signal.

 

[Oliver_I]

So to clarify - did you power up the aircraft at that exact location or did you power it up and then move it to the takeoff location? And if it was that location, did you have anything potentially magnetic close to it at power up - your phone for example? Something caused the IMU yaw to be incorrectly initialized making it think it was pointing east when it was really pointing NW. It doesn't seem like it could have been magnetic distortion at the launch point itself, or at least it went away before launch because as the aircraft takes off and climbs the magnetic heading doesn't change - that suggests that at this point it is correct.

The firmware does seem to have the capability to respond to a yaw discrepancy by turning the aircraft while holding the yaw value constant until the yaw and magnetic yaw agree - we've seen examples of that. It didn't happen here - maybe it did not have time before the drift started, maybe the discrepancy is too large, or maybe something else is happening. Strangely, IMU0 yaw, which was also incorrect, but different from IMU1 yaw, was adjusted to match the magnetic yaw after takeoff (see post #36), but it was not the active IMU so that didn't help. The fact that the two IMUs were initialized with different headings perhaps suggests that the magnetic interference at startup was very local - such as a nearby phone, but I'm just guessing now.

If you want to try an interesting test - take the aircraft out to that same location and start it after starting the RC and the app so that the data are logged as early as possible in the startup process.

Hi! Yes, I powered it up at the exact location where I took off. Maybe 2m away from it, but there was no magnetic source there except maybe my car which was parked only a couple of meters away (but turned off). My iPhone was plugged into the RC and I didn't have another one with me.
Thanks again for your effort! I might do that test... see if it happens again. This time I probably won't take off though...

 

[BudWalker]

Seems like this is a parallel thread; sorry everyone!

While possible, it would take very specialized software to compress the data stream on-the-fly, and the resulting format wouldn't likely be familiar. As I say, possible but difficult and probably not open-source.

In my case, ExtractDJI works fine on the full DAT from the aircraft; it builds a lengthy list of DAT files, one for each flight. But those DAT files are unintelligible by CsvView, which also stalls if I try it on "Flight 1" of the full-size DAT. So the gross structure of the DAT is still visible to ExtractDJI (it can extract individual flight DATs), but the flight data within a DAT is unintelligible to CsvView. That speaks of encryption more than compression to me, though I freely admit that's some hand-waving when I know nothing about the magic of either tool. I do know enough to say encryption on-the-fly would be easier than compression on-the-fly (again, both are possible).

Still, decompression may be worth a shot. But I'm of little use there. I only have WinZIP, which I can try ... for a sample of one.

@bytebiz
Maybe you guys should start another thread. . You're right. The structure of the .DAT file that DJI Assistant creates hasn't changed. It's a simple zlib compression scheme. But, the FLYxxx.DAT files that it contains have changed, for the Mavic Air at least.

 

[BudWalker]

Hi! Yes, I powered it up at the exact location where I took off. Maybe 2m away from it, but there was no magnetic source there except maybe my car which was parked only a couple of meters away (but turned off). My iPhone was plugged into the RC and I didn't have another one with me.
Thanks again for your effort! I might do that test... see if it happens again. This time I probably won't take off though...

But, you did move the Mavic after power on and before launch. The extent of the geomagnetic distortion can be small; less than 2 or 3 inches.

Thank you very much for your detailed analysis! Fantastic!

The yaw part makes sense to me. I usually point the mavic away from me during start up, so that would have been NW. Sometimes also towards me (SE), so when I saw SE on the map I thought that's correct. Might have been wrong though.
What I don't understand is: If the direction is not correct, why doesn't the mavic just turn around instead of speeding in eastern direction?

Also I turned it on right on the spot where I started, I don't see any source for magnetic interference there. That's a bit strange.
And the GPS thing... the "health" is not shown in the App, or is it? I just saw P-GPS mode and 9 or 10 sats locked and thought that's fine.

Thank you again!
Oliver

The Mavic can't know if it's compass heading is incorrect. Only the pilot can determine that by checking to see if the red triangle heading indicator in the map display is the same as the actual heading.


The gpsHealth can be seen on the RC display. It's the GPS bar display

 

[Oliver_I]

But, you did move the Mavic after power on and before launch. The extent of the geomagnetic distortion can be small; less than 2 or 3 inches.


The Mavic can't know if it's compass heading is incorrect. Only the pilot can determine that by checking to see if the red triangle heading indicator in the map display is the same as the actual heading.
View attachment 34788

The gpsHealth can be seen on the RC display. It's the GPS bar display
View attachment 34787

Thanks, I will take more care of this in the future.

 

[BJR981S]

Your car was too close. It is a huge magnetic anomaly. It does not need to be running.

Cheers

 

[anom3]

Just a quick note... My understanding is that the minimum number of GPS satellites for a lock is 7. So 9 is actually quite low. I usually wait until I get 12 or more before lift off. I say wait but really by the time I turn of my RC I usually have the 12. MP btw.

 

[BJR981S]

Just a quick note... My understanding is that the minimum number of GPS satellites for a lock is 7. So 9 is actually quite low. I usually wait until I get 12 or more before lift off. I say wait but really by the time I turn of my RC I usually have the 12. MP btw.

Actually that is not strictly correct. But is a good rule of thumb.

The number of satellites is indeed important, but not as important as the relative position of the Satellites in the sky. A 7 Sat lock could in fact be a better lock than a 12 Sat lock. The lock accuracy is referred to as its HDOP and VDOP numbers. The lower the numbers the better.

WIKI

HDOP – horizontal dilution of precision; VDOP – vertical dilution of precision; PDOP – position (3D) dilution of precision; TDOP – time dilution of precision. These values follow mathematically from the positions of the usable satellites. Signal receivers allow the display of these positions (skyplot) as well as the DOP values.

My understanding is that the strength display that DJI has introduced that is next to the number of Sats is the HDOP value.

So you should pay more attention to the strength indicators. Than the sat number.

 

[Oliver_I]

Just a short update: DJI repaired my Mavic Air free of charge and very quickly. Great service! They replaced the outer case and the props and said apart from that all is fine. I did ask them to analyze the logs, but didn't get any info about that. Well, they will probably not tell their customers if they have found anything unusual...
I think the cause of the flyaway is clear though after this thread. So I am happy and will be more careful in the future.

 

[Jameslavis]

I’m not sar or bud by any means but one thing I’ve noticed in my short time. I’ve had 3 flights from exactly the same spot and on the second flight I had a **** load of finicky connection notes in the app. Didn’t take off as I didn’t want my own fly away post.

Glad it was fixed.

 

[BudWalker]

......

My understanding is that the strength display that DJI has introduced that is next to the number of Sats is the HDOP value.

So you should pay more attention to the strength indicators. Than the sat number.

If you're referring to this

then that's the gpsLevel value. It's not a DOP indicator. The coords that are used by the Flight Controller are actually derived from both the GPS and IMU data. That's why the coords data has a higher resolution in both time and space than what can be expected from just GPS data alone. The gpsLevel value reflects the FC's confidence in this derived coords data. That's why gpsLevel will drop to 0 if the FC thinks there might be a compass error.

But, you're absolutely right. This value should be checked before flight to make sure it's at least 4.