Core Temperature implementation

[Ron George]

Interested to know what goes into the black box of "core temperature", which shows up in my performance tab. During very high intensity races, core temperature asymptotically approaches 40 deg C, which is fascinating but also scary. How reliable is this model ?

[Mark Liversedge]

On Sunday, 12 February 2017 21:22:32 UTC, Ron George wrote:

Interested to know what goes into the black box of "core temperature", which shows up in my performance tab. During very high intensity races, core temperature asymptotically approaches 40 deg C, which is fascinating but also scary. How reliable is this model ?

I asked Mark Buller the original author of the article the algorithm is taken from this very question a couple of years ago. His reply:

"What the 2013 paper shows (Table 6) is that high (according to our guidance manual TBMED 507 figure 3-1) work rates up to 675W (the cycling community may call this low), the algorithm works well. (Most of our vigorous Army field exercises seem to fall within this level). We have one group of data from cycle ergometers (study B.1) at about 1000 W (metabolic rate) where the algorithm overestimates core body temperature but this is in a very hot environment (33 C air temperature). We lack data at other temperatures and at these higher work rates to conclude anything at the moment."

Cheers

Mark 

[Steve Mansfield]

Timely topic... last week I rode home in 41C heat for over an hour, got a little dehydrated, and my core temp was reported as lower than the ride to work in much more agreable temperature.

[Chris Cleeland]

On Mon, Feb 13, 2017 at 3:51 AM, Steve Mansfield <quit...@gmail.com> wrote:

Timely topic...

Indeed!  Very timely, as I just noticed this data point in my file from yesterday and was curious because I didn't ever remember noticing it in the past.

I recently got an ANT+ HR strap to replace my old one that stopped working, and sometimes I actually remember to wear it.  A quick inspection last night revealed that "Core Temp" data was available for any ride with HR data.  So I thought that maybe the HR strap supplied core temp data, too, and added learning about this to my mental to-do list.

It looks like I have the answer, although based on what Mark wrote below it doesn't sound like HR is an input to the model, so I'm wondering why it only shows up for me with HR data?

FINALLY, I think it can be confusing to have measured data and modeled data presented in identical manner, especially when the data itself could feasibly be measured.  To clarify by example, data such as "temperature" or "speed" are both something easily measured and recorded with reasonable accuracy; things like W' or the Coggan metrics are, by definition, model outputs.  It would be good to have the UI somehow display *measured* data points differently from modeled data points, with maybe a "mouse hover" pop-up help that indicates a description of the data point and whether it's measured or computed and, if computed, whether it's from a direct model or a correlation model (not sure if those are proper terms, but hopefully my intended meaning makes sense).

Thoughts?

[Mark Liversedge]

On Monday, 13 February 2017 14:13:43 UTC, Chris Cleeland wrote:

On Mon, Feb 13, 2017 at 3:51 AM, Steve Mansfield <quit...@gmail.com> wrote:

Timely topic...

Indeed!  Very timely, as I just noticed this data point in my file from yesterday and was curious because I didn't ever remember noticing it in the past.

I recently got an ANT+ HR strap to replace my old one that stopped working, and sometimes I actually remember to wear it.  A quick inspection last night revealed that "Core Temp" data was available for any ride with HR data.  So I thought that maybe the HR strap supplied core temp data, too, and added learning about this to my mental to-do list.

It looks like I have the answer, although based on what Mark wrote below it doesn't sound like HR is an input to the model, so I'm wondering why it only shows up for me with HR data?

The Core Temperature algorithm uses a kalman filter based upon HR as a leading indicator. https://www.ncbi.nlm.nih.gov/pubmed/23780514

It was originally developed by the US military to help prevent serious issues with infantry and other personnel whilst on manoeuvres or training. It wasn't developed for cycling or running and therefore some caution should be applied.

The quote I provided previously was from Mark when I asked about applicability to cycling. In my own data I have found that rides where CT approaches 39C to be very, very hard. Which I find very useful information when reviewing performance (or lack of it !).

 

FINALLY, I think it can be confusing to have measured data and modeled data presented in identical manner, especially when the data itself could feasibly be measured.  To clarify by example, data such as "temperature" or "speed" are both something easily measured and recorded with reasonable accuracy; things like W' or the Coggan metrics are, by definition, model outputs.  It would be good to have the UI somehow display *measured* data points differently from modeled data points, with maybe a "mouse hover" pop-up help that indicates a description of the data point and whether it's measured or computed and, if computed, whether it's from a direct model or a correlation model (not sure if those are proper terms, but hopefully my intended meaning makes sense).

I think this is a fantastic point and should be taken very seriously.

Almost all discussion around cycling and performance seems to revolve around one or other output from a model instead of empirical data. Worse still, some self-coached athletes go so far as to ignore things like RPE and HR for less reliable metrics of performance.

Now, quite how we do that in a universal way is challenging, but perhaps we can try something with the new overview dashboard that's being prototyped.

