Tag Archives: electronics

Home Sweet Garage

Alright, I think it’s about time for this silly article on plasma arc waste disposal to get knocked off the top of my site, don’t you?  It’s just fluff, honestly.  Filler.  And I’m tired of looking at it.  So how about a post on a real project for a change?  Sound good?  Great.

First though, a quick gripe.  I hate waiting for parts to arrive.  Specifically “last” parts.  Like that final DigiKey order, or in my case, a shipment of PCBs from Advanced Circuits.  You see, I now have everything I need to complete this really exciting new device I’m designing at work, except for the PCBs.

Assorted parts, but no PCBs...

And not having boards is kindof a show-stopper.  So I’m crossing my fingers and hoping that Advanced Circuits gets them shipped out early, as they so often do (because they’re totally awesome).

But let’s get down to business.  If you happen to have been reading my blog about six months ago, you may remember that I recently moved to the middle of nowhere Waterloo, Iowa to start working for John Deere.  Now prior to moving here, finding a place to live has been, for me, frustrating.  “Oh, here’s a place that’s nice, but it’s too far away,” or, “That’s way too expensive,” or, “Uh, what’s that growing on the ceiling?”

Not so this time.  Deere actually provided a relocation assistant to show me several nice places around town.  All I had to do was tell her what I was looking for and BAM, there we were.  Plus, the cost of living in Iowa is virtually zero.  So here I am, renting a lovely townhouse, about ten minutes’ drive from work.

Now, nothing’s ever perfect, and this place is no exception.  For instance, it’s got a nice single-car garage with an opener, but there are two problems.  First, the remote control has terrible range.  My landlord warned me about this, but explained that I just needed to find that “sweet spot” for it in my car.  But this thing is kindof a brick and looks rather like some RadioShack project box.

This really is a garage door opener.

The second problem is lighting.  The garage door opener does have a single light bulb which comes on when the unit operates, but it’s pretty anemic.  This isn’t helped by the fact that the inside of the garage is almost all dark wood, either.  Plus it seems to take a few seconds for this light come on, and it only stays on for a few seconds afterwards.

So in Iowa, winters are long, dark, and cold.  Not unlike a mine shaft, I imagine.  But I like light.  So I took a trip to Home Depot one weekend, and for about $50 (those motion-detecting switches are kindof steep) solved problem number two quite simply.

Let there be light!

Yep, that’s a Lutron motion-sensing light switch, wired into an extension cord, and a simple reflective lamp fixture.  And it’s all just clamped to the top of a set of shelves I already own.  Easy peasy.  And it works like a charm.  The switch has two little pots to control sensitivity and on-time.  Which is great, because I love adjusting things.  So now I can pull into the garage, catch those last few minutes of Wait Wait, Don’t Tell Me, and then hop out and voilà, let there be light.  And I saw that it was good (enough).

Now for a while, I lived with problem number one without much complaint.  I had to be in my driveway before the remote would trigger the opener, but it wasn’t a huge deal.  Then for some reason, it routinely started failing me.  My car actually had to be within a few feet of the door for it to open.  And more than once I had to get out of my car (heaven forbid) and wave the remote around in front of it.  I replaced the battery, but this made no apparent difference.

So again, one weekend I decided I’d had enough and sat down at my workbench to sort out the problem.  I popped the project box remote open and started probing.

A very simple garage door opener

To make a long story short, I discovered that the transmitter was simply broadcasting a repeating pulse train via (I believe) amplitude modulation.  Somewhere in the 800kHz range, although I don’t have equipment capable of measuring such high frequencies with any sort of precision.  I can tell you that the DIP switches you see control the sequence of the transmitted pulses to match a particular receiver.

Get on board the pulse train!  Woo woo!

Since I know virtually nothing about RF amplification, and didn’t want to risk damaging the remote, I decided to piece together my own remote from components I had lying around.  Here’s what I used:

Transmitter:

  • SparkFun 315Mhz ASK transmitter module ($4)
  • AVR ATTiny13 8-bit, DIP8 microcontroller ($2)
  • 5V Regulator
  • 9V Battery
  • Protoboard
  • Button

Receiver:

  • SparkFun 315Mhz ASK receiver module ($5, discontinued)
  • Olimex AVR-MT-128 development board ($75)
  • 12V wall-wart power supply

