How to Design a Fan Cooling System Using a Microcontroller

introduce

I prefer peace and quiet. That's why I prefer to listen to softer broadcasts from BBC Radio 4 or Classic FM. That's why I like fully ground-in CW on PIN diode devices from Elecraft and Ten-Tec. That's why I run a Mac Mini for macOS and a fanless industrial PC for Windows.

Equipment cooling and equipment noise often go hand in hand. The more cooling required, the more airflow is required and the more fan noise will be generated. However, fan selection and mounting options will help mitigate this noise. Smart fan cooling systems will also control fan speeds.

This project is an offshoot of a unit whose goal is to cool communications suites in hot climates. Equipment needs to be monitored and cooled while keeping auditory nuisance levels to discreet levels. It can be adapted for cooling dummy loads, power supplies, computers, lighting.

plan

Looking for a solution, I found that cheap single-board controllers only provided a simple fan curve solution. These controllers simply tracked temperature differences based on fan speed. There were not many parameters that could be modified. At the other end of the scale, there are complex cooling controller systems for gaming computers that use PC software. These are fully configurable systems that balance the desired cooling performance with the sound levels produced.

It was difficult to find a middle solution. One between a simple standalone board and a complex system used by a PC. So an embedded system was designed to meet my requirements. Start simple and then build the design to specific needs. The project quickly included some easily customizable features that could be set to individual temperature and fan speed requirements.

feature

Two fan controllers.

Full fan speed control from 0% to 100% PWM.

The temperature sensing range is 0 to +120degC (32degF to 248degF).

The fan tachometer reads 9999 rpm.

The OLED display shows fan and temperature information.

Fan PWM command bar graph (10% intervals).

Rotary encoder for navigating the configuration menus.

Defines the temperature range, from minimum to maximum.

Defines the fan speed range, from minimum to maximum.

Three Auxiliary Fan-B Work Options:

a) Main fan A and auxiliary fan B operate in series (symmetrically).

b) The main fan A and the auxiliary fan B run in opposite directions (asymmetric).

c) The main fan A and auxiliary fan B are configured as hot standby.

Audible Fan-A fault or shutdown alarm.

Illuminated fan-A shutdown alarm.

Glowing DS18B20S sensor bus indicator LED.

Illuminated +12V and +5V power LEDs.

Configuration settings are saved in EEPROM for power-off recovery.

Configuration header for setting the temperature unit (degC or degF)

Configuration header for setting symmetric, asymmetric or hot standby mode.

Isolated external P input for enabling/disabling operation of auxiliary devices.

Main fan A failure detection, used to switch to fan B in hot standby mode.

Serial port for debugging and firmware upload.

In-circuit serial programming port for burning directly into memory.

KF2510 3+1P, fan connector socket.

Easy-to-use onboard reset switch.

Two versions

Two versions are designed. Both are functionally identical. However, each version is created to suit individual needs and build skills.

Shield Version: This is the easiest to build, as the Arduino board already handles half of the functionality. The shield attaches to the top of the Uno R3 board just like any standard shield. It provides the rest of the circuitry needed to get it running in a surprisingly compact package. Building the shield version is simpler, although you should still be able to handle the 15 0805 SMDs it uses. Code uploads are much easier to manage, and are performed as usual using the Arduino IDE over the USB serial port.

Embedded Version: This is built around an Atmega 328P-AU microcontroller and has all the circuitry required for a standalone, independent unit. The build complexity is greater. You should have and be proficient in SMD project building. Note that you will also need to be familiar with the ICSP port. Upload code to the microcontroller memory, at least initially, until you burn a bootloader if desired.

operate

This code was built dynamically as needed. From a simple temperature tracking fan speed utility it quickly avalanched into this customizable version. No doubt there are other programming methods to achieve what is desired. This is it. Regardless, my code can be easily corrected, modified, and improved to everyone's satisfaction.

Boot sequence

On power-up or reset, the device waits a few seconds for any fans that are still spinning to stop. The delay required depends on how hard the fans are spinning and their momentum. The delay can be defined in the code by modifying the variable spinDownDelay.

The code then runs a startup sequence which will first test the fan to find its minimum speed value. This will be used for stall detection during the fanJamCheck() function. This sequence sends increasing PWM values ​​to the fan, up to a ratio of 20:100 (20%). By that time, most fans will have started. Its progress is displayed on the OLED before finally starting the main code and one of the operating modes. Each of these selectable operating modes is listed and explained below.

Two basic fan modes are possible:

First, the passive up and down sweep mode simply follows the slope of a defined curve defined by the Fan Minimum and Fan Maximum values. The rate of this sweep can be configured, but the temperature sensor data is not used to control the fan speed.

Second, the active trigger mode activates the fan and controls its speed based on the slope of the curve defined by Temperature Min, Temperature Max, Fan Min, and Fan Max. There are two types of active trigger modes. The first sub-mode only takes the sensor temperature input to control the cooling fan. The second sub-mode takes the sensor temperature input but also requires an input voltage (P-IN) to enable the cooling fan. This can be used with an auxiliary device to trigger the fan controller only when the auxiliary device deems it necessary.

Scroll through the image below for an example of a configured slope:

A passive sweeping mode:

Here the fan speed will sweep up and down on the fan speed slope as defined previously by Fan Min and Fan Max. The temperature reading is not used, but the sweep rate can be changed.

Two active trigger modes:

Here the fan will be triggered when the minimum temperature is reached and only when the P-IN input is enabled.

Trigger at minimum temperature:

a) From zero fan speed (fan off until triggered).

b) Start at the lowest fan speed (the fan spins at the lowest fan speed until triggered).

Triggered at minimum temperature, but only if the P-IN input is also enabled.

a) Starts at zero fan speed. (Fan is off until triggered).

b) Start at the lowest fan speed (the fan spins at the lowest fan speed until triggered).

These fan modes and how they relate to speed and temperature are most easily viewed by scrolling through the sample temperature/fan speed graph that is displayed.

Configuration

In the configuration mode we define how the unit will operate and what cooling slope we want. Essentially it is by defining points on a graph to get the slope we want. We can enter this mode by pressing the rotary encoder button. Then scroll through the configuration menu, continuously pressing the same button. Turn the rotary encoder at each parameter to modify its value and thus define a new operating mode or temperature slope.

Configuration Menu:

OF MIN

Set the minimum fan speed value (5% steps).

FAN MAX

Set the maximum fan speed value (5% steps).

