Fix ERG mode delay by adding a delay adjustment

So here’s the thing:

I use an Elite Direto and in ERG mode it takes a few seconds to adjust to new power targets. Depending on the type of connection I choose it’s between 2 and 5 seconds and it’s constant for each setup.

So I thought it would be great if there was something like a sync function so that the graph and resistance match. Similar to the track sync feature of e.g. VLC player where you can delay the audio track to sync with the video. By sending the new power target 2, 3 or 5 seconds earlier the resistance would change in sync with the graph.

2 Likes

Great suggestion!

TR already sends the power changes early - I’d say 1-2 seconds, you can see and feel it when doing harder intervals. But making it adjustable would not be a bad idea, some trainers are much slower to react to power request changes than others. Of course the ideal would be an auto mode, where TR ‘learns’ the reaction time of the trainer and adjusts the ramp accordingly… This isn’t far-fetched, most “intelligent” thermostats have this feature where the controller adjusts its demand lead time to ensure temperature hits the target at the requested time. Of course the time constant isn’t quite the same.

1 Like

Hey @unicyclist!

Thanks for the recommendation :slight_smile:

While this is not a feature on our current roadmap, there is an easy workaround that you can do today that will allow you to fine-tune the speed at which your trainer reacts. Gear selection plays a huge role in the reactiveness of the ERG mode, so if you are looking to speed up the response, go ahead and shift into an easier gear.

In other words, if you are in the big ring, shift to the little ring and some middle gear in the back.

By lowering your gearing, you are lowering the overall inertia in the system, which makes it easier for the ERG mode to execute the commands coming from TrainerRoad, and lowers the overall reaction time.

I will also pass on your feature request to the team for future consideration as we complete projects and Development Resources free up :slight_smile:

Cheers!

2 Likes

Hi,

thank you! I’m already in the lower chainring and also mostly in third/fourth cog. That definitely helps. What also helps for big effort intervals is switching to big chainring with the beginning of the interval - that way the time for the trainer to react is bridged with the increased resistance of the bigger chainring. With the downside of course, that the delay at the end of the workout is still there, so you need to switch back or work 5 seconds longer.

Anyway no huge issue, just a nice possible improvement!

If the rumors are true and you’re working on doing TR workouts outside and/or smart adaptation of workouts I’m totally fine if this issue gets a lower priority. :wink:

I like using my smart trainer (a Kickr) in Erg mode, but there’s a delay of 2-3 seconds at the start of an interval, where the power is usually low, before it settles in at the target power. I assume this happens to most people in Erg mode. Even if I use resistance mode instead, or using my old dumb trainer, it’s difficult to hit the target power in those first few seconds of the interval. This affects the average power for the interval, and the little ball thingy. Although that’s not a problem for longer intervals, it has a noticeable and annoying effect on the averages for microbursts and other short intervals.

I know I should ignore the little ball. I know I shouldn’t worry about the reported averages for each interval. I also realize the lag in the power drop-off at the end of the interval cancels out the lag at the start. Nevertheless, I can’t help but find it a bit annoying.

Could an option be introduced whereby the power averaging doesn’t begin right at the start of the interval, but begins after a few seconds instead? I don’t think we need to see the little ball in those first few seconds, and I think it would be better if the power from those first few seconds is ignored in the averaging process.

1 Like

This was touched on previously in this thread in terms of tips for addressing that delay, but I’m passing along to the team that we have another request for this feature!

Note that the power not being quite at the target for the first 1-2 seconds of the interval is also compensated by the power not being all the way down in the first 1-2 seconds after the interval is over. In other words: we tend to agonize over data details that have really limited impact in real life. Imagine doing those intervals on the road, your power curve would not be perfect either.

Thanks, yeah I’ve noticed that, that ERG mode reacts quicker in a low gear. However, I tend to do my training in a gear that’s appropriate for the events I’m focusing on, so if I’m training for TTs and crits, I want to do most or all of my training in a high gear with fast flywheel speeds to simulate the high inertia riding and pedal stroke feel of those events.

1 Like

Yes, I understand about the delay being compensated at the end of the interval, and that’s something I tried to mention and acknowledge in my second paragraph.

The delay is not affecting the quality of my training, and on that basis you could reasonably say that it’s not worth worrying about. On the other hand, if we accept it’s only a problem of syncing the period of stabilised power with the interval timing, the TR software should not bother to show me power averages for the interval, or the little ball either, if those averages aren’t correctly reflecting the period of time where the trainer is settled in at the target power.

If TR is sending the target power to the trainer 1-2 seconds earlier, as mentioned in an earlier post, then that shows the software developers already think it’s important to have the load generated by the trainer nicely synced with the interval start time. I accept that’s difficult to get right though, because it’s trainer-dependent and gear selection dependent.

My suggestion, to throw away the first few seconds of power data (only for the purposes of average power data) I think would be an easier alternative. It’s the first thing I would modify if it was my software, because I imagine it’s just a few lines of code that does the averaging and controls the ball. It would fix something that is a little bit annoying, to me at least, at quite low cost.