After every flight a file appears on your phone. Extension .txt. You open it — meaningless characters.
That is not a mistake, it is a habit: the file is binary but the extension is left as text so operating systems do not treat it as anything special.
Everything about the pilot’s flight is in that file. And the pilot cannot read it.
Understanding the structure first
One byte in the header decides everything: the version.
[ header ]
0x00 magic bytes
0x0C version ← the field that decides everything
0x10 record section offset
0x18 total record count
[ records ] fixed-length blocks, back to back
type(1) | length(1) | payload(n) | delimiter(1)
Each block carries a type: position/altitude/speed, battery cells, stick input, home point, flight-mode change, warning event. The data is orderly; the problem is that it is not readable.
Version below 13: XOR
In older files the record section is XOR-ed with a fixed key. That is not encryption but obfuscation — the intent is not security, only to stop an ordinary user poking around.
Apply the same key a second time and you get the original back. Encrypting and decrypting are the same operation.
Finding the key is not hard either: certain fields in the record blocks are predictable. XOR known plaintext against ciphertext and the key falls out.
The result: old logs decode entirely offline.
Versions 13 and 14: AES
In newer versions the record sections are properly encrypted and the key is not in the file.
What the file contains is a keychain request: an identifier for each encrypted section. You send those to the manufacturer’s open API and receive the keys for that flight.
You made the flight. The drone is yours. The data is on your phone. But reading it depends on the manufacturer’s server being up and granting you permission. With no internet you cannot open the record of your own flight.
That is not a bug, it is a design choice. And it is the technical answer to “whose data is it?”
What becomes visible once decoded
With the records in a table a flight becomes an object: a route on a map, a time slider, telemetry beneath it. And interesting things appear:
- Where the satellite count dropped — usually behind a building or a ridge. The map shows exactly where.
- Battery cells diverging — if one cell falls faster than the rest, that battery has aged; the percentage indicator never tells you.
- The gap between stick input and actual movement — this is how you measure how hard the wind was pushing.
The third is the most valuable: the difference between the station’s forecast wind and the correction the drone actually spent gives you the real wind at that altitude. Measurement, not prediction. And it directly validates the wind profile model.
What I learned
When decoding a binary format the crucial step is not the first byte but finding the version field. A format is not one thing; it is a family that changes over time.
And this: having data does not make it yours. It is yours if you can read it.