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.
Cycling Analytics now supports heart rate zones.
This chart shows the time I spent in each heart rate zone for each week in the last six months. If this was the real chart you could hover over it with a mouse and see more information. You could also have rides grouped by month or by day instead of by week. And, you can hide zones, which makes it much easier if you just want to focus on one zone, .
If you want one of these for yourself, you first need to add heart rate zones. The easy way to do this is to go to the heart rate management page and click “Set zones automatically” and five heart rate zones will be generated automatically based on your maximum heart rate (so make sure that’s set first). However, there are lots of different approaches to making heart rate zones, so this is very flexible — you can tell it how many zones you would like, and then specify your preferred heart rate range for each zone (and you can even specify their names).
Here’s something for everybody who prefers to think in terms of miles, feet, pounds and Fahrenheit — Cycling Analytics can now display distances, elevations, speeds, weights and temperatures using the US customary units.
To get this, simply go to your profile settings page and tell it to display US units. Then, distances will be displayed in miles, elevation in feet, speed in miles per an hour, temperature in degrees Fahrenheit, and weight in pounds (even though the only place weight is used at this time is for displaying power in watts/kg, and that remains in watts/kg when using US units — I doubt many people think of a cyclist’s power to weight ratio in terms of horsepower and pounds).
Have you ever wondered what it takes to ride a thirteen minute 1 in 20?
In 2002, one of our Aussie pros, Trent Lowe, did just that, clocking 13:02 before going on to win a Junior World Mountain Bike XC Championship title. Now, with the help of a video of the ride, a bit of physics and a lot of guesswork, I’ve had a go at reconstructing the ride.
The short answer is: you need to be able to put out about 6.2W/kg, which is 395W if you weigh 64kg. And, if you can do that, you’re probably being paid to ride a bike.
For anybody who isn’t aware, the 1 in 20 is a very popular climb near Melbourne, named after its fairly constant gradient (although there’s a false flat in the middle). The current Strava KOM time is 13:20, which is based on about 16,000 ascents so far.
My approach to generating the data for this ride was to:
There a number of caveats worth mentioning:
All in all, take the data generated with a grain of salt, but I think that it would broadly… continue reading
You normally ride with a power meter. Occasionally you only ride with a heart rate monitor. You want all your rides to be represented on the training load chart. Does this describe you? If it does, you’re in luck, because Cycling Analytics can now show rides with power or heart rate on the one training load chart.
At the end of the last blog post I pointed out the correlation between the heart rate and power metrics calculated to indicate the stress of the ride. Now, if you have rides with both heart rate and power (to calculate the correlation), as well as rides with just heart rate (or else this isn’t needed), the TRIMP score (from heart rate) is scaled so that it corresponds with training load (from power). Thus, TRIMP is used to estimate the training load for a ride. Traditionally, one would have to estimate the training load for a ride (it was two hours at 75%, therefore it’s 150), but automatically using heart rate is a lot easier.
If you are curious as to how well this actually works for your rides, you can look at a chart that shows how TRIMP and training load of all of your rides correlate. This chart is found at the bottom of the training load chart (and you have to click on the button to make it show).
One other recent change with the training load chart is that starting values for short-term stress and long-term stress are calculated automatically if custom values aren’t provided. The guess works well if the first week or two of your rides uploaded are representative of the riding you were doing previously, but it won’t be so good if you had an unusually big first week. If you know that the guess is inaccurate, custom values can be used instead.
One more thing: mini-training load charts are shown on the main “rides” page in the monthly summaries. These show the same information that the training load page shows when it loads. That is, it defaults to showing the same data (power and HR together if it can, else just power, else just HR) and uses the same initial values.
Since a lot of “serious cyclists” don’t have power meters, I have received a number of requests to do more with heart rate data. Therefore, Cycling Analytics is now calculating the TRIMP score for rides, which, in turn, can be used to generate the training load graph for users who don’t use a power meter.
TRMIP, or training impulse, is a metric based on heart rate that is designed to capture the stress of an activity in a single number. The formula used (described below) relies on the sex, resting heart rate and maximum heart rate, so users must enter these values before TRIMP scores are calculated.
Once TRIMP scores have been calculated, Cycling Analytics uses TRIMP scores to generate training load charts. Therefore, a user’s rides page will contain more enlightening monthly summaries, and the main training load chart page is useable.
This is similar to what a user with a power meter would see, except there is a big gap in the middle where the power curve is shown. Do you have any suggestions for what could fill that gap?
Going back in time to look at old rides is now a whole lot easier. Rather than having to endlessly scroll down and repeatedly click “show more”, there’s now a list of years and months that can be used for navigation.
Immediately underneath “Rides” on the left there’s now a list of years and months where rides exist. Clicking on the year collapses or uncollapses its list of months, while clicking on a month takes you to those rides. The number of rides in each month is shown when the mouse is over the month name. And, to make life easier, the list of years and months is always visible, regardless of whether you’re looking at the top, bottom, or middle of the ride list.
If you want to see this in action, take a look at my rides.
The way timezones are handled has changed. Previously, dates and times were shown according to the timezone set in profile settings. Now, dates and times are shown according to the timezone that the ride starts in.
There were a few problems with the old approach, with the main one being that the date of a ride when it is shown may not be the same as the date that it was considered to have when the power profile was generated. Why? The best-for-the-month and best-for-the-year power profiles are calculated ahead of time, and since it doesn’t know what timezone to use (the user can change their timezone), it uses the UTC date, but it’s possible for this to be in the wrong month or even year. For example, if you went for a ride at 7AM on January 1, 2013 in Melbourne (and your timezone is set to Australia/Melbourne, which — including daylight savings — is 11 hours ahead of UTC), the UTC date will be used when adding it to power profiles, and that date is 8PM on December 31, 2012.
The new approach completely avoids this problem by always using the local date. There are a couple of potential problems. Firstly, the wrong timezone might be chosen. This shouldn’t happen, but get in contact if it does. Secondly, this doesn’t work when there is no GPS data for a ride. If this is the case, the user’s timezone (at the time the ride was uploaded) is used.
That’s all for now. Oh, for any software developers reading this, I’ll probably be releasing an open source latitude/longitude to timezone lookup library and a web API in the near future.