Tag Archives: control

Heatsink or Swim

Apparently I have a thing for testing.  I rather love to run experiments, even when there’s no immediate need for the results.  I guess I just enjoy trying stuff, and hey, maybe even learning a thing or two. 🙂

So last weekend I was doing a bit of tinkering and got to wondering about the performance of different heatsinks.  Now just intuitively, I know that larger heat sinks tend to dissipate more heat than smaller ones – particularly if they have larger surface areas.  But just how much better is a tall, finned heatsink than a small, clip-on device?  This is what I wanted to find out.  So I gathered up five sinks of varying sizes and started to design my test.

The Heatsink LineupPictured above, from left to right, we have the following parts:

  1. A small clip-on heatsink, 230-75AB, cost: $0.36
  2. A medium-sized, bolt-on heatsink, 7-340-2PP-BA, cost: $3.91
  3. A larger bolt-on heatsink, 531202B00000G, cost: $1.28
  4. A Pentium 4, Socket 478 CPU cooler, cost: ~$35.00
  5. A Crydom SSR heatsink, HE-54, cost: ~$25.00

I decided to test each of these sinks with a TO-220 package transistor (since, at least in the case of the first three devices, this is what they were designed to cool).  Specifically, I’ve chosen the IRL2703, an N-channel MOSFET rated for 30V and 24A.  Now, the TO-220 package is also commonly used with regulators, diodes, etc.  So these heatsinks might be found in a number of different applications.

In order to control the power dissipated in the transistor, I’ve built a very simple current-control circuit using an op-amp (LM741) and a 0.1Ω sense resistor (Rs):

MOSFET Current Control Schematic

I will be using the transistor as, essentially, a variable resistor connected to a 12VDC power supply.  The transistor’s drain-to-source resistance varies based on the voltage applied between its gate and source.  Control of this voltage is the responsibility of the op-amp shown in the schematic above.

If you can recall the “golden rules” of ideal op-amps, you’ll remember that, with negative feedback (that is, a path between the op-amp’s output and its inverting (-) terminal), the voltage at the op-amp’s inverting (-) terminal will be equal to the voltage at its non-inverting (+) terminal.  In the circuit above then, if Vin = 1V, after being passed through the potentiometer’s 10:1 voltage division, the voltage at the op-amp’s non-inverting (+) terminal, and consequently its inverting terminal, will be 0.1V (remember also that no current flows into either of these “ideal” terminals).

So notice that the op-amp’s inverting terminal is connected to one leg of our sense resistor, Rs.  So when our input voltage is 1V, the voltage across Rs will be 0.1V (remember the voltage divider).  By Ohm’s law then, the current through the sense resistor will be I = V/R = 0.1/0.1 = 1Amp.  So an input of 1V will yield 1A through the transistor.  With an input voltage of 12V then, we’ll be dissipating approximately 12W in the transistor (actually 11.9W, to be precise; we’ll lose 0.1W in the sense resistor).

For my experiments, I’ll be using a constant current of 0.5A, which will yield a power of 6W.  This seems to be a reasonable value to use with all of my heat sinks.  And it’s still not quite enough to completely toast a naked (no heatsink) transistor.

In order to measure the temperature of the transistor as the test proceeds, I’ll be using a Kintrex infrared thermometer, model IRT0421, which I’ve had for years.  My plan is to simply move the thermometer around the transistor, at close range (1-2″), and record its maximum reading.  Admittedly, this isn’t the most precise solution.  A better idea would probably be to attach a small thermocouple between the transistor and the sink.  But that’s something I don’t have.  My method should at least provide a good indicator of relative, if not absolute, performance.

My procedure here is quite simple.  First, I will attach a heatsink to the transistor using a small thermal pad.  I will then apply a current of 0.5A at 12VDC, and allow the transistor to reach a stead-state temperature.  I will then allow everything to cool, remove the thermal pad, and try the same test again.  Perhaps my video-self can explain this better:

