There has always been a bit of lag for steering. I had a steerzo, now the Rizer and it was the same for both no matter how what hardware I used to run Zwift. I’ve Tested using an Apple laptop, Windows PC, MS Surface pro, Apple TV, iPhone & iPad. Using combinations of direct connection using Bluetooth & Ant+ or connecting devices via companion app.
The Rizer is an incredible piece of hardware and experiencing gradient changes makes Zwift so much more enjoyable (as long as you don’t compare the gradient in the risers app to Zwift). It’s obvious that this isnt going to go away. If anything, I suspect more connected devices will appear in the market. I’m sure the development team at Zwift is hard at work on improving their Bluetooth API’s to handle the future of the IOT. Authoring standards for API’s that control attributes like gradient or windspeed would accelerate 3rd party company’s to make more gear for our pain caves.
If you make it (work), we will buy it… And then we will never have a reason to leave the platform for competitors like Trainer Road, Spinnervals or (
) Peloton.
The fact that gradient devices like the Rizer are laggy and that the gradient doesn’t quite match is really disappointing. There are times when, on rollers, the Rizer is still going up but in Zwift, I’m already on the decent… 2-3 seconds later Rizer catches up and drops down. This never happens when I am using a Surface pro connected to a Lifefitness or Woodway Treadmill for running. 3% in game running translates perfectly to the incline on the treadmill. I expected the same for the Rizer but that was not the case.
I’m really hoping Zwift enhances their API with a dedicated gradient attribute that can be read by devices like the Rizer, Kicker Climb and whatever else is in the pipe.
If this ever gets to the Zwift product owner, PLEASE give us 2 things:
-
A method for controlling timing of the gradient. Like a slider bar in the menu that allows us to advance or delay when the gradient signal is sent. That way if we have a device that is a bit slow to respond we can adjust Zwift so it sends the trigger to the device a few seconds BEFORE our avatars get to the virtual hill. This will obviously have to factor in speed too since a -2 second advance might work at 10 kph but it wouldn’t have the same effect of the avatar was going 40 kph.
-
It would also be good to have a few profiles to chose from that affect what is sent to the device. Something like:
A. “Baseline” 1:1 profile would ensure that a 2% grade in Zwift is a 2% grade signal sent to the device.
B. a moderate profile focusing on increasing the effect of smaller gradients but tapering off as the climbs gets steeper. So the modifier starts at 1:1.5 (2% in game sends a 3% signal to the device) but reduces down to 1:1 for any in-game hill >15%. This way flatter roads would be more fun and big climbs wouldn’t cause kill the effect.
C. The opposite of B, focusing on big climbs over flat roads. It starts at 1:1 but increases to 1:1.5 or more as the virtual climbs get steeper.
D. This one’s odd, but a profile that looks at the selected route and maximizes the climbing devices range of motion would be cool. If the user picks a route that has a virtual gradient range of 1-10%, and their device has a functional range of 1-20%, then the overall modifier should be 1:1.5. If the route has a max of 15%, then the modifier should be 1:1.3 and so on.
Just a few ideas that have been kicking around in my head while pedaling away in Zwift.