TEMP MIN

Set the minimum temperature value which will trigger the fan to Fan Min.

TEMP MAX

Set the maximum temperature value, at which the fan will rotate at Fan Max.

model

Scan or trigger

Set passive up and down sweep speeds. Or trigger fan speeds to actively track temperature data from a DS18B20 sensor.

Scan rate

(Available if Sweep was previously selected) 1/Slow to 10/Fast. Select how fast the fan speed sweeps from Fan Minimum to Fan Maximum.

TRIGGER

(Available if Triggered was previously selected)

1 Temp/Zero. Temperature is triggered from zero. Will trigger at Temp Min and start spinning at Fan Min speed. When not triggered, fan speed will wait to reach zero.

2 Temp/Fmin. Temperature triggers from the fan minimum value. Will trigger at Temp Min and start rotating at Fan Min speed. When not triggered, the fan speed will wait at Fan Min.

3 Pin / Zero. Triggered from temperature zero, but requires external P input to enable. Will trigger at Temp Min and start spinning at Fan Min speed, but only when enabled by P input. When not triggered, fan speed will wait to reach zero.

Pin 4 /Fmin. Temperature triggered from Fan Min, but requires external P input to enable. Will trigger at Temp Min and start spinning at Fan Min speed, but only when enabled by P input. When not triggered, fan speed will wait at Fan Min.

TEMP OFFSET

-9 to +9 degrees. To correct for any temperature errors in the DS18B20 sensor, this compensation value can be added. The default is 0 degrees, no correction.

SAVE & EXIT

Yes/No.Yes, will exit configuration mode with the appropriate Morse "R" tone and a brief "Configuration Saved" message. Your settings will be saved to the EEPROM. No, will cycle through the configuration options again.

Because the FAN MIN and FAN MAX values ​​are dependent on each other. It is not possible to set the FAN MAX value below the FAN MIN value or to set the FAN MIN value above the FAN MAX value. Similarly, the TEMP MIN and TEMP MAX values ​​are dependent on each other. It is not possible to set the TMP MAX value below the TEMP MIN value or to set the TEMP MIN value above the TEMP MAX value.

This code limits the allowed range you can set. For example, if you cannot select a lower FAN MAX value, it may be because you are trying to set it below the FAN MIN value.

default setting

After the unit is installed, the following options rarely need to be changed. They are configured by using two header pin jumpers, whose settings are read when the switch is opened or reset.

1. Auxiliary FAN-B settings using jumper J1/U2:

ASYMetric: Auxiliary Fan B will rotate at the opposite speed to the main Fan A. Therefore, when Fan A is at maximum speed, Fan B will be at minimum speed. These fan speeds will dynamically follow the temperature slope defined by Fan Min and Fan Max.

SYMMetric: Auxiliary Fan B will rotate synchronously with the main Fan A. So when Fan A is at maximum speed, Fan B will also be at maximum speed. These fan speeds will dynamically follow the temperature slope defined by Fan Min and Fan Max.

STandBY: Secondary Fan-B acts as a backup for the primary Fan-A in a hot standby role. Therefore, Fan-B is usually shut down until Fan-A gets stuck or fails. When Fan-A fails, Fan-B takes over.

2. Temperature setting unit of jumper J2/U1:

degF: Fahrenheit. Used in the United States, Liberia, and the Cayman Islands.

degC: Celsius. Used in other parts of the world.

Building Blocks

Microcontroller:

We don't need the processing power or bells and whistles found in the ESP8266 or ESP32. The Arduino platform with its ATmega 328P chip has more than enough speed, memory space, and GPIO pins.

Of course, like the original Arduino UNO R3, an ATmega328P microcontroller is used in the embedded circuitry. This microcontroller offers 32K Flash, 2K SRAM, and 1K EEPROM storage. Its 16Mhz clock speed is more than enough to run our moderate tasks, and it has enough input/output pins to meet our needs.

The AU chip package was chosen. It is smaller, cheaper and easier to source than the larger PU DIP version. It is ideal for small embedded board applications. However, it is not too small to handle when building or actually testing. During prototyping, this Atmega 328P was mounted on a breadboard using a QFP/TQFP32 chip adapter. The legless MU version is smaller but more difficult to handle.

Temperature sensor:

The Dallas Semiconductor DS18B20 may not be the most accurate temperature measuring instrument, but it is adequate for our purposes. It measures temperatures from -55°C to +125°C (-67°F to +257°F) with an accuracy of -10°C to +85°C +/-0.5°C.

For our purposes, the code will limit the temperature range to between 0degC and 120degC (32degF and 248degF). Outside of this range, it will display an out of range (OOR) "exclamation mark" icon next to the temperature value. The value will bottom out at 0degC and 120degC (32degF and 248degF).

The three-pin TO-92 version of the DS18B20 is probably the easiest package type to use. An LED pull-up resistor to Vdd on the sensor data line improves data transfer and provides some visual feedback that the sensor is communicating with the microcontroller. Here, a 2K resistor works well to blink the LED. Some kit modules use a 4.7K value here. It depends on the voltage drop across the specific LED and the brightness desired.

OLED Display:

A small 0.91" OLED was used. It has a resolution of 128 x 64 pixels, which when used with Bill Greiman's SSD1306 library and the "fixed_bold10x15" font, gives two lines of approximately 12 characters of text. These OLED displays have an I2C bus, making them a perfect fit for our microcontroller. The required +5V supply voltage is conveniently enough, since it is the same as the rest of the board. Some OLED boards specify a +3.3V supply voltage requirement, which can be checked by seeing if there is or isn't a +3.3V regulator. My board has a tiny 662K low dropout +3.3V regulator, confirming that it accepts +5V, which it then converts to +3.3V on its own. Regarding the I2C logic level inputs, they are +5V tolerant and I didn't need a level shifter.

SSD1306Ascii is an unbuffered character library for small monochrome OLED displays written by Bill Greiman. I often use it in projects using OLEDs with the fixed_bold10x15 font. It provides a readable character size for my tired eyes on these small displays. For this particular project, the FAN_fixed_bold10x15 file is a modified version of the font where I added some extra icons for use with the fan controller. This font file can be included in the same sketch directory and added to the Arduino IDE for easy editing.

FAN_fixed_bold10x15 is the fixed_bold10x15.h font that has been modified by adding the extra characters used by the fan controller's OLED display. Reverse engineering this font to create custom characters and icons is described in detail later.

Optocoupler:

