Controlling the speed of a DC motor via PWM

[engineheat]

Hi,
I would like to control the speed of this DC motor with PWM using an Arduino:

https://www.delta-fan.com/products/BFB0712HD.html

I found the following diagram to use:



Notice the flyback diode D1. When buying a diode, what specs do I need to watch out for in order to ensure it is suitable? Should I also include resistors or capacitors in series with the flyback diode? I'm considering this diode:

https://www.digikey.com/en/products/detail/nte-electronics-inc/1N5401/11644131

But I'm not too clear on what some of the specs mean:

Voltage - DC Reverse (Vr) (Max) 100 V

Current - Average Rectified (Io) 3A

Voltage - Forward (Vf) (Max) @ If 1.2 V @ 3 A

I also want to make sure the MOSFET in the diagram is a N Channel enhancement type.

Thanks

[james_s]

Nothing is critical about this circuit, your fan only draws 310mA, any N-channel power mosfet rated for at least 30V or so ought to be fine, ideally something that is logic level compatible, I would just search by price and look for the lowest RDSon you can find for a price of a dollar or so in a package style you can work with, really just about any old random N channel mosfet ought to work fine though. The diode is probably not even necessary at all but if you want to put it there for good measure then something like a 1N4007 ought to do.

[Siwastaja]

Your post is contradicting, because you say you are controlling a DC motor, but post a link to a fan, which is not a DC motor, but a complete product which contains a BLDC motor (which is NOT a DC motor despite having DC in its name) and an inverter circuitry to control it.

If you were to control a DC motor:

Notice the flyback diode D1. When buying a diode, what specs do I need to watch out for in order to ensure it is suitable?  I'm considering this diode https://www.digikey.com/en/products/detail/nte-electronics-inc/1N5401/11644131

Having fast or no reverse recovery is essential. Schottky is the correct type as they have no reverse recovery. What you suggest is standard recovery standard Si diode, not suitable. Standard recovery diode won't work because with PWM, the motor current does not decay to zero (except at very low loads or speeds) but works in continuous conduction - i.e., the energy stored in the motor inductance keeps the current flowing, through the diode, during MOSFET off-time. When the MOSFET then turns on, current is still flowing through the diode. The diode has to turn OFF very quickly, otherwise short-circuit current will flow, wasting energy and heating up the diode and MOSFET.

You can see standard recovery diodes suggested in some relay or solenoid circuits, but it's because the controller does not turn the transistor ON again too quickly after turning off - current has time to decay to 0, no short circuit current.

Should I also include resistors or capacitors in series with the flyback diode?

Absolutely not. The reason for the diode is to provide a continuous, low-impedance path for the motor winding current. This loop needs to be as short as possible, without any unnecessary components. The diode, while schematically in parallel with motor, must be located next to the transistor, not at the motor. You also need to provide low-impedance power supply: capacitance between Vcc and GND, placed physically close to the MOSFET-diode series combination.

Voltage - DC Reverse (Vr) (Max) 100 V

Diode blows up if it sees voltage more than 100V. Your circuit has 12V over the diode, when the MOSFET is conducting, nowhere near 100V. Though, fast switching of current will produce voltage peaks due to layout parasitic elements, usually in range of 20%-100% depending on how good job you did. I would choose a diode rated for at very least 25V max reverse voltage. The exact same applies to the MOSFET Vds_max, by the way. Chose a MOSFET rated to at very least 25Vds_max, but 30V would be a good idea for a bit more margin.

Current - Average Rectified (Io) 3A

Average current through the diode. This might be optimistic; you'd need to run thermal calculations too.

Voltage - Forward (Vf) (Max) @ If 1.2 V @ 3 A

How much voltage is lost over the diode when it conducts (so would be 0V for an ideal diode). 1.2V is already 10% of your 12V supply, meaning that if you run a large DC motor with small duty cycle (small speed) producing a lot of torque (a heavy load, e.g. accelerating a vehicle), diode being in conduction most of the time, the efficiency is limited to 90% by the diode alone. If your motor current were to be 3A, this would mean 1.2V*3A = 3.6W dissipated on the tiny diode. A schottky type with lower Vf would make heatsinking easier and increase the efficiency.

I also want to make sure the MOSFET in the diagram is a N Channel enhancement type.

Yes, that's the correct type for ground-side switching.

You would also need current sense and pulse-by-pulse current limiting for a motor controller of any larger motor. A tiny motor below some dozen watts does fine without current sense by just overdimensioning the MOSFET and diode to handle the stall current of the motor.


---

Now, for the BLDC fan control - all of this is less critical, because the fan already comes with an inverter, which already has those switching transistors and freewheeling diodes. As james_s says, you probably could get away without any diode.

I would still add a schottky diode, and a power supply capacitor close to the MOSFET-diode combo as explained above, because even with motor inductance handled by the internal inverter bridge of the fan, you still have some parasitic inductance from the wiring, capable of generating some sort of voltage spikes. A small schottky diode does not cost much after all.

Another question is whether it's a good idea to PWM the supply currrent to a fan. Many have done that, me included, but if it's not mentioned in the fan datasheet, it's in principle similar abuse as trying to cut power to your television thousands of times per second. By far, the best option is to get a fan with PWM control input (so-called four-wire fan). But usually standard BLDC fans still work fine when PWM'd if you don't mind audible noise so you can try it out.

[engineheat]

Now, for the BLDC fan control - all of this is less critical, because the fan already comes with an inverter, which already has those switching transistors and freewheeling diodes. As james_s says, you probably could get away without any diode.

Thanks for the reply. Learned a lot. I guess I overlooked the fact that it is brushless DC motor which works differently than a DC motor with a brush/commutators. So those switching transistors that it comes with are performing the same function as that of the commutators in a brushed motor - that is - for basic operation of the motor. They are NOT for PWM. For PWM, I would still need my own MOSFET. But you are saying since they already have flyback diodes, I can probably get away with not having diodes. Am I understanding it right?

Another question is whether it's a good idea to PWM the supply currrent to a fan. Many have done that, me included, but if it's not mentioned in the fan datasheet, it's in principle similar abuse as trying to cut power to your television thousands of times per second. By far, the best option is to get a fan with PWM control input (so-called four-wire fan). But usually standard BLDC fans still work fine when PWM'd if you don't mind audible noise so you can try it out.

I'm not sure why the spec of that fan says "2 lead wires", but I actually see 3 actual wires in the photo (blue, black red). So what is the third one for?

Do you know if there are four-wire fans similar to the one I showed when it comes to size, flow rate, etc? I do want to get one from a reputable supplier, as opposed to cheap no-name Chinese stuff. What are some reputable brands in the industry for fans of this size?
Thanks

[james_s]

