Additional measurements – Fan RPM

During the fan noise measurement (“How loud is that fan anyhow?“), I had wanted to also relate fan rotational speed to noise level. At the time, I did not have a tachometer and I didn’t wish to spend the time researching, designing, building, programming and testing one for a tool that I simply don’t have a recurring and pressing need for.

However, I did find that UNI-T had one available on the BANGGOOD.COM web site. The model UT-373 Tachometer is an inexpensive unit and at the time of purchased, it was US$13.33. After 4 weeks of shipping time (the longest I’ve ever seen from BANGGOOD), the UT-373 arrived today and so I set out exploring it’s features. It comes with a few strips of reflecting material, presumably to affix to surfaces one wishes to measure from. It uses a laser diode and photo detector focused through a plastic collimator. The detection distance is from 1.5 inches to 7.5 inches and the laser can be switched off for use with an external light source. Not only does the UT-373 provide RPM readings but it will also provide a count of pulses. For US$13.33, its a nice functional unit.

On to the RPM measurements for the AVR Fan Controller. Below, I provide an updated table with the fan PWM value, the % of fan Speed, the fan’s RPM and the SPL.

FAN PWM	FAN Speed	RPM	SPL
0	0%	0	37 dBA
96	38%	4120	60.5 dBA
128	50%	4980	65.5 dBA
160	63%	5730	69.2 dBA
192	75%	6230	72.5 dBA
223	87%	6730	73.1 dBA
255	100%	7150	74.2 dBA

For those of you that take a liking to graphical data and charts, shown below is the correlation of Fan Speed vs. Fan RPM vs SPL.

This post concludes the AVR Fan Controller project.

If anyone duplicates this project or creates a similar one for use with the larger DP and DPS power supply modules, please contact me with your results.

Peace and blessings.

Advertisements

Performance testing the AVR Fan Controller

With the hardware and software design finished and the PCB mounted in the DPS3005C’s case, I wanted to performance test the fan controller.  For this purpose, I needed to put a maximum load on the DPS3005C and let it heat up while collecting the data from the fan controller.  The thermistor and ATtiny13’s ADC combination was good enough to attain 0.1ºC temperature accuracy but even a 1ºC accuracy would have been “good enough”.

I decided to test both the 5-speed and 7-speed lookup tables. At the time of performance testing, I did not have the SPL meter for noise level measurement.

I typically use a spreadsheet for each project to keep track of notes, formulas, empirical performance data, etc.  The project spreadsheet can be downloaded here, complete with the thermistor conversion data, test data and charts.

In the 1st test, the 5-speed lookup table was used.  The full 5.1 amps was drawn from the DPS3005C using a 0.2Ω load and measurements were taken (and collected) every second.  The test started at room temperature (~27ºC) and continued until the maximum temperature stabilized.  The data was then imported into the project’s spreadsheet and a chart was created from the data.  Below is the chart for the 5-speed table:

The chart on the left depicts the entire test from 27ºC to 53ºC.  The chart in the upper-right depicts the heat-up curve and the chart on the lower-right depicts the cool-down curve.

Referencing the chart on the upper-right, it is interesting to see that before the fan is enabled, the temperature of the DPS3005C’s heat-sink rises rapidly.  Once the fan speed is set to 38%, the slope becomes a little more gradual. At 58% fan speed, stabilization seems to occur at ~53ºC.

Referencing the chart on the lower-right, it is interesting to see that once the load is removed, the heat-sink cools off rapidly with the fan speed at 58%.  Once the heat sink reaches 49ºC, the cooling is more moderate as the fan speed is 38% and even more moderate once the fan is off.

This 1st round of testing data leads me to the conclusion that although the fan is probably not necessary for the DPS3005C, it does help vent the heat from the case, even at 38% speed. At 38% fan speed, the noise level is ~60 dBA, which is ~23 dBA louder than when the fan is off.

Below is the chart for the 7-speed table:

Once again, the chart on the left depicts the entire test from 27ºC to 55ºC.  The chart in the upper-right depicts the heat-up curve and the chart on the lower-right depicts the cool-down curve.  The overall data chart shows two testing sessions back-to-back,

