Earlier this week Strava shut down their existing API without making a new one publicly available. That caused issues here, because that API was being used here to upload rides to Strava. In light of this, the Strava uploading feature has been remade to work with the “upload by email” feature that Strava still provides.
If you want to have your rides uploaded to Strava, you will need to go to the linked accounts page and add the email address you use to sign in to Strava. (You need to do this even if you already had your account set to upload rides to Strava.) When this is done, an email is sent from the email address you provide (fun fact: an email can say it comes from any email address) to Strava with the ride file attached, and sometime in the next ten minutes or so, the ride should appear on Strava.
This approach to uploading rides isn’t as good as the previous method, as it no longer provides direct feedback to Cycling Analytics about the upload so it’s impossible to show a link to the ride on Strava. This also means that the Strava ride management tool doesn’t work any more, as it relies on the API that used to exist. Hopefully Strava will one day make an API available to the public again, but based on their communication, it probably won’t be this year.
Here is a list of file formats that Cycling Analytics currently supports.
FIT — The FIT, or Flexible and Interoperable Data Transfer, file format was developed primarily by Garmin and is used by most recent Garmin devices such as the Garmin Edge 510, Garmin Edge 810, Garmin Edge 1000, Garmin Forerunner 310XT and many more. FIT files of rides are supported by Cycling Analytics (that is, if you record a ride, the FIT file should be supported; the FIT file format is vastly more complex and allows for all sorts of things beyond what bike computers create). If possible, set your device to record in one second intervals for best results.
GPX — The GPX, or GPS eXchange, format is a simple format designed to store GPS tracks, but can be extended to store information like heart rate and cadence.
TCX — The TCX, or Training Center XML, format is similar to GPX, but more advanced, and was developed by Garmin.
SRM — SRM files are created by SRM PowerControl head units. Currently, only files from PowerControl 7 devices are supported. Support for older formats will come, but I don’t have any files to test it against (get in contact if you have some). One caveat is that all rides are currently stored with a recording interval of one second in Cycling Analytics, so SRM files with a recording interval of 0.5s have every pair of records joined together (this will be changed someday).
DAT — DAT files are produced by Wattbike indoor bikes. Wattbikes record additional in-depth information about pedal strokes, although Cycling Analytics doesn’t yet do anything with this. The ride date is not contained in the file, so it must be somewhere in the filename in the format DDMMYY or YYYY-MM-DD-HH-MM-SS (i.e., “220714.dat”, “z3-workout-220714.dat” or “2014-07-22-08-35-22.dat”). If the filename doesn’t contain a date, the current date is used.
PWX — The PWX file format is similar to TCX and was developed Peaksware.
CSV — There are many different ways that CSV (or comma separated values) file formats are structured. Currently, CSV files from Cyclops Joule and iBike Newton devices are supported. For CSV files that don’t contain dates, the filename will be searched for a date as with DAT files, or the current date will be used.
BIN — BIN files produced by Cycleops Joule devices are supported.
DB — DB files are produced by Pioneer head… continue reading
There’s now a tool for managing the connection between rides here and on Strava. It can be accessed via the linked accounts page if you have set up your account to upload rides to Strava. (Here’s a direct link.) It tends to look something like this:
It’s useful for adding or removing connections between rides here and on Strava, and is handy if something has gone wrong when uploading a ride to Strava. There are more instructions at the bottom of the page.
On the topic of integration with Strava, there are a couple more changes coming soon: there will be an option to strip power and/or heart rate data from the ride that is sent to Strava; and there will be a way to only send select rides to Strava, rather than all of them (although, it’s possible to do this now by disabling automatic Strava uploading on the linked accounts page, and using the new Strava management page to upload only the rides you want).
In other news, the ride summary (at the top left of ride pages) has been updated. It’s been entirely remade, but the most notable changes are that either power or heart rate based metrics can be viewed (if both exist), power and heart rate zones are displayed… continue reading
Cycling Analytics now does power zones properly. Power zones can now be set as a percentage of FTP, and the actual wattages used are based on the FTP that is current for the ride. Power zones can be configured on the power management page (previously, this was the FTP management page), and power zones can now be shown on the zones chart:
Do you ever lament the fact that your massive widescreen monitor is barely used by most websites (except by some that don’t enforce a maximum width and have text running across the entire width, which doesn’t do much for readability)? Well, now it’s possible to make charts go fullscreen.
To do this, find the little grey bar on the right at the bottom the chart legend, hover the mouse over it, and then click on the fullscreen option.
As an aside, the wider grey bar on the left has a use too — clicking on it hides (or shows) the legend, which is useful for some of the charts where the legend otherwise gets in the way of what the chart is showing.
There are a few charts that don’t support this at the moment (because they’re using older charting code). Eventually they’ll be replaced.
This post might have a complicated sounding title, but most of this is pretty straight forward. One of the nice things about having a lot of data from a lot of people is that interesting things can be done with that data. Therefore, there are now a few simple charts that show Cycling Analytics users how they compare with the rest of the users. Head over to the statistics page and take a look.
The first few charts show how the user’s resting and maximum heart rates, weight and FTP compare with those of everybody else. They look something like:
This chart shows a histogram of all users’ resting and maximum heart rates, and the solid thinner lines show where this particular user (me!) lies. In the chart legend it says that 34% of users have a lower heart rate than me and 43% have a higher resting heart rate. This probably means that 23% have the same resting heart rate (that is, it’s in the same 50–54BPM grouping), except rounding errors mean these numbers don’t always add up to exactly 100%. If you hover over the chart with your mouse (on the actual page, not this picture), it shows what proportion of the users have a resting heart rate lower than where the mouse is… continue reading
Power output and heart rate have a complicated relationship. When you ride hard, your heart rate goes up. When you get tired, you find it harder to produce the same amount of power, and when you’re tired enough, you find it hard to raise your heart rate. And, all else being equal, the fitter you are, the more power you can produce at the same heart rate. Looking at power and heart rate data together can reveal more than either alone.
There is a concept in exercise science called physical working capacity (PWC), which refers to the amount of power that is produced at a specific heart rate. PWC130, PWC150 and PWC170 are the the power produced when the heart rate is raised to 130BPM, 150BPM and 170BPM. Ideally, these numbers are worked out by doing a specific test, but it’s also possible to work some things out by looking at power and heart rate from a normal ride.
Cycling Analytics now has a new chart that shows how heart rate and power are related. It is found on the pages for all rides that have power and heart rate data, and it looks something like:
Your first impression might be “that’s a big, colourful, messy set of lines and dots”, but it does… continue reading
Rather than having a single weight and a single resting and maximum heart rate, as of today, these numbers now have dates associated with them, so an entire history of them can be stored. They can be shown on a chart too:
This is useful for people who measure their resting heart rate frequently (a higher than normal resting heart rate often occurs when overtraining), and also for those who want to keep track of their weight.
This also means that these three parameters (weight, resting and maximum heart rate) are now treated in conceptually the same way that FTP is — they’re histories of a value, and provided at least one value exists, the value for any day can be given according to the following rules:
Finally, this also means that FTP, weight, resting and maximum heart rate have a consistent interface on the API that is being developed. Let me know if you want early… continue reading
Users can now choose what aspects of their data they want visible to others on the privacy settings page. It looks something like this:
Hiding power and heart rate data prevent all data about power and heart rate from being revealed (including averages and maximums and the data stream for the ride). Hiding power and heart rate metrics prevents information that could be used to directly work out the FTP and heart rate zones used to be displayed (including intensity and training load).
Here is a short update about a few recent changes and other things.
Normalised work is now calculated as intensity2 × time riding, rather than as intensity × time riding. (This is how it was always meant to be calculated.) This has caused all normalised work values to be changed, and consequently all short-term stress and long-term stress values have also changed (I suppose it’s possible that some haven’t, but generally they will have changed).
Ride uploads were mostly broken for a day or so a couple of days ago (so if you tried to upload a ride earlier this week, but it didn’t work, try again now). Thankfully a number of people let me know, and I worked out that it was caused a minor change I made that had nothing to do with ride uploads, but caused some other things to be updated, which in turn caused most ride uploads to fail. Since then I’ve added some more monitoring so I am alerted when things go wrong (it lets me know when file uploads fail, and when “Something went horribly wrong” errors occur), so hopefully now I will learn of major problems very quickly, and find bugs that my testing hasn’t picked up.
One more thing: One of the things I’ve come to appreciate in running this site is that ride files can contain all sorts of things that you don’t expect. My favourite example so far is from a FIT file that a user of this site was having difficulty uploading. It turned out that halfway through, the timestamps jumped ahead exactly 4599 days, to July 2025.