Arduino Hex-Bridge Shield: Concept and v1.fail

So, I guess I am finally coming to terms with living in a world where Arduino rules. If you've been living under a rock, an Arduino is an AVR-based microcontroller development board with an array of peripherals, a huge library of code, and a large user base. They have become a staple of DIY projects and "Arduino compatibility" of DIY hardware is now a legitimate concern.

I'm faced with two options, then. One: I could continue to rant about how I designed most of my current TI MSP430-based hardware to do everything the Arduino does, but better, and how the Arduino is not a replacement for learning how to design circuit boards and program microcontrollers directly. Or, two: I could drink the Kool-Aid and make something useful that also happens to sits on top of an Arduino.

Cue the Hex-Bridge Shield. (Scientific name: Large Arduino Switching Shield with Field Effect Transistors.)

Here are some pictures of v1.0, a failure for reasons which I will discuss below:

Hex-Bridge, Top Side: MOSFETs.

Sidecap.

Hex-Bridge Bottom Side: Gate Drive.

Okay, so calling it a shield is a bit of a stretch. It doesn't really sit on the Arduino so much as the Arduino sits under it. (Can you see where?) It's pretty compact for what it is, though: six semi-independent, high-power MOSFET half-bridges, with all the gate drive circuitry included. Each bridge was a version of my modular half-bridge design, which I've used in every motor controller I've built for the last two years.

The gate drive is based on a design we originally did for the Cap Kart long ago. Each FET gets its own 2.5A gate drive optocoupler (HCPL-3120). An optocoupler passes a signal through an LED and photosensor (packaged in a single chip) to electrically isolate a circuit, which is useful for protecting the microcontroller from high power switching noise. These particular optocouplers are designed to drive the gate of a MOSFET, on when the LED is on, off when the LED is off. By arranging two LEDs in anti-parallel and including a low-pass filter, passive shoot-through protection for each bridge is achieved.

One high-level half-bridge schematic.

Notice how the LEDs are arranged so that only one can be on at any given time. Also notice that the low-side gate drive optocoupler is fed by an inverted signal. This creates synchronous rectification, mirroring the PWM on the low-side to minimize diode losses and allow regenerative braking. This is just a high-level schematic, leaving out details such as the shoot-through delay filter and the gate resistors and protection components. But it should give the general idea. One down side of this method is that it requires a separate high-side supply. This makes it expensive (about $15 per bridge for all the gate drive components, which is more than the FETs themselves). Integrated half-bridge drivers such as the IR21844 provide a less expensive solution. v2.0 will use these.