The PC817C is a general purpose optocoupler that is widely used in many circuits to provide electrical isolation from auxiliary devices. There are several versions of this component. The version with the "C" suffix is ​​used here. Different versions have different gains. The gain of an optocoupler is expressed as the current transfer ratio (CTR), which is the collector current (IC) at the output divided by the forward current (IF) at the input, multiplied by 100%. You can use other versions and test functions by calculating and changing the value of resistor R3 to accommodate different gains.

In this version, the calculated 1K resistor value works well. Some real-world testing confirms this theory: P-IN voltages of 5V, 9V, 12V, and 13.8V produce currents of 3.8mA, 7.8mA, 10.8mA, and 12.6mA, respectively. These are considered the most likely auxiliary input voltages to use. Since the internal LED of this optocoupler drops about 1.2V, they produce corresponding power values ​​of about 4.5mW, 9.4mW, 13mW, and 15mW, respectively. Looking at the datasheet, the maximum input values ​​we are allowed are If=50mA, Vr=6V, and Pin=70mW. The 1N4148 placed across the input LED is to protect against Vr above 6V. The maximum output values ​​allowed are Vce=35V, Vec=6V, Ic=50mA, and Pc=150mW. The internal pull-up of the MCU appears to be about 50k, since 0.1mA is measured here. For this optocoupler, Ptot = 200mW maximum (total input and output power must not exceed 200mW).

Other optoisolators can be used as per similar datasheet recommendations. Alternatively, you can simplify the circuit by removing the optocoupler isolation and just pull the enable P-IN low. Port B0 of the MCU has its internal pull-up resistor activated in the code.

serial port:

There is a serial port already installed on the UNO R3 board. This is used for uploading and debugging in the classic Arduino way.

I have also included a serial port in the standalone version. These 6 header pins align perfectly with most FTDI FT232RL USB to Serial adapter modules. It also allows debugging with the Arduino IDE if a bootloader is available, and indeed sketches can be uploaded. Don't forget to switch the FTDI USB to Serial board to use +5V (not +3.3V). For USB to Serial programming and debugging, the fan controller should of course be powered.

ICSP Port:

The UNO R3 board already has an ICSP port installed. This is required to burn code directly into its microcontroller memory, which we rarely use. This is probably how the manufacturer burned the Arduino bootloader into the UNO.

I have also included an ICSP port on the embedded version. This is the only way to initially burn a bootloader onto the standalone version. These 3x2 header pins align perfectly with most common ICSP programmers like the USBasp. It allows direct loading of the ATmega 328P. For ICSP USBasp programming, the fan controller should be powered off, as most programmers like the USBasp will power their target itself.

Note that some older ICSP programmers require power from their target to operate, in this case the fan controller unit should be powered. Some may only need to see a voltage on ICSP pin 2 to operate. Your mileage may vary. It's always best to check with your specific programmer.

Don't forget to switch the board to use +5V (not +3.3V). Section 27.8 of the ATmega datasheet describes in-circuit serial programming of the chip.

Tachometer Noise Filter:

Any noise on the tachometer line from the fan RPM pin 3 can be a problem and give a false reading. This noise can be extra switch bounce, like pulses. Although it is common to use tachometer circuits that use Hall sensors or optocouplers instead of mechanical switches.

Fans running at low RPMs have these noise pulses that create a greater discrepancy in estimating the actual RPM value.

For example, at low speed, a fan might send out about 8 pulses in 1 second. These 8 pulses equate to 4 rpm because the fan sends two pulses per revolution. Therefore, 4 rpm is 240 rpm (4 rpm x 60 seconds). Noise pulses due to bounce may create an extra 9th pulse that incorrectly equates to 270rpm (4.5 rpm x 60 seconds). This is a total error of about 12% of the actual value.

At higher RPMs, these extra noise pulses in the waveform have less impact on calculating the correct RPM value. For example, at higher speeds we might get 266 pulses, which actually means 133 rpm or 7980 rpm (133 rpm x 60 seconds). The extra noise pulses here make a total of 267 pulses, which equates to 133.5 rpm or 8010 rpm (133.5 rpm x 60 seconds), which is a smaller difference from the total value. The error is less than 4% of the total actual value. This is just an example, as most fans run below this at their maximum speed.

To mitigate the effects of any noise on the fan RPM output, an integrating filter consisting of R2 and C1 (shielded circuit) or R7 and C14 (embedded version) is used. Through some calculations and experimentation, an adequate time constant was found. The values ​​of 1K and 1nF gave a suitable time constant to filter out any higher frequency noise pulses present on the fan tachometer signal.

AMS1117 LDO Regulator:

This already forms part of the Arduino power subsystem. It provides a regulated +5V which is also used to power the fan controller shield. It is a tried and tested robust regulator for its size. Made by different companies and readily available. Different manufacturers publish different datasheets with slightly different maximum input voltage and power consumption criteria. I have also used it on standalone embedded boards.

Code

This code was built upon and features and functionality added over time and as my needs dictated. I am not a programmer and there is no doubt some unnecessary complexity in the program flow, similar to Chartres' maze. Sprinkling global variables throughout the code must also increase efficiency. This is it. It serves my purposes and does not noticeably slow down operation.

#define DEBUG 1 or 0 is used to enable or disable output of debug information on the serial port. Your choice will be set at compile time. When enabled, the Serial Port Debug OK message is displayed first. This is followed by the sketch file name with the date and time of the compilation.

#include "FAN_fixed_bold10x15.h" to allow use of my adapted fixed_bold10x15.h font. This has the special icon characters that the fan controller uses to show mode and status. It should be in the same folder as the fan controller sketch.

Some specific libraries that need to be installed using the IDE's library manager are:

OneWire.h and DallasTemperature.h are used to communicate with the Dallas Semiconductor DS18B20 temperature sensor.

EEPROM.h facilitates access to the microcontroller's non-volatile EEPROM memory space.

SSD1306Ascii.h and SSD1306AsciiWire.h use the OLED display and access its I2C bus.

TimedAction.h is needed to be able to prototype the different tasks in the code. Three threads will run pseudo-coherently. These are used to read the rotary encoder, read the RPM speed of fan A, and read temperature information from the sensor.

Functions:

