Worklog - Inter-Com (January 26 2010)
The communication protocol
It was time to decide the communication protocol for the modules (forget about the BANIS and the subscribers for now). At first, i wanted to make my own protocol. Actually, i already had designed a protocol, some years ago (when i was in the army actually), that i used to call SEBI (SErial Bus Interface). Although it worked perfectly and it had many error corrections, it had two major drawbacks: It was rather slow due to the error correction routines, and it was mine.... Being mine means that is impossible to find it implemented on another chip. So, if i interface a chip that uses SPi or I2C, then i will have to add two communication protocols. Therefore, i decided to use a commercial protocol, and of course i chose my favorite, the I2C protocol.
Here are the IDs of the 8 BUS modules:
Module name
ID
Fan 1
b'00000001'
Fan 2
b'00000010'
Fan 3
b'00000011'
Fan 4
b'00000100'
Fan 5
b'00000101'
Fan 6
b'00000110'
Inlet temp
b'10010000'
Outlet temp
b'10010001'
Currently i am testing a I2C routine between 2 DS1621 and 2 Fan modules. I am measuring the transmission or request errors. Until now, no error has ocure. The I2C protocol itself has not an error correction,but it is supposed to work in integrated systems, with one chip near the other, and without many interferences that may cause data loss or change during the transmission. Nevertheless, there are other techniques to implement error correction that i do not plan to use if there is no need. I am sure that there will be no problem, but if something goes wrong, i have already something in mind...
Here is the system for under test. This photo is 2 days after the first power on of the system. Many changes have i done from then, but now it operates satisfactory. The temperatures sampling rate is about 4 seconds, and the rpm sampling rate is 8 seconds, but i plan to bring it down to 4 seconds as well. I am not sure what will happen if i have all 6 fan modules under heavy negotiations, but i suppose everything will go smooth:
The NTC sensor interface
Not to forget the NTC temperature sensors. For simplicity and to maintain each A/D input as is, i have connect the sensors along with the resistor into one piece, and 3 wires comes out. One is the positive, one the negative and the other is the signal. This way, i will have the 14 A/D inputs of the PIC directly on the PCB without any other component, free to use as i may in the future. A drawback to this method is that i use 3 instead of 2 wires but come on, all the sensors will go no further than half a meter, most of them will be very close to the PCB.
The resistor is directly soldered to the thermistor
Two heat-shrinks covers the resistor and the wires
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?
Home
Projects
Experiments
Circuits
Theory
BLOG
PIC Tutorials
Time for Science
Contact
Forum
RSS
Reddit this
HOT in heaven!
NEW in heaven!
