Before anything else, let me ask: If you go into Windows, can you see the fan speeds being displayed there? If you are not doing so already, install Intel Desktop Utilities (IDU) and use it to see the fan speeds. If you do not like IDU, I would next recommend that you install AIDA64 (it does the best job of properly handling the actual hardware design of the board). If you don't want to pay for this great app, you can try using Speedfan or HWMonitor, but they don't, in some cases, understand the board properly and will misrepresent voltage and temperature sensor readings. Regardless of which you use, if you see fan speed readings here and the fans are properly speeding up and slowing down to compensate for temperature changes, you can ignore the fact that the BIOS is not displaying fan speeds if you want.
Now the (possible) bad news: Over the years, I have seen many cases where poorly designed fans (and there are lots of them around, even from the so-called 'name brand' suppliers) that send high-voltage spikes back on the tachometer input line. These spikes will eventually (and permanently) burn out the receptors in the fan speed control device (in this case, the Super I/O IC). Subsequently, fans will appear to operate correctly but never be detected nor their fan speed displayed. Secondly, I have also seen many cases where folks hook up fans that require more amperage than the fan headers can supply (limit is 1.5A for chassis/auxiliary headers and 2.0A for CPU header). This will eventually (and permanently) burn out the FETs used to power the fans. This often gets people that use a 'Y' cable and connect two fans to a header. We can hope that neither of these issues is the case here, but I mention them first just in case we end up there.
Ok, let's proceed. Your situation has four possible outcomes:
- We can get the fans to run properly (perhaps with a little finagling).
- We find that the fans don't provide a good tachometer signal at all.
- We find that the fan's don't provide a good tachometer signal unless they are running at a higher speed.
- We find that one of the problems mentioned above has damaged something on the board and this is going to make it impossible to resolve the issue.
First thing to do is to go into BIOS Setup, navigate to the configuration scene for fan speed control and configure all fans for manual control at 100% duty cycle (i.e. full speed). Exit BIOS Setup with a save. After the reboot, use F2 to reenter BIOS Setup and navigate to the fan speed control scene again.
If fan speeds are now being displayed and readings appear correct, put all fans back into automatic control mode. Exit BIOS Setup with a save. After the reboot, use F2 to reenter BIOS Setup and navigate to the fan speed control scene again. If fan speeds continue to be displayed, great, you are done. If not, however, we have arrived at outcome 3 and you will have to replace these fans if you want fan speeds to display.
If we get to this point, we need to do two things:
- We need to clear the CMOS configuration. Power down the system and unplug it from the wall (you can also use switch on power supply to disconnect power if it has one). Remove the CR2032 battery from the board. Wait at least 15 minutes. Restore the battery and plug the system back into the wall (or turn back on at power supply switch) - but do not power back on yet.
- We need to install (or reinstall) the latest available BIOS using the Recovery method. Using some other computer, download the .BIO file for the latest BIOS and place it on a freshly-formatted (FAT32 file system) USB 2.0 (not 3.0!) flash disk. Plug this flash disk into one of the (black) USB 2.0 USB port on the back panel of the board (do not use front panel connectors). Remove the (yellow) BIOS Configuration jumper from the board. Power on. The system should now start installing the BIOS; a display of the phases completed and in progress should be seen on the monitor. When the update is complete (a message will tell when this is the case), power off the system and restore the jumper to the 1-2 pins.
When these are done, power on and use F2 to enter BIOS Setup. Set up the date and time. Then, use F9 to restore the BIOS configuration to its defaults. Mkae any changes to the defaults that are absolutely necessary for your system configuration (i.e. SATA mode, Boot Order, etc.). Exit BIOS Setup with a save. After the reboot, use F2 to enter BIOS Setup and navigate to the fan speed control scene. If the fans are displaying properly, great, we're in outcome 1 and we're done.
If we still don't have fan speeds displaying, we are at outcome 2 or outcome 4. Determining which will take replacing these fans and determining whether the new fans are handled properly.
Hope this helps,
Thank you Scott for your reply.
I have both speedfan and hwmonitor, neither show values for the said fans. I should add that the RPM readings work (in BIOS and in Windows) for stock fans, as well as for Corsair AF120/140 series that I also have. I just recently added a splitter on both front/rear headers, each to a 3- and 4-pin connectors (4 fans total). When I used the PWMs, I noticed changes in speed under heavy loads such as in games. So I assume they work okay, just without any readings.
I have yet to try your suggestions.
Hhmmm, now I am not so sure I understand what your issue is...
Fans send short power pulses on the tachometer signal, two such pulses per revolution. The "sensor" is a simple circuit that measures the average number of pulses seen each second. Knowing this time, you can then calculate how fast the fan is actually spinning. If you think about it, this simplistic implementation does not allow for determining anything other than whether a fan is there (because pulses are seen) or is not present (or is broken, because no pulses are seen). That's it.
When you use a Y cable and connect two fans to a single header, these fans *MUST* be of the same type (i.e. 3-wire+3-wire or 4-wire+4-wire). The fan type detection circuit will not work otherwise (the controller has to know whether to control fan speed by, for 4-wire fans, sending the PWM signal or, for 3-wire fans, by varying the voltage provided; it cannot do both).
When two fans are connected to a single fan header using a Y cable, the pulses both fans are sending on the tachometer line are wire-OR'ed together. When pulses come at the same time, they appear to be one. Otherwise they remain separate and are included in the total. This means the speed reported is an amalgam of the two fans' speeds and is not truly indicative of either fan's actual speed. The speed could be as high as that of the two fans combined or as low as the speed of the faster fan.
I want to reiterate something - When two fans are connected to a single header using a Y Cable, the total amperages of the two fans must not exceed 1.5A. If it does, you will eventually (if not immediately, in a puff of smoke) burn out the FET providing power to the fans and the header will be dead and useless.
Okay, so current setup is this:
front intake on a Y cable: 2x Corsair SP120 PWM (4-pin 0.25A on fan label, 0.18A in website), RPM not detected in BIOS/Windows otherwise works.
rear exhaust on a Y cable: 2x Corsair AF120 (3-pin 0.40A), RPM detected.
What happens if you swap the Y cables from one header to the other?
If you connect only one of these PWM fans to a header, is its speed detected?
No change. Even before using the splitter, the PWMs did not show any readings.
Did you try plugging a single 3-wire fan into this header? If you do and it still doesn't display fan speed, either this fan is (also) bad or the tachometer input has been fried (this cannot be repaired; you live with it or replace the board).
Despite the keying that exists in these fan headers, folks have still found ways to plug fans in incorrectly. If you are misaligned but you force it on anyway (you are way stronger than the plastic keying arm), this is what happens. The result is a shorting of the tachometer input, which will fry it (12V on an input that expects 5V; a fraction of a second with power applied is all it takes for this to occur), sometimes with a puff of smoke.
Note that I am not accusing you of anything; this can also happen if a fan somehow develops (or came with) a short in its hub. I have seen this before more than once. A few years ago, we analyzed one fan that fried tachometer inputs. Despite having only 12V on its power input, we found that this fan generated 18V tachometer pulses. This didn't fry the tachometer input immediately; it took a few minutes for the damage to build up to the point of failure (and no puff of smoke this way). You might ask how this is possible? Remember that a fan is essentially a motor and motors can generate power as well as consume it...
The condition is the same as I wrote previously. The speed reading works with the stock fans as well as the AF Series, all of which are 3-pins. The 4-pin PWM Series do not. In other forums I have found other users of this particular Corsair fan with the same problem, on certain motherboards.
Do you have any other (i.e. non-Corsair) PWM fans that you can try with this board?
The 7 (and 8) Series Intel Desktop Boards utilize an innovative fan detection circuit that can determine whether the fan connected has 3 or 4 pins and will use the appropriate control method for the fan detected. That is, passing the PWM signal through to the 4-pin fan and letting it make the fan speed decisions itself, or directly controlling the speed of the 3-pin fan by varying the voltage (scaling it down based upon the duty cycle of the PWM signal) of the power delivered to the fan. Either way, you get a fairly linear - and well predictable - response curve.
I am curious to see what the cause is for this fan's tachometer signal not being seen. The fan detection circuit does not require the tachometer signal to determine whether the fan is 3- or 4-pin, so fan control is going to work just fine regardless, but, in my systems, I demand to be alerted if my fans fail to operate properly and the tachometer signal is absolutely necessary to determine this...
I am betting that the pulses on the tachometer signal are not reaching the necessary (5V) threshold for detection. Do you have a way to check this? An oscilloscope is necessary to do this accurately, but you should be able to get an idea by checking the voltage that you see on this pin (it is pin 3 in both the 3- and 4-pin fan connectors) while the fan is spinning...
Unfortunately, I don't. All of the 3 fan headers of my board (CPU, Front, Rear) works fine except when using these particular PWMs.
To copy a post in Corsair's forum:
So I grabed his mainboard (Asus M3A78-T)and my DMM in order to figure out how the mainboard measures the fan speed and found out the tacho pin is pulled up by a 2.7kOhm resistor to 5V not 12V. I then canged my test setup with those same values and now there appeared a noticable difference in both fan signals. The SP120 fans signal had an amplitude of only 3.5V and the lowest value was 1.5V, while the other fans signal had an amplitude of about 5V and the lowest value was just over 0V.
Apparently the Corsair SP120 fan tacho output has a too high series resistance to work correctly in this system. I do not know who is to blame here as Intels specs are unclear about tacho currents, resitances and detection voltages but is does seem strange that both mainboards have this problem with this fan while working with many different other fans, so I would guess the problem is in the Corsair fan.
In order to test out if this was really the problem I made an adapter with one resistor and one transistor and when I put that in between the motherboard and the SP120 fan the fan speed was detected corrrectly and everything worked smoothly.
This may or may not apply to my situation, I just don't have the resources to do a test myself.
My initial reaction to this was to say "no way; this is properly spec'ed", but I went back and looked at the spec and, sure enough, it does not specify a voltage for the tachometer signal. Hhmmm, I am not sure anyone will want to open a can of worms changing a spec that has been around for so many years - and pushing it through the industry ratification process. I know the author for this spec; I will drop him a note...