Mark

[Chris Cleeland]

On Mon, Feb 13, 2017 at 9:01 AM, Mark Liversedge <liver...@gmail.com> wrote:

In my own data I have found that rides where CT approaches 39C to be very, very hard. Which I find very useful information when reviewing performance (or lack of it !).

I originally noticed the datapoint because yesterday's Max was over 39C and avg was 38C.  This was on a day when I was wearing standard summer kit with a sleeveless base layer but the rest of my teammates were in knickers and long sleeves.  In other words, my temps should be low.

I think that my HR measurement is wonky right now, which I would guess contributes to the model-calculated temp showing higher than reality. At one point yesterday my HR was displayed as 200...while I was churning a blistering 120 W on a slight downhill chatting.  I don't know if the strap is having issues or if my hairy chest creates problems or what.

 

 

Almost all discussion around cycling and performance seems to revolve around one or other output from a model instead of empirical data. Worse still, some self-coached athletes go so far as to ignore things like RPE and HR for less reliable metrics of performance.

Hah! Yes, the supercomputer between your ears is often the very best feedback mechanism.  If it felt hard, it was.  Measurements are useful when you want to know if "hard" today was the same as "hard" was yesterday or, even more importantly, a year ago.

 

Now, quite how we do that in a universal way is challenging, but perhaps we can try something with the new overview dashboard that's being prototyped.

Hopefully there is time to kick it around before The Great UI Revolution so that it fits into the entire UI/UX story rather than being bolted on the side.

The notion that came to me while using GC 3.3 was to have measured data rendered in bold typeface, and model data maybe in italic non-bold.  It's simple, isn't subject to color issues, and doesn't get in the way.  The downside is that it's not very obvious why some data is rendered one way while most is rendered a different way.  Communicating the meaning--no matter what's chosen--will be the hard part.  Whatever is chosen will have to be documented.

[Steve Mansfield]

Here's some data on this for y'all... Max Core Temp vs TRIMP - both are HR based of course. N=565

Not really seeing anything hugely useful here

[Mark Liversedge]

On Tuesday, 14 February 2017 08:50:57 UTC, Steve Mansfield wrote:

Here's some data on this for y'all... Max Core Temp vs TRIMP - both are HR based of course. N=565

I'd be most interested in rides where CT rose above 37.5C i.e. CT got to a point where it probably impacted performance as it was outside of a normal range. https://en.wikipedia.org/wiki/Human_body_temperature

And in those cases IF is likely more interesting to look at if looking for correlations kin rodes of shorter durations. At longer durations TSS is deeply problematic anyway since it increases with time regardless of work done. 

Mark 

[Chris Cleeland]

On Tue, Feb 14, 2017 at 3:45 AM, Mark Liversedge <liver...@gmail.com> wrote:

On Tuesday, 14 February 2017 08:50:57 UTC, Steve Mansfield wrote:

Here's some data on this for y'all... Max Core Temp vs TRIMP - both are HR based of course. N=565

I'd be most interested in rides where CT rose above 37.5C i.e. CT got to a point where it probably impacted performance as it was outside of a normal range. https://en.wikipedia.org/wiki/Human_body_temperature

Do you mean ACTUAL MEASURED CT, or the output of the model?

 

And in those cases IF is likely more interesting to look at if looking for correlations kin rodes of shorter durations. At longer durations TSS is deeply problematic anyway since it increases with time regardless of work done. 

Presuming you're not descending a mountain for some duration larger than an inter-interval recovery period, you're still pedaling on a longer ride.  The TSS model incorporates that time into your score. It is not perfect, but I hardly think that makes it "deeply problematic".  It's a useful tool with some recognized deficiencies.

--

Chris Cleeland

[Steve Mansfield]

Some more data - n is similar to before

[Steve Mansfield]

Sorry, same chart twice

[Mark Liversedge]

I think it would be better to look at Max Core Temp.

Here is an example R chart:

I've attached the chart, you can drag and drop it in.

Mark

[Mark Liversedge]

Oops. There was a typo in that R chart, attached a fixed one.

Mark

[Steve Mansfield]

Here's a fairly poor overlay of Max 20 minute NP, Max 1hr NP and max 20 minute  power and max core temp. Data is since Sept 2016. GC doesn't export those NP metrics hence doing it graphically

[Ron George]

Thanks all. I think the signal from the noise for me is to avoid spending too much time at the core temp algorithm. It works in some contexts, doesn't in some and I highly suspect what it does during runs.  Moving onto more useful things.

[Mark Liversedge]

On Friday, 17 February 2017 11:02:32 UTC, Ron George wrote:

Thanks all. I think the signal from the noise for me is to avoid spending too much time at the core temp algorithm. It works in some contexts, doesn't in some and I highly suspect what it does during runs.  Moving onto more useful things.

Fair enough. I would say I don't think we can say anything about its usefulness right now, good or bad.