[TOOL][WIN] Offline TXT FlightRecord to CSV Converter

Hi, thanks ferraritpt, no problem I understand and I will use msinger's tool for these files. I don't know why they are different... thanks again for your tool !
 
That's just crudely estimated from the number of telemetry points transmitted by the aircraft that are not received by the RC.

I'm curious which recorded categories found in a converted .txt to .csv file are being used for the crudely estimated telemetry points?
 
I'm curious which recorded categories found in a converted .txt to .csv file are being used for the crudely estimated telemetry points?

I don't think it matters. They are all transmitted ten times per second, and either all or none seem to make it in each set - I've never seen a log file where just some of the data in a row are recorded.
 
They are all transmitted ten times per second, and either all or none seem to make it in each set - I've never seen a log file where just some of the data in a row are recorded.
well, that's not entirely true :)
just like in the DAT logs (you can see it in column description), in TXT logs it's the same: various categories have various update rates
for example CUSTOM, OSD are updated 10 times per second, battery information only once per second

I write new CSV row with each OSD on the input

"I've never seen a log file where just some of the data in a row are recorded"
that's because all non-updated columns retain their values until next update (with some exceptions of course)
BudWalker does the same thing when processing DAT logs
 
  • Like
Reactions: msinger
well, that's not entirely true :)
just like in the DAT logs (you can see it in column description), in TXT logs it's the same: various categories have various update rates
for example CUSTOM, OSD are updated 10 times per second, battery information only once per second

I write new CSV row with each OSD on the input

"I've never seen a log file where just some of the data in a row are recorded"
that's because all non-updated columns retain their values until next update (with some exceptions of course)
BudWalker does the same thing when processing DAT logs


OK - thanks for the clarification. So do the updates to the various fields show up as completely independent data packets, or are they grouped together somehow? I've never attempted to delve into the data structure of the txt or DAT files.
 
OK - thanks for the clarification. So do the updates to the various fields show up as completely independent data packets, or are they grouped together somehow? I've never attempted to delve into the data structure of the txt or DAT files.
For both the .txt and the .DAT the fields are grouped into record types. Each record type has it's own update frequency. Both converters write a new row in the .csv at a fixed interval. The value for each field written to the .csv is the current value; i.e., it doesn't depend on any of the values since the last update.

With TXTlogToCSVtool this isn't an issue because the interval is fixed at 0.1 secs which is the highest sampling rate.

But, with DatCon the sampling rate can be adjusted. It's defaulted to 30 Hz which is slower than the sampling rate of some record types. This was done to keep the size of the .csv files from getting too large. This could be a problem since some data, e.g. gyro data, can be different from the value when it's written to the .csv. Increasing the sample rate will overcome this but also make for sometimes humongous (possibly gynormous) .csv file sizes.
 
For both the .txt and the .DAT the fields are grouped into record types. Each record type has it's own update frequency. Both converters write a new row in the .csv at a fixed interval. The value for each field written to the .csv is the current value; i.e., it doesn't depend on any of the values since the last update.

With TXTlogToCSVtool this isn't an issue because the interval is fixed at 0.1 secs which is the highest sampling rate.

But, with DatCon the sampling rate can be adjusted. It's defaulted to 30 Hz which is slower than the sampling rate of some record types. This was done to keep the size of the .csv files from getting too large. This could be a problem since some data, e.g. gyro data, can be different from the value when it's written to the .csv. Increasing the sample rate will overcome this but also make for sometimes humongous (possibly gynormous) .csv file sizes.

Right - that makes sense. In the context of the original question, I was really referring to how the data are transmitted from the aircraft, but that's probably lost once written to the log files. In particular, if the downlink becomes marginal we see entire rows missing from the files, but if the data are being transmitted at different rates from the aircraft then one might expect to see rows with only partial data.
 
Right - that makes sense. In the context of the original question, I was really referring to how the data are transmitted from the aircraft, but that's probably lost once written to the log files. In particular, if the downlink becomes marginal we see entire rows missing from the files, but if the data are being transmitted at different rates from the aircraft then one might expect to see rows with only partial data.
I expect that the tablet .DAT is being written as packets arrive from the AC; i.e., "data is being transmitted at different rates". So, the higher frequency record types arrive more often than the lower frequency ones. But, that detail is lost when the .csv is created. DatCon, and I think TXTlogToCSVtool, writes an entire row that contains all the latest values.
 
  • Like
Reactions: sar104
DatCon, and I think TXTlogToCSVtool, writes an entire row that contains all the latest values
Right on -- the TXTlogToCSVtool and my log viewer do this too.
 
I'm curious which recorded categories found in a converted .txt to .csv file are being used for the crudely estimated telemetry points?

The reason for my question in the above quote is I was attempting to create a new data gauge in DashWare. As most know, DashWare uses the flight data converted to a .csv file in Excel. There use to be logged Signal data in flight logs, and now neither .TXT or .DAT produce such data. However, the AirData website tool manages scaled Minor Signal Error data which appears from uploading either .TXT or .DAT flight log.

Basically, this all came about while testing comparisons of a recent NLD Signal Boost mod.
 
Stumbled across this tool, but is there a way of bulk converting log files into a multiple flight log that would be suitable for CAA etc? So just long/lat, flight time etc from multiple .txts in one CSV?
 
Hi,

Someone noticed too that the DJI mavic mini flightrecord.txt files are not decrypted in a good order using Ferraript txt to csv converter?
Seen few files now and in the camera sn field illegal chararters are used or wrongly decryped, so reading csv will give errors or not all records are in the csv file.

cheers
JJB
 
Seen few files now and in the camera sn field illegal chararters are used or wrongly decryped, so reading csv will give errors or not all records are in the csv file.
Can you attach one of your TXT files here so we can try it?
 
Can you attach one of your TXT files here so we can try it?
I was sent few files by early testers, and they asked me not to publish their files.
I do not have a mini myself so...

Flightrecords converted on phantomhelp are different converted than my use of txt to csv tool, wich is weird ofcourse. The verbose cvs is different too. (using an update version of ferraript txt to csv converter?)
Uploaded txt files to phantomhelp shows for instance 4 cells batt values....
I use the csv file as a source for my own program, all other converted files are read without errors, but mini files will not be txt file read (stops at the first line) or after few lines when it sees an illegal character??


cheers
JJB
 
Last edited:
Uploaded txt files to phantomhelp shows for instance 4 cells batt values....
That makes sense. I haven't made any changes to handle the Mavic Mini logs yet.
 
Sorry if its;'s been asked before but with 32 pages of posts I haven't been right through them all, is there a MAC version for this amazing looking tool please??
 

Members online

Forum statistics

Threads
143,066
Messages
1,467,358
Members
104,936
Latest member
hirehackers