TCX to CSV Converter

Update January 2021. As well as this TCX converter I have a .FIT file converter here: Fit File Converter. This will read .fit files and allow output as .csv or tab separated files

Jan 2025 - I had a report that this program may not work on some TCX files - I don't have a device that creates FCX files (anymore) so I am a bit stuck analysing the issue. However I have recovered the source code of an older computer so can investigate further if people send me their problematic TCX files - there's a link to a folder on my Google drive in the comments or also here: Link

In the post here: Power Meter Comparison, I showed some data comparing power from my Tacx Smart Turbo Trainer and a 4iiii crank arm power meter.

To do this I obviously needed to log the power data into 2 acquisition systems as a Garmin will only record 1 power meter at a time. I used my Garmin for the 4iiii data and logged the Tacx data in a TCX format using a PC based trainer application -  VeloReality (Veloreality).

However I needed to read the TCX file that the Veloreality creates into Excel, so I wrote a small (Windows) program to do this (note that initially I manually uploaded the data into Strava and then used my other program (Strava Data Analysis) to get the data - however this means that I need to upload 2 identical rides and this obviously screws up the annual statistics).

Here's the program (which is available to download, see further in the post).

This is the main window, pretty simple really. Press the "Import TCX File" button (or use File/Import TCX File)

There are also 2 areas to display the data as the TCX file is processed. The top text box shows general information about the activity recorded and the lower text box shows the actual time based data (as will be seen later)


Also on the Menu bar is an "About" dialog box showing version and release date.

To import a TCX file either select the button or use File/Import TCX File as here:

 
In either case a standard File Open Browser appears. Select the file in the normal way:

The file will immediately start to be imported. A progress bar shows an estimate of progress.

Once imported and converted the Export button will become active allowing the data to be exported as a .csv file using a standard Windows Save dialog box

Here's an example of a converted file:

And for information this is the source TCX file:

This program has worked reliably for me, on a small sample size of TCX files. This of course means that it will not work for you - so please contact me via this Blog so I can investigate issues

The program has some small configuration possible . Basically it reads a line of the file at a time and compares contents of each line against some specified pre-defined strings, and then processes accordingly. The user may edit these strings if there are differences, perhaps due to language etc. This is done as follows.

From the main File menu select File/Show Application Folder.

This will open the folder used to hold an old fashioned INI file (and also some small application log files). The INI file is created on first run from hard coded variables.

Open tcxconverter.ini and you will see the following:

[TCX_Converter]
TCX_Header=<?xml version="1.0" encoding="UTF-8"?>
TCX_Track=<Track>
TCX_Trackpoint=<Trackpoint>
TCX_Activity=<Activity Sport="
TCX_Activity_end=">
TCX_Id=<Id>
TCX_Id_end=</Id>
TCX_Lap=<Lap StartTime="
TCX_Lap_end=">
TCX_Time=<TotalTimeSeconds>
TCX_Time_end=</TotalTimeSeconds>
TCX_Distance=TCX_Distance
TCX_Distance_end=</TriggerMethod>
TCX_Trigger=<TriggerMethod>
Value_Trackpoint=<Trackpoint>
Value_Trackpoint_end=</Trackpoint>
Value_Time=<Time>
Value_Time_end=</Time>
Value_Position=<Position>
Value_Position_end=</Position>
Value_LatitudeDegrees=<LatitudeDegrees>
Value_LatitudeDegrees_end=</LatitudeDegrees>
Value_LongitudeDegrees=<LongitudeDegrees>
Value_LongitudeDegrees_end=</LongitudeDegrees>
Value_AltitudeMeters=<AltitudeMeters>
Value_AltitudeMeters_end=</AltitudeMeters>
Value_DistanceMeters=<DistanceMeters>
Value_DistanceMeters_end=</DistanceMeters>
Value_Cadence=<Cadence>
Value_Cadence_end=</Cadence>
Value_HeartRateBpm=<HeartRateBpm>
Value_HeartRateBpm_end=</HeartRateBpm>
BPMValue_Value=<Value>
BPMValue_Value_end=</Value>
Value_Speed=<Speed>
Value_Speed_end=</Speed>
Value_Watts=<Watts>
Value_Watts_end=</Watts>
Value_Extensions=<Extensions>
Value_Extensions_end=</Extensions>

Here it is clear the each entry in the TCX file (either as an activity header or data value) has a matching INI file category. Here are some examples:


The type of activity in the TCX file is "Biking" and is recorded in the file as follows:
<Activity Sport="Biking">
I want to extract Biking and so this is preceded by <Activity Sport=" and followed by ">
So that the program can detect this it has a variable called TCX_Activity which equals <Activity Sport=" and another variable called TCX_Activity_end which equals ">
The program searches each line between these two variables and extracts Biking
So if your file has a different text either side of the data required these INI file settings can be edited
This process is used throughout the program


There are some assumptions and limitations

• Correct TCX format. I assume that every 1st line will be: <?xml version="1.0" encoding="UTF-8"?>. If this is not the case then the conversion will abort. No other format check are performed
• The way I have written it is not at all good and assumes all files look and are formatted exactly like this file. I suspect it will fail when TCX files alternatively formatted are passed to it. This will be an interesting programming challenge to better handle XML type files. I think some form of recursion will be required and I have always struggled with that
• Some data (like cadence in this example) is duplicated as it also appears in the <Extensions> block. There is no processing to remove this duplicate
• It will only process the variables in the INI file. If your file has additional variables these will be ignored. I will address this to an extent by allowing user defined variables to be defined in a later version
• Error trapping is crude and simple
• I extended my C# programming learning by using Databinding for the text boxes in this application. I think this affects performance and is not strictly necessary

