Thinking about making fan controller... need input

[joesgarage11]

Great plan, Dutch2. Sounds like you've got quite a project there. Have you done much electronic design?

I use a couple of temperature controlled fan controllers. The one on my regular computer is a slightly modified two channel version of the circuit Gooserider is planning without the DigiDoc.

As an interim solution, I'm planning to make a hybrid solution that uses a DigiDoc as a front end, driving my fans via a thermistor controlled FET voltage regulation ckt. (here: Fan control ckt) I think this will let me have fans that turn on and off with variable speeds as needed, and still give me rpm readouts.

It is working very well with one thermistor hanging in the case that controls a fan on the power supply, and the other thermistor in the fins of a Zalman passive heatsink on the video card that controls a fan blowing on the video card and hard drive.

For a software solution on my server I use SpeedFan, a free program. Check the web site to see if your motherboard is supported.

[Gooserider]

The temperature readouts would be selectable in C or F and there will be two different sensors, one for 10C to 100C, and one for -40C to 125C. You hook one up and select in software which one it is.

Seems reasonable...

Resolution will most likely be 0.5 or 1 degree C for both sensor types. Accuracy is determined by the sensor will probably be something like +-2C or +-3C. If I can find a more accurate sensor that does not cost an arm and a leg that could become an option too. Products like the ADM1027 that are used on a motherboard have a similar accuracy. Ones that use a NTC are probably worse.

Hmmm... I could live with that, but my instinct goes against having a display that shows more 'accuracy' than the sensor is capable of...

For as far as LCD layout goes, I was thinking about making it totally user configurable. The only thing I haven't figured out yet is how to store the configuration in the microcontroller.

That sounds good, probably better than trying to do a 'one size fits all' approach.

By the way, I have RPM measurement working and I was thinking about what Gooserider said about truncating the RPM display... Do y'all think a 100 RPM display resolution is OK? In other words it would display 2400 or 2500 RPM, not 2434 or 2482 RPM. I'm measuring it way more accurately, but do we really care?

100 RPM resolution is fine, I don't think there is much to be gained by going to a more precise count.
However, that isn't quite what I meant by 'truncating' the display - I was thinking more in terms of displaying '24' instead of 2400 (or 2434). I don't THINK anyone would be running a fan at less than 100RPM, and it doesn't seem to me like there is a huge amount to be gained by drawing the extra 0's if one could instead say 'RPM x 100' the way most tachometers do. (Of course that implies the first sort of truncating as well, but...)

Gooserider

[Bat]

Sounds good, Dutch2. Being able to update the firmware in place is a great advantage.

As for the voltage-out is concerned, obviously there's no need for it if the control stuff is being done by the microcontroller.

Do you think it's worth having a control loop for varying the pulse-width to get the desired fan speed, or would you just assume that speed would be proportional to puse-width? I expect it would only make a difference at very slow speeds, where it might be necessary to keep adjusting the pulse width to keep the fan turning. Possibly at those speeds the speed measurement wouldn't work reliably anyway; see this thread.

I don't think a generic one-size-fits-all set of constants for the control loop(s) would work too well. Consider two extremes:
1. A graphics chip with a small (therefore small heat capacity) heatsink, which needs a quick response when someone starts playing a game, and will react quickly to changes in fan speed.
2. A water-cooling system in which the water temperature will only ever change very slowly in response to system load and radiator fan speed, so the fans should also be adjusted slowly.

Ideally the controller would be able to observe the system's behaviour and learn the best way to behave, but I don't think it would be realistic to attempt that.

Those settings need to be configurable, but perhaps a reasonable and safe default would be something that gives a fairly quick rise in fan speed and a rather slow fall. That asymmetry adds complexity though.

[Dutch2]

I'm starting to think that RPM measurement is just for user entertainment, and not needed for the operation of the controller.

Whatever control algorithm the controller uses, if the temperature goes up, it will spin the fan faster. If the temperature keeps going up, it will make the fan spin even faster.
If the heatsink and fan are dimensioned correctly, the whatever faster speed will cool the part down to whatever temperature you are looking for, causing the controller to slow the fan down again.

What we are *really* interested in is that the controller spins the fan as slowly (quietly) as possible to keep the temperature where we want it.

It's probably good to be able to see that at idle it only takes something like 30% fan power to keep things cool, and 80% at full load. In other words, "required fan power", not fan RPM, is what really tells us what is going on.