In my experience most 2 wire brushless fans respond fairly well to PWM. Not all of them but enough that it's worth trying.

[Siwastaja]

Yes, you got it right. The third wire usually is a tachometer output, giving pulses more frequently the higher the speed. Fourth wire would be PWM control.  That being said, tacho output is usually yellow so if you have just black, red, blue, maybe blue is PWM control?

Fans can be ordered with different options with slightly different part numbers, so it's not weird to see photos with different number of wires. Just read the datasheet carefully, paying attention to the exact part number and every letter and number in it.

https://www.digikey.com/en/products/filter/fans/dc-brushless-fans-bldc/217
Digikey parametric search has this "features" field where "PWM control" is available as a search term. I would go for such a PWM controllable fan instead of "abusing" a normal fan by cutting the power/ground wire with a FET, even if that usually seems to work out just fine.

[engineheat]

Yes, you got it right. The third wire usually is a tachometer output, giving pulses more frequently the higher the speed. Fourth wire would be PWM control.  That being said, tacho output is usually yellow so if you have just black, red, blue, maybe blue is PWM control?

Fans can be ordered with different options with slightly different part numbers, so it's not weird to see photos with different number of wires. Just read the datasheet carefully, paying attention to the exact part number and every letter and number in it.

https://www.digikey.com/en/products/filter/fans/dc-brushless-fans-bldc/217
Digikey parametric search has this "features" field where "PWM control" is available as a search term. I would go for such a PWM controllable fan instead of "abusing" a normal fan by cutting the power/ground wire with a FET, even if that usually seems to work out just fine.

Thanks. I've been doing some research on those fans, and I learned that there are PWM fans with 4 wires. It seems the 4 wire version is a lot easier to implement for a beginner like me as you can just directly hook the PWM pin of the Arduino to the PWM wire of the fan for speed control. And then the power source connects to the power wires. I probably dont even need any additional diode or MOSFET. Right?

[Siwastaja]

Yes, that's correct. Drive the PWM input directly from microcontroller IO pin.

[engineheat]

Thanks.
The fan I'm talking is actually this:
https://www.mouser.com/datasheet/2/632/BUB0712HD_SM-2948392.pdf

It does say 25kHz for PWM, and after doing some reading on Arduino, it seems the analogWrite function doesn't output anywhere near that frequency. So right now I'm currently reading about using timers to get higher PWM frequency.

But it seems so much easier to just use the analogWrite. I wonder from a theory perspective what's the drawbacks (if any) if one used a much lower PWM frequency?

[engineheat]

As a side question, these 4 wire PWM fans seems to be for computer use. I wonder if they have bigger fans for say, home ventilation use or HVAC use that work similarly (4 wire, PWM, can be controlled via Arduino)?

thanks

[james_s]

They certainly do have HVAC fan motors that can be controlled similarly, in that field they're called ECM motors. I think it's a digital interface rather than PWM but I've never actually put a scope on one to find out. Whenever I have time to install the new furnace in my house I might poke around out of curiosity.

[Siwastaja]

Yeah, digital interface or 0-10V analog control signal, which is very easy to generate with a potentiometer if you have more than 10V available, but a bit pain-in-the-ass if the highest voltage available to you is 5 or 3.3V.

[Algoma]

The PWM goes on the Yellow control wire. If you PWM the whole supply voltage, that poor fan controller needs enough time between pulses to wake up and figure out what is going on each cycle.  To that fan, Its like controlling the speed of your car by shutting off its engine every few seconds. Yes, there are fans that are designed to be PWM controlled that way.

In this case you simply power the fan with steady voltage and control the duty cycle of the signal to the yellow wire. The rest of the speed control circuit is already inside the fan.

[Simon]

These little fans often have a PWM input to set the speed. Another way to do it is to make a crude buck converter. Put an inductor in series with that fan and a capacitor across it and you can regulate the voltage. Those fans can often run off much lower voltages than the nominal. For example I have used "24V" fans running at 5V to slow them right down when blowing air across my soldering desk.

[james_s]

It really depends on the fan. A lot of them have only two wires, others have 3 wires, often the 3rd wire is a tachometer output, sometimes it's a PWM input, often the same base model fan will be available in several variants with different operating voltages and control schemes. Some fans work very well fed from PWM power, others don't.

[MathWizard]

I've put standard diodes in parallel with with fans, for PMW. Yeah so that's not much good then at 50kHz. Schottky are the ones with a thin metal layer between the PN junction, iirc, and that somehow helps make them so fast.

[engineheat]

https://www.digikey.com/en/products/filter/fans/dc-brushless-fans-bldc/217
Digikey parametric search has this "features" field where "PWM control" is available as a search term. I would go for such a PWM controllable fan instead of "abusing" a normal fan by cutting the power/ground wire with a FET, even if that usually seems to work out just fine.

It's so hard to find a 4 wire centrifugal blower with PWM. The ones I can find are mostly tubeaxial type. The 4 wire brushless blowers are all out of stock. I talked to a manufacturer and was told the 4 wire version requires a special order with a minimum quantity. Wonder why the blowers are not as popular for PWM compared to the axial ones. If I understand correctly, these are all computer fans right?

[Psi]

If you want to PWM a DC fan, like a 2 wire computer one that contains electronics, you will need to pwm it very slowly. Like under 20 Hz.

Another option is to PWM into a large capacitor so its really not pwm'ing the fan at all but producing an adjustable DC voltage to run the fan on. But if you do that you wont be able to spin the fan down to very slow since a 12V fan probably wont even work at under 4V

Its a hacky solution, best to find 4 wire fans as recommended above.

[engineheat]

For the 12v, I'm curious what's the difference between powering it with, say, a fixed 9V versus PWM with a duty cycle of 75%. The average voltage is the same, but with PWM, during the on time, the voltage is higher.

I wonder what difference there are in terms of air flow rate and static pressure generated. For instance, according to the datasheet of many fans, there is a roughly inverse relationship between static pressure and flow rate. Is it safe to say that max static pressure and max flow rate will decrease in both scenarios?

[Simon]

If you want to PWM a DC fan, like a 2 wire computer one that contains electronics, you will need to pwm it very slowly. Like under 20 Hz.

Another option is to PWM into a large capacitor so its really not pwm'ing the fan at all but producing an adjustable DC voltage to run the fan on. But if you do that you wont be able to spin the fan down to very slow since a 12V fan probably wont even work at under 4V

Its a hacky solution, best to find 4 wire fans as recommended above.

You will just get a hot capacitor if you do that, you need a simple buck, put an inductor in series and diode in parallel, the fan should actually have some capacitance anyway so the inductor is more important.

[Simon]

