I'll see if I have any of those Tartan boxes in my toolbox.
Naahhh... not overheating. This thing is all MOSFET; virtually no heat generated at idle. It has 2 40mm fans in LO-HI compressor mode (one high volume fan direct into a high velocity fan for higher total static pressure) to get lots of cooling in a small package. Their minimum RPM is based on the idle requirements of a multi-XEON or similar server; still a considerable amount of current draw. Any quieter fan would also be slower, and would do the same thing due to lower Tach output.
I've tried several recommended mods; even scabbed in a 7808 to power them (they're PWM controlled); but like I said... anything that successfully dropped RPM to a tolerable volume also made the PSU immediately either shut down after a few seconds or go into limp/POST-loop mode.
I'm currently working on a rear housing with a muffler built in; that's what this thing is. Just my 3DP is being all kinds of a dick to me right now. Guess it didn't like being moved.
mnem
*knocks self unconscious with a compressor mallet*
I am guessing the PSU is monitoring the fan RPM and expects it to be above some minimum. So when you drop the RPM, it goes below some threshold and the PSU goes into an error state. The counter/divider idea was to trick the PSU into thinking the RPM is in the proper range, even though the actual RPM is less.
Could you use a Signal Generator to test that theory? Disconnect the fan RPM line and feed a generated signal into the RPM monitor, and then you can take over control of the fan.
Mostly, it is about the enclosure being two sheets of metal lower than 1.75". In those 42mm you simply can't put a horizontal-flow fan that pushes enough air to cool the PSU without revving it.
Additional constraints come into play in the intended application, where you need to pull air in one end, and push it out the other, and you will have another unit on top, another below, and another to one side. The supplies will typically be placed in pairs for A/B supply, into 1HE computers stacked 40 to a bay frame, so there is really no alternative to create a pretty narrow high-speed jet of cooling air.
I've experienced this exact supply in a parallel super computer consisting of 442 compute nodes in 12 rack cabinets. The heat load when the moron HVAC engineer shut the cooling off to do something that did not require shutting the cooling off was impressive. Temperature rise rate more than 1° science-degree per minute, starting at 24°...
I was going to write a whole long diatribe about the role of failure in design... but
this is the nuts/bolts of it. I spent some time futzing around with a PWM dev board trying to trick the thing; it appears the POST includes a test loop where it ramps up the RPM and monitors it to make sure it "sees" the fan. There is an I²C bus connection at the pin header, which indicates to me that the server can modify fan speed to some extent in software as well; not sure if that includes revving down as well as up. A fixed signal will not work. A divider might... but it monitors two fans at the same time which operate at different RPM. It was at that point I stopped to re-evaluate my engineering scope and realized that the RPM isn't the problem; the noise at idle is. If it ramps up under load, it NEEDS to... just like my DPS-1200s.
I'd stick a 8 pin PIC in the circuit. measure the generated fand voltage / PWM and generate correct RPM to keep the control circuit happy. You could also use it to actually switch the fans to high speed when you need too. one of the 8 or 14 pin PICs with internal clock is more than adequate, no support components required.
That's great if I really wanted to spend a week polishing my programming skillz to develop a hindbrain for the thing.
Hello, my name is mnem, and my Kung-Fu is weak. Have we met...?This is why I decided to attempt a mechanical noise-abatement solution that allows the PSU to operate as intended rather than trying to trick the thing into thinking it's still shoved up a Dell server's arse. mnem