Curve based on rpm

[notEvil]

Hi,

I'm wondering why the fan pwm -> rpm curve isn't* used for control curves. It would be nice to set (temperature, rpm) steps instead of (temperature, pwm).

As a sidenote, pwm -> rpm is sometimes non-linear, but rpm -> air volume / time approximately is

* except for scaling

[markusressel]

Well on the one hand the automatic RPM mapping still has some weird edge cases sometimes, which is why manual rpm curve editing needs to happen first imho. On the other hand I didnt start working on it, because the pwm based algorithms worked good enough TM for my use cases. Thats not to say I dont like the idea, I just havent had the need to actually do it.

[notEvil]

Thanks, for my "use case" (want to set temperature, rpm pairs for the steps and don't mind non-linearity) it would be sufficient to have a command which looks up the curve at a certain rpm and returns the corresponding pwm (scaled to 0 .. 255 for direct use).

And regarding edge cases, are they real? I mean, if the curve isn't monotonic at some point, it should only be in a small region. If this is the case, then the inverse would yield a reasonable close value.

[notEvil]

I changed a few things and it works quite well

• fanController.calculateTargetPwm: return immediately after f.curve.Evaluate()
• fanController.UpdateFanSpeed: create inverse of fan.GetFanCurveData and call util.CalculateInterpolatedCurveValue
• measureRpm: don't update the fan curve data

Without the last change it behaved strangely. I guess my fans don't respond fast enough, so fast changes in pwm introduce wrong pwm, rpm pairs.

[notEvil]

Hi again,

because you mentioned edge cases and such, I wanted to share my experiences:

• on my system, with continuously increasing pwm, the rpm readings are significantly below convergence, and with continuously decreasing pwm, the rpm readings are significantly above convergence
• with a few convergent (pwm, rpm) pairs*, slightly adjusted**, second order spline with fallback to linear interpolation should approximate the curve well enough
  • see the html and class Interpolator at https://gitlab.com/notEvil/fncntrl

* I used 7 pairs; median rpm out of 21 readings, 1s apart
** for instance, average pairs at negative slopes

GitLab

!evil / fncntrl · GitLab

GitLab.com

[markusressel]

Thx for sharing your research, definitely sounds interesting, although I would have to look into some of the technical terms you used to get a deeper understanding.

[Pachin0]

I would also like to have this feature. My server fans for some reason don't output RPM values but do respond to pwm control just fine. If rpm is a direct function with pwm, can't we just make the curves with that adjustement?

[markusressel]

@Pachin0 While I understand your desire for this feature, I would question the value of a PWM to RPM mapping if no RPM sensor is available. Without the ability to accurately measure the fan's speed, it would be difficult for fan2go to ensure that the fan is operating within safe parameters. Additionally, the relationship between PWM and RPM can vary based on factors such as airflow restrictions. The whole point of RPM based curves would be to eliminate this and let fan2go automatically adjust the PWM value until the fan is spinning with the desired RPM. This requires the presence of a RPM sensor though. Also, If you do not have access to RPM data, you would need to manually figure out the PWM to RPM relationship and pass it to fan2go, which would be really cumbersome. It may be more beneficial to investigate why your server fans are not outputting RPM values.