msinger
Approved Vendor
- Joined
- Oct 30, 2014
- Messages
- 32,154
- Reaction score
- 10,911
- Location
- Harrisburg, PA (US)
- Website
- phantomhelp.com
[TOOL][WIN] Offline TXT FlightRecord to CSV Converter
- Thread starter ferraript
- Start date
msinger
Approved Vendor
- Joined
- Oct 30, 2014
- Messages
- 32,154
- Reaction score
- 10,911
- Location
- Harrisburg, PA (US)
- Website
- phantomhelp.com
new version is out
it fixes one small bug
in rare cases text fields (like APP_SER_WARN.warn) contained new line character - that led to broken CSVs
so new line character is now replaced with semicolon (or comma, if you use semicolon as delimiter)
thanks, BudWalker, for pointing that out
it fixes one small bug
in rare cases text fields (like APP_SER_WARN.warn) contained new line character - that led to broken CSVs
so new line character is now replaced with semicolon (or comma, if you use semicolon as delimiter)
thanks, BudWalker, for pointing that out
fool's day brings you another new version 
but this time there is some bad news too
changes:
- added better support for Mavic Air - especially correct cell voltages reporting (note: BudWalker did let me know about this problem and I had 1 source TXT only so I just hope it will work fine for all of you)
- added some battery info for Mavics - if exists in the log
- added a few new text constants for flycCommand and other fields
and now a little bit bad news
it's been a long time since I decompiled DJI GO apk, my main source of information
and few days ago I tried it again with newest version (4.2.8) and I found out two things:
1. Since 4.1.4, DJI encoded all text constants, so it's harder to read the code. Fortunately some clever guys found the decryption algorithm so it's possible to decode the sources.
2. Since 4.1.10, DJI must have added some protection to APKs, because decompilation is now basically not helpful at all - part of the code is decompiled fine, but part of the code is not decompiled at all and part of the code is totally missing.
conclusion: at the moment, the tool is based on the sources from DJI GO 4.1.9
in the future, if DJI changes important parts of the DJI GO, it will be very hard (maybe impossible) to adapt my tool for it
lets just hope they don't do that anytime soon...
but this time there is some bad news too
changes:
- added better support for Mavic Air - especially correct cell voltages reporting (note: BudWalker did let me know about this problem and I had 1 source TXT only so I just hope it will work fine for all of you)
- added some battery info for Mavics - if exists in the log
- added a few new text constants for flycCommand and other fields
and now a little bit bad news
it's been a long time since I decompiled DJI GO apk, my main source of information
and few days ago I tried it again with newest version (4.2.8) and I found out two things:
1. Since 4.1.4, DJI encoded all text constants, so it's harder to read the code. Fortunately some clever guys found the decryption algorithm so it's possible to decode the sources.
2. Since 4.1.10, DJI must have added some protection to APKs, because decompilation is now basically not helpful at all - part of the code is decompiled fine, but part of the code is not decompiled at all and part of the code is totally missing.
conclusion: at the moment, the tool is based on the sources from DJI GO 4.1.9
in the future, if DJI changes important parts of the DJI GO, it will be very hard (maybe impossible) to adapt my tool for it
lets just hope they don't do that anytime soon...
and now a little bit bad news
it's been a long time since I decompiled DJI GO apk, my main source of information
and few days ago I tried it again with newest version (4.2.8) and I found out two things:
1. Since 4.1.4, DJI encoded all text constants, so it's harder to read the code. Fortunately some clever guys found the decryption algorithm so it's possible to decode the sources.
2. Since 4.1.10, DJI must have added some protection to APKs, because decompilation is now basically not helpful at all - part of the code is decompiled fine, but part of the code is not decompiled at all and part of the code is totally missing.
conclusion: at the moment, the tool is based on the sources from DJI GO 4.1.9
in the future, if DJI changes important parts of the DJI GO, it will be very hard (maybe impossible) to adapt my tool for it
lets just hope they don't do that anytime soon...
Don't you find it at least a bit ironic that you're complaining about DJI keeping their code (and their encoding mechanism) secret - yet you yourself refuse to release the source code for your decoding application, or describe in detail what you've learned about DJI's encoding (which would allow other people to help you keep up with DJI's apparent continued obfuscation).
So please, stop being so secretive. You're not the only smart person out there; please let the rest of us help you with this. Please release your source code, or at least a detailed description of what you've learned about how DJI's TXT logs are currently encoded.
it took me a little while to think over the reply to your comment, so here we go:
in this case I wasn't complaining about DJI, they can mostly do good job
but they still deserve complaining, at least for two things:
- DJI GO (at least Android's version) is still very buggy and it looks like they are making things worse only
- with all those new prohibitions and conditions, it's like they are punishing users (for example it's totally inacceptable to tell users when they can fly or force them to update firmware or DJI GO)
and now to the code and decoding
with your attitude you are exactly the same as dozens of people asking us to share the decoding algorithm
it's sad that nobody has come with something like "hey, I want to help you, I found something in DJI GO / firmware that you haven't, I want to make your tool better"
for a while I was thinking about some kind of poll, where users of my tool could be able to vote if I'm (or exactly we are) to share the algorithm or not
but then I realized few things:
1. I believe DJI encrypted the logs, because they wanted to have some kind of insurance, that the logs were valid, not faked.
Because if somebody has encryption/decryption algorithm, he can abuse it and alter the logs.
I can easily see webpages offering "did you crash because of your fault? send us your TXT log, 50 bucks, and we will change the log so it will look like it was hardware fault and you can ask DJI for free repair"
It has been 19 months since DJI came up with encryption and it's 18 months since we broke it.
DJI hasn't changed the algorithm since then so I believe they are satisfied with things as they are now.
2. You say "You're not the only smart person out there; please let the rest of us help you with this".
Well, where are all those smart people? Because until now, as far as I know, there are no new services offering to read the encrypted logs, except all those old ones - Airdata, djilogs, phantomhelp and my converter.
Sadly that also means that if DJI changes the encryption in the future, there will be nobody to break it (maybe Airdata again).
So I decided I don't want to risk to lose the current win-win situation, I don't want to give DJI any reason to change the algorithm.
I don't care of what people will think of me - I'm trying to do what I think is the best for users of my tool.
I will never agree to publish the algorithm.
Anybody smart enough has to agree with me. BudWalker, the guy who invented decoding algorithm for my tool, supports me with this too.
End of story.
You just don't get it. The reason nobody wants to help you "make your tool better" is because you insist on keeping your tool (and its algorithm) to yourself.
But anyway - your loss. The Internet will 'route around' you, rendering you irrelevant.
my loss? sorry, I can see no loss for me in this
yes, once in the future, internet will find the way
but for 18 months it hasn't, so we are the ones who decide the conditions
Looks like now we have Software Justice Warriors to add to the pack...
I hope you will go write the same thing to owners of all the online converters, especially paid ones. Otherwise you're picking the person who is the most open and provides the most information about the log format.
If a good programmer is really interested in the source, he will reverse-engineer the tool with no problem. A basic one who can't do this, is unlikely to be of any help anyway.
(I get triggered by demanding attitude towards people who provide their work for free; sorry)
Really? What is the URL of the web page that describes the log format?
This is the one thing that would be most useful to people. If no such page currently exists, then I guess I'll have to write one myself. Stay tuned...
Oh. Ok, I did not expected that.
Here is a Wireshark dissector which can read the DAT logs within the drone, and DUML packets from internal communication between modules within the drone:
o-gs/dji-firmware-tools
The dissector is provided as a series of LUA scripts, which are relatively easy to understand.
It is likely that the TXT format will contain packets similar to the DUML format (or just plain dumps of the DUML packets).
sorry, I made a mistake there
the correct version of the citation in my post should be "hey, I want to help other people too..."
because the tool is for other users, not for me
the version sufficient for me was completed 2 years ago, I personally need nothing of these new fields
it's funny, I had the same thing on my mind
and don't forget about DJI!!!
there was Excel document attached that described it in detailed way
but I removed it
read Notice 2 in the first post of this thread
anyway, the discussion moved far away from the topic and I won't be wasting any more time with explaining or arguing, because in the end it's useless, it brings nothing good
new version is out
last version maybe fixed some Mavics' cell voltages, but it also broke some others'
this time I did it (finding the offset of voltages) by another method, it should be working fine for all logs
if not, don't hesitate to let me know!
last version maybe fixed some Mavics' cell voltages, but it also broke some others'
this time I did it (finding the offset of voltages) by another method, it should be working fine for all logs
if not, don't hesitate to let me know!
Similar threads
