How is ERG mode working from a software point of view?

Does anyone have any insights on how ERG mode is implemented from a software point of view?

I’m assuming it goes like this: TR (or any other client software) says to trainer: give me 250 watts. Trainer goes and implements 250 watts.

But what is the follow-up process? Does the trainer store this value until it gets another signal from the software to alter the watts to a different number? Is the client software doing any monitoring in any way (dude, you’re giving me too much watts! Adjust please!). Perhaps different client software implements this differently (potentially causing weird interactions with the trainer-software)?

Another interesting question is how the feedback loops inside the trainer work. Do they operate on a second-by-second scale, or look at power in the last 30 seconds… but I guess we can’t know about those in light of ‘company secrets’.

Here’s an in-depth explanation of Powermatch, Erg mode works on the same principal just minus the additional power meter.


The first part of your question, the loop between the app and the trainer, is standardized in the trainer protocols of ANT+ and BT. Indeed the app gives a target, and lets the trainer go. The app also receives the current power output from the trainer, so it has the means to indicate that the trainer is or isn’t able to match the demand; TR displays a power bar that changes color, for example. But there are no further commands that the app can give to the trainer regarding its ability or not to match the power demand. I believe the power target is broadcast continuously by the app, I’d have to check the specs to make sure, unless we have a resident ANT+/BLE expert on hand.

The second part of your question, the « inner loop » if you want, is proprietary to the trainer manufacturer, and is implemented in the trainer firmware. One can observe the differences between trainer models in how fast and tight that loop is. One can assume that the control loop uses a filtered power signal to avoid reaction to noise.

1 Like


You can make a career out of it.


I had actually written PID in that response, but decided against over-geeking it.

1 Like

If you want to look up technical details, you can look at the ANT+ FE-C protocol. As for how the trainer works, that’s control theory. :slight_smile:

Does the difference in the power reported between a smart trainer and a power meter matter in the implementation of Powermatch? ie Do you get a better experience with it the closer they are, or does it not matter?

No! PID is fascinating stuff! :joy:

Powermatch introduces a 3rd control loop - the app reads the powermeter output, compares it to the power output from the trainer, and adjusts the demand to correct any offset. To get a stable system, this loop must act slower than the trainer one (changing resistance to meet power demand), and slower than the cyclist’s variations in cadence. Therefore, the larger offset between trainer-measured/estimated power and powermeter measurement, the more this 3rd loop has to do, and since it does it slowly by design, the more potential lag between a power demand and everything settling at the right point. In other words: power matching will be faster if the offset is small, more laggy if the offset is large.

You know what would be absolutely awesome? Some ai built into trainer, to avoid messing up the pid loop as the workout progresses. Many times i feel like dorito wants me to to fail when im tired or God forbid do quick out of saddle during threshold. I predict killer feature like that by 2020.

I often wonder how much better these smart trainers would be if they used cadence sensor inputs and made adjustments for eddy-brake loads outside of minima/maxima for target load. However, avoid the “death spiral” or whatever we call it when we break down and can’t maintain cadence sometimes keeps my legs going through the interval.

Usual transmission frequency for BLE hardware is once per second, or there abouts. Eg the trainer sends a signal once every second of the power currently being generated.

I’d imagine most apps use receipt of this once-per-second transmission from the trainer to then trigger a communication back to the trainer with target power. It’s possible the app also has an internal independent timer that triggers a communication of target power to the trainer, but seems like this would add some unnecessary complexity as the difference between the two timers would be a max of one second.

The trainer then uses its PID algorithm to adjust actual power to target.

I don’t know much about ANT, but I think ANT may send data more frequently.

Yeah, I’d imagine tuning of a system like this for a trainer is tricky - get fast response, but avoid the death spiral. Not easy to do I’d bet.

1 Like

Thanks. Intuitively I thought that might be the case but didn’t know.