When you have a RHR that is wrong on one one day, and the next day(s) there is no update on RHR (no new value comes through), intervals keeps using the most recent one.
You should at least know where you get your data from because otherwise you will never be able to spot the source of an anomaly.
The RAW data is only one part needed to make the calculations. The second part that needs to be correct and consistent in between platforms, are the settings that make up how the load will be calculated.
If you use Power to calculate load, FTP needs to be the same on all platforms.
If you use HR to calculate load, things become more complicated. That’s because there is no standard way to calculate load from HR. But you need some model to be able to calibrate the HR during the workout to a “known” intensity. There are HR models to calculate load based on:
Max HR
LTHR
HR zones
the most accurate one is based on your HR reserve and that is HRmax-HRrest
So you see that if you use the last one and you have wrong HRrest data, the result will be completely off. And that last one is default in intervals.
I would suggest you go to the settings page and choose one of the other two options for calculating load from HR (time in zones or Avg HR), then click on Update activities and then recheck if the fitness chart now is closer to what you see in TP.
My guess is that it will. And the bogus calculations would then all be caused by one or more entries of false RHR.
BTW: To make things easier for us, try to give more info from the beginning. Like what method you’re using for TSS calculation for example…
And I see what you mean about resetting the HR load call method in settings and then updating the activities.
But the issue is not there I think… the fact is that intervals, TP and Strava are just destinations for data that is created in the garmin universe - apart from visualizing, I don’t actually « do » anything on these platforms.
So yes, I know where the data comes from (Garmin). But I have no idea what data specifically gets brought over to intervals (TSS is definitely not exported to intervals…)
And since I haven’t changed anything to the settings in either GC, TP, Strava or intervals, I really don’t understand why just two adjacent activities have a problem that has neither existed before, nor after.
The simple fix would be simply for me to use TP TSS as an estimate, manually add it to the problematic activities in Intervals, and call it a day.
But I would rather understand the issue than solve it, because without knowing why things happen to CTL, it is difficult to want to commit to using the platform.
If @david says you have a RHR input of 113 anywhere in your RHR history, then I believe him. And if you have Load calculation set to HR with the model HRSS, you can be damned sure that the source of your problem is there. TSS is NOT coming from Garmin, Strava or whatever other platform. You ONLY get the RAW activity data (sec by sec values) and TSS is calculated on every platform independently with the chosen model. Every parameter that is not a recorded, sec by sec, value is calculated on the platform. Intensity, TSS, avg speed, avg HR, etc etc etc is a calculation that is done on the platfrom and not a copy of what Garmin spits out (luckily )
How that number got there can be a mystery, but if it is there, it’s wrong. So you should check the RHR field data. The easiest way to do that is to set the activity list view and add the resting HR column.
Anyway, if you want to use HRSS as the load calculation model, you need to update your RHR on a regular basis. If you don’t, you better use one of the other models. Actually, the way HRSS is implemented in intervals, it sort of NEEDS activities with Power and HR to make the model.
So just check that field and then come back with your findings.
ok, so Resting HR is 113 in ALL activities!! the real number is 60… i have no idea where GC, Strava and Intervals get their RHR from, but sure as hell, it is not a number i input myself.
And, I spent the better part of an hour going through all of these to see where RHR can be manually set and I could not find it anywhere
but all that stil does not explain why only TWO activities haves this bizarre TSS…
sure i can fix it manually by using TP numbers, but that does not explain WHY I have a TSS of 2 in 2 activities, and why this never happened before, and never since.
So I went to the offending activities in Strava and clicked on “Refresh Activity Achievements”, and lo and behold, the TSS numbers in Intervals updated to something that looked normal.
Resting HR is still lout to lunch, but at least the TSS of 2 is now gone.
CTL now looks better and has the same shape (sort of…) as that in TP, but the spread between TP’s CTL and Intervals CTL is still larger than it has been in the past, and I am not sure why.
Here are the original Excel charts updated for the corrected TSS (there is still something weird about my CTL in Intervals…):
Your problem is almost solved but you don’t realize it yet and you don’t understand why. I’ll try to do my best to explain in detail…
First the consequence of the incorrect RHR:
If load calculation is based on HR and you have the model set to HRSS, which I am by now just about 100% sure (even if you still didn’t confirm), all TSS calculations on intervals are too low
Let’s say you have a HRmax set to 173 and RHR 113 (the bogus number you have). That gives you a HR reserve of 60bpm. If you workout at 143bpm, your intensity for that workout is 50% and your load will the be 25TSS/hr. 113 + 0.5*60=143 and Load is the square of intensity/hr, 0.5 squared is 0.25 *100= 25
But with the same HRmax and a RHR of 63 (just to make it easier to calculate) the reserve is 110 and the workout at 143bpm accounts for an intensity of about 73% and a load of 53TSS/hr.
Second: Why do all activities have this bogus RHR of 113
I don’t know where the first 113 came from, you’ll have to investigate that yourself.
Intervals needs a RHR to make the calculations. If you don’t enter one, Intervals will copy the most recent one to every day you had a workout. Days without workout will have a blank field for RHR
So there is only one single time that this number came in and that is on the first day that it occurs in your history
Third: How to enter RHR
If you continue to use the HRSS model for load calculation, I strongly suggest to measure RHR in the morning on a regular basis
On the Activities page, click on the button to add a calendar entry and choose Add Wellness data. That’s where you update RHR. If you enter 60 today and never update it again, all future workouts will be calculated with a RHR of 60
Unfortunately, I’m affraid that you can’t batch edit the RHR number. So you would need to go back to the first day where the 113 RHR is found, replace that by 60 and then go through every day and correct or delete the bogus value.
Once all the wrong values have been deleted or corrected, you will need to reprocess all those activities. That can be done as a batch job. Go the list view on the activities page and select all the workouts that need correction. Then click on “Edit” - 'Reprocess File".
If you prefer not to go through all that hassle, just do what I told you in my earlier post. Change the calculation model to “Time in Zones” if those were set correctly or Average HR and click on Update activities. If you just would have tried that, you would already have a fitness chart that is almost identical to the one from TP.
But I guess that now you will not only have a correct Fitness chart but also the understanding of why it was wrong…
You can batch update resting HR by downloading the wellness CSV, editing that column and uploading. Go to Options → Wellness → Download CSV on the calendar page.
Wow! @MedTechCD , @david , thank you! v clear help, i managed to fix the issue.
The resting heart rate came from one entry at 113 whereas all previous ones looked clean. I get the wellness data from GC, not strava, and i don’t now where that a data point came from, because i can’t find it in GC (all the other entries in GC were also in the wellness CSV…). Nevertheless, problem found an fixed, thanks @david
Also fixed the TSS and CTL calcs and am using Time in Zones now as opposed to RHR, thanks @MedTechCD
And the results speak for themselves - the CTL chart is now v close to the one in TP and the delate is more or less the same now as it was 6 months ago, and is within a usable range. More importantly, the two CTL charts are no longer diverging.
)