writeConfig() and readConfig() will read and write configuration data to the chip's EEPROM memory. EEPROM addresses can be read an unlimited number of times, but can only be written to about 100,000 times on average. If you change the configuration 10 times a day, that equates to a write cycle life of about 27 years. Function firstRunCheck() looks for the values ​​73 and 42 for key1 and key2. Two arbitrary numbers. A nod to the ubiquity of radio stations and The Hitchhiker's Guide to the Galaxy. Function firstLoadOfEeprom() will populate the new microcontroller chip with valid EEPROM values ​​if the chip has never been configured before, if not found.

At power on or reboot, the function findFanStopLimit() runs. This finds the PWM value at which the main fan A starts spinning. It returns this value as minLimit to the variable fanStopLimit. This PWM percentage value is later used to detect the stopping or failure of the main fan A.

Functions oneDit() and oneDah() are used with oneRoger() to sound the Roger confirmation 'R'. They also produce the Fan-A fault alarm sound. These two functions produce the Morse dot and dash sounds through the buzzer. This was done directly by me through bit manipulation of the Port C register with the passive buzzer connected to PC0 and PC1. By driving each output out of phase we increase the volume because we actually have a 10V potential difference across the piezo plates of the passive buzzer.

This is similar to how the excellent ToneAC library works. However, for this simple application, I have avoided using that library by coding this function directly. We don't need its volume and frequency control options, nor its timer requirements.

The function encoderRead() is a prototype thread that is triggered every 50 milliseconds to read the rotary encoder.

Using the function menuClicked() we detect the press of the rotary encoder momentary switch button.

Functions valueChanged() and delimitValue() are used to select individual values ​​for each configuration parameter.

The function oledDisplay() is used to print to the two-line display of the SSD1306 OLED using a custom font.

When the temperature of TEMP MIN is reached and triggered, the function showTempTrigIcon() displays a thermometer type icon.

Function tachCounter() is a prototype thread that is triggered every 1 second to read the RPM tachometer waveform from the main fan A.

The function getTemperature() is a prototype thread that is triggered every 3 seconds to query and read the temperature data from the DS18B20 sensor.

Function triggerCheck() checks the temperature trigger and considers if we are using P input mode and have an enable signal at the P-IN connector.

Function fanBsetup() reads the relevant jumper position to set the auxiliary fan B operation mode to asymmetric, symmetric or standby when the switch is ON.

The function fanBconversion() calculates the operating speed of fan B compared to fan A, taking into account the current operating mode of asymmetric, symmetric or standby.

Function percentToPWM() converts the percentage speed value into a value suitable for feeding directly to the timer register for PWM control. This is used to control the speed of Fan-A.

The function percentToBars() displays the PWM commanded to Fan A as a moving bar graph on one line of the OLED display.

Function fanJamCheck() checks the stopping of fan A and signals it after four violations. It then sounds the alarm and flashes the red warning LED.

The stepIncrement() and steppedDecrement() functions increase and decrease the speed of the fan in passive sweeping mode.

The function pwm25kHzSet() sets the PWM frequency to 25khz. This change is needed because the fan requires a PWM signal that runs at 25KHz, and the default Arduino PWM frequencies available are only 490Hz or 980Hz, depending on the pin used.

The ATmega328P has three timers and we can use them all at the same time. A timer is a register that increments (or decrements) for each clock pulse. The 328P has three and their use is switched between functions such as delay(), millis(), micros(), Servo(), Tone() and other libraries. The clock frequency is taken from the 16MHz crystal clock. This clock frequency can be divided down by a prescaler before being fed to the timers. When the timers increment to their maximum register size they will overflow. For timer0 and timer2 which are 8-bit timers this is 255 (65535 for 16-bit timer1). It is also possible to set the value at which this overflow occurs. We do not need to wait until the timer register reaches 255 (or 65535) to flag an overflow. The control register configures timer1 for mode 10, no prescaler, and a count of 320. A value of 320 with our crystal clock at 16Mhz will give us a 25KHz PWM signal. The code uses the function percentToPWM() to convert it from a user-friendly percentage fan PWM value.

The interrupt service routine encoderISR() is used to read the rotary encoder.

The interrupt service routine tachISR() is used to count the pulses from the tachometer RPM waveform sent by the main fan A.

EEPROM Memory

Displays details of the default values ​​that are loaded when the computer is first powered on.

Address 0 key1 73d Dahdahdiddley.。.Diddleydahdah。

address1 key2 42d life, the universe and everything.

Address 2 fanMin 10d Minimum fan speed = 10%.

Address 3 fanMax 90d Maximum fan speed = 90%.

Address 4 tempMin (°C) 40d Minimum temperature 40degC.

Address 5 tempMax (°C) 70d Maximum temperature 70degC.

Address 6 tempMin (°F) 100d Minimum temperature 100degF.

Address 7 tempMax (°F) 160d Maximum temperature 160degF.

Address 8 Mode 1d Scan.

Address 9 Scan rate 5d 5 (medium speed).

Address 10 triggers 1d by temperature at 0% fan speed.

Address 11 tempOffset 0d 0 degrees temperature correction.

Address 12 Save and exit 0d 0.

The read and write functions of the code will skip addresses 4 and 5 or 6 and 7, depending on which temperature units are selected using the hardware jumpers (U1 on the shield or J2 on the separate PCB).

Custom Characters

The fixed_bold10x15 font included in the SSD1306Ascii library is my font of choice. It is clear and easy to read. However, it only gives us two lines of about 11 or 12 characters to display any information. I resorted to using custom icon characters to get more information on the small 0.91" OLED display. I modified the original fixed_bold10x15 font included in the SSD1306Ascii library. This modified font is FAN_fixed_bold10x15. It is called by the code and should reside in the same sketch folder.

Additional characters print specific icons used by the fan controller code to the OLED. They include characters that generate a fan speed bar graph, an OOR warning, Celsius and Fahrenheit symbols, an RPM fan rotation symbol, an RPM fan stuck warning, a trigger mode in use, a scan speed in use, and a P input enable icon.

Example of scrolling through displayed information:

The bar graph shows our controlled speed of the main Fan A to within 10%. The two letters to the left of this PWM bar graph indicate our operating mode. The bottom line shows the temperature and the Fan-A tachometer speed in RPM. Out of range OOR temperatures are indicated with an "exclamation mark" icon. Any extended fan stop of Fan A is also indicated with an "exclamation mark" within the RPM icon. When the fan is triggered when the temperature minimum is reached, a "thermometer" icon is displayed. In P input mode, an "arrow" icon indicates when the enable signal is present.

These were designed with pen and paper, then the original font files were reverse engineered and modified. The hex value of each new character was added to the original file through editing.

