FEATURED Building PWM Controller for 4 wires PWM fan

[LennyRhys]

This is a really nice development guys. I just bought myself a Delta AFC1212DE which I should get early next week (woohoo) so I put the 2-98% controller on breadboard again. I read through the last few pages of this thread again and I noticed something that Bob said about his Nidec (which I also have):

Bob - my Nidec behaves very differently from yours. You said that when you grounded PWM it didn't have any effect on speed; when I ground PWM the fan goes to the lowest duty cycle I get with the 2-98% controller (whatever that may be...not convinced it's 2% or anything close lol). Whether the PWM is grounded or the PWM is fed from the controller and set low, the fan draws 230mA. But that's not the only strange thing...

With this fan (and this fan only) the controller is totally unresponsive for the first 1/8 (or so) turn of the potentiometer. The current stays steady at 230mA and after a fair bit of travel on the pot the current starts to increase steadily, topping out at about 2.5 amps. Fortunately, this time the fan didn't manage to eat any more of my components

None of my other PWM fans have this behavour with the same controller. Any ideas?

 

[Bobnova]

Defective fan? That's very different behavior than mine!
I got a second Nidec like my first one, and it behaves the same way (haven't tried grounding it), at 0% PWM (real zero from the MCU) it stops dead, that part is different. Turn it up a bit (takes maybe 5% before it lights) and it cranks to life.

Does yours go to full stop at all?

 

[LennyRhys]

Nope, 230mA is the lowest it goes, and my guess is maybe 1500-2000rpm at that speed (couldn't be bothered connecting the tach).

Just noticed what bing quoted from the Nidec website and one of their "custom" PWM functions is mid-to-full-speed PWM. That sounds a lot like my Nidec!

Out of curiosity, are you using the CMOS version of the 555/556? I only have TTL...

Here's my Nidec's label:

 

[Bobnova]

My 556 controller uses an NE556, I think that's the TTL flavor. Not really sure, I've been working through the pile of chips Seebs sent me.

Same as mine by and large, above the 0DC mine says 4815D P1, and it doesn't have anything inbetween DC 3.3A and MADE IN CHINA.
Under the -35 mine says OCT.

That goes for both of mine, the labels are identical. I think they came out of the same decommissioned server, too.

I'd guess the speed of mine on full low (but not stopped) at around 1k, so far the only time I tried to get RPM out of it to the mobo it caused a failure to POST. Not real inclined to blow my mobo to bits trying to figure it out.
Only time I've tried to get a reading via MCU chunked one of two interrupt pins and a digital pin on the MCU in question.
Atmel thoughtfully agreed to send me product development samples though, so I'll be making another effort at getting tach input/output using the other interrupt pin. If it dies completely I have spares now. Plus I think I might know what happened, not positive, but I may have forgotten to engage the internal pullup resistor, so my "pull-up" was a dead short internally. It went "snap!" when I plugged it in. Bad sign.

A thought: What frequency is your controller running at? The MCU flavor I just put together runs at 15.3khz +/- 10% (internal oscillator in Attiny85s can be of highly dubious accuracy) I don't remember what my 556 flavor runs at, not sure I've tested. It uses the official Bing556 circuit, but variance between caps means it could be anywhere! The other 556 circuit I made with caps from the same batch ran 18khz to 20khz if I recall correctly.

 

[LennyRhys]

I'm using a polypropylene 680pf which gives a very stable 16khz (I believe). Also have some silver mica to play with, and bog standard ceramic too. From what I remember I don't think changing the frequency helped, but there's no loss in trying!

 

[Bobnova]

You need an Arduino-ish-MCU-thing, then you can actually test the frequency

Given that mine behave the same way at 15k and 18-20k you're probably right though.

(Actually, I just love atmega/arduino platform and think everybody else should too. Given that you're in europeish: jeelabs.com is where i'd go)

 

[LennyRhys]

Yeah no matter what value cap I use there's no difference to the behaviour of the fan, so I suspect it's the way the PWM has been implemented in this particular fan - dayum!

On a different note, with the PWM wire grounded the fan responds extremely well to voltage control and can be slowed down to quite some extent. The beauty of this is there's virtually no heat because it's drawing less than 3W - not bad for a 39W fan!

 

[Bobnova]

That's an interesting thought!
I'm still tempted to put a stiffening plate on mine to see if I can shut it up at low speeds, they still move a tremendous amount of air at 1krpm. If the motor didn't twist itself into a pretzel every time the magnets fired it'd be a fantastic low speed fan.

 

[jalyst]

Wow things are progressing pretty fast WRT your plans Bob!
I'm subscribed on weekly basis to this thread & so much has happened

It's still quite a long way off what I'm hoping for*, so I'll still articulate what I envisage to folks @ the arduino forum, as you suggested.
But even so, I'm happy to be one of your "preliminary testers", when/if you need any more

Cheers
*which TBH needs some reconsideration.

 

[bing]

I was thinking about that too bing, what works great for me benching isn't really fine enough control for normal users I don't think.
Once I get an ICSP header on there so I can safely program it I'm going to try 5%, and see if I can get some functionality for holding the button down, I don't relish hitting it 20 times to get from one end to the other (excluding the fact that you can jump direct by hitting both).

I'll send you the next one if you want bing, you've been an incredible help with all this fan controller business! It might even have a real PCB!

Wow .. thanks for the generous offer, sure, just take your time, no rush, and it will be my honor to have that fine piece of equipment.

About the control button, suggesting to put the feature that if the button was pressed in normal time frame, then the increment or decrement step will be using the smallest step available, but if the button was pressed for quite long time, say like 500ms or 1 sec, then the increment will jump to big step like 5% or even 10%.

Again this is just an idea, not sure if you still have the code space left and hopefully its not too complicated and time consuming to re-write the up/down buttons handler code.

I'm using a polypropylene 680pf which gives a very stable 16khz (I believe). Also have some silver mica to play with, and bog standard ceramic too. From what I remember I don't think changing the frequency helped, but there's no loss in trying!

Dave, that plastic 680pf is more than enough for this circuit, while silver mica imo is way too overkill.

How is your 1st controller that you told us that its broken, did you build the new one ? Suggesting to switch to 0-100% version if you can, its way better.

Yeah no matter what value cap I use there's no difference to the behaviour of the fan, so I suspect it's the way the PWM has been implemented in this particular fan - dayum!

On a different note, with the PWM wire grounded the fan responds extremely well to voltage control and can be slowed down to quite some extent. The beauty of this is there's virtually no heat because it's drawing less than 3W - not bad for a 39W fan!

It is possible that you have a really rare, weird and heavily customized prorietary fan that is not complying with any fan controls standards out there.

 

[Bobnova]

So far I'm using 1.8k of 8k storage, 2 bytes of 512 bytes of EEPROM (writable from inside the program), and maybe 70 bytes of 512 bytes of ram, lots of room left for additional features. I think you have the right idea for the buttons, I'll see what I can do on 'em.
The PWM is an 8bit value, so I can do 256 steps, less then 0.5% per button press is intense control! I may make it somewhat open ended, have a ~70ms press do one PWM step, then an additional step for every 100ms the button is held down, or just one step every 30 additional ms. The full range would take 7.6s that way. I do have two spare pins, so I could put more buttons on to control range or something.

I built a ICSP header (sortof, heh. It's a 4x1 header rather than 6x2, but it works) into my perfboard version so I can reprogram it as it sits.

Oh hey I forgot to update!
I played with which timer does what, and got 31khz PWM output.
Then I played with the internal occilator calibration and was able to drop the CPU clock to 6.4mhz from 8mhz, giving my 25.4khz PWM speed. Perfect! That got rid of the vast majority of the motor whine at 50% throttle.

Other than PWM the program needs maybe 10khz to get the job done, so it's not like dropping from 8mhz to 6.4mhz puts a dent in things. Still feels a bit weird downclocking though, given my benching tendencies!

 

[LennyRhys]

bing - I just have the 556 on breadboard atm. I will definitely look into making the 0-100% controller, but I think it'll have to wait until I'm on holiday! And you are right about the Nidec - I think I have a rare proprietary fan. I suppose I could send it to you if you want to play with it, and one of my San Ace 9SG fans too?

Other news: I have 2x Delta AFC1212DE and 2x Thermalright TY-140 coming this week for my new case mod, all PWM fans, so I'm really looking forward to seeing what they can do when paired with the 556 controller!

 

[bing]

Wow Dave, how can I reject such offer ! Thank you so much ! PM to follow.

About the delta afc1212de and ty-140, I have both too, I believe you will love them, the delta when at minimum speed will be very quite but still has very good static pressure compared to 25mm fan, while ty-140 is different league, very2 silent and for it's price and performance, imo one the best 140mm fan out there.

 

[LennyRhys]

My pleasure bing - maybe you can play with the San Ace and see if you can stop that awful whining noise!!

And yeah I love the AFC1212DE... just an amazing fan, and only 1.6 amps ("only" LOL). I am going to put one on the CPU and the other on the GPU so I decided I would build a controller specifically for this fan. I had originally thought of a third channel for the TY-140s but they are so quiet it's just not necessary.

I don't have time for the 0-100% controller just yet so I decided to redesign my 556 layout and make it even more compact, and I'm very happy with the final result.

The unit uses floppy drive connector for power and the PWM frequency is 25KHz +/-. I don't know what frequency this fan is, but the spec sheet says it takes a PWM signal from 30Hz to 300KHz (?).

 

[Bobnova]

Very nice!

I just discovered the floppy drive connector too, it's a perfect 0.100" pitch!

Just don't plug it in backwards

 

[LennyRhys]

I just got my second AFC1212DE in the post. I'm amazed at how different the two fans are - although exactly the same model, thay are quite different in behaviour/performance/aesthetics.

The fan I received today is on the right in each picture and is in brand new condition; paradoxically, it cost me £5 with no postage whereas the first one I bought is definitely older and a bit grubby, and it cost me £15 including postage lol. Oh well, two kicass PWM Deltas for £20 is a bargain - cheaper than two Gentle Typhoons!

The newer fan is different in the following ways:

• totally different impeller with bigger blades - "feels" a lot more powerful
• different frame design
• different PWM behaviour - it doesn't stop at low duty cycle (the first fan does)

LOVING these fans though. A LOT

Anyway, on the controller front I finished up the two channel 556 controller with a perspex-fronted case and more of my favourite brushed aluminium knobs I will either mount it in a modified drive bay or set it up externally as it is at the moment...I'd definitely prefer it inside the case though.

 

[Bobnova]

Re-wrote the code for button holding!

Now the first time you hit it, you get a 00.78% change in output (aka 2 points in a 0 to 255 scale). If you hold it for >450ms it starts giving you 00.78% every 10ms till you let go.

You can still hit both buttons to jump straight to max (from anywhere), or to minimum (if you're at max).

The code is clunky, but still only uses 2k of 8k of flash. Should still fit in ram too, I didn't add too many variables, just a lot of if-then-else-ness.

In fact, having just checked over the code, it looks like I used an additional one (1) bit of ram.
If that puts me over the 512byte limit I'm going to laugh.

Next up is repackaging it for the attiny85, as I've been testing on the atmega328, due to the fact that it has serial output and is hence far, far, far easier to debug.
Mostly this means changing pin mappings (three, each in only one spot (which eats eight bytes of ram due to laziness and occasional issues using a "byte" variable to compare to ints)) and multiplying the various places milliseconds show up by ~56 to account for there being ~62,000 milliseconds in a second in attiny85-land (this is what I get for screwing with the internal timers to get the PWM speed roughly where I want it, and then dropping the CPU clock speed to find tune PWM speed)


As an amusing side note, I can overclock (or underclock) this thing in software, I could even do it with buttons like a ROG Connect!
Of course if I go >10% OC it runs the risk of not being able to write the EEPROM correctly, pretty much the exact same issues you have when cranking PCIe with sata drives.
Once I get the conversion to attiny85 finished, I'll send it off to seebs for testing.
I'm hoping to get my PCBs ordered in time to get them in this month's small-batch production, we'll see. I will be able to get some attiny85 breakout+PSU+ICSP boards made, that'll be fun to have. Beats setting it all up on a breadboard.


EDIT:
Contemplating a user runnable calibration routine for the buttons. It'd be expensive in EEPROM but I have lots to spare (currently using two bytes of 512, calibration would eat 24 bytes or so(less than I thought, really)), and somewhat expensive in ram (96 bytes there, ouch), but I think I have plenty there too. In theory there is a register that stores the amount of free ram that I can poll to find out how much I have, but A) I'm not sure if it works on attiny85s, and B) getting a number somewhere between 0 and 400ish via LED flashing is a pain.

It'd make mass(er) production a lot easier, but also gives the user an opportunity to completely confuse the poor MCU. I think I'll probably wait on that till I know the rest of it works and/or I have an issue where it works here but looses calibration on delivery. In theory it won't, but in reality who knows.
Or if I start making them by the bucketload, then spending an hour on a calibration routine could save some time. I'm hoping that each PCB based buttonboard will be close enough in tolerances (resistors: I'm looking at you!) that I don't need to mess with it.

 

[bing]

Dave, interesting different on both fans, both mine are the same as the new (right) one and you're right, this particular model can not stop at low duty cycle.

How is the noise profile between them too ?

This particular delta afc1212de (right one) is quite unique imo, I really like it's noise profile even at high speed, it sounds like only whoossing moving air without the annoying high pitch noise and the whining like FFB series.

Love the housing and finishing on the panel for the knobs, really clean & smooth edges , great sanding job you've done there.

 

[bing]

Now the first time you hit it, you get a 00.78% change in output (aka 2 points in a 0 to 255 scale). If you hold it for >450ms it starts giving you 00.78% every 10ms till you let go.

I think this method and algorithm is even better and easier to implement than the one I suggested !

Of course if I go >10% OC it runs the risk of not being able to write the EEPROM correctly, pretty much the exact same issues you have when cranking PCIe with sata drives.

Yeah, this is not easy since your mcu is not using an external accurate reference clock like xtal, not sure, how bout using few more variables, one for stating the oc state, and few others as the constants for the delay loop in eeprom writing routine. Say at stock speed, the delay will be the minimal, once oc-ed, the delay routing will be using longer/more loop and etc, hope you get what I mean.

Btw, about the eeprom's write cycles life, I think you don't need to worry them too much, I have a really old circuit with external eeprom, and used to worry like you, but they've been running for more than 10 years and constantly writing the eeprom when powered up that could happened once every day, yet they're still running fine until today.

 

[Bobnova]

Don't really have a reason to OC, I just like the concept
With an external OCing with software would be difficult, with the internal there is a calibration register I can write with an offset that modifies the clock speed. I have it running at 6.5mhz right now, down from the normal of 8mhz.

I found a blurb from a fellow Atmel MCU user a couple days ago, he tested a atmega168 eeprom to destruction, it finally started giving errors in the 300k write cycle area! Took a couple days of doing nothing but writing/reading one cell of eeprom.
Given a save every three seconds, 300k saves is going to take a while!