It's so hard to find a 4 wire centrifugal blower with PWM. The ones I can find are mostly tubeaxial type. The 4 wire brushless blowers are all out of stock. I talked to a manufacturer and was told the 4 wire version requires a special order with a minimum quantity. Wonder why the blowers are not as popular for PWM compared to the axial ones. If I understand correctly, these are all computer fans right?

Axial and centrifugal are very different, Axial is low pressure but high flow, centrifugal will have much more pressure but you loose flow. It depends on what people are trying to cool or if they need to duct the air somewhere. Even on the axials there is a huge range. Actual computer fans do pretty much no pressure, but you can buy a 120mm fan that will do hundreds of pascals in pressure, you just need to feed it 125W rather than the 5W of you more computer variety fans.

Fan laws say that flow follows speed in a linear fashion, pressure follows speed to a square fashion, this means that the power demand on a fan follows a cubic relationship to the speed. Double the speed, 8 times the power. Matching a fan to the requirements in terms of flow and pressure is a thing that with low power computer fans is not even bothered about. coincidentally as your air flow through a duct increases the pressure drop across the duct goes up with a square relationship to flow (fan speed).

Once you get into engine cooling and air conditioning sizes this all really matters but I can imagine some people out there hoovering up all the stock of little centrifugal fans for a particular use.

[Siwastaja]

Another option is to PWM into a large capacitor so its really not pwm'ing the fan at all but producing an adjustable DC voltage to run the fan on. But if you do that you wont be able to spin the fan down to very slow since a 12V fan probably wont even work at under 4V

You surely mean PWM into LC circuit, forming an unregulated buck? (Don't forget the diode.) PWM into a large capacitor will not work and at best, is extremely lossy, and more likely, just blows up within hours.

Even with inductance added, lack of current sense is still a possible issue. A switch mode converter IC would solve all of this in one go.

[Psi]

and more likely, just blows up within hours.

What's going to blow up?  I was not suggesting PWM at mhz, it's just a DC computer fan.

[Siwastaja]

and more likely, just blows up within hours.

What's going to blow up?  I was not suggesting PWM at mhz,

MOSFET is going to blow up even from single switching event because SOA will be likely exceeded into the large capacitor as there is nothing to limit current except Rds_on + capacitor ESR. This might not happen when testing at lab table, but then happen at elevated temperature (like +40degC after the circuit is warmed up) as the electrolytic cap ESR decreases with temperature while the SOA of MOSFET is squeezed smaller.

Or, it might run "fine" for an hour after you find the room filled with capacitor internals, like I found out the first time I built the very circuit you are describing some 15 years ago.

So even 1 mHz (millihertz) of modulation might be enough to blow it up, it can be a single event. Hundreds of Hz would be enough to severely heat up the large capacitor exceeding the ripple current ratings by orders of magnitude.

You can of course use some massively oversized MOSFET to move the issue into just the capacitor heating or blowing up. Or you can bring the PWM frequency down low enough so that the capacitor survives. But then it does not filter much, and the fan is going on-off-on-off...

it's just a DC computer fan.

Fan does not care. The problem is switching the capacitor with unlimited current, even without load.

[Nominal Animal]

The fan I'm talking is actually this:

The interface to 4-pin PWM fans used in PCs (Intel, AMD, servers, even SBCs) is standardized here (Intel PDF).

Essentially, they take their power from a 12V rail, determine speed from a 25 kHz (21-28 kHz) PWM input, and return two pulses per rotation as an open collector output (less than 1 kHz: at 1000 RPM, 33.3 Hz).  Note the 5.25/3.3V and 12V pull-up requirements!

Various Arduinos (even cheap ATtiny202s) can do 25 kHz PWM, you just need to reduce the PWM prescaler; at 16 MHz, you could use a prescaler of 4 (instead of 32) and duty cycle between 0 (0%) and 159 (99.375%).  The exact details vary depending on the exact microcontroller.

I personally would use two N-channel MOSFETs (like NX138AKP) to invert and level-shift the PWM and Tach signals; I've already simulated this for 2.5V - 5.5V control logic for a related but separate case.  A single MOSFET each will invert the logic levels, but it is trivial to adjust in software on most microcontrollers.

[engineheat]

I powered the fan with nominal voltage (12V) directly, without any electronics, and it ran fine. The flow and noise is a bit higher than what I want. Then I powered it with a 6V battery pack directly. It still ran, but the flow is too low although the noise was low too.

We've been talking about PWM up to this point, but what about just using an adjustable buck converter to bring down the voltage from 12V to something like 8 or 9V? How is it different than the PWM approach in terms of the static pressure and flow rate that I can expect?
Thanks

[Siwastaja]

Adjustable buck converter is the ideal solution. Just make sure the fan starts at that voltage, even after the bearings wear out or dust accumulates making it harder to turn. Well, if it starts at 6V, then 8-9V won't be a problem. Both static pressure and flow rate go down when lowering the voltage. Some datasheets might show curves for different voltages, but I'd suggest simple testing.

[engineheat]

Adjustable buck converter is the ideal solution. Just make sure the fan starts at that voltage, even after the bearings wear out or dust accumulates making it harder to turn. Well, if it starts at 6V, then 8-9V won't be a problem. Both static pressure and flow rate go down when lowering the voltage. Some datasheets might show curves for different voltages, but I'd suggest simple testing.

Can you recommend a good adjustable buck converter? I played around with a no-name one years ago and it died after a few days. The motor wattage is less than 5W and draws less than 0.5A. I just need one that converts 12V to a range from 6V to 12V.

There's so many different ones, (and of different size) I don't know which to get or what to look for. Some have big components like the following one:



And some are really small:

https://www.sparkfun.com/products/15208


Thanks

[alligatorblues]

When I need a pwm controller, i just purchase one off eBay for $3. Haven't had one fail yet. I even have a 10A for driving tec chips.

[Siwastaja]

Can you recommend a good adjustable buck converter?

Try some modules from Digikey/Mouser/etc. (use the parametric search). Real companies like Murata and WE make regulator modules, and while a tad more expensive than Ebay crap, they would work reliably.

If the fan is small (a few W), you don't need a switcher; dropping some voltage with a schottky diode (or string of standard diodes) is good enough. Say, 4-5 standard Si diodes in series to drop from 12V to 9V. Making 9V out of 12V by linear regulator / resistive dropping is still 75% efficient. An oversized yet non-synchronous buck module running at low load is not necessarily more efficient at all, could be even worse!

[Nominal Animal]

Say, 4-5 standard Si diodes in series to drop from 12V to 9V.

This was standard practice with 3-pin (voltage-controlled) PC fans (and many PWM-controlled ones are 3-pin compatible); for example, Noctua LNA and ULNA adapters simply add standard silicon diodes in series with the fan, dropping the voltage over the fan.  And Noctua fans are generally considered very high quality fans, too.

[engineheat]

Well I decided to just try the PWM approach first. I'm using an Arduino Uno.

Here's my planned schematic:



I have a potentiometer that I plan to use to change the speed and it's connected to pin A0. Do I need any pull up or pull down resistors or capacitors anywhere?

Thanks

[Psi]

What's going to blow up?  I was not suggesting PWM at mhz,

......
Fan does not care. The problem is switching the capacitor with unlimited current, even without load.

I'm an idiot. Shouldn't be posting late at night

[ArdWar]

Here's my planned schematic:

Put the MOSFET on low side (below the fan) if you're using NFET (like IRFZ44).
If you're using your schematic placement (high side) then you have to use PFET instead (IRF9540 etc) and some additional gate drive circuit due to the higher drain voltage.

If you want to drive them directly from GPIO, you actually have to pick logic level MOSFETs instead of those parts. But for your relatively low current application, those parts should still be fine.

It's good practice to put gate pullup resistor for PMOS and pulldown for NMOS.

[Siwastaja]

That won't work. N-channel MOSFET needs positive Vgs to keep on, you would need more than 12V+8V = 20V to keep it conducting, yet the IO pin only gives 5V. Simply move the MOSFET to ground side (swap MOSFET and fan in the schematic) because the fan is a floating load (as long as you don't need tacho output). IRFZ44N is massively oversized and does not turn fully on at 5V at higher Id, but given very low load current, it will still work here.