Main components:

Arduino UNO R3 (which already has elements like ATmega 328P microcontroller, clock oscillator, power input and voltage management, reset system, USB-serial connection, ICSP connection, etc.).

DS18B20 temperature sensor.

Optocoupler PC817C.

OLED SSD1306 0.91" display.

LED indicator and passive buzzer alarm

Rotary encoder for menu input.

Onboard reset button.

Initial setup jumper header.

Shielded version circuit principle:

The shield provides a neat add-on to the top of the Uno R3 board. It provides an easy way to connect the fan controller's specific circuitry to the microcontroller and subsystems already on the Uno board. Refer to the shield schematic.

Fan-A and Fan-B have independently controlled PWM output signals which are derived from pins D9 and D10. The RPM tachometer waveform is taken from Fan A, passed through an RC noise filter and fed to pin D2. This is used to calculate and display the rotational speed of the main Fan A.

A high on pin D11 will illuminate red LED4 through its 1K current limiting resistor R4. The code does this when it determines that the main fan A is stuck, to signal an anomaly. Likewise, it sounds an alarm through passive buzzer SG3 across A0 and A1. Each output is out of phase with each other, which increases the noticeable volume level. Still, I have a small 220 ohm resistor R1 to reduce the current here to an acceptable level. This piezo buzzer also sounds when the switch is opened and confirms that the configuration settings have been saved.

The SSD1306 OLED uses the I2C bus. Its data and clock lines are connected to the Uno's pins A4/SDA and A5/SCL. Two pull-up resistors R5 and R6 of value 5.1K may or may not be needed. Some OLED boards will operate without these as they already have them built in.

Rotary encoder SW1 provides a way to scroll and set the desired configuration. The DT and CLK lines are read by pin inputs D3 and D4. The momentary switch is grounded when pressed. The microcontroller reads this low level at pin D6 to cycle through the menu items.

The output of the PC817C optocoupler U3 is brought to input D8 on its pin 4. It is used to optically isolate the enable signal from any auxiliary device we may choose to connect to the header P-IN. If the optocoupler output side is illuminated by the internal LED on its input, this value will be low. Resistor R3 limits the current through the input level to within specification. The value of 1K is suitable for the most common voltages we expect to have in a ham shack. A 1N4148 diode protects the same input diode from accidental reverse polarity connection. Without this protection diode, the optocoupler's LED will not be able to withstand reverse voltages of more than 6V.

Please note: The P-IN header connections are different from the embedded version. The enable voltage for the external device should be connected to pin 2 of the header. Its negative line, usually the ground for the auxiliary device, is connected to pin 1 of the P-IN header. This is marked "1 G" on the silkscreen.

P5 is where we connect the DS18B20 temperature sensor, making sure we respect its pinout. Its data line DQ goes to pin D7 and is used as a single-wire bus to communicate with the sensor. The white LED2 will blink when we ask and receive temperature data from the sensor. I found that a pull-up resistor is needed to ensure a good bus conversation.

A value of 2K gave me a steady stream of data and ample illumination for the 0805 surface mount LEDs I used. Higher values, such as 4.7K, can be used, but it ultimately depends on the voltage drop across the LEDs you choose to use. This can vary by manufacturer, model, and color. Your mileage may vary.

Header U1 is read during an open at pin D5. If pins 1 and 2 of this header are bridged by a jumper, D5 is low and the code will use Fahrenheit. If pins 2 and 3 are bridged, there is actually nothing in the circuit. The internal pull-up on D5 will keep it high and Celsius units will be used.

Using header U2 we can select the operating mode between the two fans. The external pins are connected to Uno pins A2 and A3. Reading the state of these inputs will define how the auxiliary fan B works with fan A. Symmetrical (in series) or asymmetrical (opposite). The jumper connects one or the other pin to the central ground pin. If the jumper is not installed, both sides are high and a logic 1 will appear on both input pins A2 and A3. Then, if Fan-A fails, Fan-B will wait in hot standby mode.

I added a small tactile switch SW2 to the shield. This is connected to the Uno's RESET pin. In fact, it is parallel to the Uno's own reset switch, but is now covered by the shield and almost inaccessible. Like this, a reset can still be performed easily.

To power the fans we need +12V. This voltage comes from the barrel connector and is then regulated to +5V by the AMS1117 to power the rest of the UNO circuitry. For the fans to work we must always supply the UNO with about +12V on this barrel connector. The DC input to the fans is taken from Vin, which is the pin connection to which the input voltage is recovered after passing through the reverse voltage protection diode marked M7 on the Arduino. This is a standard 1N4007 rectifier diode which drops the 12V by about 0.7V. The UNO's AMS7111 +5v LDO regulator is rated for 800mA. Ideally we need to go below this as we are already at the top end of his recommended input voltage (although the maximum input is higher). Therefore the small linear regulator needs to shave off about 6V from the main 12V used to power the fans. As an example, the total current with both fans running at 100% was measured to be about 270mA. Around 100mA per fan (in line with the specified current draw specified by the fan manufacturer) and 70mA for the Arduino board. We can see that we are well off the quoted 800mA and very much within the AMS1117 power consumption spec.

While I often see up to +20V quoted, Arduino recommends no more than a +12V input for powering their UNO boards. This is all based on the current and power the onboard LDO regulator has to handle. Using +12V at the barrel connector input, after the diode drop, we still have about 11.3V which is acceptable for driving a fan. This can be checked on the fan datasheet. Typically 12V fans will take 10V to 13.2V (some even 7v to 13.8V). Using the 13.8V commonly found in any hut power supply, we have 13.1V. Still within the fan specs. This slight increase does not put any more dissipation burden on the AMS1117 +5V regulator since we are not running high currents through it.

Green LEDs 1 and 3 generally assure us that we have +5V and +12V on our board. LED1 uses a 1K current limiting resistor R7 for +5V and LED3 uses a 2K current limiting resistor R8 for +12V. The difference in resistor values ​​is due to the different voltages being indicated. Like this, the brightness levels will be very similar.

Standalone embedded version:

This is on a single board with an embedded ATmega328P-AU, including all the other subsystems. The serial and ICSP port headers are still available for debugging and necessary chip burning. Naturally, there are more surface mount components to solder here. This of course includes the 328P-AU. Its 0.8mm pitch TQFP package will be more challenging. The same goes for configuring and loading in an initial sketch and/or bootloader.

