My issue is inconsistent, which is fairly annoying. Sometimes it’s 2 seconds before, sometimes 1 second, sometimes it’s late. Similar thing happens on the exit. It sucks because I have to be ready 2 seconds before just in case so I don’t get caught off-guard, but I also don’t want to assume it starts because I may start spinning off the cliff. My suspicion is that Zwift has gotten bloated enough that it’s taxing CPU or other resources and the PC isn’t able to task switch enough for Trainerroad to poll the trainer on time. I may try to prove that by running swift on the ipad one time.
For those looking at the slightly delayed start, are you seeing a similar delay at the end?
If so, you are essentially getting the full interval length, it’s just shifted a second or two. That’s been my experience, as long as I keep on the juice thru until ERG releases.
My issue is inconsistent so the start delay does not always match the end delay likely because of what I believe the root cause to be. Not to mention I can’t predict the start or the end, which makes things tricky.
I’ve been dealing with it since before i started this thread, so it’s not a showstopper, but isn’t ideal.
1 Like
I’ve only just see this thread…
I have a Neo 1 and noticed this change of behaviour manifest at exactly the same time that I switched to using the Android Beta app ( now Production) a couple of months or so back. Considering the precise timing of the behaviour change, I naturally assumed the change was intentional and was due to revised code within the new app, so am very surprised to read that this isn’t the case.
I’m doubly surprised because I’ve not updated any firmware on my Neo since forever, and my setup (eg. Android device, connection method) hasn’t intentionally changed at all, so it’s hard to see what else could account for this new behaviour other than the TR app. 
As far as I’m aware (ie. I’ve never noticed otherwise, and I think I would have if it happened), my Neo is consistent with the way it behaves regarding ramping into / releasing from intervals, with just a step change coincident with my switch to the new Android app:
- it used to (ie. for the previous 3 years) always always feel like it was beginning to ramp the resistance slightly before the interval start timestamp and then release it slightly before the end timestamp.
- then for the past couple of months or whatever it is (since I began using the new Android app), it always feels like it’s doing the resistance changes right on the timestamp.
Time spent in the work interval is identical, just feels like it’s all shifted later very slightly. It isn’t a problem, just a slight change in behaviour, which once I got used to - which has actually taken quite a while considering it’s such a minor thing! - it makes a little more sense to me than the previous behaviour, but both approaches were/are fine for me.
Same here. I noticed it immediately when the new app was released (NOT the beta).
I’m using the Tacx Neo (original one) as well and prior to the new app (with the old mobile app), it always worked flawlessly at 2s before the interval.
Not a big deal though since the interval stays the same length, but after years of being used to having to up the cadence a little before those 2seconds because you hit a wall sometimes, well, it’s a bit of a mindset switch now…
So something must have changed, that’s for sure 
Yep, the fractionally delayed start to an interval doesn’t seem to compensate for the (same) fractionally delayed end to the interval - despite the total work interval duration being the same. All in the mind of course 
, but I also had become long accustomed to the resistance feeling like it was being released a couple of seconds before the mark and now find that final couple of seconds “extra” ( not actually extra) work psychologically hard.
Old style (old TR Android app):
ㅤ
New style (new TR Android app):
Exactly this for me also. @IvyAudrain If there is no intentional change in the code itself (?) it might be a change inside the used framework from classic to new app…it could be that the electron framework (of the new apps iirc) or a following library handles ant+/Bluetooth communication differently…?
Either way…new behavior is ok for me.
There could be some differences between the previous and latest mobile app since we’ve done some work that changes how we connect to devices. There shouldn’t have been any changes on desktop versions, though. If you think something is amiss, as always feel free to reach out to support@trainerroad.com and we should be able to get you back on track. 