msinger
Approved Vendor
- Joined
- Oct 30, 2014
- Messages
- 31,960
- Reaction score
- 10,786
- Location
- Harrisburg, PA (US)
- Website
- phantomhelp.com
$1500 just flew away and kept going
- Thread starter Dr.tones
- Start date
I thought that the mapsmadeeasy.com log viewer converts .DAT files, or is that only for the P3 and Inspire? I had assumed that the P4 files had a similar structure, but I haven't tried to read one yet.
msinger
Approved Vendor
- Joined
- Oct 30, 2014
- Messages
- 31,960
- Reaction score
- 10,786
- Location
- Harrisburg, PA (US)
- Website
- phantomhelp.com
I know that it says that, but I expected the P4 files to be similar - maybe not though. If no one has tried then I guess I'll throw a P4 file at it and see what happens. Hopefully I won't break the internet.
msinger
Approved Vendor
- Joined
- Oct 30, 2014
- Messages
- 31,960
- Reaction score
- 10,786
- Location
- Harrisburg, PA (US)
- Website
- phantomhelp.com
I usually use DatCon to convert DAT files -- and, I know that does not work with P4 DAT files. Perhaps @BudWalker knows the difference between P3 and P4 DAT files.
They file format may not be all that different. I don't know. What's totally different is how they are encoded, possibly encrypted. If you're interested take a look at .DAT file for the P4?
Thanks for the information. Seems like you guys hit a dead end trying to decode those files back in April.
.
...YoungGun, the Data is generated by the Craft and/or the DJI-GO App that is to say the Remote obviously sends Ctrl Signals to the Craft, the Craft in turn sends Signals (Telemetry) back to the CS (Ctrl Station) which in this example is the Remote, the Phone/Tablet and the App.. DJI Inspire1 & Phantoms also generate an OnBoard File Proprietary .DAT File that contains much of the same data and more.. DJI is currently the only one that can view this file and they use it for warranty claim diagnostics.. (DJI Log Converter reports to be able to view the FLYxxx.DAT from the Phantom3's, I have not used or seen any of their results and they charge 1$ per)
..the DJIFlightRecord_*.txt is the File generated on the Tablet/Phone that can then be used to Diagnose your Flight and Craft by way of a few different Online Converters, for example: PhantomHelp Log Viewer, or Healthy-Drones.. basically these converters take the DJIFlightRecord_*.txt file and extract the data into a CSV type file, PhantomHelp then displays a portion of that CSV File on the Web Site, it also allows you to dwnld the CSV and the KML it generates from the CSV data.. PhantomHelp in the early days and still is a great service considering that DJI decided to put this data into the .txt file in a format that is not readily view-able with a standard txt file viewer/editor.. where Healthy-Drones stands out as the Current Best Online DJIFlightRecord_*.txt Converters is that in addition to the bare-bones CSV and KML's the developer has gone to great effort to then compile that data using algorithms and then display it in a graphical format.. so, what advantage is it to have these pretty charts and graphs? you can then do real preventative/predictive maintenance on your craft to keep it Safe and to protect your investment in it AND Obviously to learn from it.. Healthy-Drones has a Free-Acct that allows you to upload and store up to 50 Flights.. the other accts are based on fee's and also allow more flight record storage, more data and are Very affordable in my opinion.. as I stated in an earlier post, I have no Vested Interest in Healthy-Drones, I do not personally know the Developer aside from a few emails back and forth diagnosing minor bugs within the service., also as I stated earlier if you fly these crafts and don't take advantage of at least one of these services you're flying blind and you fly at your (or others) peril.. it is simply irresponsible to fly these things beyond say the tree line in your own yard without some clue as to the state of the machine your flying...
...below are the links to the various Converters I spoke of:
.
HealthyDrones.com - Innovative flight data analysis that matters
.
https://www.phantomhelp.com/LogViewer/Upload/
.
DJI Log Converter
.
IIIDaemon
www.GasRecovery.net
.
...sar104, this point of view was addressed and proven to be nothing more than an Assertion based on speculation and lack of data (I haven't deleted any of the posts)...
.
...I think, I could be wrong, but i think where your missing the point is that your assuming the original Google-Earth graphic posted is accurate which in fact it is not...
.
IIIDaemon
www.GasRecovery.net
Addressed where? That is the behavior that I, too, have seen on logs of flights in which the connection was lost and not re-established. The only speculative, unsubstantiated assertions that I've seen in this exchange have been yours.
.
...sar104, hhaha really? so Flying Behind that Big Rock and the referenced Original Google-Earth Graphic isn't an assertion based on speculation..?
.
IIIDaemon
www.GasRecovery.net
Meta4
Premium Pilot
- Joined
- Jan 8, 2014
- Messages
- 15,301
- Reaction score
- 9,243
The flight data doesn't back this theory up.
At the time the flight record ends, the Phantom had gone behind terrain which would block radio signal.
It was above the ground below it and if it continued flying in the same trajectory, the ground was falling away so the flight data does not support the idea that the Phantom was flown into the ground.
The only explanation for the data is the simplest and most obvious one: SIgnal was blocked by flying behind terrain.
The P4 then entered RTH and crashed into the top of the rocky outcrop as can be seen in the OP's recovery video.
If it had been flying just a little higher, it would have cleared the outcrop.
HD only ever gives a brief summary and as it does not show actual data it is of limited use in incident investigation.
Looking through the data, I see a max turn rate of 14.8 in 1/10th of a second and it occurred soon after takeoff.
I also see several other 12-14° in 1/10th of a second turns throughout the flight.
The difference between my number 14.8° and HD's 16.5° is too small to worry about and is possibly due to a difference in milliseconds between data points.
The flight data gives no indication that there was anything like this happening at the end of the flight and HD is working from the same data.
Is there a specification of the file format available? I could easily prepare an appropriate program if I had these specs.
msinger
Approved Vendor
- Joined
- Oct 30, 2014
- Messages
- 31,960
- Reaction score
- 10,786
- Location
- Harrisburg, PA (US)
- Website
- phantomhelp.com
I understand the logging (in a basic sense). The reason I asked which file was being used was because of the fact that if connection was lost the data obtained from the mobile device would end prior to the actual crash (as mentioned in a more recent post).
I'm not trying to diagnose or enter the debate, just checking my assumption of the data source.
I was unaware that data from the P4 couldn't be read.
Sent from my iPhone using Tapatalk
I posted the following over on .DAT file for the P4? and thought it might be relevant here.
The P4 and P3 .DAT files are similar. They both get recorded onto an internal SD card that is very difficult to access physically. They are both encoded which allows the internal bus to be more efficient. In the case of the P3 the .DAT can be directly accessed via the USB port. All it takes is a file copy.
If we were able to access the P4 .DAT in the same way; i.e., just a file copy then it should be relatively simple to determine the format and DatCon would work for P4 .DAT files. @FredzMaxxUAV obtained a set of these P4 .DAT files when he had the P4 disassembled and was able to physically extract the SD card. I was then able to use some of the tools that I developed to reverse engineer the P3 .DAT file. The P3 and P4 .DATs use the same kind of format but are different enough that it would require some work to to determine the format.
The real problem is that, so far, we've been unable to get a copy of the internal SD card's .DAT file. Unlike the P3, there is no way to directly view and retrieve the internal .DAT files on the P4. Instead the P4 .DAT files are retrieved via the DJI Assistant app which then produces three files that can be sent to DJI. I've looked at these files and they are either encoded, compressed or encrypted. It doesn't make much sense to encode them. There isn't much to be gained by compressing the internal .DAT file since it already has a lot of entropy, i.e. it can't be compressed much further. But, I did look at the obvious compression schemes.
I think the files that the DJI Assistant produces are probably an encryption of the internal .DAT file. If so, then it's effectively impossible to retrieve the internal .DAT file from these files.
One possibility is to determine how the DJI Assistant produces the three file from the internal .DAT. If the bits coming across the USB to the DJI Assistant aren't encrypted then it should be possible to mimic the DJI Assistant and get those unencrypted bits. @Hans 75 attempted to use a USB sniffer but didn't get very far.
The P4 and P3 .DAT files are similar. They both get recorded onto an internal SD card that is very difficult to access physically. They are both encoded which allows the internal bus to be more efficient. In the case of the P3 the .DAT can be directly accessed via the USB port. All it takes is a file copy.
If we were able to access the P4 .DAT in the same way; i.e., just a file copy then it should be relatively simple to determine the format and DatCon would work for P4 .DAT files. @FredzMaxxUAV obtained a set of these P4 .DAT files when he had the P4 disassembled and was able to physically extract the SD card. I was then able to use some of the tools that I developed to reverse engineer the P3 .DAT file. The P3 and P4 .DATs use the same kind of format but are different enough that it would require some work to to determine the format.
The real problem is that, so far, we've been unable to get a copy of the internal SD card's .DAT file. Unlike the P3, there is no way to directly view and retrieve the internal .DAT files on the P4. Instead the P4 .DAT files are retrieved via the DJI Assistant app which then produces three files that can be sent to DJI. I've looked at these files and they are either encoded, compressed or encrypted. It doesn't make much sense to encode them. There isn't much to be gained by compressing the internal .DAT file since it already has a lot of entropy, i.e. it can't be compressed much further. But, I did look at the obvious compression schemes.
I think the files that the DJI Assistant produces are probably an encryption of the internal .DAT file. If so, then it's effectively impossible to retrieve the internal .DAT file from these files.
One possibility is to determine how the DJI Assistant produces the three file from the internal .DAT. If the bits coming across the USB to the DJI Assistant aren't encrypted then it should be possible to mimic the DJI Assistant and get those unencrypted bits. @Hans 75 attempted to use a USB sniffer but didn't get very far.
It isn't speculation at all - it is the result of converting the log file to kml and then opening it in Google Earth. It is the recorded flight path, including elevations, overlaid on a reasonably accurate DEM. Both @msinger and I independently did that immediately that the log was posted. I didn't realize that you were unaware of how to do that.
In any case, if the aircraft had not been found then there might be some residual doubt over what happened but, since it was found, and in exactly the location that was predicted from the flight data and RTH height, this argument is moot. Even though you apparently don't understand the reasoning, the flight and its log data are not consistent with your attempted explanation.
Similar threads