[Simon]

This will not work, piss the fan off or the fan may run pretty much at the full speed but with a shorter life time.

So put an inductor in series with the fan, a capacitor across the fan (it may have enough internal capacitance). Put a fast diode from the mosfet switch output to the oposite power polarity that the mosfet switches. You now have a basic buck converter. Use a sensible frequency like over 100kHz. Or just buy a speed controllable fan.

[eugene]

I've controlled fans in this way (but with the transistor on the low side of the fan) and it worked fine. The caveat is that the PWM frequency needs to be low, like 50Hz. Experiment to see what makes your fan happy.

If the OP simply uses analogWrite() on the Arduino Nano, then they're going to get a PWM frequency that will be much too high. 490Hz, IIRC. That will make the fan unhappy. Interestingly, that frequency would not work with a 4 wire speed controllable fan either as they want ~25kHz...

Fortunately, it's not hard to adjust the PWM frequency of the Nano: https://www.etechnophiles.com/how-to-change-the-pwm-frequency-of-arduino-nano/

[engineheat]

I changed the setup for the 2 wire fan to:



When PWM frequency is 30 Hz, it runs fine and I was able to control the speed with a pot. I implemented the low frequency PWM from scratch using millis(). But when I used the default frequency of 490Hz for analogwrite(), the fan did not like it. It does not spin at low duty cycles and only spins weakly at high duty cycle.

I got myself some 4 wire PWM fan as well. Those need 25khz. Fortunately I was able to figure out how to get 25khz using timers. The 4 wire fan also has a wire for tachometer. I'd like to know how those work and how to capture the speed using the Arduino. I think it just outputs a pulse per revolution?

I wasn't able to find much info on the tach in the datasheet:
https://www.digikey.com/en/products/detail/delta-electronics/BFB0712HH-AWPH/13997125?s=N4IgTCBcDaIEIDE4AYDsBGMAJLBaAggOoAKWIAugL5A

Thanks

[Nominal Animal]

I'd like to know how [4-pin PWM fans] work and how to capture the speed using the Arduino.

Already told you, in #24.

All 4-pin 12V PWM computer fans are supposed to follow the Intel 4-wire PWM Fan specification.

You need two N-channel MOSFETs with low Vgs(th), capable of sinking at least 10mA, and one pull-up resistor to 12V (R2).  I like NX138AKR, because they're cheap in SOT-23-3 and well suited for this (and won't be harmed by accidentally putting 12V or ground on the fan tach or PWM pins, as it can handle Vgs to ±20V), but many, many other N-channel enhancement mode MOSFETs are just as good for this; pick your favourite.

Additionally, you can use a small resistor (R1) to limit the very very short current spike when switching the PWM MOSFET (to protect the I/O pin; not all microcontrollers need this), and a pull-up resistor (R3) to your microcontroller I/O voltage, 3.3V or 5V, although typical microcontrollers do have sufficient internal pull-ups you can enable on inputs.  Their values shown in the above schematic are just examples.  For an ATtiny85 running at 5V, I intend to use R1=220Ω, R2=10kΩ, and omit R3.



The tach input is two pulses per rotation.  Thus, if you get P pulses per second, the fan is rotating at 30×P RPM.
Conversely, even at 3000 RPM, you only get about 100 pulses per second, so you can use an interrupt on the pin.

The above circuit inverts the logic of both signals, i.e. your microcontroller needs to generate PWM that is LOW during the duty cycle, and HIGH when idle; and the start of the tach pulse is a trailing edge, i.e. HIGH to LOW transition.

The fans are not required to start under 30% duty cycle.  The duty cycle is relative to the maximum speed the fan is capable of given the current supply voltage.

[eugene]

With all due respect, I don't think all of those transistors are necessary. The tach output is typically open collector, so all that's needed is to connect it directly to a GPIO pin with a pullup resistor to VCC. The PWM input can be driven directly by a GPIO pin. Supposedly, 5V logic is required, but they often work fine with 3.3V. No significant current goes in or out of either fan pin.

[Simon]

I'm still confused, why are you trying to speed control a 2 wire fan when you can get one with a PWM input?

I am speed controlling a much bigger 2 wire fan, this is brushed, and even though it will work with plain old PWM, I am making a basic buck converter. You seem to be finding the simplest problem and turning it into the biggest project. Fundamentally if you don't understand how these things work and therefore how to trick them into doing what you want because you are too lazy to use the right tool for the job you will waste a lot of time on something that is a non issue.

[engineheat]

I'm still confused, why are you trying to speed control a 2 wire fan when you can get one with a PWM input?

I only recently got the 4 wire version. It was out of stock.

[engineheat]

With all due respect, I don't think all of those transistors are necessary. The tach output is typically open collector, so all that's needed is to connect it directly to a GPIO pin with a pullup resistor to VCC. The PWM input can be driven directly by a GPIO pin. Supposedly, 5V logic is required, but they often work fine with 3.3V. No significant current goes in or out of either fan pin.

Like this?

[engineheat]

Any idea on how to count the pulses using the Arduino to get the rpm?
I saw some solutions using the pulseIn() function but that seems to wait for the tach pin to change states so wouldn't work well if the rpm is slow or 0.

I can only think of waiting a fixed time period in the loop each time, and count how many times the tach pin changes state from HIGH to LOW.

[pqass]

Any idea on how to count the pulses using the Arduino to get the rpm?
I saw some solutions using the pulseIn() function but that seems to wait for the tach pin to change states so wouldn't work well if the rpm is slow or 0.

