ATtiny Fan Controller for the DPS3005C Programmable Power Supply
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.
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.
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:
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.
Right-click on the file name and select your browser’s “Save Link As” to rename the file without the “.pdf” file extension. [ Note: you MUST rename the PDF extension to ZIP because the free WORDPRESS, which I am using for this blog, does not allow ZIP files to be embedded as media content. Renaming with a PDF extension seems to bypass this limitation and does not invoke your browser’s PDF viewer. ]
In the next post, I’ll discuss the testing phase.
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.
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.
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 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.
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.
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.
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)
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.
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.
Recently I purchased a programmable power supply. I wanted something a bit on the lower price side but I wanted some features; adjustable voltage and adjustable current with current limiting. A digital display for readout would be great as well.
After some research, I decided on the RUI DENG DPS3005C available from many Chinese supplier websites. I purchased mine from BANGGOOD.COM. There is a metal case available for it as well, so I purchased that item along with the DPS3005C. The DPS3005C will accept an input supply voltage between 6 and 40 volts and will provide an adjustable voltage between 0 and 32 volts with an adjustable output current between 0 and 5 amps. There is also an adjustable over-current protection feature that immediately disconnects the load from the power supply should it be tripped. Nice features for US$30 (the case is an additional US$19).
The case is meant to house different models of the DP and DPS series of programmable power supplies. One such model mounts to the bottom of the case and the display/control board mounts to the front panel. For the DPS3005C, only mounting to the front panel is required and there is ample room inside the case for another (estimated) 3 x 4 inch board.
The DPS3005C comes with a USB2TTL bridge and a BlueTooth adapter that plugs into the DPS3005C to give the user the ability to communicate with the device using free software provided by RUI DENG. Johan Kanflo also wrote an open source firmware for the DPS5005 that likely works with the DPS3005C.
In looking at the user feedback for the case on BANGGOOD.COM, several people were commenting that the heat exhaust fan was incredibly noisy. When I first received my case and power supply, I tested the fan to see if it was noisy. The fan runs full speed at 5 volts but other than the sound of air flowing, I heard no noticeable noise. I assumed that RUE DENG had replaced the fan with a quieter one and proceeded to build the power supply. After installing the device in the case, I powered up the fan for test and sure enough, the fan was noisy. At the time, I decided to leave it alone and continue the build.
Once built and tested, I had a chance to use my new programmable power supply. Until my 24V/6A DC house-current power brick arrives, I used two 12V/7AH sealed lead-acid batteries connected in series, which worked fine but after only a few minutes of running the DPS3005C, the fan noise started to get to me. I knew it wasn’t going to get any better, so I started looking back at the user feedback. The most common “cure” was to simply run the fan at 4 volts by changing the 5V DC/DC converter’s feedback resistor.
With the case cover off, I performed some load testing on my unit by drawing the full 5 amps of current. The current pass MOSFET’s did heat up the heatsink, so I figured that running the fan was probably advisable as opposed to not running the fan at all. Most of my project power needs are using micro-controllers that run at low voltage and current. I didn’t see that the DPS3005C would be creating much heat but I could still see the need for the fan at higher temperatures.
I had some NTC thermistors from another project and pulled a few MTD20N03 nMOSFET’s from a defunct computer motherboard. I have a few ATMEL (now MICROCHIP) ATtiny13’s left over from another project and they seem to be great candidates for simple controller projects like this one.
I made the decision to design a simple multi-speed fan controller using the parts I had on hand.
For the MOSFETS, I knew the fan drew 200 ma at 5 volts, so as a preliminary test, I tried using a 2N7008 nMOSFET but the RDSon (~7.5Ω) was too high and introduced a voltage drop nearing 1.5 volts. However, the MTD20N03 with an RDSon of 0.035Ω, could handle that load without a problem and so I stuck with that one. The MTD20N03 is housed in a TO-252 package and is essentially a surface mount component.
Next post I will address the design criteria.
DPS3005C ATtiny Fan Controller 