Worklog - It's a decentralized system (January 26 2010)
What i mean by "decentralized system" is that there will not be a single HUGE micro-controller that will check all the temperatures and the fans. That would be impossible with just one PIC. First of all, i need one PWM output dedicated to one fan. And if this PIC fails, the whole system will fail. Instead, i plan to use multiple small (and cheap) PICs that each one will do a certain job. Implementing a decentralized system, will give me the following profits:
Increased system reliability
Ease of system upgrading
Faster sampling rate for each module
Look at the following chart of this system. Please note that this chart may change AND more modules will be added in the near future:
Now you've got a better view of the "Decentralized system". The PIC 16F1937 reads the data from the other modules through the Local BUS or directly from the A/D inputs of the PIC. Each module will take care of itself and will answer to the Master ( PIC 16F1937 ) when it is asked. The fan module for example will receive once the speed to set the fan and will not occupy the LCB (Local BUS) any more, unless the master asks for example the speed of the fan or send a new speed setting. In case of emergency (fan failure for example), the fan module will request the master attention and will send the error number.
BANIS?? Where are the bunnies??
If you have seen the above photo, you may have notice a "BANIS" BUS. I am not going to extensively describe this bus, as this has nothing to do with this project (almost nothing). This BUS is a completely insulated BUS that runs Between All Negotiating Identifiable Subscribers (A.K.A. BANIS). An Identifiable Subscribers is a device with a unique ID. One device is the PC System Health Monitor for example. Each device will be able to negotiate with another device bi-directional.
Let me give you a quick example. There are 3 subscribers in the BANIS, a weather station (ID=1), the PC Health Monitor (ID=2) and a color monitor (ID=3). Each one is acting as a stand-alone device and may have no interference with the other subscribers. But through the BANIS, the monitor for example may request data from the other two subscribers, and then display them in a neat color monitor on the desktop... Neat? Moreover, all subscribers are powered through the BANIS network! Here is a graphical example of a BANIS network:
For my production capability and free research time, this is a rather HUGE network, but hey, "A journey of a thousand miles begins with a single step" (Lao Tse)
I should have mention it in the article. I may add it later on. I add the cap because i could not drive with PWM this fan and get rpm feedback at low rpms. I have face the stall problem myself using other fans. But this fan has not any particular problem by reducing the voltage. After all, i will never drive them below 800rpms. And this circuit can go even lower w/o stalling the fan.
Actually, the problem with PWM was that (maybe you have face it also) from lower to higher rpms, the duty cycle was changed only a couple of steps %. I tried from very low frequencies up to very high frequencies, still the regulation was terrible. That's the reason for this cap.
I have not even had time to build your initial circuit - I\'m too busy supporting our original speed controller and designing a new temperature controller right now but will get to this soon. And when I do I\'ll send you the results.
I see that you have added a 470uF cap across your FET, converting your PWM back to a noisy switching power supply. Can you explain why you added the cap?
We tried a cap across our switching tansistor but found that the motor tended to stall at lower RPMs. But we did come up with a design using a smaller cap & second resistor in the power transisitor drive circuit that stretches the transistor on ramp and reduces the on-pulse kick from a loud growl to very soft pulses. This change would not work with your circuit because you are running at a much higher frequency than we are.
I realized after my last post that my logic behind sampling only when the fan is on flawed. With your higher frequency design, your RPM pulse train is slower than your drive frequency. To make this design work for you, you would need to convert the incoming RPM pulse into a shutter or gate then count the number of PWM pulses riding in on the pulse. And since the PWM frequency is a constant, you can translate the PWM pulse count into RPM.
Yes, i changes the 4049 with an 741 that i have in stock. The reason for the 741, is that i have a lot of them to foll around. I will post the circuit or course.
As for the second post, i suppose that this would work as well. This will dramatically reduce of course the signal reading interval(i read about once a second) because then it would be very hard to keep the rpm low.
Will you try this? If you do, please post the results.
I was sitting here looking at my O'Scope and eating my Dominos Pizza when the real solution just came to me!
Instead of trying to condition the short pulses that occur when the fan is off, you should restrict your speed measurements to only when the fan is on. I'm assuming you can trigger a internal loop on the rising edge of the PWM on pulse? Then you can count incoming tach pulses across a fixed time window and calculate the fan's RPM from the pulse count. You may end up slowing your frequency back down in order to provide a wide enough window to measure your fan speed at all settings. You can even use a tach output pull-up resistor that's tied to your controller's 5V rail, possibly eliminating any need for signal conditioning.
You don't state in the text but I assume you replace the circuit you built around the 4049N with your LM741 based trigger circuit? At least the components on your board supports this.
It's been a long time since I designed anything around a LM741 OP Amp and the design is getting old. Maybe you can design the entire analog side around one LM324 OP Amp or if you want to stay with two 8 pin packages, something more efficient like a TLE2021?