Carb utilisation and ingestion on activities

Carbs ingested is now filled in from session field number 177 which is calories consumed, divided by 4 to get grams (assuming that is mostly carbs). Will deploy Sat AM.

2 Likes

Working! Thank you :smile:

1 Like

Unless your doing a recovery or z2 ride you’re not going to ingest as much carbs as you will burn.

Really just a matter of gut tolerance for longer harder rides >90mins

Very nice feature, sadly it doesn’t work well for rides with a lot of freewheeling (which happens all the time in the mountains). For example my today ride has CHO utilisation almost as high as calories burnt (355g CHO and 1587 kcal, meaning 1420kcal from carbs) even though I was below threshold all the time and for the most part significantly below it (which means I should have burnt some fat as well).

Do we have access to the data from the paper the calculations were done on? I am willing to spend time finding a better function if I can get the data. It won’t be difficult as the researchers based it on TSS which increases with time, not with actual work/intensity.

For me, the numbers given by this TSS equation seem too high.
I have done several metabolic cart tests and converted the data to carb and fat consumption for a given range of power.
For example 150 W → 45 g/h ; 200 W → 100g of carbs/h

I will keep beating the same drum: TSS is a metric that increases mainly with time, not actual work. It doesn’t work for measuring training load. It doesn’t work for approximating CHO consumption. It doesn’t work for anything power related. It’s a shame piece of good research was wasted because of this nonsense but here we are.
What would work better is using the power curve to approximate CHO consumption and then integrating over it (taking area under it). If we can get some actual data we could try to fit the curve and get some reasonable estimations.

4 Likes

The link under " Code Availability" of the paper points to the files here: OSF

2 Likes

Hi, I’m sharing my spreadsheet here if you still would like a copy:

Thank you.

@david I have some weird values concerning Carbs used in some of my sessions.
Especially when the sessions are very short, the Carbs used (in german: KH verbraucht) shows values that can’t be right.
I marked them in red in the screenshots. As I said, what all sessions have in common is that they are very short and have a very low calorie usage.





I mentioned this earlier in this thread. It is because of the high variability of your activities.

I ignore this value completely.

@R2Tom Ok - but perhaps a simple crosscheck with “calories used” could verify if the value is at least a little bit valid. If the value is less than 1/4th of “calories” used it might be valid. if it is 1:1 - no way.

I totally agree.
It’s super annoying to see I am using 113g carbs with only 95 kcal in my commute only because I do two minutes of effort to climb a hill :face_with_peeking_eye:

I just hope nobody takes it that that is the amount of Carbs to eat on a ride because at least in my case it is always far far too high.

1 Like

The Cho consumed indicated is really exaggerated…1 hour for Z1 gives me 300 grams

See the posts above. It’s a “design” decision, and probably not for recovery rides. I completely ignore it and doing my own calculations.

Don’t know if @Jeff_Rothschild is still active here to answer those questions.

Hi guys, happy to try and help. Not sure in your exact case, but ithe calculations are dependent on accurate input values for FTP, prior day TSS, etc., so maybe something in the chain is off?

Thanks for reaching out @Jeff_Rothschild , maybe @Giuseppe_Leccese can also share an example.

An extreme example is this where I stopped 2km before finish, and accidentally saved the activity, so this was the remaining part:

73g of carbs for a 5 minute ride with 2 minutes of coasting is a huge estimation. I understand that this is an extreme example with only 5 minutes, but also have examples with 15 or 20 minutes rides (commutes in hilly area)
So this implementation makes it difficult to build summarised values for weeks or a month if single activities, especially recovery rides or commutes estimate too much used carbs.

Yeah that is obviously an invalid estimate. Similar to rides much longer than 90 mins not being reliably estimated, there is also a lower limit (due to the use of the squared training load terms in the models). So 30-90 mins would be the range these models were made for. I know that’s a huge limitation for this group but it’s a known limitation. I can work with Mark to offer a workaround estimator for very short or very long sessions.

1 Like

is incorrect…one houyr z1 390n grams,…

1 Like

Sry to chime in here again and possibly annoy you David, but I’ve been observing this feature (and this thread) basically since its first implementation. I’m happily coaching ~30 athletes and love intervals.icu, but the carbs feature still is 0% working and I’m getting a bit tired of explaining to ignore this to my athletes who keep looking at the number of course. Just looking at my own rides in the last while, no matter how hard or easy I ride, my energy apparently always comes ~100% from carbs which is obviously far from true. Living in the middle of the alps, I basically cannot produce a ride with a variability index below 1,1 really. I dont think we should have this feature if its not working at all honestly. Dont want to sound too harsh, please read it as constructive feedback.

Personally I think there would be far easier and sufficiently precise solution. Nerding out about Mader equations etc is nice but its not leading nowhere. Your carb utilization will be different tomorrow comapred to yesterday, based on a million factors. Just use a curve that describes the % of carbs burnt at each intensity from 3 points (like 50% FTP = 20% carbs, 80% = 50%, 100% = 90% for example) and calculate the power data against that. It doesnt have to be more complicated.

3 Likes

We have disabled our current calculation, it seems it doesn’t work well for too many people. Carbs used is now an editable field in the UI and elsewhere. Custom activity fields and apps can update it so people can implement their own calculations.

2 Likes