-
-
Notifications
You must be signed in to change notification settings - Fork 22
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
WIP: Fix/linear pwm adjustment #267
WIP: Fix/linear pwm adjustment #267
Conversation
Once i find time, i would like to change this PR to:
|
…ional new feature
# Conflicts: # internal/controller/controller.go
…tructs in config, refactor control loop logic, rename "simple" to "direct"
…ld prevent users from disabling it entirely
Hey @jwefers ! As you might have noticed, I have invested some time into finishing this up. Would you be able to test the PR in its current form? |
wow, i lost track of this...i became a parent :D i'll let you know once i find some evening time to game and test it out :) thanks |
Haha, congrats! 😄 👶 |
I have been running and testing this branch extensively for the last days, so I think I feel quite comfortable merging this now. |
Addressing #266
This throws out the PID approach, instead linearly approaches the desired fan speed, capped to x amount of change per second. On my system, it feelds solid and not unpleasant.
Work is needed in understanding why the scaling into a window of possible (still-rotating) fan speeds is needed, as this is not really hidden from the user when they are supposed to give a step function themselves.
I understand the idea of staying within supported min and max, but i think it defies expectations when still having to give 0-255 for desired values. Maybe percent is better then. Let the user give fan speed percentage values with internally map in between min and max supported. Maybe even raise the min boundary to lowest-still-spinning when neverStop is set. But it should be made transparent to the user what happens with their values internally.