GUI Version of DatConverter

[Mateintwo]

I send you a small part of it ... since the whole one is more than 30 mb.

Is it ok for you ? I'm quite sure there are some problems with the convertion of lat and long.

the green "Dashware Compatible" is there before convertion and everything goes fine ...

thanks for helping

Luca

 

[BudWalker]

I send you a small part of it ... since the whole one is more than 30 mb.

Is it ok for you ? I'm quite sure there are some problems with the convertion of lat and long.

the green "Dashware Compatible" is there before convertion and everything goes fine ...

thanks for helping

Luca

Did you avail yourself of @Luap s offer to help? He knows far more than I do about Dashware.

You can also try using an earlier version of DatCon. Go here, download and install version 2.3.0,

 

[Mateintwo]

Did you avail yourself of @Luap s offer to help? He knows far more than I do about Dashware.

You can also try using an earlier version of DatCon. Go here, download and install version 2.3.0,

Sure I sent him a part of the .csv file as well as a couple pf screenshots of what is displayed on Dashware.

I will wait for a feedback.

thanks

 

[BudWalker]

Sure I sent him a part of the .csv file as well as a couple pf screenshots of what is displayed on Dashware.

I will wait for a feedback.

thanks

I'd like to know if your issue is resolved using DatCon 2.3.0. Would it be possible for you to install 2.3.0 and try it? Go here, download and install version 2.3.0,

 

[Mateintwo]

I will do it tomorrow morning with pleasure, I hope to have a feedback before from Luap in the meantime. I'm from Italy , can't do it this evening.


Sent from my iPhone using PhantomPilots

 

[Luap]

I will do it tomorrow morning with pleasure, I hope to have a feedback before from Luap in the meantime. I'm from Italy , can't do it this evening.


Sent from my iPhone using PhantomPilots

I had a look at the csv.
Here is the flight path Dashware plots.

Is that the path you were expecting?

In any case the reason Dashware draws a straight line with your csv is because the longitude and latitude have no GPS values in the first 382 rows.
Dashware can only plot a flight path when first rows have GPS values.
So delete the rows that do not have any values and it should work.

You must be doing something wrong in the DatConverter. It should be green and say Dashware compatible when you convert and the GPS values will be none zero/blank.

If it is green and you have zero GPS values it might be a bug in the DatCon version you are using.
Let us know if any of this helps.

 

[BudWalker]

@Luap, @Mateintwo, @DRoss
That explains the problem. I knew that Dashware can't tolerate 0 for Latitude and/or Longitude. But, I had mistakenly thought that Dashware would handle a blank for Latitude and/or Longitude.

Dashware users can safely use DatCon 2.3.0 - the new fields that 2.3.2 has aren't in the Dashware profile.

 

[flyNfrank]

@Luap, @Mateintwo, @DRoss
That explains the problem. I knew that Dashware can't tolerate 0 for Latitude and/or Longitude. But, I had mistakenly thought that Dashware would handle a blank for Latitude and/or Longitude.

Dashware users can safely use DatCon 2.3.0 - the new fields that 2.3.2 has aren't in the Dashware profile.

So 2.3.0 is currently more compatible with Dashware, in that it is able to recognize blanks? Or is there different reason the Dashware users should use 2.3.0?

And then also, the current Dashware Profile has not been updated with the new field data gained in DatCon 2.3.2?

 

[BudWalker]

So 2.3.0 is currently more compatible with Dashware, in that it is able to recognize blanks? Or is there different reason the Dashware users should use 2.3.0?

And then also, the current Dashware Profile has not been updated with the new field data gained in DatCon 2.3.2?

Yes, that's correct. Version 2.3.2 produces a .csv that can make the present Dashware profile (found here) not work correctly.

When the P3 is powered up it starts writing data into the .DAT file. Typically, IMU data starts being reported after about 2 seconds. GPS data comes later or not at all if the P3 can't acquire enough satellites. Up until DatCon 2.3.0 the default was start to producing the .csv only after the GPS data became valid. Starting with DatCon 2.3.2 the default was to start producing the .csv earlier and write blanks for GPS data until that data became valid. This change was made to accommodate CsView since it knows that blanks mean that data is invalid. Since Dashware can accept blanks for invalid data in some cases, such as vpsHeight, I assumed that the same held true for GPS data. Apparently not.

I'm unaware of any efforts to update the Dashware profile to include the new fields found in 2.3.2

 

[flyNfrank]

Yes, that's correct. Version 2.3.2 produces a .csv that can make the present Dashware profile (found here) not work correctly.

When the P3 is powered up it starts writing data into the .DAT file. Typically, IMU data starts being reported after about 2 seconds. GPS data comes later or not at all if the P3 can't acquire enough satellites. Up until DatCon 2.3.0 the default was start to producing the .csv only after the GPS data became valid. Starting with DatCon 2.3.2 the default was to start producing the .csv earlier and write blanks for GPS data until that data became valid. This change was made to accommodate CsView since it knows that blanks mean that data is invalid. Since Dashware can accept blanks for invalid data in some cases, such as vpsHeight, I assumed that the same held true for GPS data. Apparently not.

