Does anyone have a reference for understanding the Telemetry files- what each fields represents (a 'data model' of sorts) and how to interpret the data?
Telemetry data- fields and interpretation
- Thread starter av8orct
- Start date
Yes. The easiest way is to use a program developed by one of our members @h-elsner called Q500log2kml. You can find the file in the download section at Private Homepage h-elsner. It is a self supporting program (no runtimes are needed) and you have to give Windows permission to run it the first time. A pdf user manual is bundled with it.
This program is tried and true for reading legacy Yuneec log files.
This program is tried and true for reading legacy Yuneec log files.
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,640
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
And the PDF Manual has a chapter with explanation of all columns. See 3.4.1 and 3.5.1.
br HE
br HE
Your program makes reading the data much easier than using a spreadsheet like Excel. Sure wish Yuneec would release their interpretation of MavLink so we could get a better understanding of the ulog and tlog files for H520, H+, H3, and H520E.
Thanks to you both, this is very helpful
@h-elsner— the data definitions are extremely valuable in understanding these files. Thanks for taking the time to create and share!
I’m curious-how is flight time determined? Is it from the start to end of the file time? Or is there another parameter considered (GPS lock, TAS, etc)?
Is there a way, from the log files to determine what’s a ‘landing/takeoff’?
@h-elsner— the data definitions are extremely valuable in understanding these files. Thanks for taking the time to create and share!
I’m curious-how is flight time determined? Is it from the start to end of the file time? Or is there another parameter considered (GPS lock, TAS, etc)?
Is there a way, from the log files to determine what’s a ‘landing/takeoff’?
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,640
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
The flight time in the Overwiew page depends on flight mode. As there is no take-off/landing indication (as for example PX4 Autopilot has) in the data I decided to use a set flight mode that belonging to flights. For Yuneec legacy those are: 0..7, 9..14, 18, 20..24, 26..29, 31..33 (Q500 has not all of them). I take change from 16 to one of the set above as start time and back to 16 as landing time. That is not exact and problematic in case of landings inbetween but a good aproximation.
br HE
br HE
You've done a remarkable job with the data file. I've tried to sift through it and make some sense.... it's all about inferring! Your data definition file is like the the Dead Sea Scrolls...
One final question- do you happen to know if the date/time stamp comes from the ST10 or is it pushed from the GPS signal?
One final question- do you happen to know if the date/time stamp comes from the ST10 or is it pushed from the GPS signal?
Once the ST10 gets a good fix from its GPS chip the time used is from the satellites. This can cause issues if you are on Daylight Savings Time as the recorded time will be an hour slow in most cases.
This is the case with all STxx controllers.
This is the case with all STxx controllers.
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,640
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
... and nearly as old. With this program I started in 2015 and let it grow. 7 years is eons in the drone business.
It's amazing how these projects take on a life of their own and continue to morph.
Can you tell me how you calculated the 'Distance'? I'm assuming you take the initial Lat/Long and calculate the distance from that point to each subsequent Lat/Long. The largest number becomes the 'Distance'?
are there other parameters you're looking at to decide if a particular lat/long is excluded?
I've been dabbling a bit with the data and trying to understand it better. With my formula (found on the 'net), I'm getting about 2 additional meters for each flight. I'm thinking I'm including too many rows.
Can you tell me how you calculated the 'Distance'? I'm assuming you take the initial Lat/Long and calculate the distance from that point to each subsequent Lat/Long. The largest number becomes the 'Distance'?
are there other parameters you're looking at to decide if a particular lat/long is excluded?
I've been dabbling a bit with the data and trying to understand it better. With my formula (found on the 'net), I'm getting about 2 additional meters for each flight. I'm thinking I'm including too many rows.
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,640
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
Distance is the maximum of current distance to start point. As start point I use the very first coordinate from a data set where the flight mode is one of the set of "flying" flight modes.
The distance is calculated by Haversine formula. The formula contains the earth radius but this depends on latitude and altitude msl. To make it easy I used a fix value optimized for lat=50° and alt=60m. That will result 6365.692m.
Additionally there are different ellipsoid models for our earth, but if you want get all this into calculation then it will get very complex and this will take a lot of time during calculation.
Same formula is used to calculate the length of the flight track. It is the sum of differences between the coordinates of every data set. Of course, the sum of all rounding errors is also included there. Hopefully up and down will level that, hopefully!
br HE
The distance is calculated by Haversine formula. The formula contains the earth radius but this depends on latitude and altitude msl. To make it easy I used a fix value optimized for lat=50° and alt=60m. That will result 6365.692m.
Earth Radius by Latitude Calculator
Calculates radius and diameter of the Earth for a given latitude.
rechneronline.de
Same formula is used to calculate the length of the flight track. It is the sum of differences between the coordinates of every data set. Of course, the sum of all rounding errors is also included there. Hopefully up and down will level that, hopefully!
br HE
Today I discovered something about the Q500log2kml program that some might find useful. I apologize if you have already documented this or there is already a post about it. I could not find any.
I am using the program to explore the data from an H+ and use the output of the Flight Record to log my flights and track battery usage/life. Occasionally, the vehicle type will be shown as "invalid data" and in some of these cases the Batt remain would be 5.0 V =~0%. Looking at the associated Telemetry file, I noticed a pattern where these flights had at least one row of data at the beginning of the file with the battery voltage other than the actual voltage. Several other values on these rows have values that are not reasonable, including the vehicle type. Likely the file is starting to log before valid data is present so some default value is logged. I edited the associated telemetry files to remove all rows until a valid battery voltage was present, figuring that the loss of a few samples of data with invalid values would be okay (I did maintain a backup first). The other parameters also have valid values at this point.
I restarted the program and had it reload the directory of log files again. When I produced a new flight record with the edited telemetry files, the Vehicle Type is now correct. Interestingly, this also seems to resolve the Batt remain value as well, even though the final row of the file has a reasonable battery voltage logged and was not edited.
Thanks for putting together such a great tool for keeping tabs and troubleshooting our drones. I am just getting started with the H+ and am thrilled to be able to keep track of its performance from day one.
I am using the program to explore the data from an H+ and use the output of the Flight Record to log my flights and track battery usage/life. Occasionally, the vehicle type will be shown as "invalid data" and in some of these cases the Batt remain would be 5.0 V =~0%. Looking at the associated Telemetry file, I noticed a pattern where these flights had at least one row of data at the beginning of the file with the battery voltage other than the actual voltage. Several other values on these rows have values that are not reasonable, including the vehicle type. Likely the file is starting to log before valid data is present so some default value is logged. I edited the associated telemetry files to remove all rows until a valid battery voltage was present, figuring that the loss of a few samples of data with invalid values would be okay (I did maintain a backup first). The other parameters also have valid values at this point.
I restarted the program and had it reload the directory of log files again. When I produced a new flight record with the edited telemetry files, the Vehicle Type is now correct. Interestingly, this also seems to resolve the Batt remain value as well, even though the final row of the file has a reasonable battery voltage logged and was not edited.
Thanks for putting together such a great tool for keeping tabs and troubleshooting our drones. I am just getting started with the H+ and am thrilled to be able to keep track of its performance from day one.
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,640
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
There is an option in Settings > Other Settings > Purge H Plus. This removes from analysis most of the strange datasets that H Plus flight controller sends.
br HE
br HE
Thanks! I see that I have it on, so I will try toggling it off as well to see what changes in the results. I will also go back and study the manual some more to see what nuances I have missed!
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,640
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
To be more clear, the useless datasets (mostly filled by default/initial values) will be still visible in the table. It is never a good idea for analysis tools to hide things that be or may be not important for diagnosis. But those data will be excluded for charts, lists and so on.
It should be not necessary to edit CSV files before. If yes, let me know what exactly kills your analysis, charts or whatever in order I could improve filters for Typhoon H Plus.
br HE
It should be not necessary to edit CSV files before. If yes, let me know what exactly kills your analysis, charts or whatever in order I could improve filters for Typhoon H Plus.
br HE
Thanks for the feedback. I agree that the analyst should have full choice in what they choose to identify as an outlier and not have the analysis tool decide. Your program is excellent at deciphering the data from the H+ and giving me a great visualization tool. Purely for fun, I really enjoy the .KML export.
Thanks again for an excellent tool.
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,640
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
Following your hint I found a missing condition for a special combination of initial data which commonly exits at the beginning of a telemetry file. I solved this bug and uploaded today the corrected version. I hope filtering for H Plus is better now.
br HE
Nice! I grabbed the updated executable and will give it a try after I get some more flights. I've only had the H+ for a little over a month and I'm trying to get out to fly any chance I can.
