Fan Control
- Thread starter ooooooo
- Start date
I guess you are tried to do this in hardware, programming the fan controller directly? A fast solution is to read CPU temp, and have the fan setting (fan slider in fan control) adjust automatically in HWiFO software ( I would keep HWiNFO minimized, or you can make it a separate utility maybe) . Can you implement that feature please?Martin said:
The fan controller chip has an internal table with temperature value thresholds and corresponding fan speeds which is applied when that level is crossed. Doing this manually in HWiNFO32 is not a good idea, since software can freeze or crash and in such case you would completely loose the fan control and the system might run above thermal limits without sufficient cooling.
ooooooo said:
Does this help you?
<!-- m --><a class="postlink" href="http://www.smsc.com/media/Downloads/Application_Notes/an174.pdf">http://www.smsc.com/media/Downloads/App ... /an174.pdf</a><!-- m -->
It shows RPM to TACH conversions. It also has TACH-RPM lookup tables.
Update:
I found the full SMCS 2113 datasheet;
<!-- m --><a class="postlink" href="http://download.siliconexpert.com/pdfs/2009/10/24/8/42/45/521/smsc_/auto/2113.pdf">http://download.siliconexpert.com/pdfs/ ... o/2113.pdf</a><!-- m -->
See page 29: Programming the Lookup Table
I hope that helps.
<!-- m --><a class="postlink" href="http://www.smsc.com/media/Downloads/Application_Notes/an174.pdf">http://www.smsc.com/media/Downloads/App ... /an174.pdf</a><!-- m -->
It shows RPM to TACH conversions. It also has TACH-RPM lookup tables.
Update:
I found the full SMCS 2113 datasheet;
<!-- m --><a class="postlink" href="http://download.siliconexpert.com/pdfs/2009/10/24/8/42/45/521/smsc_/auto/2113.pdf">http://download.siliconexpert.com/pdfs/ ... o/2113.pdf</a><!-- m -->
See page 29: Programming the Lookup Table
I hope that helps.
Thanks. I do already have those documents, without them I couldn't implement that fan control.
However the RPM is not a problem, it's the temperature representation in the LUT, which in this case is read in the form of PWM Input Duty Cycle that I don't know how to convert into degrees Celsius.
However the RPM is not a problem, it's the temperature representation in the LUT, which in this case is read in the form of PWM Input Duty Cycle that I don't know how to convert into degrees Celsius.
I had a program that did something similar with my Dell. I would set the speed for the temperature, the software would increase the fan speed. The bios / chipset (whatever) would slow down the fan again. Software increased the speed, system would slow it down again. Over and over and over...
Eventually the fan stopped working properly and the system frequently locked up / blue screened due to heating problems. Had to replace the fan and system board.
Eventually the fan stopped working properly and the system frequently locked up / blue screened due to heating problems. Had to replace the fan and system board.
I can think about adding some simple option to fix an issue, but giving the users too much control over the Temperature/Fan LUT (Look-Up Table) would be a bit complicated to implement and if not properly configured could cause damage. And this is something I don't want to be responsible for..
So after checking a dump from 8740w, the pre-defined look-up table looks like this:
1. If Temp Duty Cycle < 6.25% => 1650 RPM
2. If Temp Duty Cycle < 12.50% => 2300 RPM
3. If Temp Duty Cycle < 25.00% => 2700 RPM
4. If Temp Duty Cycle < 37.50% => 3230 RPM
5. If Temp Duty Cycle < 50.00% => 3510 RPM
6. If Temp Duty Cycle < 62.50% => 3510 RPM
7. If Temp Duty Cycle < 75.00% => 3510 RPM
8. If Temp Duty Cycle < 87.50% => 3510 RPM
Note that the temperature values are not in Celsius as I already mentioned, but in duty cycles of a PWM pin input. I have recalculated them to percent. The resulting fan RPM values are not exact and it seems that when trying to force the fan > 3500 RPM it won't rotate faster.
I can offer to make a simple change to the table, so now the question: what kind of problems are you experiencing with the default fan control logic ? As I have been told, it seems that the fans begin too late to spin faster (temperature too high already) ? If this is the case I could change a single entry in the table to force a higher spin rate at lower temperature. Check with current HWiNFO32 what rates do you have and how would you like to change the logic (like - change step 4. to 3510 RPM, etc).
So after checking a dump from 8740w, the pre-defined look-up table looks like this:
1. If Temp Duty Cycle < 6.25% => 1650 RPM
2. If Temp Duty Cycle < 12.50% => 2300 RPM
3. If Temp Duty Cycle < 25.00% => 2700 RPM
4. If Temp Duty Cycle < 37.50% => 3230 RPM
5. If Temp Duty Cycle < 50.00% => 3510 RPM
6. If Temp Duty Cycle < 62.50% => 3510 RPM
7. If Temp Duty Cycle < 75.00% => 3510 RPM
8. If Temp Duty Cycle < 87.50% => 3510 RPM
Note that the temperature values are not in Celsius as I already mentioned, but in duty cycles of a PWM pin input. I have recalculated them to percent. The resulting fan RPM values are not exact and it seems that when trying to force the fan > 3500 RPM it won't rotate faster.
I can offer to make a simple change to the table, so now the question: what kind of problems are you experiencing with the default fan control logic ? As I have been told, it seems that the fans begin too late to spin faster (temperature too high already) ? If this is the case I could change a single entry in the table to force a higher spin rate at lower temperature. Check with current HWiNFO32 what rates do you have and how would you like to change the logic (like - change step 4. to 3510 RPM, etc).
What I would like to do is change the fan speeds on the lower temperature settings.
So what you can do is read from LUT and make upper one or two values (7 and/or 8 in your example) unchangeable. This way you don't have to worry about anything bad happening, the system would be protected. And let the users change/experiment the lower values, both temp(PWM) and RPM. I don't know if everyone agrees, but that would be best for me. (Also, a setting to revert to factory settings would be needed. So you would have to read and store LUT settings before modification.)
Thanks for your work on this Martin.
tiker, I don't know which program you used, but I used i8kfan program on a Dell with no problems for years.
So what you can do is read from LUT and make upper one or two values (7 and/or 8 in your example) unchangeable. This way you don't have to worry about anything bad happening, the system would be protected. And let the users change/experiment the lower values, both temp(PWM) and RPM. I don't know if everyone agrees, but that would be best for me. (Also, a setting to revert to factory settings would be needed. So you would have to read and store LUT settings before modification.)
Thanks for your work on this Martin.
tiker, I don't know which program you used, but I used i8kfan program on a Dell with no problems for years.
According to feedback I'm getting there was a need to improve the thermal protection on these particular models due to the fact that the fans start to spin at higher rates when the temperature is already too high.
In practical that would mean: "Change 2. to 2700RPM and 3.&4. to 3500RPM"
I'd prefer to implement such a fixed change rather than universal modification which would take much more time to implement.
And btw, even if I would make any change to the LUT it wouldn't remain persistent - it would reset to default values upon new boot, so you would always need to run HWiNFO32 to re-activate such a change.
In practical that would mean: "Change 2. to 2700RPM and 3.&4. to 3500RPM"
I'd prefer to implement such a fixed change rather than universal modification which would take much more time to implement.
And btw, even if I would make any change to the LUT it wouldn't remain persistent - it would reset to default values upon new boot, so you would always need to run HWiNFO32 to re-activate such a change.
Non-persistent changes are even better. If anything goes wrong people can just restart.
The changes would have to be user configurable. Otherwise, I don't see how it would work on different systems. For example, on my system lowest RPM value is 3000 and highest is 7000. So any fixed value like "Change 2. to 2700RPM and 3.&4. to 3500RPM" would not be useful in my situation.
The changes would have to be user configurable. Otherwise, I don't see how it would work on different systems. For example, on my system lowest RPM value is 3000 and highest is 7000. So any fixed value like "Change 2. to 2700RPM and 3.&4. to 3500RPM" would not be useful in my situation.
Incredible work!
Please send a bill to HP
. If HP cared about it's customers it would have such a feature in BIOS.
Locking the settings for the extreme temperatures (number 7 or 8) would probably be better for the average or nontechnical user (but technical users and me will find it very useful), but other than that, great work. No other system information software has this capability! Thanks!
Please send a bill to HP
. If HP cared about it's customers it would have such a feature in BIOS.Locking the settings for the extreme temperatures (number 7 or 8) would probably be better for the average or nontechnical user (but technical users and me will find it very useful), but other than that, great work. No other system information software has this capability! Thanks!
What do you mean by permanent? In the above post on NBR I explained that a change remains until reboot, since the BIOS reconfigures the fan controller each time. So you should autorun HWiNFO32 with sensors after each boot to reload the settings again.
ooooooo said: