PID Fan Control #800
PID Fan Control #800
Conversation
|
IMO it would be safer to also keep the existing automatic fan control, and add a dropdown for which fan control algo to use, until we have enough testing data. There are so many different fan setups, heatsinks and environments out there, it would be a miracle if this works immediately on all devices. |
main/tasks/power_management_task.c
Outdated
| pid_set_sample_time(&pid, POLL_RATE - 1); | ||
| pid_set_output_limits(&pid, 35, 100); | ||
| pid_set_mode(&pid, AUTOMATIC); | ||
| pid_set_controller_direction(&pid, REVERSE); |
There was a problem hiding this comment.
Do we need these two controls? AUTOMATIC/MANUAL and DIRECT/REVERSE? They're only set once and with a hardcoded setting. Might as well just yank them, or are there plans to re-use the PID class for other things as well and we want to keep a more general version?
There was a problem hiding this comment.
- AUTOMATIC mode:
The PID controller continuously calculates the output based on the current input, setpoint, and tuning parameters. It actively adjusts the output to minimize the error.
- MANUAL mode:
The PID controller stops automatic adjustments. The output is either fixed or controlled externally. This is useful for tuning, testing, or when you want to override the PID temporarily.
- DIRECT:
An increase in input (e.g., temperature) causes an increase in output (e.g., fan speed).
Use this when the output should move in the same direction as the error.
- REVERSE:
An increase in input causes a decrease in output.
Use this when the output should move in the opposite direction of the error.
It is possible to add a dynamically mode change to it maybe in the future, I'm peeking into auto tuning functionallity. Therefore I would leave it in here for now
|
Please consider making the target temperature configurable instead of fixed 60°C. If you underclock you may wish to set a target temperature of 45°C and if you overclock a target temperature 70°C may be reasonable compared to the THROTTLE_TEMP 75°C. |
|
I'm running this on both my Gamma and Supra, the Gamma stays at 35% and 55°, the Supra at 100% and 65°. So not really a proper test, maybe later today when it gets warmer here I get more feedback. Agree with a configurable setpoint. |
I will add the configureable setpoint |
The plan is to test this extensivley and integrate this into 2.6.3 if this is save to use |
|
This is exciting to see my idea take shape 😬. Running it on my three today so should see it adjust as the temperatures rise. For me I'd like to see the minimum fan speed be reduced to 20% though as when ambient is cool as per my image, 35% isn't low enough. |
|
My three ran perfectly yesterday ran upto 100% fan speed as ambient rose and back down to 35% through the evening. I'd very much like the lower end fan threshold to be around 20% though. 👍 |
|
Is there a reason low end can't be 0%? |
Someone mentioned somewhere that not all fans modulate down to that level so if 15% was called for example the fan would actually stop but I don't see that as much of an issue as if the fan did stop the temp would rise and trigger it to start again at what ever level it works at. I'd prefer 0% to be honest as when I've been manually adjusting mine I sometimes need 9%. |
|
The fan on the supra I have only starts spinning at ~10%. On restart it takes a bit to get the temperature right, it overshoots about 5C until it comes back down to the set point: Maybe a more advanced way would be to do a calibration run on startup, see what the RPM curve is over the fan percentage, and then steer the PID based on desired RPM instead of fan percentage? |
No there is no reason why it can't be 0, I set it to 15 now I feel uncomfortable setting it all the way to 0. I think even a bit air flow shall exist. |
main/tasks/power_management_task.c
Outdated
| pid_compute(&pid); | ||
| power_management->fan_perc = (uint16_t) pid_output; | ||
| Thermal_set_fan_percent(GLOBAL_STATE->device_model, pid_output / 100.0); | ||
| ESP_LOGI(TAG, "Temp: %.1f°C, SetPoint: %.1f°C, Output: %.1f%%", pid_input, pid_setPoint, pid_output); |
There was a problem hiding this comment.
Also log power_management->fan_rpm. This will be useful when troubleshooting weird fan setups.
|
I ran a test with my Supra with crappy fan and heatsink, from a cold start, with minimum at 0%:
It takes about 100 seconds to reach peak temp of 65, and another 50 seconds or so to get it back down. This is in a warm environment, ambient temp was 27C. Even with a deadzone of 10%, it picked up the fan rpm quick enough to prevent too far of an overshoot. On the other hand, the Gamma I have on stock can be happy below 10%, it doesn't have a deadzone, it's the opposite: at 0% the fan still runs around 3000 rpm: So I would say the PID controller is absolutely capable of handling both scenario's from 0%, both run better with this and a lot quieter and stable compared to the old fan control. |
|
Not sure if me posting is useful but my three have worked well down to 20% so far. Not quite cool enough for then to call for 15%. If they weren't clocked so high they for sure would need a hell of a lot less fan. |
|
It seems to work well. However, I wouldn't set a target of 60°C, but rather 50°C. The reason for this is simple: if the fan runs just a little faster and can lower the temperature, the ASIC automatically consumes less power. Less power consumption = automatically lower temperatures. So you would optimize the process in both directions and on top of that, you would also get significantly quieter operation. From 65°C I would activate some kind of hard panic mode that sets the fan to 100% until the temperature drops back to 60°C. In my tests, the ASIC at 50°C uses almost 2 watts less, but as soon as you are at 50°C and use less, the temperature and fan speed automatically drop. With these processes, we would have covered all eventualities and optimized the process perfectly. |
|
In my testing yesterday with target set at 60 the temps overshot that because my ambient went upto 30+c. They were between 62 and 65 degrees with 100% fan speed. I belive if it hits 70c it shuts down so in my mind it kinda works how it should? |
|
On Gamma 601 I noticed that restart is required in order to apply changed target temperature setting. Any reason why changed target temperature couldn't be applied on the fly when saving settings as it works for changed voltage and frequency? |
Working on that ATM |
* pid init * feat: PID controller * fix: adjust PID setPoint temp * changed TPS546_get_iout() to read the combined current for both phases (bitaxeorg#796) * fix: include * fix: don't collect hashrate while in power_fault (bitaxeorg#804) * fix: raw ints to enums * feat: add ui target temp * fix: PID reduce min fan speed to 15 * fix: add openapi temptarget * fix: adjust default temp target * fix: adjust setPoint on the fly * add comments * fix: go back to 60 and set var instead of hard code --------- Co-authored-by: skot <140785+skot@users.noreply.github.com>
* pid init * feat: PID controller * fix: adjust PID setPoint temp * changed TPS546_get_iout() to read the combined current for both phases (#796) * fix: include * fix: don't collect hashrate while in power_fault (#804) * fix: raw ints to enums * feat: add ui target temp * fix: PID reduce min fan speed to 15 * fix: add openapi temptarget * fix: adjust default temp target * fix: adjust setPoint on the fly * add comments * fix: go back to 60 and set var instead of hard code --------- Co-authored-by: skot <140785+skot@users.noreply.github.com>
* pid init * feat: PID controller * fix: adjust PID setPoint temp * changed TPS546_get_iout() to read the combined current for both phases (bitaxeorg#796) * fix: include * fix: don't collect hashrate while in power_fault (bitaxeorg#804) * fix: raw ints to enums * feat: add ui target temp * fix: PID reduce min fan speed to 15 * fix: add openapi temptarget * fix: adjust default temp target * fix: adjust setPoint on the fly * add comments * fix: go back to 60 and set var instead of hard code --------- Co-authored-by: skot <140785+skot@users.noreply.github.com>
adds a PID controller