I'm unaware of any efforts to update the Dashware profile to include the new fields found in 2.3.2

Very good. So based on what you know now, which direction do you think you'll go with the next version after 2.3.2?

 

[Mateintwo]

So it works now on my side !

What I did was to install DatCon 2.3.0 and use the same settings about Time Axis that Luap Showed me in the image above.
I don't remember exactly which settings I used but I'm sure they were not the same .
I think on wednesday I choose " Flight Start " as first choice and then " Motor Start" and " Motor Stop in the other ones.

I have to work now and can't test differences in my convertion trying different choices but I will do it later.

The sure thing is that now the correct path is shown, as in the attached image .

thanks for helping and compliments for this outstanding job!

Luca

 

[BudWalker]

So it works now on my side !

What I did was to install DatCon 2.3.0 and use the same settings about Time Axis that Luap Showed me in the image above.
I don't remember exactly which settings I used but I'm sure they were not the same .
I think on wednesday I choose " Flight Start " as first choice and then " Motor Start" and " Motor Stop in the other ones.

I have to work now and can't test differences in my convertion trying different choices but I will do it later.

The sure thing is that now the correct path is shown, as in the attached image .

thanks for helping and compliments for this outstanding job!

Luca
View attachment 66066

By default, DatCon 2.3.0 will set the right values in the Time Axis Panel. If the Dashware panel has the green "Dashware Compatible" then the .csv that is produced should display the AC path correctly.

 

[flyNfrank]

Bud I was in the middle of working with a few files and I just noticed there was no Time Stamp in any Dat file. Is that something that can be added somewhere? I trying to compare a TXT and DAT of the same file, but I was unsure if the two were of the same flight or not. Turns out they were not.

When I said Time Stamp, I basically just meant date displaying a column like the txt files.

 

[lazaruz]

First of all, let me join everyone else and thanking you for the awesome work you are doing with this tool!

I've been playing around with a few .DAT-files and it works great but could someone please explain the columns "Tick#" and "offsetTime"? I have tried reading about them in the manual but I don't seem to get it
My second question is this... I have two .DAT-files, both created 2nd of October at 17:48. Are these files from the same flight and should the data from them be joined to make a complete flight?

 

[BudWalker]

First of all, let me join everyone else and thanking you for the awesome work you are doing with this tool!

I've been playing around with a few .DAT-files and it works great but could someone please explain the columns "Tick#" and "offsetTime"? I have tried reading about them in the manual but I don't seem to get it
My second question is this... I have two .DAT-files, both created 2nd of October at 17:48. Are these files from the same flight and should the data from them be joined to make a complete flight?

When it can, DatCon will produce a .csv that is 1) compatible with Dashware and 2) is consistent with the .csv derived from the DJI Go App .txt file. It can't always do this and that's why the time scale stuff is complicated. Usually, it's not necessary to understand this stuff - just use the offsetTime scale. @Luap and I assumed that if a user were doing something that required understanding the time scale stuff then they would already be expert enough to understand it.

I reviewed the manual - pages 0.5 to 2.0 (it's been a long time since I wrote it). If you had some questions that would help me understand what needs further explanation.

Depending on what you're doing you might want to try using CsvView instead. It fixes all that complexity by not allowing you to make choices . CsvView is kinda like using the Excel plot package, only a lot easier. It's also kinda like using Dashware without the eye candy factor. CsvView can be obtained by going here.

There are a couple of reasons that .DAT files can have the same date/time stamp. Take a look at the bottom half of this page. If they come from the same flight there is an app called DatMerge that will merge them into one .DAT. I haven't released DatMerge to the general public because I haven't gotten around to implementing a GUI. I.e., it has to be run from a shell (command line interpreter). Most users don't know how to do this. PM me if you want a copy of DatMerge

 

[lazaruz]

When it can, DatCon will produce a .csv that is 1) compatible with Dashware and 2) is consistent with the .csv derived from the DJI Go App .txt file. It can't always do this and that's why the time scale stuff is complicated. Usually, it's not necessary to understand this stuff - just use the offsetTime scale. @Luap and I assumed that if a user were doing something that required understanding the time scale stuff then they would already be expert enough to understand it.

