how to read the assistant export file

[wntmldrs]

Today I was flying, and making pictures with my camera. A deadly error : never do two things together !!
I send the Mavic up to see if the sunset was visible. I parked it at 38 meters above me. Then I took my camera and did some sunset shots.
Then I grabbed the remote and Litchi it said .... disconnected .... I was too baffled too check what he display of the remote said. After some fiddling I restarted Litchi and I saw some youngsters picking up my Mavic. I went towards them had a laugh and went inside to check the files and the videos. After a flight of 1 minute no more data and no more video. After 2 minutes 'downlink data connection lost for 158 seconds.
I cannot imagine what I did wrong except laying down the remote in the grass. I exported the flight file in Assistant, but I don't know how to read it.
Help me understand what caused this.

 

[slup]

Hi there & welcome to the forum ... even though it's due to sad circumstances.

All logs that you retrieve directly from a Mavic 2 Pro by means of DJI Assistant 2 is encrypted & can only be read by DJI staff... in other words, they are useless.

If you want help with this you need to retrieve either or both of the 2 Litchi logs that are stored in the mobile device you flew with ... if you had an Android device they are here ...

The location of the log files in a Android device from the Litchi app is today for the newer versions:
For the .csv: Device internal memory\Android\data\com.aryuthere.visionplus\files\flightlogs
For the .txt: Device internal memory\Android\data\com.aryuthere.visionplus\files\DJI\com.aryuthere.visionplus\FlightRecord

When you have the 2 logs from this flight, come back here & attach them in a new post in this thread.

 

[wntmldrs]

I fly with an Apple iPad Mini.
The upload Litchi does to Airdata, do they contain all the data collected or are there other files hidden in the iPad ?

 

[slup]

I fly with an Apple iPad Mini.

Check here ...

On iOS devices, the Litchi CSV logs are in Litchi » Documents » flightlogs, and the DJI TXT logs are in Litchi » Documents » SDK_logs » FlightRecord

 

[wntmldrs]

Check here ...

On iOS devices, the Litchi CSV logs are in Litchi » Documents » flightlogs, and the DJI TXT logs are in Litchi » Documents » SDK_logs » FlightRecord

Well

 

[wntmldrs]

Here are the files. I'm really curious if there is any clue to what happened. I forgot to tell that the Mavic only has minor damage. The CSC file refuses to upload. Is there any trick ??

 

[slup]

It's enough with the TXT log you've shared ...

Unfortunately we would have needed another log that isn't created as you used Litchi ... the TXT (& Litchi CSV) contain all telemetry ... i.e. we can see all stick commands, speeds, heights & craft movements in all axis ... but we can't see any motor data or any raw sensor data, that info is stored in the DAT log. 2 DAT logs are created if you use a DJI app, one in the craft itself (encrypted so we can't read it) & one in your mobile device (but when using Litchi this one isn't created).

So all we have is the telemetry ...

Here you have some relevant data out from your attached TXT log drawn out in a chart, the chart is zoomed in on the period between 57sec into the flight where you release the sticks & start to hover the M2P ... to the end of the log.

If you click on the chart you make it bigger ... the graphs are explained in the legend under the chart, the stick commands is dashed graphs, values in the legend is from where the chart marker is placed, in the end at 75sec.

As seen, nothing indicate a up coming disaster ... the M2P pitch up to brake when you release the sticks & the speed goes to 0mph. There in the end where the chart marker is placed at 75sec, your sticks are neutral (value 1024), height is stable & roll pitch and yaw doesn't show any abrupt or abnormal values ... then the log ends.



If looking at the battery data it looks like below ... nothing abnormal there either, also the log indicate that the motors are up & running.



As we know that the TXT log is recording between motors on to off when the M2P is connected with the RC+app ... it leaves us with 2 reasons for a log recording termination.

1. You lost the RC+app to M2P connection ... but not likely as that wouldn't make your M2P crash into the ground.
2. The motors stops ... will happen if it's a sudden power loss. This is likely ... as we have earlier seen several batteries coming lose from M2P's due to some swelling during flight.

So with what we have nothing definitive can be said ... but it's very likely that this incident was due to a sudden power loss ... so the disconnect you first reacted on was actually your M2P shutting down & start to free fall.

 

[wntmldrs]

