Pauses in Workouts lead to overstated Personal Records

Recently I’ve been at the pointy end of SSB2 and have had cause to take a few recovery pauses, eg.

  • in the latter intervals of Spencer +2 I needed a mid-interval break so back pedalled briefly;

  • prior to the 3rd and 4th intervals in Lamarck I needed a longer recovery valley so paused the workout during the 2min recovery valleys, while I kept pedalling, to give me an extra minute or two at 40%.

The “problem” is that these recovery pauses aren’t captured by TR, meaning the plot of work performed does not actually represent what happened, leading in turn to my Personal Records being overstated…

For example, my Personal Record chart now shows a localised peak at 46 minutes, formed by 4x 10mins at 100% FTP + 3x 2min recover valleys during Lamarck, but as stated above, that’s not what actually happened.

The reality was that I had a 1x 2mins recovery valley and 2x ~4mins, and hence the 40 total minutes I did at 100% FTP was performed within a longer overall time period (~50 mins) than Personal Records says I did it in (46 mins).

Any time a workout is paused this issue will arise. I could exclude these paused workouts from Personal Records, but that’d be a shame, as even taking account of the pauses some records were likely set and it’d be a unfortunate not to be able to see them.

Is there a good reason (other than some added programmatic complexity) why TR cannot capture these pauses and make use of them in PR calculations? Ideally, the plot of the workout would show, both in realtime and afterwards, where pauses occurred, by extending the x-(time-)axis for the duration of any pause, so there was maximum clarity of what work was actually completed during the session. Without taking account of these pauses the PR data from (indoor) TR rides will be inaccurate and overstated, materially so in some cases.

1 Like

I think that is quite a reasonable question.

It is funny how the two workouts you named seem to cause us quite a lot of trouble.

I’d not previously made much use of pauses, but the past few weeks changed all that, and it got me thinking that my usual post-workout “reward” of perusing any new Personal Records left me feeling a bit of a fraud because I knew they weren’t true numbers… :thinking:

I’d be interested in getting some TR input on this, so if I’m lucky @larry or @Bryce might chip in?

This issue was discussed in another thread recently, and there is a comment from Bryce (IIRC). I will try to find that thread and comment to link here.

Edit: Found it.

3 Likes

I have a different issue w/ “pause”. I use Stages spin bikes at the gym, w/ my iphone paired up. Works great, except that on a number of occasions, the display on the bike has gone dead in the middle of a workout, which means I have to jump off, clean off that bike, find a new one, set it up and re-pair the phone (which can take several minutes of pedaling to find the right bike under “devices”, as it picks up several bikes at once). This means as I’m pedaling, the program has auto re-started and I’m missing part of the interval (eg, I missed the first 4 minutes of a 30 minute interval yesterday). I’d like to see a hard “stop” button, where I really stops the program and doesn’t start back until I hit “start”. I’m probably the only person on TR that this applies to tho : )

You can stop and save your workout. After getting on the new bike, go into the same workout and select resume on the “…” menu.

Can’t you just deselect the “pedal to play/pause” option? (It’s an option on the desktop app, not sure if it’s on mobile)

Thanks @mcneese.chad; I’d missed that thread but unsurprised the issue’s been raised before.

I’d agree with the views expressed in that thread: this looks like a deficiency/(bug) in how TR constructs the PR plot, as there are commonly-occurring circumstances in which the PR plot will be materially incorrect.

Maybe it’ll be addressed in the future some time…

For now, I’ll try to put comments against the Workouts in which I’ve paused so I’ve a chance at least of spotting that the w/o’s numbers are overstating things. Not ideal but hey.

1 Like

This isn’t a TR specific issue. WKO4 and GC also have the same issues and there isn’t a great way to handle it.

Exclude the PR if it bothers you.

3 Likes

I believe it could be solved programmatically, as TR is able to record the pause length so would have the data to work from. It’s a design decision not to do so. I can understand that, even though I don’t like it.

As I explained up-thread excluding isn’t really an answer as it leaves a hole in the data.

Is there a stop button? I’m on a tiny iPhone 6 w 51 year old eyes. I can barely find the pause button!

There is not a “Stop” button, but after pausing, you can close/finish/end the workout (not sure on the exact wording).

1 Like

I don’t think standard file formats, such as .fit, allow flags so I’m not sure TR could do this & still remain cross-compatible.