Now the precise components specified here aren’t really too important.  I used what I had.  I would recommend the RF transmitter and receiver though (except that the receiver has been discontinued).  These are both pretty amazing for the price; I got them a number of years ago and haven’t yet put them to much use.  But they’re fantastically simple.  Just apply TTL-level serial data to the input of the transmitter, and watch it appear at the output of the receiver.  That’s it.  No configuration/setup required.  The only complication is that there is no error checking.  So you’ll need to be clever about dealing with the occasional garbage data.

So how does this all work together then?  Well, when you press the button on the prototype remote, the 9V battery is then connected to the transmitter module and the MCU (via the 5V regulator).  The MCU then sends out a slew of bit-banged (since the ATTiny13 has no hardware UART) serial data to the transmitter, which then sends it wirelessly to the receiver.

Now this is a garage door opener!  Well, sortof...

The receiver then sends this data to the ATMega128 (on the AVR-MT-128 dev board), which does have a hardware UART.  If the received data is correct, a relay on the dev board is quickly closed and then opened again.  The relay terminals are wired up in parallel with the door open/close button inside the garage.  Thus, the action of the relay simulates a real button press and causes the garage door to open/close.

The receiver

That’s it.  Again, pretty simple, right?  The receiver, since it’s got an LCD display, also indicates how many times the door has been actuated (either opened or closed).  This was a comforting feature during initial testing, because it allowed me to determine whether or not my garage had been opened at any unexpected time.

Sophisticated, yes?Well I’ve been driving around with this silly protoboard taped to my center console for about two months now.  It’s been working great; I can now operate my garage door reliably from the street (a distance of probably 50′), and this little gadget has made for such a nifty conversation piece that I might just leave it in protoboard form.  I mean, a small enclosure would be nice and stuff, but…

Seriously though, if you have any cheap and cheerful ideas for housing the transmitter in a more elegant and robust manner, do let me know in the comments.  By the way, at this point in a post I’d usually provide links to my code, but I’m not going to do that this time.  I’d rather not make it too easy for the tech-savvy thief to break into my garage, you know?  Yea, I’m probably just being paranoid, but still.  Lots of crime in Iowa you know. 🙂

Now ultimately I’d like to extend the functionality of my device so that it automatically opens and closes the door when I come and go.  If you’re curious about how that might be done, take a look at one of my older posts on the subject.  Thanks for reading though, and feel free to pose any questions below!

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!

Pure Analog Servo Control

A Standard Hobby ServoHobby servos, such as the one pictured at right, are wonderfully useful little devices.  You’ll find them moving control surfaces on model planes, in steering linkages on RC cars, and even in the feeding mechanism of an automatic ping-pong ball launcher (one of my simpler college design projects).

Anytime you need something to rotate to a specific position, think of the hobby servo.  They’re fairly low cost, and come in a variety of torque sizes, from tens to hundreds of ounce-inches.

So let’s say you’ve bought yourself a servo from Tower Hobbies (or wherever).  How are you going to control it?  Well, you could purchase a radio and receiver, but if you’re not planning on building your servo into a vehicle of some sort, that’s really overkill (and expensive).  You could program a microcontroller to generate the control signals, but that could get complicated if you’ve never worked with MCUs before.  Instead, what I’d like to discuss today is a purely analog circuit for PWM servo control.

First, let me give you a little background information.  Hobby servos are typically connected by three wires: power (red), ground (black), and signal (yellow/white).   The power and ground lines are typically hooked directly to your battery or power supply.  The signal line, however, is used to command the servo to move to a specific angular position.  This signaling is normally accomplished via pulse-width modulation (PWM).  That is, a digital pulse is sent to the servo on a routine basis (e.g. at 100Hz, or 100 times per second).  The width or duration of this pulse determines the position of the servo’s horn. For instance, a pulse width of 1ms commands a fully clockwise rotation, a width of 2ms commands a fully counter-clockwise rotation, and a width of 1.5ms will center the horn.

Now the question is, how do we generate such a signal?  Why, we simply use the following pulse-width modulator circuit (adapted from Maxim Application Note 3201):

PWM Generator SchematicAlright, so maybe you’re thinking, “Dude, that’s a big circuit.”  Well yea, it sortof is.

But then again, those three op-amps could actually all be housed inside a single 14-pin DIP/SOIC package.  And beyond that, all you need are eight resistors, one capacitor, and one potentiometer (a variable resistor).  So while this may be physically more complex than just plopping down a microcontroller, there’s no software required.