Getting and installing the program.

I have had trouble in the past trying to provide a robust means for people to install the program. I have been adding a zip file containg the Installer that Visual Studio builds and this has had I believe mixed success for people to get it to load.

However with further work, and actually building it as a Release rather than a Debug version, reveals that a standalone exe file is also created. This will just run and work although these is no installer. This is much easier

I have put both these solution in individual Zip files on my Google drive. Here is the link for these files: Link

TCX_Converter_1_0_0_7_exe.zip is the standalone exe file and TCX_Converter1_0_0_7_installer.zip is the installable version


Please give feedback in the comments section of this post and I'll contact you for further information if there are issues

Power Comparison Between my Tacx T2240 Flow Smart Trainer and a 4iiii Crank Based Power meter

Back in May 2018 I started a post here about how I had started to measure power as part of my cycling with my Tacx T2240 Flow Smart Trainer and a 4iiii Crank Based Power meter

Firstly I will say that having a "Smart" trainer has meant that I have ridden the turbo a lot more than I ever did on my original "dumb" unit - having a means of defining some form of structured work out and getting specific measurables has really been an improvement and I rode hundreds of miles on the turbo over the initial 3-4 months ownership. Needless to say the good weather then saw it relegated to collect dust again but its back out now and in use. 

As I noted in the earlier post I used either VeloReality (Veloreality) or Road Grand Tours (RGT) (https://www.roadgrandtours.com/). Both different but both providing a means of training. In the case of Veloreality I use it very much as a structured training aid by defining a power/time profile, whilst Road Grand Tours is more of a video game approach where you can ride up some famous virtual climbs (Stelvio for example). I have not tried what appears to be the all encompassing Zwift yet however and I think RGT will struggle to break in to the market against Zwift. Over the summer RGT added a number of updates including a flat Criterium circuit and also scheduling races very much as per Zwift

However my perception of riding the trainer at a given power level felt a lot harder than on the road at the same power level. This is very difficult to quantify as its perception. Now that the good weather is over I have decided to analyse this slightly more scientifically. Given I have 2 power measuring devices and a means to record the same ride on 2 devices (a Garmin and Veloreality) I have started some vaguely analytical tests.

Here is the result of the first ride - very much a turn up, ride bike and collect data event. Here's the data:

This graph shows the difference between the 2 power meters vs. time:

The error is fairly consistent against time. There is an odd error at ~1800secs that is not seen elsewhere.

Here is the same data (note that the 4iiii data is a rolling average over 10 seconds) plotted against each other, allowing the relationship between the two data sets to be assessed

What is seen here is a reasonable correlation (although 75% R2 is not great) and the linear curve fit shows that the Tacx meter reads 18Nm lower than the 4iii meter.

This offset ties in with the perception that the power reads lower on the Tacx.

I then collected a 2nd set of data a week or so later (a different test cycle to the first):

In this Graph we see that the 4iiii power meter read a lot higher at the start of the ride although this difference starts to reduce as the first ramp is approached. It can also be seen that at the end of the ride that the difference has reduced. This behaviour is different to the first ride which shows a constant offset.

In order to show this more clearly here is a plot of the error vs time:

This shows clearly the convergence of values over time.

Using the same approach the correlation between the 2 meters was plotted:

This is a much better correlation than the first (R2 = 0.88) although the offset is bigger at 39 - this is strongly influenced by the initial offset I believe.

In both these cases it was a case of turn up and ride and collect data to understand what the problem might be. This leads to many issues.

A third experiment was then carried out. In this I rode an easy warmup for ~5 minutes before starting any measurement.

Additionally I completed a calibration of both the 4iiii meter and Tacx before data collection.

In the case of the 4iiii this is a "0" rather than a calibration - whilst unclipped and with the crank arms vertical use the calibrate process either from the 4iiii Mobile App or via the Garmin.

For the Tacx it needs a coastdown test. In this instance it failed the first time so I spent a number of iterations using the app to get the result to be exactly half way between "too loose" and "too tight" I still don't quite understand how this is a calibration.

The data is here:

The power/time plot for this activity shows that by about half way through the session the error between the two power meters is quite small and this smaller error is maintained for the rest of the ride. This is clearer here:

The error has dropped to about 5W (4iiii still reading higher). This is pretty acceptable given the quoted accuracies of the 2 devices

Following this further here is the correlation data for the full ride:

On this occasion we have got a 92% R2 value (this is pretty good) and a zero offset of 15W. The data shows this is primarily at the start of the ride so I performed the came correlation for the 1st half and the 2nd half of the ride, here:

For the 1st half: 96% R2, 36W offset, and the 2nd half: 97% R2 and 11W offset

This result for the 2nd half of the ride is pretty impressive. I believe that the error has reduced as the TACX unit has warmed up, although this is not seen in the other 2 rides. It would be challenging to have to ride on the turbo for 20-25 minutes before starting the proper ride in order to get reliable result

As a bit of additional reading DC Rainmaker has a recent post (Decemeber 18) here about a similar (the same?) topic: dcrainmaker.

I don't agree with everything he says  (especially about accuracy) but he sees lots of product and has time to collect data and analyse it and there is a lot of interesting information

(More comment to be added - 20 Dec 2018)