As with the 5-speed charts, one can see that the fan does effectively vent the heat from the case. One will also note the “chatter” of the fan speed at 55ºC.  This is because the 50%/63% speed threshhold is at 55ºC and the temperature the DPS3005C’s heat-sink seems to peak out at 55ºC.  Adding hysteresis to the program would resolve this issue OR raising the threshhold temperature to say, 57ºC would also resolve this issue.

Based on the measured data, my conclusion is that although a 5-speed lookup table is adequate, I may be able to use a 3 or 4-speed lookup table.  By finding the “‘sweet spots”, a compromise may be tailored to produce a fan speed to run at the lowest (quietest) noise level at specific temperature threshholds that would still effectively and efficiently cool the DPS3005C’s heat-sink at high loads.

This completes the project log for the AVR Fan Controller for the DPS3005C Power Supply Module.

Software specifics

I decided to keep this project as simple as possible but without giving up functionality. Having a surplus of ATtiny13’s (in a DIP8 package), I tend to go to this MCU for smaller controller projects.  It has 1KB of FLASH program memory 64 bytes of RAM and 64 bytes of EEPROM.

I’ll admit right up front that I’m not big on using “C” for my microcontroller projects. I’ve been programming AVR’s for many years using assembly language, so this project, like most others I’ve designed, is written in assembly language for the 8-bit AVR series from ATMEL (now owned by MICROCHIP).

For this project, all I really needed to do is repeatedly read the ATtiny13’s ADC, compare it to a value and set the PWM register to set the proper fan speed.  Even though this project is “line powered”, I still see no need to waste power if I don’t have to.  My hardware and software experience is embedded low-power (battery operated) devices, so when I can, I use the AVR’s sleep instruction and the watchdog timer in interrupt mode to periodically wake the MCU.  The program flow is as follows:

1. Initialize registers, I/O ports, variables and (UART)buffer.
2. Initialize the ADC, PWM mode and UART.
3. Initialize the watchdog timer for 1 second timeout.
4. Fetch the reading from the ADC (4 samples are taken and averaged).
5. Look up the ADC reading in the temperature-to-PWM table.
6. Set the PWM register to set the fan speed.
7. if UART enabled: send the ADC reading and PWM value.
8. Reset the watchdog timer then enter sleep mode.
9. Watchdog interrupt wakes AVR, goto step #4.

The lookup table being implemented is a simple window-comparator type stored in the AVR’s FLASH program memory.  At the moment, there are a total of 7 steps, including “off” and “full on”. The table data is below:

.dw 420,0    ;Speed level 0 (below 34 deg C - off)
.dw 338,$60  ;Speed level 1 (35-44 deg C)
.dw 267,$80  ;Speed level 2 (45-54 deg C)
.dw 210,$A0  ;Speed level 3 (55-64 deg C)
.dw 165,$C0  ;Speed level 4 (65-74 deg C)
.dw 130,$DF  ;Speed level 5 (75-84 deg C)
.dw 102,$FF  ;Speed level 6 (85+ deg C)

The 1st column contains the ADC reading (i.e “420”) and the 2nd column contains the desired PWM register value, which is the fan speed.  The averaged ADC reading is successively compared to the 1st column value. If the reading is lower than the 1st column’s value then the PWM register is loaded with the prior row’s 2nd column value.  One can see that this a “windowed” function.  Using this method, any number of “levels” can be implemented.  Furthermore, this same technique can be modified for use with other “real-world” input and output devices that use the ADC for an analog input and a PWM signal as the “analog output”.

I chose 7 levels but after testing, which I will discuss in a future post, 5 levels or even 3 or 4 would be fine for this project.

WORDPRESS does not allow ZIP or 7Z files in posts (unless you pay for it) and I’m not storing my project files on any external Internet accessible repositories.  However, I am using ZOHO for email and I can store the ZIP file there.  The project’s ZIP file can be downloaded here.

In the next post, I’ll discuss the testing phase.

PCB build

For smaller projects such as this one, I tend to simply hand-wire the components onto a piece of perf-board.  I still use CAD for the schematic capture and PCB layout as I find it much easier to hand-wire the board if I know beforehand where the components will be placed and how the wires will be routed between component pins.  It also helps to have a component locator glued directly to the top side of the perf-board for testing and trouble-shooting reasons (a glue-stick works well for this purpose).