Main components:

ATmega 328P-AU

Crystal clock oscillator.

DS18B20 temperature sensor.

Optocoupler PC817C.

OLED SSD1306 0.91” display.

AS1117 5V voltage regulator.

LED indicator and passive buzzer alarm

Rotary encoder for menu input.

Onboard power switch.

Onboard reset button.

The USB serial functionality is available via an external FTDI (Future Technology Devices International) board, through the "Serial" port header pins.

The external USBasp board provides ICSP functionality through the "ICSP" port header pins.

Initial setup jumper header.

Embedded version circuit principle:

This release provides a single board platform for the fan controller code. It is a standalone variant of the fan controller, built around the ATmega 328P-AU chip. The same one used by many Arduino UNO R3 boards. Refer to the embedded board schematic.

This circuit uses an ATmega 328P. Not the 328PB version, which has some pinout differences. The suffix AU refers to the small QFP32 package type, which I found to still be relatively easy to handle during testing and building.

Since we have lost the convenience of the built in Arduino bootloader, we will have to use ICSP to upload to the microcontroller's memory. Other features such as power management, clocks, reset and a serial debug port, ICSP port will also need to be added.

Both the shield and embedded circuits use the same code. This is because all of the circuit functions and connections are designed to be compatible with each other. Below I have indicated what the equivalent Arduino Uno connection is for each input or output as this is what is referenced in the sketch.

Fan-A and Fan-B have independently controlled PWM output signals which are taken from pins 13 and 14 of the microcontroller. These are port pins PB1 and PB2 which are equivalent to I/O pins D9 and D10 on the Arduino board. The RPM tachometer waveform is taken from Fan A, passed through an RC noise filter and fed to pin 32 which is port pin PD2 (Arduino D2). This is used to calculate and display the speed of the primary Fan-A.

When the code detects that Fan A has stopped, a high level on Pin 15, Port Pin PB3 (Arduino D11) will illuminate the red LED4 through its 1K current limiting resistor R4. Likewise, it will sound the alarm through the passive buzzer SG3 across Pins 23 and 24, Port Pins PC0 and PC1 (Arduino A0 and A1). Each output is out of phase with each other, which increases the apparent volume level. Still, there is a small 220 ohm resistor R1 to reduce the current here to an acceptable level. This piezo buzzer also sounds when the switch is opened and confirms that the configuration settings have been saved.

The SSD1306 OLED uses the I2C bus. Its data and clock lines are connected to pins 27 and 28. These are port pins PC4/SDA and PC5/SCL (which are A4/SDA and A5/SCL on the Uno). For completeness, two pull-up resistors R5 and R6 with a value of 5.1K are included, although some OLED boards will work without these as they already have pull-up resistors. My OLED already has a +3.3V regulator and can tolerate +5V logic, so no level shifter is needed.

The rotary encoder SW1 lines DT and CLK are read on pins 1 and 2 of the microcontroller. These are port pins PD3 and PD4 (same as D3 and D4 on the Uno). The momentary switch is connected to ground when pressed. This low level is read at pin 10, which is port pin PD6 on the microcontroller (D6 on the Uno), to cycle through the menu items.

The output of the PC817C optocoupler U3 on its pin 4 is brought to the microcontroller pin 12, which is port pin PB0 (D8 on the Arduino). It is used to optically isolate the enable signal from any auxiliary device we may choose to connect to the header P-IN. If the optocoupler output side is illuminated by the internal LED on its input, this value will be low. Resistor R3 limits the current through the input level to within specification, and the 1K value is suitable for the most common voltages we expect to have in a ham shack. A 1N4148 diode protects the same input diode from accidental reverse polarity connection. Without this protection diode, the optocoupler's LED will not be able to withstand reverse voltages of more than 6V.

Please note: This P-IN connector is different from the shielded version. Care must be taken when connecting an external trigger. The negative side of the external line, usually ground, should be connected to pin 2 of the P-IN connector. The positive side of the external line should be connected to pin 1. This is marked as "+VE 1" on the silkscreen of the connector.

P5 is where we connect the DS18B20 temperature sensor, making sure we follow its pinout. Its data line DQ goes to pin 11, or port pin PD7 (D7 on the Uno). This is the single-wire bus that communicates with the sensor. White LED2 will blink as we ask and receive temperature data from the sensor. A pull-up resistor is needed to ensure good bus communication.

I found a value of 2K to provide a steady stream of data and adequate illumination for the 0805 surface mount LEDs I used. Higher values ​​such as 4.7K can be used, but it ultimately depends on the voltage drop across the LEDs used. This can vary by manufacturer, model, and color. Your mileage may vary.

Using header J1, we can select the operating mode between the two fans. This happens when the switch is ON. Pins 1 and 3 are connected to pins 26 and 25 of the ATmega, respectively. These are microcontroller port pins PC3 and PC2 (equivalent to Uno pins A3 and A2). Reading the state of these inputs will define how the auxiliary fan B works with fan A. Symmetrically (in series) or asymmetrically (opposite) with the main fan A. Jumper placement will ground one or the other pin on pin 2. If the jumper is across pins 3 and 4, it is actually an open circuit. A logic 1 will appear on both input pins A2 and A3, because their internal pull-up resistors are configured. With the jumper on the left, set asymmetrical operation. With the jumper in the middle, set symmetrical operation. With the jumper on the right, set hot standby.

While we don't actually need it to bridge pins 3 and 4, it's just a handy way to store the little jumper and prevent us from losing it.

Header J2 is also read during the switch opening and routed to pin 9. This is port pin PD5 (Uno D5). If pins 1 and 2 of this header are bridged by a jumper, pin 9 is pulled low and the code will then calculate the temperature in Fahrenheit. If pins 2 and 3 are bridged, there is actually nothing in the circuit. Again, we just store the jumper on pins 2 and 3 to avoid loss. Here, the internal pull-up on pin 9 will remain high and the code will work in Celsius temperature units.

Switch SW18 is connected to the reset circuit of the device on pin 29 of the ATmega 328P. Pulling it low will force the microcontroller to reset. Pull-up resistor R2 holds it high in normal operation. Diode D2 protects the microcontroller from any voltage spikes that would occur due to capacitor C7 on the DTR line of our serial port. If this DTR goes high, the voltage on our reset line will briefly double. The 1N4148 safely shunts this 10V. Capacitor C7 is needed on the DTR line of the serial port, to act as a differentiator. Most USB-to-serial chips will set DTR low and keep it low when connected to the serial port. We only need a short pulse to initially restart the microcontroller. The reset pin of the ATmega is also used by any ICSP programmer, so it is also connected to ICSP header pin 5.