I can only think of waiting a fixed time period in the loop each time, and count how many times the tach pin changes state from HIGH to LOW.

Yes on the last statement. 

It can be done by counting the number of interrupts on Arduino pin 2 (wired to the fan tach output) then freezing interrupts, collecting the count so far and the time lapsed (millis()) since the last freeze. A rate can then be calculated by dividing one by the other.  Notice that the time lapsed doesn't have to be a fixed, precise amount every time. Any update rate you prefer can be the time interval since if more time passes, more counts are accumulated.

This is what reciprocal frequency counters do; giving high precision even at low frequencies.  If your fan speed is about 1000RPM (or <17RPS) then your Arduino (@16Mhz) will be able to keep up.

Something like the following [untested] code should work:

Code: [Select]

const byte interruptPin = 2;   // or 3 would work too
volatile int counts = 0;
unsigned long last = 0;

void setup() {
  pinMode(interruptPin, INPUT_PULLUP);    // tach output needs pullup to MCU Vcc
  attachInterrupt(digitalPinToInterrupt(interruptPin), incCount, FALLING);
}

void loop() {
  noInterrupts();    // stop the count and millis() clock for a brief moment
  unsigned long now = millis();
  float rate = (now - last) / counts;
  last = now;
  count = 0;
  interrupts();    // carry on counting
  // rate var is in milliseconds per revolution which can be converted to RPM
  // may need to divide counts var by n if the fan generates n counts per revolution.
  delay(1000);   // do other stuff or wait some brief period of time before calculating rate again
}

void incCount() {
  counts++;
}


[Simon]

I don't know what the arduino offers these days in the software and it also depends on the MCU you are using. For your purposes pulses over a period of time will be better. I have used both methods and currently work on a machine where I time the pulse as I need this information quite quickly to regulate the speed. It's a case of looking at how long can you wait for the information and how long the pulse is at the slowest speed of interest and therefore at what speed do you assume 0.

[eugene]

Like this?

Yes. I've controlled 4 wire fans that way. For sending the PWM to the fan, a circuit like the one Nominal Animal shows might be more robust depending on the fan and MCU. There's a risk that the fan contains a pullup to 5V on that pin, but if your MCU is not tolerant of 5V (some 3.3V MCUs are not) then the MCU might be damaged. The open collector/drain transistor prevents any issue.

As for the tach signal, I've been trying to figure out why Nominal Animal suggests such a complicated circuit. I finally realized that he's dutifully following a line in the Intel document that says "Motherboard will have a pull up to 12V..." Once he does that then he needs all of the other circuitry to accommodate the 12V. Well, I am virtually certain that that line is an error. It makes no sense unless the logic level of the motherboard is 12V. It's an open collector output and can be pulled up to any voltage desired. In this case, pulling it up to the logic level of the MCU makes the most sense, then all those transistors are completely unnecessary.

[Nominal Animal]

As for the tach signal, I've been trying to figure out why Nominal Animal suggests such a complicated circuit.

If you trust all your fans have open collector tach outputs, and that their PWM input doesn't have a pull-up (or pull-up equivalent circut) to higher than your logic voltage, then you do not need the MOSFETs.  I don't trust the fans that much.