Below are the component side (left) and mirrored back side (right) PCB layout images. The “wires” shown on the component side are jumpers between wires on the back side.

Once the PCB was built, it was continuity tested for shorts and opens.  I find it far easier to test software on a live target, so the software was developed after the PCB was built, thus the software was written, tested and debugged before installing into the DPS3005C’s case. Below are photos of the finished PCB build; component side on the left, solder side on the right.

Once the software was developed and tested, it was time to mount the fan controller into the DPS3005’s case.  I wired a 4-pin connector for the thermistor and power input.  The 5 volt power was obtained from the original fan power supply PCB, and as mentioned previously, KYNAR wire was used to attach to the SMD thermistor.  The fan has a 2-pin JST 0.98″ plug and I had a mating PCB connector for it.

In the photos below, the finished PCB with all connections on the left.  The thermistor “mounted” to the DPS3005’s heat-sink using “sticky-tack” putty in the center photo.  The PCB mounted to the bottom of the DPS3005’s case using double-sided stick tape is shown in the photo on the right.

In the next post, I’ll speak more about the software.

Hardware specifics

In a previous posting, I spoke about the hardware concepts to be implemented in this project. Overall, its a pretty simple project; take a temperature reading and set the fan speed based on the temperature reading.  In hardware, we only need a temperature sensor, which is the NTC thermistor and a means to drive the 5 volt D.C. fan, which is the ATtiny13’s PWM output driving an N-Channel MOSFET.

Temperature measurement

I had some stock of a SMD NTC thermistor from another project.  The thermistor I used has a 10KΩ resistance at 25ºC.  Perfect for what I was looking for.  I figured two lengths of 30 AWG Kynar wire-wrap wire would be sufficient to make the connections from the themistor to the fan controller’s PCB.

The interface was easy enough; use a voltage divider and read the voltage using the ATtiny13’s on-chip Analog-to-Digital Converter (ADC).  The schematic to the left is from MAXIM’s web site article entitled “A simple thermistor interface to an ADC“.  The only difference in the circuit I used is that the thermistor (RT) and reference resistor (R1) are swapped.

Fan control

Fan control was also fairly easy to implement.  As I pointed out in a prior post, I used an MTD20N03 N-channel MOSFET “pull” from a defunct PC motherboard. The MTD20N03 has an RDSon of 35 milliohms with a Vgs of 1.5 volts typical, which is low enough to be driven easily by the ATtiny13’s digital output.  To the left is a partial schematic of the MOSFET fan driver.  As shown, the ATtiny13’s PWM output feeds R2 and C4, which form a simple low-pass RC filter to smooth the PWM’s operating frequency. Diode D1 and capacitor C3 help absorb any inductive kick fed back to the driver from the FAN during speed changes.

Data Logging

I decided to add a serial output to the project so I could log data from the device if I wanted to.  I didn’t see the need for serial input to control the device, so the soft-UART implemented is TX only.  A TTL-to-USB converter is required. I’m glad I added the serial output as it came in very handy for measuring performance of the DPS3005C, the fan controller and the cooling efficiency of the fan itself.

The full schematic of the fan controller is shown below. A PDF version can be downloaded here.

In the next post, I’ll talk more about the software. In the next post, I’ll talk about layout and building the PCB.

How loud is that fan anyhow?

So here we are, many weeks later since the last post.  Into another year … Happy 2018 folks!!  🙂

Time seems like it is passing by very quickly in the last few years. Has time really passed by that quickly or is it that our perception and awareness of the passing of time has increased? I’ve read that our perception of the passing of time is linked to the vibrational frequency of Mother Earth herself and I’ve recently read that the Schumann frequency is up to around 36 Hz from 13 Hz only a few short years ago. Wow!!  That’s an astounding change for such a short period of time considering that it nearly doubled from 7.87 Hz (when last measured in the 1950’s) to 13 Hz by about 2014!  Now from 13 Hz to 36 Hz in only 3 years?? Amazing! Okay, let’s move on as its all relative, yes?

In reference to the multitude of complaints I had read about the fan noise, I decided to look into that particular issue in empirical terms.  One’s perception of sound levels (aural acuity) is much like that of one’s perception of the passing of time, different people experience both differently.  Thus for my own edification, I wanted to acquire some actual and factual measurements.