Green LEDs 5 and 6 in summary indicate that we have +12V and +5V arriving at our board. LED5 uses a 2K current limiting resistor R10 to indicate +12V and LED6 uses a 1K current limiting resistor R11 to indicate +5V. The difference in resistor values ​​is due to the different voltages being indicated. Like this, their brightness levels will be equal.

After the DC barrel connector and power switch SW2, the AMS1117 +5V regulator U36 provides +5V to the board. Versions of this regulator are quoted as having a maximum input voltage of 15V to 20V. The recommended values ​​are lower though. The power dissipation and heating will depend on how much current it will pass. It stays within the power dissipation spec because the total current passing through it is relatively low. Nonetheless, I included a makeshift PCB heat sink because I had the board space. The +5V tab of the regulator is connected to this, and it also has thermal vias to the bottom PCB layer.

The 1N4007 diode U1 across the AS1117 is for protection when using the ICSP port. Typically, the ICSP programmer will put +5V on pin 2 of the ICSP port. This protects the AMS1117 LDO regulator from the feedback voltage when we burn the ATmega chip.

To power the fan we need +12V. This voltage comes from the barrel connector before being regulated to +5V by the AMS1117. The fan voltage is taken after the input voltage passes through the reverse voltage protection diode marked M7. This is a standard 1N4007 rectifier diode which also drops the 12V voltage by about 0.7V.

The AMS7111 +5v LDO regulator is rated for 800mA. Ideally we need to be below this as we are already at the top end of his recommended input voltage (although the maximum input is much higher). The small linear regulator needs to drop about 6V from the main 12V used to power the fan. However, the total current draw is well below this 800mA maximum. So even with the need to drop 6V, with such a low current through it, we are still well below the power consumption spec of the AMS1117.

As mentioned before, the +12V required to power the fan is taken from the cathode of U37. This is a 1N4007 diode, which gives us some simple reverse power protection, but will drop about 0.7V. Even with this drop there is still enough voltage to drive most fans within their specified voltage tolerance. This can be checked on the fan's datasheet. Typically 12V fans will take 10V to 13.2V (some even 7v to 13.8V).

Using +12V at the barrel connector input, after the voltage drop of the diode, we still have about 11.3V, which is acceptable. Using 13.8V, which is a normal output for any hut power supply, we have 13.1V. Still within most fan specs, but you may notice an increase in RPM. This small input voltage increase does not put much strain on the AMS1117 +5V regulator.

Use a 16MHz external crystal Q6. This option must be configured in the ATmega's fuse settings. The 1M resistor R13 on the crystal Q6 improves the start-up and maintenance of oscillation for various crystal specifications. Some microcontrollers have this feature built in. It is included for completeness.

Many Arduino boards use a ceramic resonator instead of a crystal. While not as accurate as a crystal, it is smaller and seems accurate enough for everyday applications. I chose a crystal because 16MHz crystals are easier to find in my area and easier to handle than a tiny ceramic resonator. I was not sure if the internal ATmega's oscillator would be good enough for our needs, especially for the serial communication functions.

Serial header H7 can be used for debugging. It can also be used to upload new sketches if a bootloader has been previously burned to the microcontroller. An FT232RL FTDI USB to TTL serial adapter module is required, set up to operate at +5V. The header pins will align with most available adapter modules. The ground side is on pin 1 marked on the serial port silkscreen. The two 1K resistors R8 and R12 on the Tx and Rx lines limit the current. So if the adapter side goes high then the microcontroller code sends the corresponding output pin low, which avoids a direct short to ground. Vcc pin 3 of the serial header is not connected. The fan controller is powered by its own regulator, while the breakout board is powered via the USB connection from the computer. Both have a common ground. The 100nF capacitor C7 has already been discussed. It forms part of the reset circuit, ensuring that a short low pulse from the serial port DTR pin triggers the reset.

To use the ICSP port J5, you need an in-circuit serial programmer to burn directly to the microcontroller's memory. With the new ATmega 328P-AU, this will be the only way to upload the first code to the microcontroller. If you burn the bootloader, you will be able to upload sketches in the classic way using only the serial port and the Arduino IDE. The ICSP header pinout follows a standard layout, as on the Arduino Uno R3 board. For ICSP programming I use the cheap and easy to use USBasp programmer. Of course other programmers can be used if the pinouts match.

The fan controller board should be powered off when programming, as it will draw power from the ICSP programmer. However, some older ICSP programmers require voltage from their target at ICSP pin 2 to function properly. In this case, the device should be powered on.

The ICSP MISO and MOSI lines are on pins 1 and 4 of the header and are connected to the microcontroller MISO and MOSI pins 16 and 15. The clock line SCK from header pin 3 is connected to the chip's SCK pin at 17, and the reset line RST joins the reset circuit at header pin 5 and is connected to the chip's reset pin at 29. The red LED4 discussed earlier is used to signal that the main fan A is stopped during normal operation and will now be used to show us any ICSP activity. Port pin PB3 is also the MOSI pin, so LED4 will flash when we connect the chip.

Embedded version build:

Again, this board uses a mix of through-hole and surface mount components. The 0805 SMD package is preferred because this small size is still relatively easy to handle. It may be reasonable if you are practicing your SMD soldering skills for the first time on a simpler project or even a practice board. The embedded version is not a good first SMD project. There are enough pitfalls to watch out for in the process of getting a working embedded version. This can cause a lot of frustration for a newbie. Those new to surface mount or embedded microcontrollers are better off starting with the shielded version. If you are confident, I will now go through a logical workflow that may avoid homemade dissatisfaction.

- For SMDs I use a small reflow oven and some low temperature leaded solder paste. The heat can be easily controlled by using a specific temperature profile that matches the solder used. Of course you can also use a hot plate and hot air rework station, but be careful about melting any plastic housing components by overheating. For example, beware that the dielectric around electrolytic capacitors can be damaged. For solder, the lead-free type is all hype now, but believe me, it's not that forgiving. Lead-free solder tends to bead up and doesn't flow or stick as easily. It's reasonable for large PCB factories to use environmentally friendly solder. For our small home hobby, it's really an environmental drop in the ocean. Health-wise, the fumes from the flux in the solder core are actually more harmful, and this is present in both leaded and lead-free solders.