You can see it on review though; there’s a sudden drop in Heart rate. Don’t know if their software could do similar though. Can imagine some intervals with dodgy HR straps would get excluded by accident though.

Can’t remember how TR handles power drops too. Those are annoying in the opposite direction if they aren’t real. Can’t remember them happening during TR sessions, but they’ve definitely been in imported data. In a similar way if Cadence is maintained I’d prefer they just interpolated with a straight line if they knew the zero wasn’t real.

I didn’t envisage it would require any flags: just let the time axis expand for the duration of the workout pause, capturing any work done if still pedalling (like in my 2nd example in the original post), or 0w if back pedalling.

It would require the UI during a workout to be a little more dynamic than currently in order to expand the time axis in real-time during a workout pause, but this is just a more complex form of what already happens if you extend warm up or cool down at the start/end of a workout.

I’m sure there’s a whole bunch of stuff I’ve not considered, as my knowledge is superficial, but “on the face of it” it would appear doable if there was a desire.

I used to be a software engineer and my eye for detail and accuracy means I wouldn’t be fully happy with the way it currently works as it commonly leads to somewhat overstated data, ie. the flaw that I and others have raised isn’t an obscure edge case rarely encountered but a frequent, normal occurrence. I’d want to address that if it could be done, pragmatically, without requiring too much additional complexity :wink:

It is a specific TR issue in that the downloaded file from TR doesn’t reflect the actual ride in the same way any other head unit does.

I can’t speak for WKO but I do use GC and it can only deal with the information it’s given. If the download file from TR doesn’t include the breaks then it can’t include them in the data and will inaccurately reflect the actual ride, especially if those breaks are in the work intervals as in the case of the OP.

Conversely the same ride imported from a separate head unit does include those breaks so GC (and maybe WKO?) can work with that data and is an accurate representation of actual ride.

I hear your pain, AldridgePrior. I have the opposite problem, which leads me to suggest a possible solution [work around].

I use an Elemnt Bolt for head unit on outside rides. It is sync’d to Strava, and pushed to TR. This means that every little stop – traffic lights / puncture / lunch / coffee is elapsed time as far as TR is concerned. That is time at 0 watts. This means that my average power on outside rides is generally low - eg. about 0.5 of FTP. I could edit the stops out on GC, but that’s a pain I cannot push myself through.

Anyway, so this suggests the workaround.

  1. Record your ride on TR and on a separate head unit.
  2. On Calendar, delete the TR record of the ride [you need to do this because TR will not allow you to have multiple rides starting / finishing near the same time. You cannot have two separate rides that overlap!
  3. Import the record of your ride from the head unit into TR.
  4. You should now have a record that has elapsed time and power, rather than program time and power. This will enable you to do what you want with the power curve.

I hope that this helps…

That’s a good suggestion michael, thanks, but I’m low-hassle so too much faffing for me to do that each time. Never mind!

Regarding your issue, that stop time or freewheeling time is recovery time, so excluding it from your average power numbers arguably would be misleading…

I don’t possess all the facts to comment properly, but I would’ve guessed that if you had auto-pause enabled on the Bolt, those stopped periods would be excluded from the elapsed time used in calculating averages, while still capturing free-wheeling recovery time, but I’m just guessing! Is that not the case? I’ve no idea just posing the question if you’ve not already explored this avenue…

Also, the Bolt has a toggle setting (in the app) to “Include Zeros in Average Power”, but I assume (guessing again!) that just impacts the displayed value on the Bolt and so irrelevant to 3rd party sites that process the data file, ie. probably no help to you…

If you stop pedaling it pauses. If you backpedal it doesn’t but your power is 0.

When I need a break I backpedal, the interval continues to count and when I recover enough I pedal and I register power again. At the end the intervals that had backpedaling have a lower average power than those that I pedaled the entire time. Lower averages mean no PRs.

As @AldridgePrior says this is how it should be with zeros included in both outdoor and indoor rides. Each of the stops you have is rest and should be accounted for.

If you were doing the intervals described in the OP outdoors as part of some hill reps and coasting back down for recovery, you would be somewhat inflating your realistic power numbers by not including all the rest time which is one of the features of the TR ride file.

This depends on the Pause setting in use in TR (On/Off) and the device used for cadence. Some (like power meter pedals) know if they are pedaling forward or backwards, and will act differently as a result.

The options and combos make this far more complicated than we might expect it to be.