Fascinating your skills to analyse and deduct possibilities from these data.
Sudden power loss because of a not fully inserted battery seems the only answer. But as soon as these youngster pick up the Mavic I sees them talking and laughing and bringing the poor thing to me. Unless the battery was back inserted by the impact of the fall.........
So what I learned from you :
the txt file is written while the motors are running
the only continuous file is in the drone and only readable by DJI
if I fly the DJI app there it generates a more complete DAT file.

What if I made, involuntary, a KILL move with the sticks, that would make the motors stop and the TXT file also ???

 

[slup]

...What if I made, involuntary, a KILL move with the sticks, that would make the motors stop and the TXT file also ???

The combination stick command (CSC) has a delay of several seconds ... so you will need to keep the sticks jammed in that position for quite a while & with your craft descending & rotating in rapid speed. Furthermore ... the CSC command is usually only allowed when some DJI defined critical state has occurred. The newer crafts that uses the DJI Fly app have the ability to set the CSC to either "Always" or "Emergency"... when people put in Always as a setting it happens that crafts go down but it's rare & we can see all the fast descending & rotation for several seconds before the motors stop & the log ends ... nothing of that was seen in your case.

 

[wntmldrs]

The combination stick command (CSC) has a delay of several seconds ... so you will need to keep the sticks jammed in that position for quite a while & with your craft descending & rotating in rapid speed. Furthermore ... the CSC command is usually only allowed when some DJI defined critical state has occurred. The newer crafts that uses the DJI Fly app have the ability to set the CSC to either "Always" or "Emergency"... when people put in Always as a setting it happens that crafts go down but it's rare & we can see all the fast descending & rotation for several seconds before the motors stop & the log ends ... nothing of that was seen in your case.

While repairing the front leg I took off the props and I can see scar marks and one prop partly sheared. So I presume the props were still turning when it came down. In Litchi I had for a few days some nagging remarks about the sensors and it advised a recalibration. Today I tested the repair and found the landing protection not working. So if I didn't pay attention the mavic would have smashed in the grass. Could that have played a role in the fatal descent of yesterday ???

 

[slup]

...I can see scar marks and one prop partly sheared. So I presume the props were still turning when it came down.

...found the landing protection not working... Could that have played a role in the fatal descent of yesterday ???

When a craft free falls with the motors off they will still rotated due to the drag from the air flowing from below the prop & up ...

A failing VPS sensor alone will not make a craft come falling down ... all circumstances so far indicates that your incident could have been due to a sudden power loss, either from that the battery got ejected (due to swelling issues or a partial attached battery) ... or that some other electronic component that affect the motors failed.

 

[Not A Speck Of Cereal]

And of course the crash could have damaged the VPS.

Chris

 

[wntmldrs]

After replacing the front leg, replacing a prop and calibrating the sensors the Mavic flies as new !!
With the Swedish help of Slup, we ruled out most propable causes.
How about this ??
Most of the time I do panorama's and often I lay down the remote, never any trouble because in a panorama it executes the commands now stored in the drone, it doesn't need a constant downlink.
But this time I am flying normally and I put the remote in the grass with the screen up and the antennas down. Maybe that caused the lack of downlink and any further lines in the log. The Mavic should start the RTH sequence but maybe, maybe my fiddling with the sticks provoked instead of RTH a fall to the ground. Because of restarting Litchi I regained downlink and the writing continues on the ground.
Very strange is the pirouette visible in the GPS file, but not in the stick inputs.

 

[Not A Speck Of Cereal]

But this time I am flying normally and I put the remote in the grass with the screen up and the antennas down. Maybe that caused the lack of downlink and any further lines in the log. The Mavic should start the RTH sequence but maybe, maybe my fiddling with the sticks provoked instead of RTH a fall to the ground. Because of restarting Litchi I regained downlink and the writing continues on the ground.

You could put the remote on the ground and then actually power it down (turn the remote off) and the drone would a) keep shooting the pano and then b) do whatever you have programmed it to do on loss of signal (hoover, land, RTH).

Leaving the remote powered on, but laying it on the ground, shouldn't make any difference unless you are imagining that somehow the sticks got put into (and held in} the CSC position. But even then, even if that caused it to fall out of the sky, it wouldn't have caused an abrupt power failure (which is what I think the logs are indicating by reading previous replies).

Chris

 

[wntmldrs]

I've uploaded the csv-file to Phantomhelp with gives about the same parameters as Airdata. In another attempt I imported the same csv-file in Excel and to me surprise many more data are available.
This is a screenshot of only the relevant fields at the moment were there is an inexplainable gap in time from 18h47 till 18h50.