The MOSFETs are IRFS3107 surface mount packages. They have a typical Rds of 2.5mΩ. (For reference, that's about the same as one foot of 14AWG copper wire.) These are monstrous 75V FETs that can, with proper heat sinking, probably handle "high-double-digit" currents. Throw a fan on and I don't even want to speculate how much current you could pass through it.

IRFS3107 Output Characteristic. 

0.2V at 85A...way better than an IGBT.

Everything on the board is sized for an input voltage of 18 to 48V. On the input, there is 990μF worth of 63V electrolytic capacitors. (These could easily be replaced with 50V or 35V capacitors of higher capacitance for lower-voltage, higher-current applications.) An LM2575HV switching regulator provides 15V @ 1A to power the Arduino and the gate drivers.

An here's where the failure comes in. Take a look at an Arduino. (I know you have one.) All of the digital signal pins are on the top row of headers, but the +5V, VIN, and GND pins are on the bottom row. I made the horrible mistake of running lone +5V and VIN lines from the LM2575 and the logic ICs, around the entire high current switching board, to the bottom headers. Bad bad bad bad bad bad. I can't even describe how bad it was.

By eliminating those traces and running an external connection for +5V, GND, and VIN, I was able to eliminate at least the most dramatic of the failure modes. While in this hacked state, it was able to run 20A continuously through a single phase with just natural convection. The resulting FET temperature was about 90ºC. Extrapolate as you see fit for a current rating with paralleled FETs, heat sinking, and/or fans.

So it has the potential to work, but in terms of a board design, this one is total scrap. Version 2.0, which is already in the works, will be better in every way. (Smaller, cheaper, better mechanical and thermal layout, easier to stack additional shields on.) But since I have nothing much to show for it yet, I can only tell you the design intent:

It would be great if the Arduino had six completely independent high-resolution PWM channels like some chips do. Then you could control two brushless motors. You could even do sinusoidal field-oriented control! Well, maybe not. But anyway, it would be cool if this shield could be used to control two brushless DC motors using square wave drive, at least. With six phases to play with, that should be possible. The trickiness is in multiplexing the PWM signal from Arduino pin 9 and 10 out to each set of three phases. Thinking about NAND gates makes my head hurt, but fortunately I got some help in coming up with a creative solution using an analog switch:

Chuxxorplexer

Actually, the real key is using one selector pin to completely control each bridge, including being able to disable it. This is where tri-stating comes in. If the selector pin is driven high, the relevant PWM from pin 9 or 10 is ANDed in and the bridge executes synchronous rectification. If the pin is driven low, the low-side FET is steady on, grounded that phase. If the pin is set as an input (high impedance), neither FET is on and the phase floats. This allows full four-quadrant control while still preserving the "off" state. Don't ask me how the analog switch accomplishes all that in one shot...but it does. Just stare at it until it make sense. That part totally works. This is what comes out of the magic box:

Digital pins 2-7 are used to select a state for each of the bridges. The bridges are labeled {A, B, C, U, V, W} from left to right. Each bridge can have one of three states:

• When its state pin is written HIGH, the bridge executes synchronous rectification based on the PWM present on pin 9 for A, B, and C, or pin 10 for U, V, and W. This means the high side FET will be PWMed with a duty cycle set by analogWrite(9 or 10), while the low side FET does the opposite.
• When its state pin is written LOW, the low side FET of the bridge will be steady on and the high side will be off. This is effectively like grounding that phase. The PWM does not matter.
• When its state pin is set as an INPUT using pinMode(), it will turn off both FETs and the phase will float. This is useful for disabling the controller or for the undriven phase in BLDC control. Note that even in this state, diode flyback can occur.

Unfortunately, the Chuxxorplexer won't make it into v2.0, which uses a different gate drive configuration entirely, but the functionality will be preserved using a much less elegant brute force set of logic chips. The important thing is that the three-state control in the table above will be preserved. This is, IMO, the cool part, giving almost complete flexibility of bridge configuration for one or two motors.

Here are a few examples:

 Monster H-Bridge

The monster H-bridge can be achieved by setting {A,B,C}={1,1,1} and {U,V,W}={0,0,0} for forward, or {A,B,C}={0,0,0} and {U,V,W}={1,1,1} for reverse. This parallels three bridges to make a super half-bridge, then combines two super half-bridges to make the full H-Bridge. This gives the highest current reversible control with regenerative braking.

Dual H-Bridge

The dual H-Bridge, also known as the drive controller. This can be used to drive the left and right sides of a tank steer robot. Since each bridge only uses one FET per leg now, the current capability is lower than the single monster H-bridge. To get this configuration, {A,B,C} = {1,0,X} or {0,1,X} for forward and reverse and {U,V,W} = same idea. X means that the unused phase is set as an INPUT, left floating. Hey, why not use the two unused phases to make a third H-bridge? Because there are only two PWM channels. Sorry. But the next one should be obvious...

Hey now...

The dual-channel BLDC controller, something I've seen before somewhere. Basically, you would cycle through every permutation of {1,0,X}, one phase driven, one grounded, and one floating. Except now you're on your own for how to achieve electronic commutation. One idea would be to use the floating phase and an analog pin to do back EMF-based sensorless control. Another idea would be to use Hall effect sensors and interrupts.

Monster Half-Bridge

The monster half-bridge, also known as the weapon or spin controller. It can only go in one direction, but it parallels all the MOSFETs for the highest possible current capability. This is actually not a "safe" configuration, since it is possible (and likely) to shoot-through from ABC to UVW if the PWMs are not in sync. To get this configuration, use only one PWM, 9 or 10. Set the other as an input and tie them together with a resistor. If you don't do this, instant destruction will occur. Along the same vein, there is also a monster BLDC controller configuration that ties A to U, B to V, and C to W.

Lastly, my favorite configuration: the SepEx controller:

SepEx Controller

This combines a super half-bridge with a regular H-bridge. The super half-bridge controls the high-current armature winding of a separately-excited DC motor. (By the way, don't bother reading the description of the SepEx motor's regenerative braking method on that page...it's totally wrong.) The smaller H-bridge controls the low-current field windings, allowing the field to be varied and reversed. Now, I don't want to pretend that this controller is powerful enough to drive a D&D SepEx motor under full load...it's not. But conceptually it can be configured for the SepEx by using {A,B,C} = {1,1,1} and {U,V,W} = {1,0,X} or {0,1,X}. Actually, don't I have a SepEx motor somewhere that I can try this with?

Oh right, there it is.

I'll leave off with a teaser for v2.0:

 Can you spot the layout improvements?