I'll try to do this for the next release.I understand! But because of the fact that these 2 altitudes are more ore less unaccurate (up to >100 meters) and now additionaly the 20m offset these values are useless right now for people who are interested in elevation above sea-level of their drones:
Wouldn't it be possible to additionaly provide a field in the dialog where the user could enter the accurate elevation of the Home Point like TXTlogToCSVtool.exe did in its recent versions? You could then write these elevations into 2 new data variables, so the original unaccaruate elevations of the .DAT could still be used.
I don't wanna use the conversion for KML files but for example for import into DashWare or other software.
GUI Version of DatConverter
- Thread starter BudWalker
- Start date
Does somebody has an idea what these 2 values Gimbal: Pitch and Gimbal: Xpitch are used for? I want to get the the pitch of the camera (= angle downwards the earth). But these 2 created with DatCon values are just between 0-5 degrees and continously changing although the camera of my drone had a constant pitch angle of about 20-30 degrees.
Documentation on the .csv columns can be found here for the P3/Inspire platform. And here for the Mavic/P4 platform. I'm a little behind on the documentation but the info about the gimbal data is there. The gimbal data has proven to be difficult and has never really been useful. All I know is that it's related in some way to the gimbal orientation. I left it in the .csv in the hope that I or someone else could figure out what to do with it. Maybe it's time to remove it.
There is a new version of CsvView. Version 1.0.3 can be obtained by going here to download it. This version fixes the bug that would occur when using V.1.0.8 of the DJI Assistant 2. There are other bug fixes as well as some new features.
Also available is the Mac version at the bottom of the list of downloads. I've not tried it since I don't have a Mac. After unzipping the download file use the RIGHT mouse button on CsvView.1.0.3.jar. Please lemme know how it works if you try this
Also available is the Mac version at the bottom of the list of downloads. I've not tried it since I don't have a Mac. After unzipping the download file use the RIGHT mouse button on CsvView.1.0.3.jar. Please lemme know how it works if you try this
A bug has been discovered in the latest DatCon (version 2.4.2). This bug appears when version 2.4.2 is the first DatCon to be installed. I.e., if a previous version of DatCon has been installed and ran there shouldn't be a problem.
If DatCon 2.4.2. is the first to be installed then it will crash the first, second, and third time it is run. The 4th run and thereafter should be fine.
If DatCon 2.4.2. is the first to be installed then it will crash the first, second, and third time it is run. The 4th run and thereafter should be fine.
Yes indeed, thanks to you ALL for your hard work and efforts with this!!!
I actually had SOME success using DatCon with my .dat files, but I could not find the appropriate details on how to use the current "Dashware Templates" they have for download, and I am looking for the more mundane data in the Gauge Sets, not really the battery amperage and motor revs, cell amperage, etc. For some reason (am I doing something incorrectly?) I had to delete a "Background" of some sort that was covering the video import and delete more than half the gauges on the templates JUST to get a simple video with a few overlay Gauges that I couldn't choose, only to keep the ones that were existing; I tried to even choose some gauges but the telemetry data apparently wasn't included or the appropriate field was not checked off in the "Analysis By Time" area. Can ANYONE advise me on how to put together a comprehensive way to use these dashware templates WITH VIDEO and not just the overhead flight records?
Again, thanks for dissecting this table and conversion process; even as it stands it sure beats using AZ Screen Copy to get some flight telemetry on the videos!
I anxiously await somebody telling me it's simple, and you "Missed this step" or something of the sort!
Regards Gentlemen,
A.J. Lebeau
Computer Network Systems Administrator/Engineer, (Ret.)
M.C.S.E., M.C.P. + I., M.C.P., CompTIA+
[email protected]
Hello BudWalker!
I'm using DatCon to convert data of a Phantom 3 for the use within DashWare. There's one thing which could be improved, especially for DashWare:
Date and Time of the flight right now are exported in 2 fields: "GPS: Date", "GPS:Time" (UTC-time, not the local time). Since these are plain Integer-values (for example: "20171031" and "182455"), Dashware isn't able to convert it into proper date/time info, the date/time Gauges are writing "1/1/1970" and "01:02:34 AM".
So please provide them ISO 8601 formated like "2017-10-31" and "18:24:55Z" or additionally within one field "2017-10-31T18:24:55Z" which are evaluted correctly within DashWare.
I'm using DatCon to convert data of a Phantom 3 for the use within DashWare. There's one thing which could be improved, especially for DashWare:
Date and Time of the flight right now are exported in 2 fields: "GPS: Date", "GPS:Time" (UTC-time, not the local time). Since these are plain Integer-values (for example: "20171031" and "182455"), Dashware isn't able to convert it into proper date/time info, the date/time Gauges are writing "1/1/1970" and "01:02:34 AM".
So please provide them ISO 8601 formated like "2017-10-31" and "18:24:55Z" or additionally within one field "2017-10-31T18:24:55Z" which are evaluted correctly within DashWare.
I've been thinking about that. It's actually a significant change since DatCon doesn't presently have a String type Series signal - all the Series signals are of type Number. Lemme think some more about this.
EDIT: The issue I described is relevant to CsvView not DatCon. I think I'll change DatCon to do what you described by adding a new column called GPS:dateTime. And leave CsvView unable to handle that field
Last edited:
Do you know if there's "just" UTC-time within the file or also local-time (or info about time-zone, time-difference to UTC etc...?).
If there's no local-time: Would it be possible to add a field into the GUI (similar to the Elevation-textfield) where the user can input the time difference of his timezone compared to UTC:
e.g.: UTC of source data says "18:09:38". User lives in Germany, summertime, so he enters "+2" in your field. Now DatCon could calculate a new value "localTime" which is "20:09:38".
If there's no local-time: Would it be possible to add a field into the GUI (similar to the Elevation-textfield) where the user can input the time difference of his timezone compared to UTC:
e.g.: UTC of source data says "18:09:38". User lives in Germany, summertime, so he enters "+2" in your field. Now DatCon could calculate a new value "localTime" which is "20:09:38".
Gimbal-Fields
I noticed that the "Gimbal"-fields have been removed during the last updates. Would it be possible to provide them again, at least as "experimental fields"? I used "Gimbal:Yaw" before which worked quite well to exactly determine the direction the CAMERA (=gimbal) is pointing at. This is most of the time identical to the drones' Yaw. But especially when drone starts or stops rotating the Gimbals direction does not line up with the drones' direction cause the gimbal movement is smoothed to prevent jerky video in these situations.
You could provide each potential Gimbal-field, I'll try testing the meaning of these values and you could remove the one's containing useless values afterwards again.
I noticed that the "Gimbal"-fields have been removed during the last updates. Would it be possible to provide them again, at least as "experimental fields"? I used "Gimbal:Yaw" before which worked quite well to exactly determine the direction the CAMERA (=gimbal) is pointing at. This is most of the time identical to the drones' Yaw. But especially when drone starts or stops rotating the Gimbals direction does not line up with the drones' direction cause the gimbal movement is smoothed to prevent jerky video in these situations.
You could provide each potential Gimbal-field, I'll try testing the meaning of these values and you could remove the one's containing useless values afterwards again.
This actually worked? Sure, I'll put them in as experimental fields. I thought I had tried them and they weren't the same as the gimbal values from the .txt.
@Sunflyer there is a DatCon beta version at
DatCon Downloads
that has the GPS dateTime stamp in ISO 8601 format. The ability to enter a TimeZone will have to wait for a future version.
There is also the gimbal fields. The gimbal fields are experimental and will require that experimental fields be turned on. Do this by using a new submenu on the menu bar.
DatCon Downloads
that has the GPS dateTime stamp in ISO 8601 format. The ability to enter a TimeZone will have to wait for a future version.
There is also the gimbal fields. The gimbal fields are experimental and will require that experimental fields be turned on. Do this by using a new submenu on the menu bar.
@BudWalker I tested most of the DATCON fields using a .DAT-file of Phantom 3 Standard and noted the following things:
- "Gimbal:Yaw": seems to be based on the same source as "Yaw", but is somehow smoothed, so a gauge's needle isn't jittering - which is good, so please keep it!
- "Gimbal:Roll", "Gimbal Pitch": i couldn't find out their meanings. Both are having about the same behaviour as "Roll" and "Pitch", but by far not identical. And "Gimbal Pitch" is definately not the pitch the Gimbal and camera are pointing at. For example if the camera points vertical down to the Earth "Gimbal Pitch" by far does not say 90° - instead it's somehow based on the Pitch of the drone. Is it possible that there's another field with the correct camera's pitch within the .DAT-file which you weren't able to decode yet?
- Do you know what "GPS:Long", "GPS:Lat" are used for, what's the difference to "Latitude", "Longitude". I observed that the "GPS:" values are nearly identical to "Latitude", "Longitude". but the "GPS:"-values are starting much later to be recorded in the DAT-file.
- "GPS:dateTimeStamp" is UTC-time. People usually want to display local time, but for example it's impossible to adjust this within DashWare (Dashware is auto converting UTC-time to the timezone of the computer. But if this is recognized wrong, we have no possibility to change it within DashWare or other software). So it would be great if you could provide a text field where users can enter time-difference of UTC and the timezone the drone shot the video, for example: +1, -3, +1:30, -02:30
and then create another column and name both "GPS:dateTimeStamp:UTC" (e.g. 2017-09-28T15:05:43Z) and "GPS:dateTimeStamp:local" (e.g. 2017-09-28T18:05:43+03:00)
- the last 3 columheaders are "Attribute|Value", "ConvertDatV1", "2.6.7". The first tells ACType|P3S or geoDeclination|3 (which is the local magnetic Declination), I'm not sure what ConvertDatV1 means. Could you please provide the content of these colums also in different colums and the values be present in each line of the file and not just in the first 4 lines - just as every other info in the colums before even if the info stays constant within each line. Software like DashWare is processing data line by line and if an info is just present in the first few lines, it won't be displayed during the whole playback.
- some tiny improvements in the right section of the GUI:
- please use checkboxes (squares which could be checked) instead of the round radio-buttons. Radio-buttons are just for exclusive features where exactly ONE option could be active and the other ones hence inactive. Checkboxes are for features where multiple can be active the same time, like all feature on the right side of the GUI.
- please put the "Elevation" input field to a seperated place, cause its value doesn't just only influence the KML-files, but also CSV- and Logfiles.
Last edited:
As I said in a previous post I don't know anything more about the gimbal signals that you see. So, if you like I'll keep the Gimbal:Yaw but remove the Pitch and Roll since it's not clear what they are.
GPS:Latitude and GPS:Longitude are 5 Hz signals that come from the GPS module. The Latitude and Longitude signals are 200 Hz signals that are computed estimates using the GPS:coords and probably the inertial and gyro sensors. I'd change the labels to IMU:Latitude and IMU:Longitude but it would probably cause a lot of confusion. IMU:Latitude and IMU:Longitude start being recorded in the .DAT file soon after batteryON but DatCon waits until they have reasonable values before starting to write them into the .csv. Otherwise it's possible that GPS coords that are 100s KM away from the actual flight will appear at the beginning causing any geo player to render unpleasant results. If you want those GPS coords anyway just use the GPS:Latitude and GPS:Longitude.
As I said in a previous post a feature that will allow the user to specify a TimeZone will have to wait for a future version.
The Attribute|Value column is what drives the Static Values Panel in CsvView. Theses attributes and their values occur at different parts of the .DAT and so it's not possible to write them in specific rows in the .csv. Also they are static and aren't associated with a particular time.
"ConvertDatV1", and "2.6.7". are used by CsvView so that it will know where to get the definitions that map column names to signal types.
Hello! Thank you for all your hard work on DatCon. I've followed all the instructions, converted my dat files into CSV using DatCon, added your Phantom profiles to Dashware using your provided instructions, but it only semi-works.
When I use one of your provided gauge templates, there's only a handful that actually work - the altitude graph, the pitch/roll/yaw indicators, and the flight time. That's it. Everything else like speed or battery life just show 0 values, and the GPS map is just a straight diagonal line. But I checked, and the CSV does appear to have all the required data like horizontal speed.
Am I doing something wrong? This is for a Phantom 3 Pro, and all the latest versions of your software/profiles.
When I use one of your provided gauge templates, there's only a handful that actually work - the altitude graph, the pitch/roll/yaw indicators, and the flight time. That's it. Everything else like speed or battery life just show 0 values, and the GPS map is just a straight diagonal line. But I checked, and the CSV does appear to have all the required data like horizontal speed.
Am I doing something wrong? This is for a Phantom 3 Pro, and all the latest versions of your software/profiles.
Sorry about that. Dashware hasn't been supported for quite some time. I personally don't use Dashware or know much about it so I can't help much. The person doing the Dashware development and support is no longer involved in the project.
I'm assuming you managed to get to the page with links to the Dashware tutorials and links to the Dashware profile. On that page is also a link to the DatCon version that you need to use with that Dashware profile. I think that's DatCon 2.3.0. You can download it here
http://www.datfile.net/DatCon/DatCon.2.3.0.zip
Depending on what you're trying to do you might want to try using CsvView
CsvView Introduction
Good luck
Thank you very much for the reply! I'll give that older version a shot. I was wondering why it was so hard to find those Dashware profiles lol, I had to manually crawl the topsite using Google, makes sense if you removed them due to compatibility issues.
Only reason I ended up here is because everyone says this is the best way to get telemetry overlay on your P3 videos.
EDIT: Yep, older version worked great, can't believe I missed that warning on the top of the page. To future googlers - you're also going to have to pre-mux an audio file into the video MP4, using something like FFMPEG, otherwise DashWare will crash trying to render it.
Last edited:
You might also want to try using Dashware on a .csv created from the Go App .txt file. Take a look at this post
[TOOL][WIN] Offline TXT FlightRecord to CSV Converter
Similar threads
