Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i-Magic - Improve run off procedure #147

Closed
cyclingflow opened this issue Nov 20, 2020 · 6 comments
Closed

i-Magic - Improve run off procedure #147

cyclingflow opened this issue Nov 20, 2020 · 6 comments
Labels
enhancement New feature or request implemented

Comments

@cyclingflow
Copy link

Due to all calibration work, i regularly apply the runoff procedure, and encountered some minor issues:

FortiusAnt selects powermode for the runoff. This might be a good idea for the fortius, however, for the 1901 brake I do not see why you would want to make starting the wheel harder, as well as change the resistance constantly during rundown.
The last also implies that runoff values are dependent on calibration factors, which i would like to avoid.

So, i have implemented a change in my fork, such that when the 1901 brake is selected, it switches to grade mode for the runoff.
I am currently experimenting with the lowest resistance level for the runoff, reasoning that we only want to measure tire/wheel resistance and flywheel effects, not brake effects.

@cyclingflow
Copy link
Author

cyclingflow commented Nov 20, 2020

Furthermore 3 minor convenience issues:

  1. Max Speed: I prefer a lower max speed. 40kph requires gearing up to largest blade on my triple (26inch wheel), which i like to avoid. 30 is the original tacx maximum. Currently I use 36.

  2. Over the years i have regularly find myself wondering, did I cleanly stop pedaling in time? I propose a change such that
    after reaching the max speed, the program signals STOP PEDALLING, and then after a slight further dip say 2kph (40-2=38kph),
    the programs starts measuring and tells you so.

  3. Minimum speed. I have noticed several times that the behavior of the wheel just before stopping is inconsistent (may be smudge or something), which made be start wondering if stopping measuring slightly above zero speed would be better.

Anyway, I implemented these changes in my fork through an additional command line argument, such that normal program behavior is not changed, but you can specify a different runoff procedure to your liking.
-r(maxSpeed,dipSpeed,minSpeed,targetTime)
the last parameter simply displays your target time needed to get consistent results across sessions.

@WouterJD WouterJD changed the title run off procedure iMagic - Improve run off procedure Nov 20, 2020
@WouterJD
Copy link
Owner

WouterJD commented Nov 20, 2020

Good ideas. I suggest to get the powercurve right first and then pick-up all other suggestions to create an i-Magic release

@WouterJD WouterJD changed the title iMagic - Improve run off procedure i-Magic - Improve run off procedure Nov 20, 2020
@cyclingflow
Copy link
Author

Working hard on it, requires quite some testing. But close to release.

@WouterJD
Copy link
Owner

I see it; I'm studying your code now

@switchabl
Copy link
Contributor

Found this only now. This is already very close to what we need for the rolling resistance calibration. Basically:

  1. Set brake to lowest resistance (not grade or power mode)
  2. "Pedal at X km/h"
  3. "Stop pedaling!"
  4. Wait for speed to drop below Y km/h, then start timer.
  5. Wait for speed to drop below Z km/h, then stop timer.
  6. Calculate estimated rolling resistance value from time and display that (also maybe display "warning: too high" or "too low" if we can decide on a sensible range)

We will need some more data eventually to decide on a) good values for X, Y, Z b) the formula to use for time -> rolling resistance, but that test protocol will be a lot shorter and simpler than for the power curve.

@WouterJD WouterJD added enhancement New feature or request under investigation Being studied for implementation in next version implemented and removed under investigation Being studied for implementation in next version labels Dec 16, 2020
@WouterJD
Copy link
Owner

Implemented in Version 4.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request implemented
Projects
None yet
Development

No branches or pull requests

3 participants