search

ptx2 / gymnasticon

Make obsolete and/or proprietary exercise bikes work with popular cycling training apps like Zwift, TrainerRoad, Rouvy and more.
https://ptx2.net/posts/unbricking-a-bike-with-a-raspberry-pi
MIT License
299 stars 39 forks source link

Remove phantom pedal strokes. #35

Closed jeremydk closed 3 years ago

jeremydk commented 3 years ago

If the last cadence received by gymnasticon is non-zero, we continue to fire off phantom pedal strokes (which continuously reset the pingInterval). We can remove the pingInterval resetter from onPedalStroke, and force the cadence to zero if we receive a ping request (i.e. no stats received in the last second).

I've tested this from my Peloton and all looks good, but would need to have someone validate the flywheel behavior.

This should address https://github.com/ptx2/gymnasticon/issues/32

ptx2 commented 3 years ago

Just gave it a try on the Flywheel bike. I did notice something that might need a look into. It seems possible to get in a situation where we stop generating pedal strokes depending on the timing of ping interval and stats events.

It's possible to reproduce with the bot like this:

gymnasticon --bike bot --bot-power 60 --bot-cadence 50 --bot-host 127.0.0.1 --bot-port 3000

I think the issue is with setting simulation.cadence to 0 periodically.

I realized there is actually a timer in there to handle this already but I made a typo so it's not actually firing ;-) If you rename opts.bikeStatsTimeout to opts.bikeReceiveTimeout in the statsTimeout Timer initialization, it will bail shortly after the bike stops sending data, the idea being that systemd will restart it. I pushed up a change which uses that timer to fix the immediate problem but there's an unsolved problem I'm running into where if you exit a ride and re-enter, Zwift appears to require you to manually rechoose the power/cadence sensors before they'll work again. Out of time for today but I pushed up what I have so far here: https://github.com/ptx2/gymnasticon/compare/peloton-stats-timeout

ptx2 commented 3 years ago

Ok I just reverted those changes and pushed up something different to that same branch. It just sends the app a single zero stats event after the user has left the ride. I've tested it a bit here and looks good -- what do you think?

jeremydk commented 3 years ago

That proposed change makes sense to me -- scopes us just to the peloton, and uses the fact that the serial connection is very chatty, so a 1s timeout makes a lot more sense. Wasn't a fan of letting systemD flap the service -- it would work but it felt a bit off to me.

ptx2 commented 3 years ago

I wasn't a huge fan either :-) I'll go ahead and merge that in. Thanks for the help finding and fixing this!