Archived from groups: alt.comp.periphs.mainboard.asus (
More info?)
Hi,
You sound like someone to try my latest wild idea on.
I have not looked at the Intel spec for fans yet, you seem to have
information from it.
I installed a "Zalman CNPS7700 AlCu CPU cooler" with Fanmate 2 for
controlling the fan speed.
It does such a great job cooling my CPU that even when set to the lowest
speed my CPU temperatures at max. load are way below normal temps.
Before with the Intel supplied fan the CPU temperatures were so high that
the CPU was limiting most of the time. (P4 640)
With the fan speed ~960 RPM both the BIOS and the Probe program complained
that the fan had failed.
The point that they stopped complaining was about 1200 RPM.
The ~960 fan speed was way too fast, there was noise being generated that
was not necessary.
I thought about patching the probe program and the BIOS to not complain
about the slow fan speeds, but I had not gotten around to looking into that
possibility.
Then I purchased a front panel display which has a Fanmate type control and
CPU fan speed display along with CPU, HDD and CASE temperature readouts.
The minimum fan speed is inside the special chip for the display panel which
again is too fast, 1250 RPM.
So the patching of limits idea will no longer fly. A hardware solution is
needed now.
I did some searching in my very old data books for a frequency doubler chip
and found one, but it was a reference to a chip documented in a book I did
not have and due to the book being 30 years old it must have been replaced
several times.
Today there probably many ways to do a frequency doubler and make the output
meet the Intel fan requirements.
So you can have a much slower fan speed and all the monitoring programs will
be quite happy but displaying the fan speed twice what it really is.
Will this hardware solution fly?
--
Stephen H. Fischer
Paul wrote:
> In article <1123559373.575160.208030@o13g2000cwo.googlegroups.com>,
> "Richard" <ehope8@gmail.com> wrote:
>
>> I recently install a ASUS motherboard in my old case and see a message
>> "Power Fan below threshold" from the ASUS utility software. There is a
>> CPU fun and a CHA fun for the case. I can not find the POWER fun for
>> the POWER supply.
>>
>> Does that mean the Power Supply Fun stop working? Do I need to buy a
>> new Power Supply 300W?
>>
>> Thank you in advance
>
> There are several options for power supplies.
>
> A cheap power supply might have no monitoring capability at
> all. If there is no monitoring cable on the PSU, then the
> PSU cannot talk to the motherboard.
>
> If the PSU has a two wire cable, with a three pin connector
> on the end, that is a fan monitor cable. The two wires are
> "tachometer_output" and GND. When this PSU cable is connected
> to a fan header on the motherboard, the motherboard should
> be able to measure the RPMs. It does this by measuring the
> period between pulses.
>
> If the PSU has a two wire cable, with a two pin connector
> on the end, this could be a thermistor output. A negative
> tempco thermistor, nominal resistance 10K ohms at 25C, with
> a beta of 3435, would be the typical component used. Most
> monitoring chips and associated software would expect this
> kind of component, and the temperature is computed with
> the assumption that the thermistor is one of that type.
> The thermistor inside the PSU allows the motherboard to
> measure the temperature of the PSU, and with the right
> software, you might be able to raise an alarm if the PSU is
> too hot. Recent motherboards don't seem to have the
> necessary two pin header - my P4B has a TRPWR header, but
> I don't think my other boards have one of those.
>
> Since the fan speed is typically measured by measuring
> the period between pulses from the fan, the measurement
> register has a limit to the amount of counts it can hold,
> before it overflows. The slower the fan goes, the more
> counts that accumulate in the counter. The operation
> looks something like this:
>
> | <--- Motor pulses twice per one fan revolution ---> |
> _____________ _____________ ___
> ___| |______________| |____________|
>
> _ _ _ _ _ _ _
> _| |_| |_| |_| |_| |_| |_| |_
>
> | <- seven counts in total-> |
> counter = 0x07 hex
>
> The monitor chip makes those tiny measurement pulses, and the
> frequency of the pulses has to be selected to give good
> resolution and good min to max range. The pulses are created
> by a chain of divide-by-two flops, and the BIOS sets up the
> right value for the divide chain before Windows boots. I think
> both the BIOS and the OS/applications have access to the
> monitor chip, and it could be that the OS/applications are
> not allowed to change the divider chain (there is no standard
> for the interface that I've heard of, so this is just a guess).
>
> Now, imagine a thought experiment. The BIOS designer at Asus
> expects the fan to spin at 3000 RPM. They set the divider so
> that the 8 bit counter (max value 255 decimal) will catch
> 128 pulses in the time it takes the fan to generate one full
> pulse. Now, the customer gets the motherboard, and plugs in
> a PSU with a fan that spins at 1500 RPM. When spinning at 1500
> RPM, the pulses are stretched out by a factor of two. Instead
> of 128 pulses accumulating in the 8 bit counter, a total of
> 256 accumulate in the counter. That is one more pulse than
> the counter can hold, so an overflow bit is set (or equivalent
> thereof).
>
> When the software detects an overflow, it doesn't know if the
> total counts are 256 or a gazillion (when the fan stops). The
> fan speed is somewhere between 0 and 1500RPM, but due to the
> measurement method, there is no way to know. In a situation
> like this, the BIOS reports "0 RPM", even though you can see
> your fan is still spinning.
>
> So, in some cases, there may still be room in the divider
> chain, to adjust the frequency of the measurement pulses, and
> bring the pulse period measurement back within the 1..255
> count range limit of the counter. But whether the software
> is allowed to do that or not, is something I cannot answer.
>
> You may ask the question, "why do they measure the period
> of the pulses, when they could count the revolutions ?".
> The answer is, the period measurement method allows the
> speed of the fan to be computed faster. The measurement
> time is bounded by the time it takes to overflow the
> counter. The question one has to ask, is why the silicon
> chip designers could not use a larger register to accumulate
> counts, like maybe a 16 bit register. With sufficient register
> bits, there wouldn't even be a need to adjust the divider
> chain.
>
> The RPM value you see, is not the value extracted raw from
> the chip. The readings are averaged, to reduce the jitter
> in the values seen. Averaging the values increases the
> latency in seeing a change in fan speed, but it avoids
> the RPMs being annoyingly unreadable by a human.
>
> For monitor chips that sit on the SMBUS, rather than an
> LPC bus, it is possible for two software programs to
> interfere with the readout of registers from the monitor
> chip. When this happens, a program like MBM5, Speedfan,
> or Asus Probe, might report the fan at one moment is 0 RPM,
> and at the next instant is 10000 RPM. The SMBUS has no
> semaphore to prevent simultaneous accesses by two programs,
> and the serial data on the SMBUS is cut off in mid access.
> The result is garbage values seen by the software.
>
> Much of the above is supposition and assumptions on my
> part, as the datasheets do not describe in clear English
> how this stuff works. I hope (most of) the above is correct.
> At least it may help explain why programs readout "0 RPM"
> when the fan is still spinning.
>
> HTH,
> Paul