I wanted to analyze some data from a tlog file and figured that Excel would be the most flexible way so I created a little utility to extract the data I was interested in and save it as a comma separated value (CSV) file. Each selected parameter is in a separate column, and Excel can open the csv directly.
Note that it can't open the tlog file directly. You must use the Mission Planner to convert it to txt format. so:
1. From the APM Mission Planner Flight Data page select "Telemetry Logs", then "Tlog > Kml or Graph", then "Convert to Text".
2. Select the tlog file you are interested in, and the Mission Planner will create a txt file in its log folder.
3. Open the txt file in this program and it will parse the file and list the available parameters in the left tree control. Double click on the parameters you are interested in and they will be selected and displayed in the right tree control. If you want to remove a parameter from the selected list, double click it.
4."Save As" and provide an output file name. This will produce the csv file that you can open in Excel and plot as desired. The file will look like this, where each row was produced from one packet in the input file that contained at least one of the selected parameters.
If you want to re-use the list of parameters you can save and re-load them from the "configure" menu. These are simple text files you can edit directly if you like.
I am not familiar with the deloyment process for C# programs, so I have placed the entire project folder here.
Comments
Thank you for making such a good program.
It's an old post, but I'm waiting for an answer and I'll just ask one question.
I succeeded in extracting only the files and data I wanted using the program, but an error occurred in the simple timekeeping part.
For example, in the data log photos that Andrew uploaded, not all of the Time parts (all of the B columns in Excel) are displayed.
Date Time mavlink_gps_raw_int_t.lat mavlink_gps_raw_int_t.lon mavlink_gps_raw_int_t.alt mavlink_vfr_hud_t.airspeed mavlink_vfr_hud_t.groundspeed mavlink_vfr_hud_t.heading
2021-06-27 ?ㅽ썑 349453324 1283339761 19230 0.01 0.00380502 0
2021-06-27 ?ㅽ썑 349453324 1283339761 19230 0.023 0.004059403 0
I uploaded some of the data I extracted.
I really want to know the solution.
Thanks again for making a good program.
hi,
when using the tlog extractor program to extract mission data from Mission Planner the default date and time columns extracted by tlog extractor program are 4 seconds behind the mavlink_system_time_t.time_unix_usec.
why is there a discrepancy in the time?
where does the default time and date data from the tlog extractor come from? what is the source? GPStime? Universal Coordinate time? Time from the internet (which is usually Universal Coordinated time).
thanks in advance.
Jeff Z
oke, thanks for your information andrew.
There may be others, but I found these three time parameters:
1. mavlink_system_time_t.time_boot_ms
2. mavlink_gps_raw_int_t.time_usec
3. mavlink_global_position_int_t.time_boot_ms
I checked one of my own tlog files and the three values looked consistent to me, although the middle one (GPS) is scaled in microseconds, not milliseconds. Note that this one is is valid only once the GPS has a lock, and that while it is scaled in microseconds it comes from a millisecond value that was multiplied by 1000, so the last three digits are always zero.
When I last looked at this a couple of years ago even the value being returned in the GPS field was being generated based on the "millis()" function which gives the number of milliseconds system since the system was booted rather than truly being GPS time. So, at the end of the day, the three time values above have the same source - all are time since the system was booted, with two being scalled in milliseconds and one in microseconds..
thanks andrew,
in mavlink_vfr_hud_t i can get data throttle, and where i can convert time second to milisecond?
i tried this with using data time_boot_ms in mavlink_global_position_int_t. when i compare time in mavlink_global_int_t and mavlink_cfr_hud_t i got different time data between both data.
in data throttle i get 20533 time data, and in time_boots_in i get 4407 time data.
where i can get correct time data to throttle?
thanks advice,
rizki
As long as the VFR_HUD packet is being logged you will find the throttle parameter.
I don't think there is any mechanism for measuring RPM, so no way to log it. The closest you have is the throttle command.
Andrew
hello andrew,
i newbie here, i want to ask a question to you.
i'am wondering how to get data rpm and real throttle in tlog?
thank you advice,
best regards,
Rizki
Check GCS_Mavlink.pde for the data that is being transferred:
The mavlink_gps_raw_int has, amongst other data, the position direct from the GPS.
static void NOINLINE send_gps_raw(mavlink_channel_t chan)
{
uint8_t fix = g_gps->status();
if (fix == GPS::GPS_OK) {
fix = 3;
}
mavlink_msg_gps_raw_int_send(
chan,
g_gps->last_fix_time*(uint64_t)1000,
fix,
g_gps->latitude, // in 1E7 degrees
g_gps->longitude, // in 1E7 degrees
g_gps->altitude * 10, // in mm
g_gps->hdop,
65535,
g_gps->ground_speed, // cm/s
g_gps->ground_course, // 1/100 degrees,
g_gps->num_sats);
}
The mavlink_global_position returns position from "current_loc" instead. That, in turn, comes from the ahrs code. There is a comment there that refers to dead reckoning although at present it just copies the gps data over as long as the gps has a fix. Someone must have an idea for adding dead reckoning at some point in the future. So, as long as the gps has a fix the two sets of data returned are equivalent for latitude/longitude, and return different sets of other parameters,
static void NOINLINE send_location(mavlink_channel_t chan)
{
uint32_t fix_time;
// if we have a GPS fix, take the time as the last fix time. That
// allows us to correctly calculate velocities and extrapolate
// positions.
// If we don't have a GPS fix then we are dead reckoning, and will
// use the current boot time as the fix time.
if (g_gps->status() == GPS::GPS_OK) {
fix_time = g_gps->last_fix_time;
} else {
fix_time = millis();
}
mavlink_msg_global_position_int_send(
chan,
fix_time,
current_loc.lat, // in 1E7 degrees
current_loc.lng, // in 1E7 degrees
g_gps->altitude * 10, // millimeters above sea level
(current_loc.alt-home.alt) * 10, // millimeters above ground
g_gps->velocity_north() * 100, // X speed cm/s (+ve North)
g_gps->velocity_east() * 100, // Y speed cm/s (+ve East)
g_gps->velocity_down() * -100, // Z speed cm/s (+ve up)
ahrs.yaw_sensor);
}
Agus,
You have two choices for getting the code. If all you want is to get the current version and don't need to keep it up to date, download Arducopter-2.9.1.zip from here. It has everything in 2.9.1. If you want to keep up to date then you can install a git client and clone the repository. Some info on that is here.
Andrew
Agus,
That makes sense. I will have a look.
You need to download and look at the code. There are generally comments in the header files. So, in this case, the header file is mavlink_msg_sensor_offsets.h, and the parameters are as follows:
typedef struct __mavlink_sensor_offsets_t
{
float mag_declination; ///< magnetic declination (radians)
int32_t raw_press; ///< raw pressure from barometer
int32_t raw_temp; ///< raw temperature from barometer
float gyro_cal_x; ///< gyro X calibration
float gyro_cal_y; ///< gyro Y calibration
float gyro_cal_z; ///< gyro Z calibration
float accel_cal_x; ///< accel X calibration
float accel_cal_y; ///< accel Y calibration
float accel_cal_z; ///< accel Z calibration
int16_t mag_ofs_x; ///< magnetometer X offset
int16_t mag_ofs_y; ///< magnetometer Y offset
int16_t mag_ofs_z; ///< magnetometer Z offset
} mavlink_sensor_offsets_t
Unfortunately, no units specified, so back to the code again. The mavlink processing is generally handled by GCS_Mavlink.pde, and I found the following
// m/s/s
Vector3f accels;
accels.x = (float)packet.xacc / 1000.0;
accels.y = (float)packet.yacc / 1000.0;
accels.z = (float)packet.zacc / 1000.0;
It is the accels.x,y,z that end up in the mavlink packet, so units are m/s/s.
You can also find generic mavlink documentation here. Units are often mentioned, but in this case it is in "sensor's raw units" which doesn't help much.
Andrew
-
1
-
2
-
3
-
4
of 4 Next