Friday, January 23, 2009

Insensitive / TSS^

No, it's not a "someone made an inappropriate remark" story! It's another power meter, cycling training item. So for those non-PM using readers who's eyes roll around the top of their head when I go on about this stuff, then you can look away now :D .....

There have been lots of comments lately on the Google groups wattage forum about the Normalised Power (NP) algorithm and whether it could be improved. The discussion, as they often do, has drifted a bit from that into - "could the Training Stress Score (TSS) metric be improved?"

Well can they? Possibly.
Should we bother? I'm not so sure it matters.

Maybe it's because of the insensitivity of these things. Lemme show you an example.

I have produced a standard Performance Manager Chart (PMC). It covers my riding since I started back on the bike last year (~ 7 months).

As an experiment, I decided to add onto it another version of the PMC, with data based on an augmented TSS (TSS^). In this case, the calculation of TSS is not a function of the ratio of NP to Functional Threshold Power (FTP) but expressed as a ratio to Maximal Aerobic Power (MAP).

Now there is no particular reason for doing it other than curiosity, nor would there be any great sense given the underlying physiological and other rationale for choosing FTP as the anchor point. But that's not my point. It's an experiment to see what it means, from the point of view of how we actually use the information to monitor and guide our training.
MAP for most people is typically 25% +/-3% higher than FTP and so by anchoring an augmented TSS calculation to MAP instead of FTP, that will of course change the way TSS is calculated (since now I get a much lower weighting for threshold work and have to exceed MAP for gains to be multiplied).

And the impact of changing the TSS calculation? Well that'll change the PMC and how we interpret our training, right? Well, maybe.

Here's the PMC chart with two sets of lines for ATL, CTL & TSB. Default time constants used. One is based on TSS, the other (right hand axis) is based on the augmented TSS, “TSS^”. As always, click on the pic for a closer look.

Anyway the fact that the augmented ATL^, CTL^ and TSB^ mimic the same patterns, just with different absolute values, should not be a surprise since there is a reasonably consistent relationship between FTP & MAP.

Of course the relationship between FTP & MAP does vary (which it has during the period in the above chart), and when it does there will be deviations (as can be seen in the different slopes of the CTL and CTL^ lines).

But even so, just look at how closely the TSB and TSB^ lines track each other. Yet I have changed the TSS weighting formula quite a bit by anchoring to MAP instead of to FTP.

So if I showed you those charts independently, and multiplied the right hand axis values by two, you simply would not know the difference and it certainly wouldn't provide any different or additional insight into what was going on with my training.

So what would a PMC look like using these other “improved” formula for NP and/or TSS? That's what I'd like to see. Can it really provide us with a better insight into what's going on with our training?

I suspect all the mucking about with alternative NP or TSS formula would do is simply produce slight variations in the PMC (maybe absolute numbers a little different here and there) but the underlying training patterns that emerge would be the same and the interpretation would be the same. And even if the patterns are different, we still have to look at them in the context of the composition of our training, rest of life factors etc just like we do now (or should do).

Basically the modelling is pretty insensitive.

But let's see some examples folks....

I'm always open to looking at things in different ways to help garner additional insight.


Steve Palladino said...

1) Seeing/knowing that there is essentially no difference between a MAP anchored and FTP anchored TSS could suggest that the MAP anchored TSS might be better for many folks, simply because it is likely that for many, the MAP test will produce a more valid/reliable/consistent/reproducible test result, as opposed to jumping between the 7 deadly sins (really 9 if you count 5 as 5a, 5b, and 5c) to estimate FTP, as many do.
2) I really think that NP/TSS is not the place for people to look for an improved metric. I think that the ATL time constant and its intra-individual variations is were the money is in terms of PMC optimization.
3) Thanks again for the informative and thought provoking posts.
-Steve Palladino

Alex Simmons said...

1. Well if you have trouble with determining FTP, then going with a fixed ratio of MAP would do the trick and mean that TSS, CTL, ATL calculations will be of the same absolute levels as everyone else (which has advantages for comparison purposes). Performing a MAP test with it's defined protocol is certainly attainable by anyone with a power meter and a trainer.
2. No argument there.
3. Cheers.

Alex Simmons said...

Don't you wish you can edit comments before the apostrophe police come around. LOL

It's "its" not "it's".

Robert said...

Right. TSS (and NP) are relatively insensitive to normal small changes in how they're calculated--but that doesn't mean there's no advantage in modifying the NP algorithm. It means that if you can find a change that improves how consistent they are in non-normal circumstances, then that's good: you improve things in unusual situations without harming things in normal situations. That's a win-win.

Alex Simmons said...

That's a fair comment and I'm all for a new and improved mousetrap, provided it's practical to use and really does catch more mice.

I haven't thought too hard about how such a mousetrap might be made though.

rmur said...

hi Alex,
well you know I use my own mousetrap or perhaps flavour of cheese on a std. mousetrap.

Re the main CTL line, I agree std. TSS and flavoured TSS are substantially the same - at least when I'm not doing much 'sloppy' riding (that raised my awareness in the 1st place).

In a light week or taper week though when one is riding basically at L1/L2 level but with some short hardish efforts mixed in, I believe that std. TSS CAN pump up the volume of those type of rides beyond what's reasonable. IOW, depending on ATL tc, it *could* mess up one's event target tsb.

Over the course of normal training, I know where I can typically operate best.. probably we all do know and tsb (given normal CTL) is the best single # I know of. Anyhow, I just don't like the idea of diluting the utility of that metric due to inflation.

Now can I fully demonstrate that? No, that would be shooting myself in the foot!!!

I'm most definitely not looking to replace or change the overall balance of duration & intensity - I would simply LOVE to see RATSS eliminated!

Just for the heck of it: has anyone evaluated how: psuedo-TSS = 100*Duration^1.2 (hrs)*IF^4 would work on a large chunk of workout files??

Anonymous said...

I think you're spot on Alex. The real innovation with cycling peaks to my mind is the concept of TSB as an aid to ramping up training and tapering effectively.

TSS can be calculated in any number of ways - it's essentially a variant on the old RPE (on a scale of 1-10) multiplied by 10 for every hour you train. So long as you're using the same approach for CTL and ATL I reckon the pattern will be pretty similar.

Personally I calculate TSS by using the square of my av HR as a fraction of max HR times 10 as a proxy for RPE and multiply by 10% for a ride with a bit of variation in tempo and 20% for a crit. This then gets multiplied by 100 for TSS.

Craig Fries said...

My concern with the current TSS metric - and resultant TSB - is that I feel for me it undevalues rides of particularly long duration. My own experience in comparing RPE/Residual fatigue with TSS scores shows that the TSS for 4 to 6 hour rides is often much lower than somewhat higher intensity shorter rides, but that RPE while on the long ride and residual fatigue after are often greater with the longer/lower TSS ride....I wonder if i wouldnt get a better metric with a "sliding scale" on the duration portion of the calc - rides longer than a given duration threshhold would get an additional boost to the duration component above the linear IF^2 * duration *100..perhaps anything over the duration threshold gets a Duration^1.1, 1.2 type calc?

Tim Savage said...

I echo these comments. Playing around with the CTL/ATL formula can give a variety of different results all leading to one thing... Form up/down, fatigue up/down and close parallels with the original calculation.

For non power metered rides I calculate TSS
=((Duration*(Average HR/Threshold)^3*60)/3600)*100. For me this brings the Coggan Power TSS & my HRTSS values very close together.

One thing I find interesting is using my 6 month CTL figure for calculating workout recovery speeds as I find this slightly more accurate for big TSS rides.

I hope this is of interest.