Before diving into the results, here are a few more pictures of the circuit and setup.  By the way, in case you’re wondering what that silver pen-like device is that’s jammed into my protoboard next to the opamp, it’s my home-made scope probe.  I took an old BIC pen, removed the guts, and then epoxied in a dulled sewing needle and wire.  It’s actually a great little probe; I leave it connected to my IOBoard most of the time.

Current Control Circuit

This is how the transistor was attached to the Crydom heatsink:
Crydom SSR HeatsinkAnd for the Pentium 4 cooling package, a single 4-40 hole was tapped (note that this image has been flipped horizontally, for aesthetic reasons, so ignore the wire colors):

Pentium 4 CPU Cooler

Results

Alright, so I’m sure you can’t wait to learn how things turned out, right?  Well, without further ado, I present to you my grand table of results:

Heatsink Under Test
Temp @ 10 Mins.
Temp @ 40 Mins.
Rating
(Expected Temp)
NONE
152°C N/A 58.7°C/W
(373°C)
Clip-On Heatsink 136°C N/A 28.5°C/W
(192°C)
Bolt-On Medium Heatsink 93°C N/A 3.1°C/W
(40°C)
Bolt-On Large Heatsink 78°C N/A 7.5°C/W
(66°C)
Pentium 4 Heatsink 32°C
(no fan)25°C
(fan on)
38°C
(no fan)25°C
(fan on)
N/A
Crydom SSR Heatsink 28°C 31°C 0.9°C/W
(26°C)

(Note that these test were performed at an ambient temperature of 21°C.  The “Expected Temp” numbers are calculated by multiplying the manufacturer’s ratings by 6W, and then adding the ambient temperature.  Also, the smaller heatsinks were only tested for 10 minutes, as it only took this long for them to reach steady state.  The more massive heatsinks were given 40 minutes.)

So now you may be wondering, “Wait, what happened to the tests with and without the thermal pads in place?”  Well I’ll tell you: the difference in final temperature with and without the pads was insignificant (perhaps one or two degrees at most).  This was a little surprising to me, as I’ve always been told to be liberal with the thermal grease/paste (and these thermal pads serve the same purpose, they’re just cleaner).  So I figured the exposed side of the transistor would be somewhat warmer without the pads in place.  And yet, that does not appear to be the case.  But am I confident enough in this result to stop using thermal paste/pads?  Eh, not really.  I’d probably still use the pads, and I’d make sure the heatsink was firmly attached (since that makes for better conduction).

Another interesting point to note: the snap-on heatsink I tested here performed little better than operation without a sink (it yielded just a 13% lower temperature rise).

Strangely though, the snap-on heatsink was the only one that seemed to measure up to its manufacturer’s °C/W rating.  I calculate a value of (136-21)/6 = 19.2°C/W, which is less than the advertised 28.5°C/W (a good thing).  But neither of the bolt-on heat sinks met their advertised ratings.  The medium-sized sink reached just 12°C/W while the larger one hit 9.5°C/W.  I’m not sure what to make of this.  Is there something I’m missing here?  Perhaps an error in my calculation?  It sure seems straight-forward…

Well finally, I was rather pleased with the performance of the Pentium 4 cooler as well as with the Crydom heatsink.  I did expect both to do well though.  The Socket-478 Pentiums could produce about 60W, so you’d expect even a stock heat sink to be able to handle one-tenth of that power with little problem.  I was amazed at just how quickly turning on the fan brought down the temperature though.  Within just a few minutes the heatsink felt cool to the touch (having just been at about 38°C/100°F).

Conclusion

In light of this data, which of these heatsinks would I choose?  Well, for this transistor, the datasheet lists a maximum operating junction temperature of 175°C.  In the above tests, I’ve measured case temperatures, so we’ll need to factor that in.  Again, the datasheet lists a thermal resistance from junction to case of 3.3°C/W.  So when dissipating 6W, as in the tests above, the junction temperature will be about 20°C warmer than the temperature of the case.  So our maximum allowed case temperature will be 155°C.  You’ll notice that with no heat sink, the transistor reached a temperature of 152°C, so in theory, you could safely operate at 6W with no heatsink at all.  But should you?  No.  For one thing, stuff starts to smell nasty at that temperature.  Plus, continuously running hot will almost certainly reduce the operating life of your transistor.