---

Equipment needed

I used to have access to an SPL meter.  It was a RADIO SHACK model; some of you know which one I’m speaking of, yes?  Well, the operative phrase here is “used to”.  I found a few on BANGGOOD.COM that received decent reviews.  I haven’t had a need for one for many years and aside from this project, I don’t see a need for one in the foreseeable future.  Nevertheless, I ordered the UNI-T Model UT-353 for about US$12. A few weeks later and it arrived.  Now in hindsight, I found many ANDROID apps that do the same but with all the variations in SMARTPHONE microphones, I don’t see how they can be accurate on all the varieties of phones.  Unless you have access to a calibrated sound source, which I don’t, then it seems to be a “hit or miss” gamble. At least with the UT-353, I can trust that there is at least some calibration performed on the units during factory testing.  Note: I see there is now a BlueTooth version, the UT-353BT, for US$4 more.  I wish they had that one when I ordered mine!

The important specs for the UT-353 are:

Sound Level Range: 30-130dB, 0.1dB resolution, ±1.5dB accuracy
Frequency Response: 31.5Hz-8KHz (A-weighted)

---

Obstacles in testing

1. How to create a sound-proof enclosure for accurate testing?  Having the meter in hand, I set out to acquire some hard data but I needed some sort of sound-proof enclosure to test in.  I thought a cardboard box would be sufficient to place the DPS3005C and the SPL meter within.  That should be good enough to block out most potential ambient noise.  I cut a small cross-slit into the side of the box and shoved the UT-353’s microphone “boom” into it so that I could see the SPL meter reading while the box was closed.  Speaking of time, I decided that early morning (3 AM) was the best time as the noise level typically drops.  I used no sound insulation inside the box because I did’t have any foam to use for that purpose.  Besides, I wasn’t performing a laboratory test with professionally calibrated test equipment, so a cardboard box was “good enough”. The distance between the fan and the SPL meter was 3 inches (7.6 cm) because that’s how much room was available in the box between the UT-353 and the DPS3005C.  In actual testing, I found it amazing that there was a 2 dBA increase in my readings when the freight train’s whistle blew, which was easily detectable by watching the display.  The house windows were closed and the train tracks are 1/2 mile away.
2. How to induce the PWM controller to traverse all fan speeds from 0% to 100%?  Hmm….  This was an obstacle that required some ingenuity.  In testing the DPS3005C under various loads, I added a TX-only UART to the Fan Controller’s code, which allowed me to record and graph data from the ATtiny13’s ADC and the PWM register.  I’ll post the graphs in a subsequent post.  In testing, I was never able to get the DPS3005C’s heatsink any hotter than 55ºC (131ºF), so the fan speed never exceeded 50% of full.  Therefore, I needed a means to directly control the fan using a PWM signal but I didn’t want to take the time to write code and reprogram the ATtiny13 to do so.  Well, my usual “go-to” for something like this is AttoBASIC.  It runs on an ATtiny85 and has both ADC and 8-bit PWM functionality. As it turned out, removing the ATtiny13 from it’s socket on the Fan controller board allowed me to access power and the fan drive MOSFET via the on-board ISP connector. A few minutes later and I had written a program to step from 0% to 100% fan speed for 16 seconds per step.  Certainly long enough to take my readings.  The AttoBASIC program is below:

 5 REM PWM FAN CONTROLLER TEST
10 PWM 0; POKE $0D 0 $81 # ENABLE 8-BIT PWM AND SET RATE TO LOWEST
15 DATA 0 $60 $80 $A0 $C0 $DF $FF # PWM LEVELS
20 CLK 1 # SLOW THE SYSTEM CLOCK FOR THE PROPER PWM RATE
25 FOR N=1 7 # INITIALIZE LOOP
30 S:= READ; PWM S # FETCH AND SET PWM SPEED
35 POKE $0D 0 $81 # SET RATE TO LOWEST AS 'PWM' COMMAND RESETS RATE
40 PRI "SPEED= "; PRI S # INFORM THE USER
45 SLP 9; SLP 9 # WAIT 16 SECONDS (2 X 8 SECS)
50 NEXT # NEXT ITERATION
55 PWM0; CLK 0; END # RESTORE SYSTEM CLOCK