I reviewed the manual - pages 0.5 to 2.0 (it's been a long time since I wrote it). If you had some questions that would help me understand what needs further explanation.

Depending on what you're doing you might want to try using CsvView instead. It fixes all that complexity by not allowing you to make choices . CsvView is kinda like using the Excel plot package, only a lot easier. It's also kinda like using Dashware without the eye candy factor. CsvView can be obtained by going here.

There are a couple of reasons that .DAT files can have the same date/time stamp. Take a look at the bottom half of this page. If they come from the same flight there is an app called DatMerge that will merge them into one .DAT. I haven't released DatMerge to the general public because I haven't gotten around to implementing a GUI. I.e., it has to be run from a shell (command line interpreter). Most users don't know how to do this. PM me if you want a copy of DatMerge

Thank you, that clears it up, I've sent you a PM

 

[schach]

Hi, I've got the following suggestions regarding DatCon:

1)
I downloaded the latest version (v2.4.2). Problem is, that this versions needs 64bit-Java which isn't running on my 32bit-Win 7 like v2.3.2 did. Please make DatCon still running on 32-bit systems too.

2)
Looking at the 3 assosiated elevation values: baroAlt(meters), relativeHeight, homePointAltitude (baroAlt= homePointAltitude + relativeHeight)
I noticed that there's a constant error of exactly 20m between these 3 values. Either baroAlt is too low by 20m or homePointAltitude is too high by 20m, cause relativeHeight-value is correct

For example:
baroAlt=540
relativeHeight=60
homePointAltitude=500

This 20m problem stays the same with each different .DAT file.

3)
baroAlt(meters) and homePointAltitude both are VERY, VERY unaccurate. It's exactly the same problem as here:
[TOOL][WIN] Offline TXT FlightRecord to CSV Converter
It would be great if you could implement the same solution like @ferraript did with TXTlogToCSVtool.exe to get much better values for these 2 elevations:

" added new field 'start Altitude' (=homePointAltitude) in advMode and new column 'OSD.altitude', so if you know the altitude of start point, fill it and you'll get real altitude in csv ... in meters only"

And actual baroAlt(meters) could be easily calculated by homePointAltitude+relativeHeight

 

[BudWalker]

Hi, I've got the following suggestions regarding DatCon:

1)
I downloaded the latest version (v2.4.2). Problem is, that this versions needs 64bit-Java which isn't running on my 32bit-Win 7 like v2.3.2 did. Please make DatCon still running on 32-bit systems too.

2)
Looking at the 3 assosiated elevation values: baroAlt(meters), relativeHeight, homePointAltitude (baroAlt= homePointAltitude + relativeHeight)
I noticed that there's a constant error of exactly 20m between these 3 values. Either baroAlt is too low by 20m or homePointAltitude is too high by 20m, cause relativeHeight-value is correct

For example:
baroAlt=540
relativeHeight=60
homePointAltitude=500

This 20m problem stays the same with each different .DAT file.

3)
baroAlt(meters) and homePointAltitude both are VERY, VERY unaccurate. It's exactly the same problem as here:
[TOOL][WIN] Offline TXT FlightRecord to CSV Converter
It would be great if you could implement the same solution like @ferraript did with TXTlogToCSVtool.exe to get much better values for these 2 elevations:

" added new field 'start Altitude' (=homePointAltitude) in advMode and new column 'OSD.altitude', so if you know the altitude of start point, fill it and you'll get real altitude in csv ... in meters only"

And actual baroAlt(meters) could be easily calculated by homePointAltitude+relativeHeight

!) DatCon was changed to require a 64bit-Java because of the larger .DAT files that get produced by the Mavic and P4. Although DatCon and CsvView could be changed to run in a 32 bit space I don't plan to do this. It's a major change and, so far, you're the only request I've had to make this available.

2) The values for baroAlt(meters), relativeHeight, homePointAltitude aren't computed by DatCon they come from the .DAT. homePointAltitude is set at launch by the AC to be the baroAlt + 20 meters. I think the 20 meter offset is because the barometric pressure may change during the course of a flight. relativeHeight is set to 0 at launch and is thereafter computed from baro(Alt).

3) Something like this done the KML panel. I.e., if you know the altitude then it can be specified so that Google Earth will show an actual profile.

 

[ferraript]

you're the only request I've had to make this available

I'm Win XP x86 user
but I use DatCon 2.3.0 and so I don't really care about x64 requirement in the newer versions of DatCon

Something like this done the KML panel. I.e., if you know the altitude then it can be specified so that Google Earth will show an actual profile

this popped into my head few days ago
you collect this altitude (if user provides it), but you use it in KML only
maybe you could use it in CSV too
but also, I personally don't need it, maybe other users would be happy about it

 

[schach]

2) The values for baroAlt(meters), relativeHeight, homePointAltitude aren't computed by DatCon they come from the .DAT. homePointAltitude is set at launch by the AC to be the baroAlt + 20 meters. I think the 20 meter offset is because the barometric pressure may change during the course of a flight. relativeHeight is set to 0 at launch and is thereafter computed from baro(Alt).

3) Something like this done the KML panel. I.e., if you know the altitude then it can be specified so that Google Earth will show an actual profile.

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 .CSV-files into DashWare or other software.