Instead, I use less than 0.50€ worth of components (from Mouser) per fan, to make sure that no matter what kind of circuit shenanigans the fan contains, my circuit will deal with it properly.  The MOSFET I chose has low Vgs(th) (it'll work even with 1.8V logic), and Vgs range is ±20V  (and Vds max is 60V).  This means that even if the fan were to short both PWM and TACH signals to 12V, my circuit doesn't mind, and nothing will break.

This is my logic: I don't want to tell others what the minimum circuit is that may or may not work with specific situations; instead, I want to show how to do it reliably, without risking your MCU.  I do the same with software, and honestly tell them that if they ever tell me they'll "add error checking afterwards, when they have more time", I'll throw them out, because that never gets done.  You either design for robust and secure implementation from the get go, or you are just throwing spaghetti at the wall and seeing what sticks.  Engineering, or guesswork.

Attached is a rendering of the 61.5mm × 15.2mm (2.42" × 0.6") board based on ATtiny85 in DIP-8, powered from 12VDC, that I designed today.  It can control two fans (using one potentiometer, on the 3-pin JST PH-2.0mm connector), using Timer1.  The capacitors are all 0805, and all resistors are 0805 (but the pads also support 0603).  The two support holes are 2.54mm or 0.1", for M2.5 or #2-56 or #3-48 nylon screws or supports.  Omit the MOSFETs, and you shorten the board by 5mm to 10mm (0.2" - 0.4").  Not worth it.

[eugene]

As for the tach signal, I've been trying to figure out why Nominal Animal suggests such a complicated circuit.

If you trust all your fans have open collector tach outputs, and that their PWM input doesn't have a pull-up (or pull-up equivalent circut) to higher than your logic voltage, then you do not need the MOSFETs.  I don't trust the fans that much.

I get that. And whatever trust I have comes from the same place as yours: the Intel spec document. It clearly states that the output of the tach signal is open collector. It also states that the specified circuit to drive the PWM input should be open collector. I know there's huge risk in trying to second guess someone else's intentions, but I'm still going to guess that those specs were made to eliminate any issues with different logic levels. Likewise, the spec that there will be two pulses per rev in the tach signal is purely practical: the Hall sensors used for commutation in these little BLDC motors output two pulses per revolution. Intel just wanted to make it easy for fan manufacturers to make fans that work with a minimum of cost and complexity.

So, using an open collector/drain transistor makes good sense when designing a circuit that might work with fans from unknown sources. OTOH, it is my firm belief that the spec that "Motherboard will have a pull up to 12V" is an error. Possibly it was intended to say "Motherboard will have a pull up to no more than 12V." That tells the fan manufacturers that they can use transistors with max Vds of at least 12V and not have to worry. Specifying that every motherboard will have a pull up to 12V makes no sense at all.

I have no hard evidence, but I'm willing to bet lunch money for a week that spec as written is a mistake.

"Instead, I use less than 0.50€ worth of components (from Mouser) per fan, to make sure that no matter what kind of circuit shenanigans the fan contains, my circuit will deal with it properly. 

I get that too. And, obviously, if I were asked to design a commercial circuit where there was no way to know what fan might be attached, then I would always include the open collector drive for the PWM. OTOH, I would not bother with the complicated tach circuit and instead just trust that the fan has an open collector output on that pin as the Intel spec calls for.

But that's a 'serious' design with PCBs etc. In this case we're talking to a hobbyist who is likely prototyping on a wireless breadboard and possibly moving eventually to proto board. For them, it's not the cost of the components but the effort involved in building the circuit, and then troubleshooting it because they put it together wrong. The Intel document says that there will be a pull up on the PWM input to no more than 5.25V (IIRC) but they encourage new designs to pull up to 3.3V. In those cases, it will not damage the 5V MCU to drive the pin directly, thereby reducing circuit complexity greatly. However, I also suggested that your open drain circuit is more robust.

I still recommend to everyone that no more than a simple pull up is required on the tach signal.

This is my logic: I don't want to tell others what the minimum circuit is that may or may not work with specific situations; instead, I want to show how to do it reliably, without risking your MCU. 

I get that too. However I also recognize that designing to specific requirements is not a bad thing. If I ask a contractor about building a footbridge across a small ravine that will only need to support me and my dog, and the contractor comes back with a design that can support military vehicles, then I will look for a different contractor.

[Nominal Animal]

I still recommend to everyone that no more than a simple pull up is required on the tach signal.

That is perfectly fine, and I understand your reasons for that.  I do not want or intend to change your opinion on that.

Thing is, on the electronics side, I am still just a hobbyist with not enough practical experience.  I have no reference or yard stick to compare to, to estimate what manufacturers can be expected to do.  Therefore, I have to err on the side of caution myself, especially since I intend to use not just the "high-end" Noctua fans, but also the cheap ones too.

What is up to argument, is whether I should have expressed the above qualifications with my suggestion.  I probably should have.

[engineheat]

I like the way you used interrupts in your code. My version does not use interrupts and the displayed rpm is not stable.

I didn't realize you can stop the millis() clock with interrupts. My current PWM of 25khz is implemented using timers, the TCCR1A, TCCR1B, ICR1 stuff. Will interrupts screw up the PWM signal?

Thanks

[engineheat]

My next step is to make the setup more permanent by soldering it to a solderable breadboard (Perfboard?). I do want the power source and the motor to be easily detachable in case I need to change them. Ideally, those can use a screw-like connection. Are there connectors (terminal block?) that can fit on the spacing of that of a breadboard?

Thanks

[pqass]

I like the way you used interrupts in your code. My version does not use interrupts and the displayed rpm is not stable.

I didn't realize you can stop the millis() clock with interrupts. My current PWM of 25khz is implemented using timers, the TCCR1A, TCCR1B, ICR1 stuff. Will interrupts screw up the PWM signal?

Thanks

millis() returns the value of an internal variable that is updated every 1.024 milliseconds via TIMER0_OVF_vect ISR.  Pin 2 external interrupt is handled by the INT0_vect ISR which Arduino hides behind the attachInterrupt() call.  Assuming 1000 RPM fan, that's 16.6 times per second or an interrupt every 60 milliseconds.

The noInterrupts() call stops all ISRs from executing.  All timer interrupts and the external interrupt raise a flag when their interrupt occurs (see: TIFR0:TOV, TIFR1, EIFR).  And will run their ISR (and clear the flag) as soon as the call to interrupts() re-enables global interrupts.

But we shouldn't stay in this interrupts-disabled state too long otherwise subsequent interrupts will be missed (flag still set, ISR yet to run when a newer interrupt arrives).  TIMER0 is set and forget by Arduino runtime initialization.  TIMER1, the one you are using, should also be set and forget until the need to change the PWM value.  I'm not sure of the need to call any ISR for TIMER1 (ICR1?).

So by keeping the interrupts-disabled state to a minimum (kept way below min(1ms,16ms)+overhead), you shouldn't lose any interrupts. And TIMER1 should still be outputting the same PWM even if the CPU is in an ISR. It'll just need to finish before you can change to a new PWM value.

I've updated the code below to do the bare minimum amount of work; just take a snapshot of the vars (5 assignments + 1.5us interrupt overhead, I think).  That way any slower math and floating point operations can be taken out of the critical section. Also, the rate is in RPM to avoid a divide by zero (in the last version).

EDIT: We don't stop the millis() clock; just hold-off updating it by preventing the ISR to run briefly.
EDIT2: Localized the rate calculating logic to the getTachRateInRPM() function.
EDIT3: Confirmed that the code works.  It just needed a cast to float in the function return.

Code: [Select]

const byte interruptPin = 2;   // or 3 would work too
volatile int counts = 0;
unsigned long last = 0;

void incCount() {
  counts++;
}

void setup() {
  pinMode(interruptPin, INPUT_PULLUP);    // tach output needs pullup to MCU Vcc
  attachInterrupt(digitalPinToInterrupt(interruptPin), incCount, FALLING);
}

float getTachRateInRPM() {
  noInterrupts();    // stop the count and millis() update for a brief moment
  unsigned long now = millis();
  unsigned long lastLast = last;
  int lastCounts = counts;
  last = now;
  counts = 0;
  interrupts();      // carry on counting

  // may need to divide counts var by n if the fan generates n counts per revolution.
  return (float)lastCounts / (last - lastLast) * 1000 * 60;
}

void loop() {
  float rate = getTachRateInRPM();

  delay(1000);       // do other stuff or wait some brief period of time before calculating rate again
}


[Simon]

what a lot of convolution to beat the arduino into doing what the very same micro could do if it was just programmed properly.

You set your timer up to run as fast as it can without overflowing between the slowest pulses (actually that is a way of extending the timer if it has other interrupts that let you count up those overflows), at every pulse the count is stored in a capture register and the timer resets.

[pqass]

what a lot of convolution...

I see now. 
But you'd need another timer (TIMER2?) to create the PWM output for the fan.
Then, no more timers.

[Simon]

Even the ATmega328 has 3 timers: https://www.microchip.com/en-us/product/ATmega328#

2x 8 bit and one 16 bit. Now you need 25kHz PWM ? if the thing were running at 20MHz that would give you 800 steps (20MHz / 25kHz). with the 16MHz that most people use that is 640 steps, or to run at 25kHz on a 100 step PWM that is a divider of 6.4, or if you were at 20MHz that is 8, wonder where I see that number a lot, it is likely that the counters can have a prescaler of 8.

Now if you are not super hot on your accuracy of speed measuring what you can do is not only have a capture compare output running for PWM but the top count/rollover interrupt enabled. This means that you know every time the counter got to 100, that means you can increment a variable every 40µs, even at a fan speed of 2000rpm that is 30ms/rev or 15ms per pulse? at 2 pulses per rev. that is 750 counts even at the highest speed. at 400rpm you will have 75ms pulses which will be 1875 counts. You also have a system clock variable that you can use, that is in a decent round number and unlike the arduino is what it says it is.

You get everything done with one counter and have a system timer for free and you don't even have to worry about reading the counter value but you could if you wanted 50ns accuracy.

This is how micro controllers were supposed to be used, not as sodding PC's!!!

[pqass]

Thanks, that's good to know you can do both in one timer.

But we're in the Beginners forum and the TIMER1 docs are 20 pages long.

Apart from his UI, all he has to call is pinMode(pin, OUTPUT) and analogWrite(pin, pwmVal) occasionally.

[Simon]

Thanks, that's good to know you can do both in one timer.

But we're in the Beginners forum and the TIMER1 docs are 20 pages long.

Apart from his UI, all he has to call is pinMode(pin, OUTPUT) and analogWrite(pin, pwmVal) occasionally.

This is the problem I have with my apprentice. He thinks bit plipping in registers is a waste of time and only wants to work on high level stuff and never looks at how something works. This means that everything he does is a start from scratch copying examples etc. The problem here is that with this way of working you get to a point where your screen does not update fast enough so you keep cranking the clock frequency beyond what it should be and are still amazed that it's even working and that the updating problem is still there. The he comes and tells me about it and I say OK, have you actually measured the screen clock frequency, so he does and it's low, OK so that is why the screen did not fall over when the clock was set even higher. OK, describe the system to me, what blocks does it have and how do they interact? Oh there is your problem, it's a general system wide problem that delays the screen data transfer, not that the screen is not being sent data fast enough....

So 20 pages you say? doddle, this is what a forum like this is for, to help you with that. If you are frightened by the datasheet of I assume an AVR then don't think about touching anything else, that is as simple as it gets. once you understand the counter in one micro controller you are over half way there for any counter in any other micro controller, while there are 100's of manufacturers most sort of do it the same way.

The problem I found when I started was that no one explains in one piece how programming micro's works. You need to understand the chip, how to use C to setup the hardware because all C lessons are about PC environments and this was the big stumbling block for me. Then you need explaining that there are the chip's header files and how to use them. I did one project in Arduino, after struggling to get into micro controllers, then I converted it into a project written in the manufacturers IDE and never looked back. Every time I think of using an Arduino for a quick lash up, 5 seconds is about as far in as I get before I realize that the way in which the Arduino abstracts the hardware for you is actually crippling your ability to get stuff done. So I go back to a plain micro controller and continue to increase my own basic code base to use as a starter for any project.

Arduino for example will not allow you to use ADC's very well, you have to ask for a conversion and wait. In my code I set up the ADC to run in a round robin mode so that it simply cycles through the channels I want it to and at any time without worrying about interacting directly with the ADC I take my results from a variable that the interrupt routine put them into. These are already oversampled and/or filtered because relying on a single conversion is a really bad idea, but this is what the Arduino teaches you to do.

Everything the Arduino system leads you to believe is wrong in my view. If you are one of the prescribed target Audience - hacker whatever the hell that is, maker, um same, hobbyist, artist anything but engineer or aspiring engineer then fine. But if you are an engineer or want to be one the Arduino is not for you, it was designed for non technical people to give people with no interest in electronics something to use. But like most things people forgot to read the specs: designed for non electronics people and maybe programmers.

[Infraviolet]

If you're using arduino's IDE and its uploading/programming functionality (AVRDUDE is the actual command line tool doing this part underneath) specifically for AVR microcontrollers and use the more abstracted functions only in very limited places (if pinMode is a bit slow, but only used once during initial setup then so what, it is very different to digitalWrite being slow when you need to bitbang out some unusual data protocol at speed) I would say it can be pretty adequate. Especially if you load programs on to their final chips with the programemr method, rather than the usual upload (lets them recover much faster after a reset). The problem with arduino isn't it in itself, it is with overly using its easy abstraction functions, and using it for chips very different from AVRs where there aren't such simple ways to directly call the underlying register functions hence you get more easily forced in to the abstraction layers, and using libraries without first looking carefully inside them to verify they work sensibly beneath their own abstractions and don't stack extra abstraction on top of already highly abstracted functions.

[Simon]

the problem with the Arduino is that it was designed for an AVR, the limitations this imposed onto the software environment and what you have available to you are then inherited into systems made with more complex chips.

Again take the analogue read example. On an AVR it only gets as bad as you do it in polling mode so your program waits an eternity as the ADC takes over 10 ADC clock cycles to make a conversion which typically runs at a mere 100kHz, so now your 16-20MHz CPU is sat waiting for say 2400 cycles doing nothing while waiting for the ADC conversion. OK, so the AVR has no hardware to support ADC averaging or oversampling so it is just thousands of CPU cycles gone to waste unless and interrupt makes use of them.

But enter say the SAMD, this now runs at 48MHz with an ADC that can do 1MSPS, so your CPU will just waste 48 clock cycles waiting. But there is still this thing that you should not rely on a single ADC result unless you have good reason to, I mean just look at the.... od sorry, Arduino users do not care for datasheets. Anyway, look at the datasheet and you will find that there are caveats galore on everything in that bit at the back that makes the 12 bit ADC just about good to do 10 bit, if you want to rely an ever last count of that ADC result you need to filter. Well the SAD has the hardware to accumulate results and bit shift them so that the while process presents itself in the same way as your single unreliable ADC result in the AVR but all that work is done in the back ground. If you go banannas on it that is a result every 1ms or so. But wait, the arduino knows nothing of this, you still get a single result and may end up writing averaging code at great expense of CPU resources when you already have hardware to do that.

I know that the modern approach is to show something snazzy and slowly work backwards and that is fine, but if the snazzy thing is so hopelessly useless except to those that do not care that you will have to unlearn so much and start again then good luck....

[pqass]

Every clock cycle is NOT sacred. God will NOT get irate if some are wasted.

Using the Arduino APIs allows the developer to work at the level of his current understanding.  With every project, if he chooses, he can explore a bit of the low-level hardware then replace the training wheels with an impenetrable yet efficient wall of register assignments.   That's much better than being thrown into the deep end with only a hardware reference manual and maybe a code-generator.

In response to questioners, specific features should be referenced by their name as they appear in the manual, a quick refresher on what they are and how they are typically used, any obvious dependencies/limitations, and include code snips where possible.  I was not aware of the ICR1 register and TIMER1_CAPT ISR nor am I entirely sure which PWM mode it would work with.  Timers are the most dense and configurable subsystem on the MCU and need to be digested piecemeal.  I think I presented a straightforward, undemanding solution.

[Simon]

learning about the micros register will not teach you basic signal processing, you are either into the engineering or you are not, this was the point of Arduino, like Yorkie bars it is for the boys, it is not for engineers!

No clock cycles are not sacred, but with the wrong approach and a total lack of understanding one will be left wondering why with such a fast processor it takes so long to do anything, so the solution must be an even faster processor. next a Blinking LED on a Pentium?

Same logic as my apprentice that thought he was cranking up his video clock when in fact something else was holding it up! And it was I who understood nothing of the specific system but enough about "systems" that got him to reason through to what was wrong.

[engineheat]

You guys have been mighty helpful. I'm able to successfully control the 4 wire fan via 25khz PMW with the Arduino and adjust/display the speed.

Only question now is, when I measured the various current draw at different duty cycles, I got about 0.17A at 100% duty cycle and half of that at 50% duty cycle, which makes sense. But when I connected the fan directly to the power source bypassing the Arduino, the current is about 0.20A, which is not that different from 0.17A but I'm kinda curious why there is a difference.

I also would like to know why this is much different than the "rated current", which according to the datasheet is 0.34 (max: 0.42) A

https://www.digikey.com/en/products/detail/delta-electronics/BFB0712HH-AWPH/13997125?s=N4IgTCBcDaIEIDE4AYDsBGMAJLBaAggOoAKWIAugL5A

[Simon]

Well I would be quite surprised to see only half the current at 50% but then I understand fan laws, oh yes, you want to do "electronics", well you are dead in the water if you don't have a basic understanding of the real world so lots of I suppose physics.

What are the actual speeds? the duty cycle of the PWM to current comparison is meaningless. As the fan is so small other factors may contribute in a way that has the whole thing deviate from fan laws as these apply to the mechanical input energy to the impellor. The datasheet seems to suggest a linear relationship of PWM duty to speed but they are so vague that it is anyone's guess. Fan laws state that the flow goes up or down proportional to speed and the pressure follows a square law. So double your speed and you get twice the flow and 4 times the pressure. This is fortunate as if you want to move air inside a duct at twice the speed you will need 4 times the pressure as that bit of fluid dynamics follows the same square law.

So what that means is that the power input to the impellor changes in relation to the speed with a cubic relationship. double your speed and the power required is 2^3 = 8 times. Do this in reverse and at halve speed you should be using 1/8 the power. Now obviously on something so small you also have to take into account that just getting the unloaded motor turning will take some considerable power compared to running the fan so the results will be skewed. This is one reason to have fan speed control, apart from noise reduction there are huge efficiencies in power by running at a constant lower speed rather than sporadically at the maximum speed (think auto radiator). When I worked around automotive stuff I did some calculations, by running an 850W brushless fan at 50% speed you would probably double the lifespan of the fan and save an amount of fuel equivalent to £10'000 over the lifetime of the fan. At the time I was working on a buss project and the company were talking about up to 10 fans on one bus.

The other thing to remember is that the power demand from the impellor is down to how much air it is moving, not how much pressure it is exerting. This is highly counter intuitive but and most people get confused over it, even engineers specing fans, if you block the fan inlet or outlet stopping the airflow the current will plummet, this is because all you are doing now is spinning a fly wheel as air is not being moved. The maximum current they state may be with the fan impellor in open air or maybe you had the airflow a little restricted.

Also that fan runs up to 13.8V it will use the more current as with a higher voltage more speed can be achieved but more torque (current) will be required to drive the fan pushing more air because if the speed goes from 12 to 13.8V that is 15% increase in speed on the motor, now we now know that the increase in flow will be 15% and power at this speed is 1.15*1.15*1.15 = 1.52. The voltage has gone up by 15% so we can make that 1.15*1.15 = 1.32, a 32% increase in current requirement. 0.42/0.2 = extra 70%, but remember that real fans will not do fan laws perfectly and you have a cheap little motor in there.

As for the current change from 0.17 to 0.2, yea, that may be the internal interface circuitry, 100% may not be 100%, I would check the arduino output is really 100% duty, many micros won't do 100%. It is also possible that there is something about the circuit that does not produce the equivalent of 100%. In my early days with speed controlling fans The fan manufacturer had a simple system, the input voltage was put through a resistor followed by a 10V Zener, this made the PWM that you would expect to be at battery voltage 10V, then they cut this in halve with a resistive potential divider that also had a filter capacitor low pass filtering the PWM to a voltage. When I tried to drive a 2N7002 MOSFET from my micro that was pulled up to the battery voltage with a 10k resistor that was quite a bit smaller than the resistors in the fan, customers reported the same behavior you have described. The problem here was that they were trying to push the systems to the limits.

[engineheat]

I got a good prototype working with the 4 wire fan and was able to control the speed using the Arduino via PWM (25khz). This has been a good learning experience.

But so far I've only used a small 12 V BLDC fan like this:


I wonder if there are much bigger fans that I can use to get bigger air flow, yet still has 4 wires and can use the same control circuitry? FYI, this is for air filtration purposes and the small one I built was for personal use. But now I want to build a bigger version that can purify a whole room. Do I need to look for AC fans?

Thanks

[Simon]

AC fans are your best bet. There are powerful brushless 12V and 24V options as well as mains. Look at ebmpapst, they have mains fans with 10V controls and sometimes a 10V supply. Spal is another option if 12/24V is what you are after, they will only work between 100 and 500Hz, I have made many a controller for them, they will also accept 0-10V input.

[Nominal Animal]

I wonder if there are much bigger fans that I can use to get bigger air flow, yet still has 4 wires and can use the same control circuitry? FYI, this is for air filtration purposes and the small one I built was for personal use. But now I want to build a bigger version that can purify a whole room. Do I need to look for AC fans?

I'd take a look at the specs of Noctua IndustrialPPC fans, for example the NF-A14 IndustrialPPC-3000 PWM, and if not sufficient or suitable, move to AC fans; specifically, I'd look at quiet AC duct fans.

NF-A14 IndustrialPPC-3000 runs at 12 VDC as usual, but may draw up to 0.61 A of current (7.3 W).  Uses the exact same control mechanism and specs as your bog-standard 4-pin PWM PC case fans (25 kHz control signal, tach return with two pulses per rotation, et cetera).  It can generate up to 6.58 mm H₂O static pressure, meaning it is well suited for air filtration.  Maximum airflow is 269 m³/h ≃ 158 CFM.

I'll probably use one or two (at lower RPM for quieter operation) for a 40/60-liter soldering open fume hood with HEPA filtering, for use in my small flat.

[engineheat]

Thanks.
While we are on the topic of air filtration and fans, I have a side question. I recently went on a trip to China where the voltage is 220V, 50Hz and I brought along my US bought air purifier that runs on 120V, 60Hz. I used this power converter:

https://www.bestekdirect.com/bestek-universal-travel-power-converter-with-qc-3.0-white

It converts 240/220V to 120/110V.

While the air purifier worked in China, I noticed that it is significantly louder. It might be possible that it was damaged during transit, but I wonder if there might be an electronics explanation? I also noticed a high pitched whine that not even my earplugs can fully block. Unfortunately, I did not bring it back to the US so I cannot test it again.

Could the increased noise be due to the power converter? Does it have to do with sinusoidal/non-sinusoidal waves?
Thanks