In general, I’d suggest keeping transistors well below 100°C.  So in this case, I’d be comfortable with either of the two bolt-on heatsinks.  Anything more is overkill.

By the way, here’s a neat article on defacing currency some home-made heat sinks.

So, comments, questions, suggestions?  Feel free to leave them below.  Thanks!

Update (11/24/2011):

Christoph kindly pointed out in the comments section (below) that I’d forgotten to incorporate the dissipation of the TO-220 package itself when predicting case temperature values based on the heatsink specs.  Although not quite half of the transistor’s surface area is attached to the heatsink, the front is still sitting in open air.  Now, the datasheet specifies a thermal resistance of 62°C/W from junction to ambient.  I’m measuring case temperatures, so we need the thermal resistance between case and ambient.  To get this, I need to subtract out the junction to case resistance of 3.3°C/W, for a case to ambient package resistance of 58.7°C/W.

Now, instead of trying to figure out the thermal resistance for just the front of the heatsink (which would just be a guess, really), let’s see what the effect of adding in the transistor datasheet’s full thermal resistance has on our predicted temperatures.

As with electrical resistances, we can determine the combined thermal resistance of the heatsink and transistor by adding them in parallel, as follows:

R_tot = 1/(1/R_transistor + 1/R_heatsink)

Let’s apply this for the clip-on heatsink:

R_tot = 1/(1/58.7 + 1/28.5) = 19.2°C/W.

That’s a pretty big difference!  For 6W, this predicts a temperature of 136.2°C – much less than the 192°C I calculated above, and much closer to my measured value (136°C).  Here is a summary of the new predicted resistances and temperatures (I have NOT yet updated the table above with these new values):

Clip-on Sink: 19.2°C/W, 136°C
Medium Bolt-on Sink: 2.9°C/W, 38°C
Large Bolt-on Sink: 6.7°C/W, 61°C
P4 CPU Cooler: N/A
Crydom Sink: No Effective Difference (the supposed resistance of this heatsink is already so low, adding in the dissipation of the transistor itself makes no noticeable difference)

So making this correction helps with the clip-on sink, but it’s made things worse (at least by comparison with the tested value) for the two bolt-on sinks…

The other adjustment we could make would be to add the case-to-sink resistance of the transistor.  The datasheet lists this value as 0.5°C/W for a flat, greased surface.  Which in this case adds 3°C for 6W.  This could account quite well for the difference in measured values for the Crydom heatsink, but it doesn’t make a huge difference for the others.

Again, these are all pretty much approximations, and as I’ve already admitted, my testing procedure is not terribly accurate.  However, I do believe that it’s still a fairly good relative comparison of these sinks.  If I were measuring the temperatures of the sinks directly, yes, there would be differences in their emissivity, which would affect my IR thermometer.  However, I held the thermometer very close to the transistor and measured the temperature of the same point on the case of the same transistor in all tests.  So I’m not too worried about this.  Again, thanks to all for the comments!

Review: An Inexpensive Wireless Relay

As you know, I’m all for DIY projects.  But sometimes, I’ve got to say, it’s just easier/better/cheaper to buy things.  For instance, let’s say you need the ability to remotely activate/power/E-stop a project you’re working on.  There are literally hundreds of ways you might accomplish this.  The wireless product offerings from SparkFun are quite extensive, and a very simple transmitter/receiver pair can be had for less than a five spot.  But don’t forget, you’ve still got to generate the appropriate signals to the transmitter, and then process those signals at the receiver.  Plus, you’ll want to add a couple of buttons, a relay/MOSFET, perhaps an LED, and of course a case.  By the time all’s said and done, you’ve spent three or four times your initial budget, not to mention all the hours consumed.  Now granted, if you’ve never done something like this before, it’s a great learning experience.  Seriously, if that’s the case, by all means, go for it.  But if your not interested in the experience, why not give this a shot:

Logisys RM01/RM02 Wireless Relay

This is the Logisys RM01/RM02 wireless relay.  It operates from a 12V source, such as a car battery.  The RM01’s relay can handle up to 6 amps and costs just $15.99 at Amazon.  The Logisys RM02 can take 15 amps and sells for $18.99 at Amazon.  I’ve recently purchased the RM01 for a project that has since been cancelled.  However, I’ve still gone ahead and done a little testing.  Here are the key points:

  • In the off state, the RM01 will draw 7.4mA from a source ranging from 8V to 15V (which leads me to believe it’s using a simple linear regulator).
  • When turned on, the RM01 itself will draw between 36 and 64mA as its supply voltage ranges from 8 to 15V respectively (so its coil resistance is about 280Ω).
  • The relay will not fully close until the input voltage exceeds 8.2V.
  • Indoor range (worst-case) with a 12V supply is about 30′ to turn on, 20′ to turn off (I haven’t explored this odd difference, so I’m not sure why it happens).  Outdoor line-of-sight range is about three times that.

I’m pretty pleased with this little guy.  It’s fantastically simple to use, and the two fobs even have red LEDs which light when their buttons are pressed, to let you know that their batteries are still good.

Honestly, I’ve been looking for an excuse to purchase one of these for quite some time.  Ever since a college friend of mine used them to control the power to his self-balancing transporter, they’ve been on my wish list (along with a few other things):

So despite the fact that the project I was going to use them with is no longer proceeding, I’m still happy to have them.  If you have any questions or would like me to do any other testing with the RM01, feel free to leave a comment.

The Mechatronics TVIP (+Video)

MechatronicsToday’s post is going to be a trip down memory lane for me.  The TVIP or Thrust-Vectoring Inverted Pendulum was my very first real engineering project in college.  My good friend Alex and I constructed it almost five years ago, during the second semester of our freshman year at RPI.  We actually started designing the system during our very first semester.  However, the bulk of our work was performed for an independent study in the [former] RPI Mechatronics lab during the spring of 2006.  By the way, in case you’re wondering, the RPI Mechatronics lab closed down when Dr. Kevin Craig decided to leave RPI for Marquette University.  Of course, he took most of the lab with him, and now runs the Multidisciplinary Mechatronics Innovations lab at Marquette!

Why do I bring this up now?  Five years later?  Well as I’ve mentioned before, I’ve been doing a lot of job interviewing lately.  During interviews, the TVIP seems to come up pretty frequently.  It’s still a great example of the work I did while employed in the Mechatronics lab.  And I’m still pretty proud of this rickety old thing.  I consider it to be quite an accomplishment, particularly for a pair of college freshmen.  🙂

So what exactly is the Thrust-Vectoring Inverted Pendulum?  Well, like many Mechatronics lab projects, it’s a demonstration of control systems, mechanical dynamics, electronics, and modeling.  To be more specific (and simple), it’s a big aluminum pendulum with a scary-looking propellor attached at the end.  A diagram should help explain:

Thrust-Vectoring Inverted Pendulum (CAD Model)

What you see there is a dual A-frame, about three feet tall, supporting a horizontal shaft to which a pendulum is connected.  That shaft is suspended by a pair of bearings.  An optical encoder is used to detect the angular position (angle θ) of the shaft and pendulum.  At the end of the pendulum, the propellor and motor are attached to a geared DC servo motor, which is used to vary the direction (angle φ) of the propellor’s thrust.  Hence the term thrust-vectoring (plus, five years ago, it sounded really cool).

Now the purpose of this setup was to demonstrate the control of an unstable system.  Thus, our goal was to vary the direction and magnitude of the propellor’s thrust in order to swing up the pendulum and then balance it in its inverted, unstable position.