The PID control loop got me thinking... to keep things simple and easy to understand & adjust (=user friendly), maybe the we should just adjust the fan power increase and decrease rate based on the temperature increase and decrease rate.
In other words, if temperature is rising quickly, increase the fan speed quickly. If the temperature is rising slowly, increase it slowly. Same for temperature decrease. Those two factors would be adjustable. That combined with a temperature where fan is off and temperature where fan is full on may do the trick?

Okie, now for RPM measurement. It is true that it will not work reliably with at low speeds because there isn't enough 'PWM on time' to look at the fan's current pulses. Not much I can do about that though.

My thoughts for the day

D2.

[Gooserider]

I'm starting to think that RPM measurement is just for user entertainment, and not needed for the operation of the controller.

You are quite probably right - I would like to know how fast the fans are spinning, so it is 'entertainment' to some degree.

Of course I'm not 100% insistent on RPM info, though others might be. I could be persuaded to accept some other performance indicator that gave an equivalent sort of info.

Whatever control algorithm the controller uses, if the temperature goes up, it will spin the fan faster. If the temperature keeps going up, it will make the fan spin even faster.
If the heatsink and fan are dimensioned correctly, the whatever faster speed will cool the part down to whatever temperature you are looking for, causing the controller to slow the fan down again.

I'm assuming that you will have some sort of negative feedback, anti-hysterisis, or other damping circuitry / software so that the fan speed will stay fairly constant rather than 'hunting' up and down. To the extent that the fans are audible, a frequent change in noise might be more irritating than a slightly louder but steadier pitch. As mentioned earlier, this wouldn't be as big a deal on a WC system which will do a pretty good job of temp averaging itself, but it could be an issue on an AC system with a smallish HSF on a chip that did alot of major temp changes (GPU?)
Perhaps it might be feasible to use some kind of 'moving average', especially on the ramp-down (say 'ramp down based on the average temp over the previous 5 minutes, while ramp up is based on the previous 2 minutes') so that the speed doesn't go up and down in response to temperature spikes, but rather does a gradual shift. (But also need some mechanism that will respond quickly to major temp jumps - include an override that speeds up the fan quickly if temps get more than say 10* over the current average?)

It's probably good to be able to see that at idle it only takes something like 30% fan power to keep things cool, and 80% at full load. In other words, "required fan power", not fan RPM, is what really tells us what is going on.

Hmmm... Would it be difficult to include that value as a possible output for either the LCD display, or the mobo via the serial port? It might be a useful thing to see, and could be especially handy for sizing fans - see what range was actually showing up and change fans to match it.

Okie, now for RPM measurement. It is true that it will not work reliably with at low speeds because there isn't enough 'PWM on time' to look at the fan's current pulses. Not much I can do about that though.

Not good but if that's the way it works we'll have to deal with it. Any estimate as to what 'low speeds' are in comparison with the speeds typically used by rheostat type controllers, or 'percent of fan power'? If 'low speeds' are equivalent to 4-5V / 30% (or more) it's a potential issue. If it is say 1-2V / 10%, then I don't see it as a real problem since it is unlikely we would want to run a fan that low anyways.

While I would prefer to see 'real' RPM numbers when they are possible, would it work to have some sort of 'calculated' number for display when they aren't?

Even if the actual RPM number isn't available, will the controller be able to tell the difference between a fan that is stalled and one that is running fine but to slowly to be accurately measured?

Gooserider

[silvervarg]

I believe there is a fundamental difference between doing internal or external mounting of a fan contoller.
If monted externally I would probably prefere to have it in a 5.25 bay. I would also want to have a display and a few buttons to interface directly with the device and I would love to have an USB port (since connecting to an internal USB port for communication could provice a front monted USB port with no extra cables). Producing of proper good looking monting stuff tends to drive costs quite a bit too.