So just how does this circuit create our PWM signal?  Well let’s start with the “Integrator” section.  This group of components (R1, C1, and U1) mathematically integrate or sum the voltage wired into the left terminal of R1 (line label #5).  Put simply, the capacitor C1 is summing up this input voltage over time.  To see how this happens, let’s start by analyzing the node between R1 and C1 (label #2).  Now assuming all of our op-amps are ideal (a fair assumption in most cases), no current will enter or leave their inverting (-) and non-inverting (+) terminals.  Since the current flowing through a series connection of electrical components (R1 and C1) must be equal, we can write the following:

Integrator Equation Derivation

The first half of this formula may look familiar; it’s ohm’s law (V/R = I).  However, we’ve defined the voltage across R1 as (V5 – 2.5).  Why?  This is because the voltage at the input terminals (+ and -) of our ideal op-amp must be equal since we have a negative feedback path (a connection from output to inverting (-) terminal) through the capacitor.  And we know that the voltage at the non-inverting (+) terminal of the op-amp must be 2.5V because of the voltage divider at node #1.  Thus, since C1 is providing a feedback path for the op-amp, we can safely assume that the inverting terminal is also at 2.5V.  The second half of this equation comes from the I-V relationship for capacitors, I = C*dv/dt.

So if we solve this equation for V3, with an initial capacitor voltage of zero, we get:

Integrator Equation DerivationIf we keep the voltage V5 constant, we’re left with just an equation for a straight line.  Basically, the output V3 starts at 2.5V, then ramps linearly up/down, depending on V5, as time (t) goes on.  If left unchecked, the output of U1 would eventually hit a supply limit (either 0V or 5V). However, the second half of the above circuit, labeled “Oscillator Comparator” ensures that this does not happen by switching V5 between 0V and 5V.

Let’s take a look at U2, the second op-amp pictured above.  You’ll notice there’s no feedback path between its output and its inverting (-) terminal.  So what we’ve got is a comparator.  That is, if the voltage on its non-inverting (+) terminal is greater than that on its inverting (-) terminal, the output of U2 will be roughly 5V (our positive supply voltage). Otherwise, the output will be roughly 0V.  I say “roughly” because this op-amp (TL072) can’t operate “rail-to-rail”, which means its output can’t quite reach our supply voltages.

In order to understand this comparator a little better, let’s take a look at the point at which it switches between its high (5V) and low (0V) output.  Since the inverting terminal of U2 is fixed at 2.5V by the voltage divider at node #1, this switching must take place when node #4 passes 2.5V.  Let’s determine the voltage V3 necessary for this to occur.  To begin, I’ll equate the currents through R2 and R3 (since again, no current flows into the + terminal):

Switching Point DerivationNow don’t be confused about where that 2.5V is coming from.  This is the switching voltage for U2.  We’re not saying that U2’s non-inverting (+) terminal is fixed at 2.5V.  It’s not, because we don’t have negative feedback.  This voltage will vary based on V3 and V5.  Anyway, solving for the switching-point voltage V3 we obtain the following:

Switching Point DerivationSo we’re going to have two switching points, based on the two possible values of V5.  When V5 is 5V, V3 will be decreasing linearly, and a switch will occur at V3 = 1.325V. However, when V5 is 0V, V3 will be increasing linearly, and switching will occur at V3 = 3.675V. So this is how the oscillation happens: V3 ramps linearly in one direction until it reaches a switching threshold, at which point the integration reverses and V3 ramps backwards.  So what does this give you?  A triangle wave, as seen in green in this PSpice simulation:

PSpice Simulation (Red = Threshold, Green = Triangle Wave Oscillation, Blue = Output)

Of course, we can’t just use a triangle wave to signal our servo.  What we need now is a third comparator to generate a PWM signal using this triangle wave and a variable threshold voltage (the red line pictured above).   This is where the components around U5 come into play.  Again, since U5 has no negative feedback path, it operates as a comparator.  Thus, its output can only be 5V or 0V (roughly).  So if we feed our triangle wave into its non-inverting (+) input, and a DC threshold voltage into its inverting (-) input, what we get at the output is a square wave (the blue line) whose pulse width is inversely proportional to our threshold (i.e. a higher threshold yields a shorter pulse).

The last trick here is that we can’t just hook up a potentiometer (pot) between power and ground.  That would give us a threshold voltage variable from 0V to 5V. What we actually need is a threshold voltage that varies from about 3.2V to 3.5V, for a pulse width ranging from 1-2ms (based on the form of triangle wave shown above).  Well in order to accomplish this, I’ve placed two additional resistors (Rx and Ry) in series with the potentiometer (Rpot).  In order to determine appropriate values for these resistors, I’ll start with two voltage divider formulae which are based on the two limits of the potentiometer:

Comparator Threshold Resistance DerivationSo when the pot’s screw is turned fully clockwise, the pot’s entire 10kΩ resistance will be placed between Rx and the inverting (-) input of U5.  This will produce our maximum threshold voltage, VH.   However, when the screw is turned fully counter-clockwise, the pot will act as a short between Rx and U5, yielding our lowest threshold voltage, VL.  If we now combine and solve these two formulae, we can determine values for Rx and Ry:

Comparator Threshold Resistance DerivationNote: To determine resistances for different potentiometer values, you’d just need to replace the 10k in the first set of equations with your updated value and re-solve.

Now of course, all we really need here is a means of controlling the threshold voltage at U5’s inverting (-) terminal.  Back when I was working on my automatic ping-pong ball launcher, I wanted to use my laptop and a DAQ card to control my servo.  The DAQ card I had available at the time didn’t allow me to generate precisely-timed digital signals.  However, it did provide several analog outputs, which I could have connected directly to U5 in order to control this circuit’s pulse width.  But I didn’t know about this circuit back then, so I actually just used a microcontroller programmed to generate the appropriate signals based on an ADC input connected to my DAQ hardware.

Finally, you may also be wondering, how can I calculate the frequency of this PWM signal?  (Or maybe you’re getting sick of all these equations?)  Well, given the above formulae, it’s actually quite simple to calculate.  We just need to set the integration formula equal to the switching voltage formula, like so:

Switching Frequency DerivationWe now solve for the time t, then multiply by four (since this equation gives you the time required by one quarter of a full cycle), and invert to find the frequency:

Switching Frequency DerivationAlright, enough of these crazy formulae.  Pictures of the final circuit?  Yes, please!

Protoboard Closeup

You’ll notice that Rx is actually a series combination of three resistors, while Ry is a series combination of two resistors.  This is because I didn’t have suitable values for Rx and Ry just lying around.  Oh well, it just makes things a little messier!  Here’s the full setup:

Full Protoboard SetupFinally, here’s a screenshot of the IOBoard oscilloscope VI I used to test out my PWM circuitry.  You’ll notice that, as I mentioned earlier, the comparator’s output doesn’t quite reach 0V and 5V because these op-amps (TL072) do not have rail-to-rail outputs:

IOBoard Scope - 2ms Pulse Width

One final note on the schematic above.   The resistance R10 should have been unnecessary. I initially included it because PSpice wouldn’t run my simulation with U5’s output floating.  However, after constructing this circuit I found it necessary for reliably servo operation.  I’m not entirely sure why this was the case; perhaps the voltage levels without R10 were slightly outside of the servo’s acceptable range?  The signal on the screen certainly didn’t appear much different with or without it.  Perhaps if I had a higher frequency/resolution scope I’d see something more telling…  Oh well, it may not be an issue with your servo.

Anyway, if you have any questions on this circuit or would like to make suggestions, feel free to leave a comment.  I’d love to hear about your experience.

Also, please help yourself to my PSpice files (from the Orcad 16.0 student demo).  These were used to create the schematic shown here as well to perform simulations.

PWM Generator Schematic 2

Here’s my final bill of materials (BOM):

  • 2x TL072 Operational Amplifier
  • 1x Hitec HS-81 Servo
  • 1x 4.7uF Capacitor (Can be electrolytic, despite the slight negative voltage)
  • 1x 10kΩ Potentiometer
  • 2x 20kΩ Resistor
  • 2x 1kΩ Resistor
  • 1x 470Ω
  • 1x 119kΩ Resistor
  • 1x 166kΩ Resistor

Update (11/2/2010): It was pointed out that the TL072 may require a minimum supply voltage of 7V, so 5V could be cutting it a little close here.  Now I’ve looked through the datasheet and don’t see a specific limit mentioned, but most of the graphs do only go down to ±3.5V (which I suppose you could interpret as 7V).  Regardless, the circuit works fine with a single 5V supply, although the outputs don’t go rail-to-rail (which is normal operation), as I mentioned earlier.  The real concern with most op-amps is their upper supply limit, as you don’t want to fry anything.  Also, you might be more interested in the TL074 for this project, which contains four op-amps in one package.  I didn’t happen to have a quad op-amp lying around when I built this circuit, hence the two duals.

V5

Picking The Right Output

The other day I ran across a publication from Allegro MicroSystems which was filled with an extensive list of terms and definitions for IC outputs. For instance, do you know the difference between a bipolar and a unipolar output? Well, a bipolar design allows the output to both sink and source current via controlled connections to power and ground. A unipolar output, however, can either sink or source current, but it cannot do both.

Now I don’t know about you, but I frequently confuse NPN and PNP outputs. I guess I just don’t work with these terms that often. Well, here’s one way to keep track of the difference: NPN outputs connect to the Negative supply while PNP outputs connect to the Positive supply. So just remember “N” for negative and “P” for positive! Take for example the following NPN sensor connected to a microcontroller (MCU):

NPN Sensor Wiring

The actual sensor circuitry is not shown here, only the output transistor. Now in this case, we have a unipolar output (the “Signal” line) which can only sink current to ground. In other words, this NPN sensor either connects the output to the negative supply (ground) or lets it float. In this configuration, however, the output does not float but gets pulled up to the positive supply line (V+) by a pull-up resistance. In this way, the input to the MCU is always either high (V+) or low (Gnd), but never in between (an undefined state).

For completeness, here’s one example of an actual PNP output used on a light curtain:

PNP Output ExampleThis may be a little tougher to interpret at first. However, there is one transistor directly connected between the positive supply rail (the topmost line) and the output (labeled OSSD). This means that the output may be connected directly to the positive supply as expected with a PNP configuration. This particular device also includes a pull-down resistor of 2.2kΩ. The difference here is that the pull-down may not always be connected to ground. That extra lower transistor can be disabled, allowing the output to float.

Anyway, check out that document and save it someplace – it might come in handy!

The $868.73 Op-Amp

Yes, you read that right; this here is an $868.73 operational amplifier, the Apex PA50A:

Apex PA50 Power Op-Amp

It doesn’t look like much, does it? Well at only ~1.5″ square, it’s not much larger than most power transistors. However, I can guarantee you it’s impressive. Most impressive. This is a power op-amp, which means it’s designed to deal with high currents and voltages. How high, you ask? Try 40 amps continuous (100A peak) at up to 130V. But you’re going to want a heat sink – this little guy may dissipate up to 400W internally.

JEDEC MO-127 HeatsinkNow sadly, these pictures aren’t mine, as I do not have a PA50 of my own. I also doubt I’d ever buy one (I just like to look at crazy-expensive parts on Digi-Key). However, this would be a fairly useful device. Normally op-amps are used at small-signal levels (from a few millivolts up to a few volts), and as such are only useful for amplifying sensors, performing filtering, etc. But with 40A and 130V to play with, you could drive multi-kilowatt speaker systems, go-kart motors, high-voltage transformers, etc (assuming stability with inductive loads). This baby would also make one serious output stage for a function generator, although its gain-bandwidth product is only 3Mhz. Interestingly, the datasheet lists “semiconductor testing” as the only potential application. Come on guys, I think a little more creativity is in order for such a product!

Now of course, you’re going to need one or two fairly beefy DC voltage sources to power the PA50, but I imagine they’ll cost you less than $800. And just what’s so special about this op-amp that drives up the cost so dramatically anyways? Frankly, I don’t know. Take a look at the following “equivalent schematic” provided in the PA50 datasheet:

PA50 Equivalent Schematic
Although this schematic doesn’t give values for individual components, we know that the final output MOSFETs (Q5,Q7,Q20,Q22) need to be rated for at least 100A (peak) and 130V. Well I’ve spec’d transistors like this in the past, and they’re not terribly expensive – perhaps $6-8 per device (double that if you want something really special). Even if all of the transistors in this package cost $10, that’s still just $220. Maybe there’s something costly about laying out all of this hardware in a single package? I’m certainly no expert in semiconductor design… Or perhaps the actual device is encased in 24k gold and diamond-studded? No, I guess they’re just trying to recoup development costs.

By the way, if you’re looking for high voltage instead of high current, try the Apex PA89, rated for ±600V output. It’s only $885.94 plus tax & shipping from Digi-Key. And don’t worry, I’m sure no one will question such a purchase. 🙂