---

The data was collected and documented in a spreadsheet.  The following chart shows the actual readings:

Fan Speed in % of full speed	SPL	UNIT
0.0%	37	dBA
37.5%	60.5	dBA
50.0%	65.5	dBA
62.5%	69.2	dBA
75.0%	72.5	dBA
87.1%	73.1	dBA
100%	74.2	dBA

Notice that the noise level only slightly increases at fan speeds of 62% and higher. Typically, under full rating of 5.1 amps with an input voltage of 24.5 volts, I don’t see fan speeds any higher than 50%.  But even at 50%, there is a ~28 dB difference in the noise level.

I posted a chart below (from here) that shows SPL level ranges in terms of human hearing perception and potential damage.  Although 65 dBA is considered to be in the range of “conversational speech at 1 meter”, which depending on the vocal tone and conversational topic of the presenter, can be very annoying for some. Fan noise at that level can be just as annoying. 75% fan speed would be considered to be equivalent to listening to a “vacuum cleaner at 1 meter”.   In all fairness, the chart references were taken at 1 meter distance from the sound source, while my measurements were taken at only several centimeters from the sound source.  I have not corrected for the distance, so the reader is encouraged to judge the levels for him/her self.

Sound sources (noise) Examples with distance	Sound pressure Level (Lp dB SPL)
Jet aircraft, 50 m away	140
Threshold of pain	130
Threshold of discomfort	120
Chainsaw, 1 m distance	110
Disco, 1 m from speaker	100
Diesel truck, 10 m away	90
Kerbside of busy road, 5 m	80
Vacuum cleaner, distance 1 m	70
Conversational speech, 1 m	60
Average home	50
Quiet library	40
Quiet bedroom at night	30
Background in TV studio	20
Rustling leaves in the distance	10
Hearing threshold	0

It’s important to know that the fan noise level testing was performed with the mechanical modifications (felt pads and rotor balancing).  I have not tested the noise without those modifications, so I suspect that the fan noise will be slightly louder. At some point, I may go back and measure the sound level with and without those modifications to see how much they improved the noise reduction.

Next up: Details of the fan controller hardware.

Design criteria and problems encountered

Having made the decision to design an ATtiny-based multi-speed fan controller for the DPS3005C housing, I set out to create the schematic.  I envisioned only a handful of parts required; NTC thermistor, matching resistor, MOSFET driver for the fan, an ATtiny13 and a few more capacitors and resistors as needed.

Design criteria: For the software controller, I needed a means to proportionally drive the fan as well as a means to measure the thermistor’s resistance as it varied with temperature. I wanted at least three (3) intermediate fan speeds between “off” and “full on”.  The fan supplied was not a 4-wire 12 volt “PWM computer fan” but I knew that it could still be controlled either by varying its power supply or by using a pulse-width modulation (PWM) scheme.  I figured that the fan was designed to run on 5 volts and I should therefore run it off 5 volts, so the only “proper” way to go was to use PWM. The ATtiny13 has a built-in 8-bit timer with two PWM outputs and a 4-channel 10-bit analog to digital converter (ADC).

I built a solderless breadboard with an ATtiny13 on it.  I added the nMOSFET and a 10KΩ pot to simulate the NTC thermistor.  Using AVR Studio and an AVR Dragon, I could manipulate the internal registers (Timer 0) of the ATtiny13 in-circuit and adjust the PWM duty cycle and frequency “on the fly”.

Driving the Fan: One thing I noticed in particular was that unless I set the PWM register to “255” (full-on), the fan wouldn’t even spin. I could see that it wasn’t the MOSFET driver.  I thought this very odd, so looking for hints, I decided to research to see if others had posted PWM fan controllers on the Internet.  I found a few but nothing glared me in the eye as to what was causing the problem with driving the FAN.  What was particularly helpful though, was MAXIM’s “Tutorial 1784” entitled “Fan Speed Control Is Cool!” (APP1784 pdf).  The application note states that “useful [PWM] frequencies range from 20Hz to 160Hz” for driving “standard” brushless fans. Aha!  I had set the PWM frequency to 4.687 KHz, which was far too high!  I was planning to run the ATtiny at 1.2 MHz (internal 9.6 MHz oscillator divided by 8), so the only PWM frequencies I had available were 4687.5 Hz, 585.9 Hz, 73.2 Hz and 18.3 Hz.  Looks like 73.2 Hz and 18.3 Hz are the only two viable candidates.  Once I changed to the 18.3 Hz PWM frequency, the fan started operating properly and I could adjust it’s speed by adjusting the PWM values in the ATtiny13’s OCR0B register. Upon further testing, I found that 73.2 Hz did not work as well as 18.3 Hz and even that frequency was a little low but did work reasonably well.

