4
\$\begingroup\$

This question builds upon this previous one How to interpret output of 3-pin computer fan speed sensor? which was asking about the 'sense' wire output from computer fans.

I am designing a fan controller for PWM fans (spec) that needs to monitor the RPM of up to 5 fans concurrently. In the past I've used interrupts on a GPIO port to build a basic tachometer for a small motor, however my concern is that this approach will not scale given that:

  • Each fan runs at a maximum of 2000rpm
  • The linked question suggests that there will be 2 pulses per revolution
  • If an interrupt is generated for each pulse to increment a counter then that works out at a maximum of 333 interrupts per second (2000rpm *5 fans * 2 pulses)

I'd appreciate any suggestions for how to implement such a monitoring system. Incorporating additional chips, etc into the design is not an issue. I will be working with Cortex M3-class hardware, probably an LPC1768 (overkill for a fan controller, I know).

Edit: Indeed, my original calculation posted here neglected to convert from interrupts/min to interrupts/sec. Sorry for the confusion.

\$\endgroup\$
  • \$\begingroup\$ Do you have specs on how quickly you would react to a fan fault event? Is the micro doing anything other then monitoring the fan? \$\endgroup\$ – Kortuk Mar 15 '12 at 18:27
  • 2
    \$\begingroup\$ Some tutor from a LPCxpresso NXP workshop once told me that the LPC1769 (LPC1768 clocked at 120MHz instead of 100MHz) can handle up to 1M interrupts per second.. 333 is not an issue, nor is 20k. Infact, if you would have 10 fans @ 12k rpm, it's 2000 interrupts per second.. no big deal. \$\endgroup\$ – Hans Mar 15 '12 at 18:28
  • \$\begingroup\$ @Kortuk There will be some background processing but nothing time-critical. The other main functions will be periodic communication with a host PC via serial, PWM control of some LEDs and periodic sampling of some temperature sensors. I imagine that the PWM generation is not affected by interrupts once it's configured and the output is enabled? \$\endgroup\$ – Paul Beesley Mar 15 '12 at 19:29
  • \$\begingroup\$ @paulbeesley, So not time critical, be fine if it takes a full second to realize there is a problem and only does so much damage. I like andrews answer but if you dont care about delay and you are only watching the fan olins answer makes the most sense, I would use a 1MHz cheap pic or some such. \$\endgroup\$ – Kortuk Mar 15 '12 at 22:36
5
\$\begingroup\$

Your math is wrong, as you might have seen for yourself if you had properly carried the units thru your calculations. You have 20 k interrupts per minute, which is 333 per second, which can be easily handled by even a modest microcontroller.

\$\endgroup\$
  • \$\begingroup\$ Thanks for the heads-up. Should be corrected in the question now. \$\endgroup\$ – Paul Beesley Mar 15 '12 at 18:02
3
\$\begingroup\$

You don't want to hook any external signal up to an interrupt pin without making very sure you won't run into a situation where you end up flooding the micro with interrupts. I learned that the hard way syncing to mains. Line noise = lots of interrupts. :-) That's bad design.

In your case I would use the capture and compare or timers; your fan tachometer outputs can be either event inputs or clock inputs; then you have a periodic (say 250ms?) interrupt that just reads and resets the counts. Just because your micro CAN handle 20k interrupts/sec doesn't mean that's a sane way to design a system.

Not enough timer or counter inputs? Depending on what the tach output looks like, you could add a resistor and capacitor to convert the signal to an analog voltage and feed those to the micro's ADC (most have 8 or more inputs). That would work very well if the tach pulse is the same width regardless of the speed. If the tach pulses are a fixed (or close) duty cycle, maybe a bunch of small F/V converters (there are lots, start with the LM2907 and go from there) feeding ADC inputs is a better option.

You could also gate the tach outputs into a single timer or counter using some discrete logic. A '138 1-of-8 decoder would work very well for this if your scanning speed was slow enough to count at least a few pulses for low rotation speeds. This is essentially the same idea as the ADC method above, but without the ADC.

\$\endgroup\$
1
\$\begingroup\$

An LPC1768 can take 20,000 Int/sec without a problem, as it can clock up to 100 MHz. Just remember that P2.10 triggers the bootloader, and not every GPIO can trigger interrupts, only Port 0 and Port 2 GPIOs can.

\$\endgroup\$
0
\$\begingroup\$

With the typical fan presenting 333 interrupts per second you could consider adding an simple 8->1 multiplexer chip that would select one of the fan TACH signals at a time and feed that into a single interrupt or timer input of the MCU. Three GPIO pins would be used to change the channel selection on the multiplexer chip and thus determine which fan is selected.

This scheme would allow for up to 8 fans to be monitored and you could measure multiple TACH pulses from each FAN in turn. Easily possible to detect fan problems for any given fan in a half second or less.

\$\endgroup\$
  • \$\begingroup\$ @Micahel Karas Brings up a good point. You don't need to sample every fan in parallel, continuously. Perhaps you only sample one fan for a few tach pulses and move onto the next. This would scale better than letting every fan cause interrupts in an uncontrolled manner. \$\endgroup\$ – gregb212 Apr 27 '16 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.