The other way to go would be to have a less costly unit that is monted internally. This means no display, no buttons and no external USB, so I would not really care if connection is though USB or RS232, but I still like to have it with an internal connector cable (so you don't need cables going out of the chassi).

Adding possibilities for expansion and for good external mounting features will probably drive costs so high it will become too expencive for internal mounting. That's my 2 cents on internal vs external mounting.
From what I can see I think it is best if you make up your mind if it should be for internal or external mounting or possibly produce 2 rather different versions.
There are already quite a few options for external mounting (eg. Digidoc 5, simple knob controlled fancontrollers etc), but the market for internally mounted less expencive devices is not really covered (please correct me if I am wrong). It seems to be limited to really simple stuff like Zalmans FanMate and temperature controlled fans.

Next issue (that doesn't concern internal/external mounting)
When mounting something like this you will end up with lots of cabels in your case. Trying to minimize the number of cabels does quite quickly become a rather important issue. The smaller the chassi the more important. With window on the chassi it becomes really important.
By letting the software giving information about temperatures you will be able to get ridd of a few cabels (and probably get a much more accurate CPU temp reading). This would also cut costs somewhat.

[silvervarg]

If things does turn out the way I hope there will in 99% of the cases
be a real software running on the PC providing some information and to display all the details you ever wanted and some more.
This software should as mentioned before be written in a OS independend language (e.g. TCL, Java etc).

You probably only need to know the real fan speed of a few fans. By keeping these fans connected with the RPM signal to the motherboard we can eliminate any RPM sensing in the fancontrollers hardware. This is assuming the pulsed modulation of fan power doesn't make the RPM signals go crazy. The rest of the fans can have its speed aproximated by software. (Knowing the fans max-speed and the % of fanspeed the controller drives the fan with).

An earlier post had some discussions about getting stable fan speeds to get less irritating noice (note that this is not the same as less noice).
A rather complex algorithm was suggested, so here is my input to the algorithm. The main ideas is to get little fan speed variation, but still allow fast fan speedup when temperature starts to raise.
For each temperature we need to keep some history, so we store a few temperature samples (e.g. the last 5 minutes). For each temperature we calculate the max temperature over the last 5 minutes. Lets call this calculated temp CT. In addition to this we only let fanspeed decrease one "step" at a time, so we also store current fanspeed and check that one before we do any changes. This will be a real easy algorithm that lets speed increase very quickly when needed but it will take a full intervall (5 minutes) to start decreasing in temperature.
By decreasing fanspeed slowly it will be less noticable and less irritating.

There can usually be a lot of temp setting and corresponding fan speed setting that can be set. It is possible to set them on the low level, but I think that is something we should avoid. By using a software for configuration to set this low level values you can configure this real easy by setting desired and max temps instead for each temp sensor.
E.g. CPU desired temp 40 C and max temp 50 C
Motherboard desired temp 35 C and max 40 C
GPU desired temp 50 C and max temp 65 C
PSU desired temp 70 C and max temp 90 C
Fancontroller onboard temp 35 C and max 40 C
HDD temp 40 C and max 50 C
For each sensor it might be good to have a few additional values:
If sensor can't be placed properly (e.g. put on heatsink instead of actual die) it is good to have possibility to add a value to the temperature.
If sensor reading is not available (e.g. during bootup) each sensor can probably be simulated by choosing what other sensor and what fixed value to add to it. This will ofcourse not be really ideal, but by keeping a good margin it should work rather well.

From this example I would say we normally could do fine with just 3 temp sensors (plus one build onto the fancontroller board). Even though it is probably good if the fancontroller supports more sensors if it doesn't drive costs a lot.

[Jan Kivar]

There can usually be a lot of temp setting and corresponding fan speed setting that can be set. It is possible to set them on the low level, but I think that is something we should avoid. By using a software for configuration to set this low level values you can configure this real easy by setting desired and max temps instead for each temp sensor.
E.g. CPU desired temp 40 C and max temp 50 C
Motherboard desired temp 35 C and max 40 C
GPU desired temp 50 C and max temp 65 C
PSU desired temp 70 C and max temp 90 C
Fancontroller onboard temp 35 C and max 40 C
HDD temp 40 C and max 50 C
For each sensor it might be good to have a few additional values:
If sensor can't be placed properly (e.g. put on heatsink instead of actual die) it is good to have possibility to add a value to the temperature.
If sensor reading is not available (e.g. during bootup) each sensor can probably be simulated by choosing what other sensor and what fixed value to add to it. This will ofcourse not be really ideal, but by keeping a good margin it should work rather well.

The idea is to avoid using software control. Software should only be able to monitor temps/RPMs etc., and to set new variables to the fan controller (temp limits/fan speeds etc.).

You could pull out the motherboard's sensor values via SMBUS, but it's not accessible in all MBs (that is, at HW level).

I'd like to have one "master" sensor, placed outside the case. Then, I'd like to be able to program the desired temps like this:
#master+30°C for CPU
#master+20°C for HD etc.

This way one could have sensing fan control. [I'd like to point out that I don't have A/C, so the ambient temps are ~20°C winter, and near 30°C in summer.] There is still need for some hard values, in case the master sensor should fail; like max. temp for CPU=55°C.

Cheers,

Jan

[Bat]

Internal vs. external controllers:
I don't think it has to be a fundamental difference. The core of the device might be the same, but if it's to be "external" then it has extra stuff attached.

Using software on the PC:
No, no, no! We don't want to have to rely on a program and an operating system doing the right thing. We want a fan controller that can function regardless of what the computer is doing. If you don't share that opinion, please create a new thread to discuss software-based fan control. Talking about it in here will be a distraction.
Seriously, are you willing to take the risk that your computer could burn up if its operating system crashes? Do you want to be limited to operating systems for which the fan-control program is available?

Algorithm:
Let me see if I've understood your description, silverarg. It looks as though you work out CT but never use it. Here's my way of describing your idea in a sort of pseudocode which I hope is clear.

Code: Select all

speed := 0
last_hot_time := now

repeat the following forever

    if (temp > maxTemp) then
        speed := maxSpeed
        last_hot_time := now
    else if (temp > targetTemp) then
        speed := speed+1
        last_hot_time = now

    if (temp < (targetTemp - small_constant_for_hysteresis) AND
        last_hot_time is at least 5 minutes ago) then
        speed := speed-1

    wait for two seconds

Is that what you meant? I suppose it would work, but the more complex ideas would give better results.

Jan Kivar, why do you want to change your desired CPU temperature etc. in line with the room temperature? Is it to avoid unnecessary speed-changes because changes are annoying? If so, room temperature should change slowly, but I don't think it'll work. Warm air has a smaller specific heat capacity, so a greater flow rate is needed to carry away the same power of heat even if the temperatuer difference between intake air and "heater" stays constant. Variations in heat output rate will be the biggest factor anyway, as programs start and stop using the processor etc.

[Bat]

Dutch2, my feeling is that the controller should monitor fan speed for its own use even if it doesn't report it. I worry about a sequence of events like this:
1. Fan at 29% power, 720 rpm, temperature below target and steady or falling.
2. Fan at 28% power, 0 rpm, temperature below target and rising.
3. Fan at 40% power, 0 rpm, temperature above target and rising.
4. Fan at 41% power, 1800 rpm, temperature above target and falling.
Return to 1.
That's what could happen if the controller controls pulse-width (well, mark-to-space ratio really) in response to temperature, but doesn't monitor the speed.
If the controller were monitoring the speed then I imagine it should be able to run the fan below its normal stalling speed. Say running at 400rpm in the example above.

Gooserider asked, "Even if the actual RPM number isn't available, will the controller be able to tell the difference between a fan that is stalled and one that is running fine but to slowly to be accurately measured?"
No. If you can tell it's running, you can work out how fast. That's true for "normal" three-wire fans, of course (or a two-wire fan with a clever external circuit to detect the spikes as the transistors switch). It would be different if you had one of those fans with a third wire that just signals "running" or "stopped" states.

As for the measurement of speed at low speeds, the thread I linked to yesterday is not quite as relevant as I had thought (though still worth reading), because it deals with varying the fan's supply voltage rather than using PWM. I would imagine that so long as the fan is spinning, and so long as the "on" pulses of the PWM are at least long enough for one revolution of the fan, there should be no problem measuring the speed during that pulse. I suppose if necessary the PWM frequency could be slowed at low fan speed.

A thought: how about PWM switching between 12V and 2V instead of 12 and 0?
2V probably isn't enough to keep a fan spinning, so we still have control down to as slow as we like, but if the fan is spinning then 2V should be enough for its internal transistors to switch on and off and give us a continuous signal on the tachometer wire (which would need a pull-up resistor to 12V, possibly by connecting it to the motherboard speed sensor).

If we do the above then there's no reason for a pulse to last as long as a revolution. Dutch2 was talking about doing clever things with pulse shaping/timing. Regardless of their length, they could be timed to start and stop at a particular point in the cycle, for minimum noise. The equivalent of starting/stopping pressing hard on bicycle pedals when the cranks are whatever's best of horizontal or vertical or some angle between.

[Bat]

(There's still the risk that the fan might be twitching back and forth while giving pulses that make it look as though it's spinning, though, as someone described in that other thread.)

[Dutch2]

Good input guys!

Ok, just to make sure everybody understands the way I'm heading...

1. The PC software is for configuration and monitoring only and not required for normal operation. If your PC is about to melt down and the OS locks up... you get the idea.

2. The controller will measure RPM and use it to make sure the fan is spinning. It will also display the RPM in the PC software or on the LCD. When the fan PWM signal is set very low a RPM measurement may not be possible, but the controller will still look for pulses to see if the fan is spinning. (I only need one pulse per PWM on-time to see if the fan is spinning, I need two sequential pulses in one PWM on-time to measure RPM)
Note: The RPM is not used in the calculation to determine how fast the fan should be running to control the temperature. It is just a result of how much power (PWM on-time) the calculation decides to give to the fan.

3. To keep things user friendly I will initially have a fairly simple temperature vs. fan speed control algorithm like Bat suggested (Thanks Bat). Maybe if we can come up with a more effective but still user friendly one I will implement it later.

4. I'm not sure I understand the 'in the box' vs. 'outside the box' thing. The controller's best place to live is inside because of all the wires. If you want to add an external LCD in a box, no problem

For as far a hurdles go, the RPM measurement with a 2-wire fan is my biggest challenge, and the control algorithm is what will take the most tweaking.

D2.

[Bat]

1. Good.
2.

I only need one pulse per PWM on-time to see if the fan is spinning, I need two sequential pulses in one PWM on-time to measure RPM

If my 12V/2V PWM idea works, then you'll see the tach pulses even during PWM "off-time" (2V time), which would make measurement easier. Worth a try?

3. I wasn't really suggesting it, just interpreting what silvervarg suggested. I had been suggesting more complicated things. In fact, if you do use that algorithm then I'd suggest that in "speed := speed+1" the number should be bigger than 1, i.e. bigger than the number used for decreasing the speed. (Of course, the way you're planning to do it, it wouldn't be "speed" but "percentage_of_full_power" or similar.)

4. My understanding was a distinction between something completely hidden away inside, and something mounted on the front of the case with accessible switches/knobs/dials/LCD/whatever.

If you're wanting to measure the speed of two-wire fans, then just in case you've not seen it I'd better mention this thread: http://forums.silentpcreview.com/viewtopic.php?t=3565

There's also this one about speed-sensing on three-wire fans under difficult conditions: http://forums.silentpcreview.com/viewtopic.php?t=5342

[Bat]

Enhancement suggestion:
Quite apart from whatever clever control algorithm there is, for each sensor a "TOO_HOT" temperature shoult be specified (at least a few degrees hotter than its "target" temperature. Any time any sensor is TOO_HOT, a warning light is turned on and all fans run at full power until no sensors are TOO_HOT. The light stays latched on until reset by the user, so that if you weren't around when it happened (number-crunching server on a hot day, perhaps) you'll still see the warning when you look at the box.

[Jan Kivar]

I only need one pulse per PWM on-time to see if the fan is spinning, I need two sequential pulses in one PWM on-time to measure RPM

If my 12V/2V PWM idea works, then you'll see the tach pulses even during PWM "off-time" (2V time), which would make measurement easier. Worth a try?

The last thread You linked has a discussion that states that the RPM output (and I quote) "gets really, really shitty" under 5V. Have You "solved" that out already?

Cheers,

Jan

[Gooserider]

1. I want to have the controller do all the 'heavy lifting' in terms of maintaining fan speeds, monitoring performance, reproting, etc. I don't want to have O/S or main CPU dependent function for anything other than configuration. My reasoning is that I want to be proof against crashes, able to multi-boot w/o needing to worry about loading the controller S/W, and also not worry about having to spend CPU cycles on background tasks. While having a report display program would be nice, I would also like to have a seperate LCD that I can look at without needing to interupt my primary tasks to load / switch displays to the report program.

2. I am not overly concerned about the algorithym used to figure the fan speeds, but I would prefer that it results in fairly steady speeds, even at the cost of mild temp instability. The algorithym should also allow the setting of minimum speeds, turn on temperatures, and either 'ramp-up' rate, or 'max speed temperatures' (different ways of looking at same thing really)

3. External / internal mounting. The earlier reference seemed to refere to putting the controller in a form factor compatible with mounting it in a 5.25" external drive bay, possibly with a display and / or rudimentary function control buttons and / or extra USB/Firewire ports (like a Digi Doc 5+ has) The internal mounting implies mounting the controller somewhere else in the system (exact location not specified) with no external connectivity, and all communication for configuration and reporting going to the mobo.

I would FAR prefer the external mount option, but the two aren't completely incompatible. Internal mounting doesn't have much in the way of board form-factor limits (other than being small enough to fit in the case ) for an external mount the form factor is limited to the size of a CD-ROM drive box, (preferably smaller) and must be capable of being mounted on a 'drive sled' Any stuff on the front panel of the sled is optional according to Dutch2's earlier design descriptions, so it could be left off.

Gooserider

[silvervarg]

1. Software control vs completely self contained.
The point with my suggestion was to get optimal performance with the least amount of cabels. You would still have a compleately safe system even without software, and depending on how many sensors you attach you may be able to reach near optimal performance without software.
With few sensors and no software running (on PC) you will get slightly overkill on the cooling, so noise level will go up. I believe this is a major difference compared to beeing dependent on the PC software.
To my suprise most people in this thread didn't seem to like this idéa. I guess you don't hate cable mess as much as I do.
One major benefit with using onboard sensors is that they will be more accurate than external sensors since they are placed closer to the heat source. Closer to the source also means they will react faster to temperature changes.

2. The term internal vs external mounting was badly choosen in may last note. As some has already figured out I was refering to 5.25" bay mount with the word "external mount".

3. One note mentioned things like 28% power gave 0 rpm (point was fan stalling at low % power). I was under the impression that PWM gave a high torque at low power, so you could run fans extreamly slow. E.g. with 5% power. I guess there is still a point where you reach fan stall speed.
Should there be a minimum amount of % power allowed (when you want fan to spin)? If so what % would be the minimum?
How often do you get an RPM pulse? Is it once per revelation or a fix number per revelation or does it vary with different fans?

[silvervarg]

Fan controller algorithm

Temp sensors should not be fixed to a specific fan. If that is all we get we are real close to using normal temp controlled fans and skip the fancontroller compleately. The point with a smart fan controller is that you can do other smart tricks, e.g. increase chassi fans when CPU temp rises so you don't need to increase CPU fan speed that much.

I think Bats pseudo-code was about what I was going for, but I guess I was thinking of something a little bit more. I haven't spent that much time on the program thoughts, but here is a first try to scribble down some pseudo-code. Please give comments and information about what is possible and what is not in the microcontroller. (e.g. memory limitations etc.)

As for temp sensors the algoritm will be something like this:

Code: Select all

array_with_temp_values1[]=[0,0,0,0...];
(one array per temp sensor)

repeat forever
   shift temp values left in array_with_temp_values1 (loosing to oldest value).
   add new temp measurement last in array
   temp_sensor1=max(array_with_temp_values1) + temp_sensor_calibration_constant1;
   (add same code for rest of temp sensors here)
   wait for x seconds
end repeat

Comment: The Above make quick temp_sensor when temp is going up and slow when temp goes down to ensure stability to the system.

For each fan we decide what temp sensors to to take into acount:
E.g. fan1_virtual_temp=(temp_sensor1+temp_sensor2)/2
     fan1_new_speed=function_fan_speed(fan1_virtual_temp, fan1_optimal_temp, fan1_max_temp)
     if (fan1_new_speed<fan1_old_speed) fan1_new_speed=fan1_new_speed-1%
     fan1_old_speed=fan1_new_speed

Comment: The above provides the intelligence to the fans and slow fanspeed decrease ensures more stable system. The 1% can be changed depending on how long each loop will take.

After all fans checked:
if (alarm_triggered) {
   set_all_fanspeeds_to_100%
   remember alarm (for beeping and user view only)
   reset alarm
}

Comment: The above handles temp alarms and gives 100% speed on all fans when temp alarm occurs.


function_fan_speed(virtual_temp, optimal_temp, max_temp) {
   if (virtual_temp>max_temp) {
      trigger alarm
      return 100%
   }
   if (virtual_temp<optimal_temp) return 0%
   return max(100%,(virtual_temp-optimal_temp)/(max_temp-optimal_temp)+10%)
}

Comment: The above gives a single point in the code where fan speeds are calculated. The last line can be debated. The suggested implementation of the last line gives 10% fanspeed at optimal temp and a linear fanspeed increase up till 90% of maximum temperature.

P.s. Don't reply to this post here since Bat created a new thread for Fan controller algorithms.

/Silvervarg

[Bat]

3. One note mentioned things like 28% power gave 0 rpm (point was fan stalling at low % power). I was under the impression that PWM gave a high torque at low power, so you could run fans extreamly slow. E.g. with 5% power. I guess there is still a point where you reach fan stall speed.

How often do you get an RPM pulse? Is it once per revelation or a fix number per revelation or does it vary with different fans?

The numbers were just examples that I made up to illustrate the problem. I don't know what the real numbers would be.
As for pulses per revolution see http://forums.silentpcreview.com/viewtopic.php?t=5342

The last thread You linked has a discussion that states that the RPM output (and I quote) "gets really, really shitty" under 5V. Have You "solved" that out already?

No, I've not been thinking about it, but the situation here is a bit different in a couple of ways, so my feeling is that it's worth hoping, worth seeing if it works.

[Bat]

I just thought of another little extra feature that some people would welcome.

The settings and software on the controller can be updated through its connection to the PC. Therefore if some malicious person halfway across the world gains control of your internet-connected computer, that person can turn the fans off and watch the temperatures climb. Would it be hard to make the board so that it requires a jumper or switch to be in the right position before it will accept any reconfiguration commands from the computer?

[silvervarg]

If a malicious hacker gets full control over your computer, what would you fear most?
1. He goes through the hassle of understanding that you have a special fancontroller to turn off your fans. The result will be that the computer gets real hot after a while and when the CPU is hot enought it will power down the computer, so he has then lost control over your computer and you can regain control when you boot it up again.

2. He erases or corrupts lots of important files that you don't have up to date backups of.

[fancontrol]

Dutch2,
Do you have a web site or something where you can post schematics, etc. of your work so far? I'm really interested to see what solutions you've come up with. You can, of course, look over what I did at the web link below.

Gooserider mentioned that maybe we should work together. Since I'm not doing any development, just making copies of the existing design, I don't see that happening. But I would like a chance to look at what you've done to see if what I've learned can help at all.

[Gooserider]

Dutch2 and Fancontrol...

Do either of you have any sort of projected time table as to when you might be able to ship something next?

I'm starting to get my PC project to the point where I'm starting to see an end to it, which means that I'm going to need to get a fan controller of SOME sort very soon (Like within the next 2-4 weeks!) I know that development or waiting for other people to show interest takes time, so I haven't been pushing at all, however I'm starting to run out of time and need to get some sort of solution that will let me get the new box running so that I can get off this old POS (reliable but SLOW...) that I'm on now.

I'm not really pushing now for that matter - If you can get it ready in time, I'd really like to use one of your designs as they sound far better than any of the commercial approaches I've seen. OTOH if it doesn't look like you'll have something, then I understand and can look elsewhere....

So, what does the time table look like?

Gooserider

[Dutch2]

FanControl, I'm not sure when, if ever, I will post any schematics. I'll post a block diagram so everybody can understand how the things works though. Most of the development is in the software anyway.

Gooserider, I'm not sure when I'll have something for you to play with. To be honest, it depends how busy I am with everything else. This is a "pet project" for me, but I still have to make a living. Things look more quiet later this week, but ya never know

Basically I have some new temperature sensors on order and I'll test them when they get here in a day or two. I'm still playing with the 2-wire fan RPM measurment circuit, and I have to write the code so you can update the software through RS232.
When those things are done I'll start laying out a circuit board and make a few. After that I could ship you one, but there will be more software development after the hardware is done.

D2.

[Dutch2]

Ok, I found some time to work on this thing some more, and I updated the schematic to what I have developed so far....

1. Six PWM outputs, 500mA maximum current. Soft PWM on and off to reduce noise. All outputs have hardware to monitor RPM on 2-wire fans, and 2 also have hardware to monitor RPM on a 3-wire fan. Configurable through PC software.

2. Eight temperature sensor inputs designed to use an analog temperature sensor and optionally a PTC if a different form-factor is required. Configurable through PC software. Fan control algorithm will determine what temperature(s) determine what fan's speed, etc.

3. Six general purpose I/O lines. Three can be used to measure analog voltages. One is an open-collector output like a fan-tach output that can be used to simulate a fan tach signal to the motherboard. I could add another open-collector output so you can turn stuff like lights on and off? Five can be used as digital input or output lines, some of which may be used for user interface buttons when a LCD is used. Actual function of each I/O line is configurable through PC software.

4. Standard parallel LCD interface to drive low-cost off-the-shelf LCDs. Same digital interface could be used to drive serial I2C LCD, only software update required.

5. RS232 interface to PC software. On-board microcontroller firmware can be updated through this RS232 port. On-board EEPROM will store configuration, no PC interface required to operate. A watch-dog timer will monitor software operation and reset the microcontroller if it goes "out to lunch".

6. Target price for assembled controller board is still under US$50.

I'm adding some protection to the general purpose I/O, but that's about it, the rest is software.

Comments?

D2.

[Gooserider]

1. Six PWM outputs, 500mA maximum current. Soft PWM on and off to reduce noise. All outputs have hardware to monitor RPM on 2-wire fans, and 2 also have hardware to monitor RPM on a 3-wire fan. Configurable through PC software.

This could be a problem - at least two of the fans I'm planning to use have a rated current of 520mA, which is more than you're allowing (and I don't really like going more than about 75% of rated max as I find it increases reliability problems) - Any way to boost the output to around 750-1000mA?

3. Six general purpose I/O lines. Three can be used to measure analog voltages. One is an open- collector output like a fan-tach output that can be used to simulate a fan tach signal to the motherboard.I could add another open-collector output so you can turn stuff like lights on and off? Five can be used as digital input or output lines, some of which may be used for user interface buttons when a LCD is used. Actual function of each I/O line is configurable through PC software.

More outputs are better on general principle, although I don't strictly need it. Can one use that simulated fan output on more than one mobo signal lead?

6. Target price for assembled controller board is still under US$50.

Sounds wonderful

Aside from the question of the power output, everything else sounds really good, I hope you can get some built soon. I also assume that the software is at least useable at this point, even if there is some debate about the optimal algorythm and other fine points?

Gooserider

[Jan Kivar]

Electronic Goldmine has a good selection of fans in all sizes... They have a couple of different units I've ordered in their September monthly flier - One is a Sanyo 'San Ace' very high output fan, 102.3CFM, 0.52A, 2600RPM, 39dBA @12VDC. (Item G14010) at $5.00 each

Is this the fan You are referring? I can't find them in the EG catalog. I think You should consider other fans, as there are fans which need less power.

Jan

[silvervarg]

Dutch2:
6. Target price for assembled controller board is still under US$50.

Sound great!
What do you plan to ship with the controller board and what is included in the 50 USD price?
E.g. I guess most of us want the temp sensors and the wire to go to the motherboard for simulated tach and a cable to connect to RS232.
Other things that might be of interest is:
Stuff to mount the board.
Wires to lenghten the fan cables.

Will the six PWM outputs be dedicated to fans? Or could I use some for other things? E.g. drive a 12V LED with light-level depending on temperatures.

[Dutch2]

I'll try to answer some of the questions...

What do you plan to ship with the controller board and what is included in the 50 USD price?

The $50 will probably include 2 temperature sensors and some connectors & wiring. I was thinking about including some "sticky feet" so you could easily mount the board on the inside of the case.
I'll have to look into the RS232 cable to see what the cost is although it should be included.

Will the six PWM outputs be dedicated to fans?

Good point.. the PWM outputs could be used to drive anything that uses less than the maximum amount of current. In theory they could also be used as a generic open collector output to turn things on and off.

at least two of the fans I'm planning to use have a rated current of 520mA

I think we talked about this in a previous post... the driver can actually handle 1000mA, but I'm not really sure what the maximum is going to be becuase the PWM wave shaping increases the dissipation a little. I'm sure they will be able to do 520mA though

Can one use that simulated fan output on more than one mobo signal lead?

Yes, the one fan-tach simulator output could be connected to multiple fan headers on the motherboard.

I also assume that the software is at least useable at this point...

There is only test software at this point, I will develop the real thing when I have some hardware.

D2.

[fancontrol]

fancontrol thinks, while reading all the stuff Dutch2 can implement in software:
I would kill my dog for a full version of the Keil compiler.