I had wondered why the higher PWM frequencies didn’t drive the fan properly then I realize that it was “electrical momentum”.  In other words, the EMF “pushes” against the mechanical weight of the fan rotor were too short and had too little”electrical momentum” to “push” the fan rotor in any manner, thus no mechanical rotational momentum could be created. Slowing the PWM frequency down gave the fan rotor “stronger” pushes for a longer period of time, so some mechanical rotational momentum could be created, just enough to move the rotor until the next “push”.

Fan Vibration: In working with the fan at full-speed, I noticed that it vibrated slightly while holding it in my hand.  I realized that part of the perceivable noise was coming from an imbalance in the fan rotor.  Mounting on the back panel of the case tends to amplify the vibrational imbalance thus making it even noisier.

I didn’t have any tools to assist me in finding the proper counter-balance weight nor the optimum position on the fan rotor but using several layers of masking tape applied on top of each other (for weight), I tried some empirical testing to see if I could minimize the mechanical vibration by sequentially locating the optimum “counter-balance” point.  I was mostly successful and was able to reduce the fan’s vibration to minimum.  Once I had balanced the fan rotor, I remounted it inside the case to see how it sounded and was fairly pleased with the results. but there was still some noticeable vibrational noise. I started to think about adding something to dampen the vibration of the fan in a manner that would isolate it from the case.  I came up with some small circular felt feet that I never did apply to my mini-quadcopter.  I had four (4) of them and was able to place them between the fan’s housing and the case. I suppose even a thin layer of rubber sheeting might have been used but had I none in my possession.

I wish I had a way to measure sound pressure level (SPL) so that I could see the actual difference in each of the two mechanical methods of vibration reduction that I used.  For now, even though it is a highly subjective means, my ears did the measurements.

For those wishing to improve the fan noise, I would suggest starting out with balancing the fan rotor and mechanically insulating the fan from the case.

NTC thermistor: I have a small stock of Murata NCP18XH103F03RB NTC thermistors, which are 0603 size surface mount components.  I didn’t think I’d have a problem soldering two AWG 30 “Kynar” wires to it in order to use them.  These are “typical” 10KΩ @ 25ºC thermistors.  The β is 3455 for 25ºC to 100ºC but rather than using the “Steinhart equation” to calculate the resistance at any given temperature, I used the table in the datasheet, which I imported to a spreadsheet.

Selecting temperature set-points: Once I had the data in the spreadsheet, I started to pick temperature set-points to use in the software.  As a starting point, I initially picked 35ºC, which is 95ºF, and picked three more temperatures that were 15ºC apart. I ended up with set points of 25ºC, 50ºC, 65ºC, and 80ºC.  Since the thermistor had a resistance of 10KΩ @ 25ºC, I thought it best to use a 10KΩ “matching” resistor.  This way, I had resistance range of  10KΩ @25ºC down to 1.669KΩ @80ºC. When converted to a voltage, the range was 2.500 down to 0.715 volts, which is well within the equivalent voltage detection range of the ATtiny13’s ADC.  I didn’t need great accuracy but with at ATtiny13 using it’s 5 volt power rail as an “external reference”, I had about 5 millivolts per bit resolution (±1 or 2 bits) or about ±0.1ºC resolution.  I would have been happy with ±1ºC resolution but ±0.1ºC resolution is certainly acceptable.

Selecting PWM values: Initially, I decided to use PWM duty cycles of 50%, 58%, 79% and 100% to see how they sounded to my ears.

In the next post, I’ll review the software functionality. In the next post, I’ll review testing the sound level of the fan noise.