This was accomplished by using two separate control loops, both implemented within LabVIEW.  The first controller was responsible for swing-up (since the propellor could not produce enough thrust to pull the pendulum straight up).  As you’ll see in the video below, the swing-up algorithm was essentially a proportional controller with an excessively high gain.  This actually caused the system to go into unstable oscillations.  That sounds pretty bad, doesn’t it?  But it’s exactly what we wanted.  Just like a child on a playground swing, our proportional controller caused the pendulum to swing higher and higher.  However, instead of continuing to let the system oscillate unchecked, once the pendulum started to close in on its balance point, LabVIEW switched the output over to a PID control loop.  The job of this second controller was to catch the pendulum and then hold it, as closely as possible, in its verticle, inverted position.  How about a video before I go on?

Now that video was taken at the conclusion of the Spring 2006 semester.  You’ll notice that the pendulum still oscillates slightly (plus or minus about eight degrees) when inverted.  This was due to an improperly tuned PID controller.  We did improve that performance somewhat over the next year or so.  During my later employment in the Mechatronics lab, I wrote up a paper that, unfortunately, never made it to publication.  It contains a bit of the more serious math on modeling and control I didn’t really understand when Alex and I first designed this system.  You’ll find a link to this paper at the end of my post.

The Details

So just what makes this thing tick?  Well, the motor and propellor are pretty standard fare for RC electric planes.  Of course that doesn’t make them any less scary.  Running this thing indoors produced a lot of noise, and you had to keep clear of the pendulum while it was operating (lest you lose a finger).  The propellor and motor were connected to a standard geared DC motor which was actually capable of rotating 360 degrees.  This presented another safety hazard; if the positioning motor rotated too far, the prop would begin biting into the aluminum pendulum.  Amazingly, in two years of operation, this never happened.  But it could have.  Control of this positioning motor was accomplished by a third PD control loop within LabVIEW.  Angular feedback was given by an optical encoder.

Now we really should have bought a commercial, heavy-duty hobby servo in order to vector the thrust of our prop.  This would have likely been safer and easier.  But what did we know back then?  Ultimately we solved the safety issue by replacing the propellor with a ducted fan.  It didn’t quite produce as much thrust, but you didn’t have to worry about how to grab the pendulum in the event of a control/electronics failure.

The New Thrust-Vectoring Inverted Pendulum

And speaking of electronics failures, we did have a couple of frightening moments during our initial testing.  The speed of the propellor motor was governed by a power MOSFET.  Twice, that FET failed during operation; in both cases it failed by shorting.  The result?

Instantaneous full-power thrust.

Pretty scary stuff, particularly since we first powered the prop motor using a 12V lead-acid battery.  However, we also eventually replaced that battery (which you see in the video above) with a dedicated high-current power supply (the box with the RPI sticker).

Now as I started to mention earlier, both the propellor and positioning motors were driven by microcontroller-produced PWM signals wired into power transistors.  We used a microcontroller (MCU) for PWM generation because the NI data acquisition (DAQ) hardware we had available at the time could not generate these signals.  Instead, it produced analog outputs which were fed into the ADCs of our MCU.  The MCU (an AVR ATTiny13) then produced PWM signals whose duty cycles were proportional to those analog inputs.  Fortunately, the DAQ hardware we had could easily process our two quadrature encoder inputs into angular measurements.

Well I’ll leave the rest of the details to the paper linked below.  If you’re interested in how to model this system mathematically, as well as how to implement the various controllers described here, have a read!  I think you’ll find my test in characterizing the viscous damping of the ducted fan rather interesting.  If only I’d had Eureqa back then…  Oh, and I’ve also included MCU source code for the ADC-PWM conversion:

Paper: A Mechatronics Case Study: Thrust Vectoring and Control of an Unstable System
Schematic: GIF Image (Also available in the paper)

Feel free to make comments or ask questions in the comment section.  Thanks!