Home     Contact     Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science     RSS     Terms of services     Privacy policy  
   
 Home      Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science   

26 January 2010
Author: Giorgos Lazaridis
PC System Health Monitor




Worklog - A huge failure (February 4 2010)

The problems began when i decided to close the PC box and check if the system can operate as good as when the box was open. I was indeed expecting a temperature rise, but i had yet more to discover.

High temperatures

Let's take a look at the temperatures once more, BEFORE i close the box





Everything looks just perfect. And now, AFTER closing the box, within an hour of operation:







I think you've got the point. The temperatures gone MAD. What this means, is that i need to (once more) re-design the air inlet and outlet of the box, as well as the whole air circulation. This is something that it just happens when trying to design something original.


How the resistance of the NTC changes, as the temperature rises

Something else that is not a really good sign, is that when the temperature rises, the PIC A/D converter sometimes halts and the program flow stops. I have not enabled the watchdog for such cases, so i noticed exactly where this error occurs. I put 3 LEDs which turn on and off between specific subroutines. From bigger to smaller subroutines, i found exactly in which line (ALWAYS) the program halts. There was nothing much to debug there, the code was perfectly clear w/o cockroaches.

My first guess was one PIC A/D limitation. The A/D converter must operate with max analog impedance of 10 KOhms. That turned out to be wrong. My NTC may be 10 KOhms in room temperature, but the 40 degrees are NOT room temperature. Actually, the resistance of the NTC (remember that a NTC will reduce the resistance as temperature rises) at 40�C is about 5 KOhms. On your left hand side you will find a screenshot of an open office spreadsheet that i made to theoretically calculate the resistance of the NTC in various temperatures. This is just FYI.

I opened the box, and discovered that the breadboard along with the PIC was all the time cooked. Also, i had placed the PIC on top of the power supply. This means (i suspect) that when the temperature in the box was 42�C, the temperature of the PIC was much higher. I took out the breadboard from the box and re-tested the circuit. Right now, it works about 4 hours without any sign of failure. I will let it work a couple of days just to make sure. In the meanwhile, i will re-design and re-arrange the entrails of the box. I am very sure that i can achieve at least 10% better performance with the same fans. The temperature right now is just unacceptable.


When the breadboard and the PIC was inside the box, it was cooked and the program crashed many times. With temperatures higher then 42�C, the PIC could operate for less than 10 seconds. So i took out the controller from the box in a more friendly environment... The sensors are still inside the box, the PIC works now perfect, the program does not halt anymore.

















Comments

  Name

  Email (shall not be published)

  Website

Notify me of new posts via email


Write your comments below:
BEFORE you post a comment:You are welcome to comment for corrections and suggestions on this page. But if you have questions please use the forum instead to post it. Thank you.


      

  • At 14 February 2010, 17:23:23 user Kammenos wrote:   [reply @ Kammenos]
    • 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.


  • At 14 February 2010, 16:41:19 user Tom Hargrave wrote:   [reply @ Tom Hargrave]
    • 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.


  • At 14 February 2010, 12:35:41 user Kammenos wrote:   [reply @ Kammenos]
    • Tom, i posted the new circuit. Will you test it with your fans? I look forward to hear the results.


  • At 13 February 2010, 14:37:54 user Tom Hargrave wrote:   [reply @ Tom Hargrave]
    • 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.


  • At 13 February 2010, 7:40:56 user Kammenos wrote:   [reply @ Kammenos]
    • 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.


  • At 13 February 2010, 2:57:29 user Tom Hargrave wrote:   [reply @ Tom Hargrave]
    • 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.


  • At 13 February 2010, 1:33:32 user Tom Hargrave wrote:   [reply @ Tom Hargrave]
    • 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?



    delicious
    digg
    reddit this Reddit this
    Faves



     HOT in heaven!


    NEW in heaven!



    New Theory: AC electric motor working principle



     Contact     Forum     Projects     Experiments     Circuits     Theory     BLOG     PIC Tutorials     Time for Science     RSS   

    Site design: Giorgos Lazaridis
    © Copyright 2008
    Please read the Terms of services and the Privacy policy