- I recommend reflowing all SMD components first, then immediately testing and ICSP burning the Atmega 328P-AU. That is, before installing the larger through-hole components. Like this, it will be easier to diagnose any programming issues right away. No need to mess around with the whole board if you need to desolder and resolder components. My first completed board had several issues that required me to remove and replace components to track down the problem. While I fixed those issues and the board worked, it did look a bit like the last dog dinner, rather than the Michelin star meal we strive to serve with every completed project.

First, reflow all the SMDs: U1, U36, U37, U25, Q6, SW18, D1, D2, LED2, LED4, LED5, LED6, C1, C2, C3, C4, C5, C6, C7, C8, C9, C12, C13, C14, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13. Once this is done, visually inspect that the solder joints are good and free of solder bridges. Use a magnifying glass or digital microscope. There are often bridges on some ATmega 328P-AU pins and these should be sucked up using some desoldering braid. Once we are satisfied we can move on to the next stage of programming the microcontroller via the ICSP header.

Check your ATmega 328P for connections. If everything is good, at least your MISO, MOSI, RST, SCK and ICSP power pins to the microcontroller are good.

Check the current status of the fuses and lock bits. The factory default settings for these fuses are usually not what we want. Here, they need to be set to the requirements of this project. Be careful when reprogramming, as wrong settings can brick the microcontroller and make it difficult to normalize it easily again.

Configures the ATmega to use an external 16MHz crystal, reserving space for the bootloader, brownout detection, boot delay, boot reset pin, etc. See the References section for the ATmega datasheet and other resources on configuring the four sets of fuses.

Low fuse: For CCKDIV8, CKOUT, SUT, and the four CKSEL bits.

High fuse: for RSTDISBL, DWEN, SPIEN, WDTON, EESAVE, and BOOTSZ with BOOTRST.

Extension fuse: For BOD level.

Lock bits: restrict access to program memory.

I set the fuses for this project with values ​​similar to the following:

L F7h

H DEh

He FDh

LB FFh

Because the factory default settings for new chips are usually:

Length 62 hours

High D9h

E FFh

LB FFh

(Among other things, microcontroller fuses are set to use its internal RC oscillator, clock divided by 8, brownout detection disabled, etc.)

WARNING: The RSTDISBL, SPIEN, DWEN fuses and the lock bits have the potential to brick the ATmega chip, or at least make it very difficult to use the chip again. So always double check your fuse settings before clicking the Write button.

- Once communications with the microcontroller and its fuses have been established, we can load a sketch. Again there are multiple ways to do this, although I find it practical here to use the Arduino IDE with the same USBasp ICSP programmer and the excellent MiniCore Arduino core. Once configured in the IDE's board manager, it allows programming of many ATmega microcontrollers (including the ATmega 328PB version sometimes used on Arduino boards these days). This kernel uses a custom version of Optiboot, which is a space-saving and more efficient alternative to the stock bootloader.

After setting up the MiniCore in the IDE's Board Manager, we can select our ATmega 328P in Tools and check its options. The Programmer should of course be set to USBasp (MiniCore). I can choose to upload the bootloader to memory and activate the USB port so that sketches can be updated later via the serial USB-FTDI port. This will create a 2 second delay when turned on. During this time, the bootloader is called and waits for any sketch to be uploaded. This serial port is also used for debugging at 115200 baud. We can also choose not to upload the bootloader and cancel the serial upload of the sketch. Since the code will start running immediately, there will be no 2 second delay. Any sketch uploads can only be done using ICSP.

Initially try uploading the Blink sketch. It is a good strategy to enable verbose mode in the Arduino IDE preferences section. Like this, you can see detailed information about what is happening during compiling and uploading the code. The Blink sketch is small, simple, and uploads quickly. The LED on port B3 of the microcontroller can be used to see if the Blink sketch is working with the board. This should be defined as data pin 11 in your Blink code. It is the red Fan A warning LED on pin 15 of the 328P microcontroller. Incidentally, this LED is also connected to the MOSI line of the ICSP port, so it can show us when In-Circuit Serial Programming activity is occurring.

Now that the microcontroller side of the project has been configured and tested, the PCB can be completed by hand soldering the remaining through-hole components.

Finally, the fan controller sketch can be uploaded to the board and all its functionality tested.

Example Uses

I use the fan controller in the following examples. I adjust the fan speed temperature slope for each application. It ensures adequate cooling at an acceptable noise level.

Antenna dummy load

With the advent of cheap 50 ohm ceramic resistors, I found some time to build a high power dummy load. It is perfect for testing HF transceivers. It uses 250N50F Aluminum Nitride (AlN) ceramic resistors. Alternatives include Beryllium Oxide (BeO) resistors. These are previously used components. Salvaged from scrapped equipment by some enterprising trader.

You should manage the ratio of "power time:rest time" applied to your load. More power over a longer period of time means higher temperatures, and therefore more time to cool down.

A large heat sink coupled with a smart cooling solution in the form of these dual fans is ideal. The fan controller board is mounted on one end of this package. The ceramic resistor is bolted to the heat sink, which itself is sandwiched between the two cooling fans. The DS18B20 temperature sensor is sandwiched in direct contact with the heat sink. You can use some zinc oxide thermal paste for good measure. The one I used was basically diaper paste from what I had on hand.

Industrial Computer

I hate noise. I use a Mac Mini with macOS and an industrial PC with Windows. Neither makes any sound and is completely silent. However, it soon became apparent that a fanless industrial PC running Windows can get quite hot. Despite being effectively housed in a large heatsink box, the lack of airflow means that its temperature does rise significantly when performing certain tasks. That's never good.

I used a fan controller and two fans to facilitate airflow above the PC. The temperature/fan speed curve was configured to cool it down enough but still not produce distracting fan noise. The temperature sensor was mounted in direct contact with the PC case.

Linear Power Supply Unit

My Microset PT-135 35A power supply is big, solid, and fanless. It uses linear regulation and is over engineered. It provides wonderful silence both in the RF and in the cabin. It has a large heat sink on the rear for heat dissipation. I decided to add some active cooling. Not that it needs it. Just a little help to aid airflow.

A shielded version is used here. Configuring a low fan speed curve keeps any fan noise to an unnoticeable level. It clips tightly to the back of the heatsink. Another solution could be to use small magnets to fix it to the case. The temperature sensor is mounted above the board and detects only the ambient temperature. It activates the fan only on hot days.