Hey Shane, why haven't you been working on your motor controllers?

I haven't done much on any of my motor controller projects in a while. For example, DirectDrive hasn't been touched since the July update where it passed a 2.4kVA bench test. And I have yet to do anything other than theorize about sensorless FOC code. And that was so long ago that I would have to reread the post to remember what I was talking about. But now that the season of building and testing vehicles is winding down, and I have sworn off doing any demos, faires, expos, exhibitions, presentations, or showcases until the spring, I can actually have time to get back to motor controllers. For real this time.

First of all, even though I've been relatively pleased with the Kelly KBS36101 controllers on tinyKart, they are frustrating to work with. With the external Hall effect sensors perfectly positioned, the performance at 80A per motor is spectacular. But, if the sensors go out of timing even by just a little bit, the controllers cut out and you lose power to one or both sides. Also, they won't work at all at full current (100A) and they have issues at full speed. (The baseline KBS is only rated to 40,000erpm, which is about 75% of this motor's top speed.) Recently, with the changeover to SK3 motors, the controller bugs have just gotten buggier. So...

I pulled out its heart...

...and put it in a box.

If I'm gonna deal with buggy controllers, they might as well be my buggy controllers. DirectDrive was pretty much designed for tinyKart. If I were as hardcore as I was back in 2008 when we built Cap Kart, I would have put it on from the start. But I guess building the entire chassis was enough of a challenge and we did get quite a lot of use out of the Kelly controllers. Still, screw it, time for the complete power system overhaul.

DirectDrive has yet to be tested under any real load, so by committing it to a vehicle, I am forced to solve any to-be-revealed bugs. I guess that means I should also buy more DirectFETs and solder paste, since things rarely go well on the first version of a motor controller. I've only built one so far, but I have enough parts for a second. The payoff will be:

• More power. DirectDrive is sized for 200A peak at 48V. In this application, assuming it doesn't just outright blow up (it will), it should have no trouble pushing 100A peak at 40V.

• Sinusoidal field-oriented control. I'm not sure this is directly advantageous on such high-speed, low-inductance motors. But the side effect of having complete control of motor timing in software is worth it. No more screwing around with sensor positioning.

• Wireless data. I can get vehicle performance data off these controllers, and use the data to help debug failures. (As opposed to the Kelly controllers, where ***  ** is the universal indicator for every possible failure...)

• Wireless throttle? It worked for Cap Kart.

• Shedding weight. DirectDrive is a tiny bit lighter than the KBS.

For all that, the only cost is probably dozens of hours of troubleshooting...

You might also notice the new battery pack. I'm tired of worrying about LiPos and am willing to take a ~20% energy capacity cut for the peace-of-mind that comes with A123 LiFePO4 cells. But in order to match the power density of the LiPos, they will have to be m1-B cells. (The green ones, not the paper ones from that DeWalt Drill tree I found.) These have a lower internal resistance, such that a 6lb, 12S3P pack can put out bursts of 6-8kW.

But yeah, messing with tinyKart's Hall effect sensors has reminded me just how much of a pain in the ass it is. It would be really, really nice to never have to play the phase-and-sensor-musical-chairs-wiring-game ever again. I am still very convinced that vehicle-grade sensorless control is a possibility. In fact, we recently found proof:

That is a $28 shady eBay eBike controller, similar to the ones that bailed me out in Singapore. Except, it's sensorless. And the start-up doesn't suck. Unlike RC plane controllers, it ramps the output frequency and voltage gradually at start-up so that you get a smooth acceleration. It also does current (torque) control in both start-up and running modes. It's quite nice on Pneu Scooter and RazEr Revolution. But it's still dumb square wave drive, and it simply refuses to start ultra-low-resistance outrunners. However, it's proof that a smooth ramping start-up is achievable.

So, that will be my first task on the way to full sensorless field-oriented control. Start-up is regarded as the hard part of sensorless control, but for some reason I think it's easy. I will be aiming for a sinusoidal drive current with a ramping amplitude and frequency determined by some estimate of the system inertia. It may need locked-rotor detection or a way to reset and try again if it fails to achieve commutation. But I think it will be pretty easy, actually, compared to the rest of the project:

Once the speed is high enough (10%?), the fun begins. Unlike the $28 version, I will be going for full sinusoidal field-oriented control, with no direct measurement of back EMF. I'm sure this will keep me occupied in software for quite a while. It is my first big software project in a long time...and sadly I'm kind-of excited for it. So much so that I violated one of my long-standing software principles:

I split my build into multiple files. :/

I'll be implementing sensorless field-oriented control first on the 3ph 3.1, Pneu Scooter's controller. It's been totally fine ever since I replaced the FETs that died in Singapore. I'm still not 100% sure what the cause of that failure was, but since I've never seen it before or since, I will assume it was something specific (like bad sensor timing....) or just high ambient temperature and humidity. Once sensorless Pneu Scooter is up and running, I can think about porting it over to DirectDrive.

Let the season of motor controllers begin...

DirectDrive v1.0: 2.4kVA Test

After my ducted fan load tester turned out to be basically unworkable, I decided to go back to lower-RPM motors. This way I'm not simultaneously testing the controller's basic functionality and the ability of my FOC algorithm to handle greater than 1,000Hz electrical frequency (it can't).

The first candidate: a re-wound and sensored Turnigy 8085-170 motor:

Well this pretty much didn't work at all. There's some issue with the sensors that makes it sound horrible, and also it's too small to be able to sink a lot of power internally.

I decided to stop when the hot glue holding the sensors in started melting.

Anyway, that was just a little distraction before the real show:

Eeeeeteeek.

The Mars PMAC (brushless Etek) is probably my favorite load-test motor. It's so big that you can't really hurt it, at least not in the time scales of a bench test. I put the DirectDrive controller on its edge to give the heat sink a tiny bit of natural convection, but no active cooling for this test. I wanted to see the temperature rise. Nice, steady temperature rise, and no spontaneous FET destruction.

Now here is where it gets interesting. Short of coupling it to a second Etek, there's not much I can do to apply mechanical load to the motor. (At least with the ducted fan, I had a way of doing so.) So, instead, I brought the motor up to speed under ideal timing conditions, i.e. manipulating the phase of the drive voltage until the current draw is at a minimum. Then, at nearly full voltage amplitude, I threw the timing way off so that the motor begins to draw 100A (phase peak).

And I let it sit that way for one minute. The phase voltage is a sine wave with an amplitude of 16V. The phase current is a sine wave with an amplitude of 100A. But...they're not in phase. So the real power is still low, but the apparent power is 2.4kVA (1.5*100A*16V). The good thing about this load is that it can all be run off a bench power supply, no need to break out the giant batteries yet.

But is it actually a representative test of the controller? It doesn't really test anything outside of the bus capacitor, where the DC current is determined by real power only. But what I'm still not sure about is how it looks to the inverter itself. Here's what it comes down to:

The RMS current is the same regardless of the phase angle. The only thing that changes is the phase of the sine wave that the duty cycle traces out. But, the MOSFETs are still either blocking 36V or carrying their share of the current at any given instant. It makes sense, then, that both the conduction losses and the switching losses should be the same regardless of the relative phase of the current with respect to the duty cycle. Anyone care to confirm or refute this?

If that is the case, than I'm happy with the test results. A minute of running at 100A with passive cooling yielded a temperature rise of 15ºC. I would guess that the heat sink mass is about 0.25kg. If it was mostly just absorbing power (with no active cooling and very little temperature gradient, this is true), then a quick estimate of the power dissipated in the inverter is 24W, which is exactly where it should be for 100A.

More testing to come.

DirectDrive v1.0: First Three-Phase Tests

After provisionally solving the first big problem with DirectDrive v1.0, the current sensor coupling, it was time to port my three-phase brushless field-oriented control software over and do some testing on an actual motor. I decided not to bother with Pneu Scooter's hub motor, since at most it could handle 750-1,000W for a short period of time and I'm looking to hit 5-10kW peak. Though really it would be a better intermediate step than what I wound up using...

Nothing about this seems like a good idea now.

"Isn't using an electric ducted fan to load test a motor controller a great idea? It can sink tons of power and it cools itself!" Well, that was the original thought anyway. This is the giant 120mm EDF from Hobby King, which can produce upwards of 4kg of thrust (the same as KM Scooter's eight blower fans...combined). They're meant to be used in model jets, but you could probably do other things silly things with them if you wanted. I bought one specifically for load testing, since they're only $43. Mine uses a this 4030-1100 motor.

With this load tester, I thought I would try something new for sensing rotor position. I printed out an optical encoder disk with eight black and white segments, which I double-side taped to the back of the motor:

And I used a three-phase set of infrared optical reflectance sensors to pick up the signal:

These mimic the function of the Hall effect sensors I would normally use in this application. They differ in a few important and annoying ways, though. For one, they are analog sensors, producing a variable voltage in response to the relative reflectance of the surface in front of them. To get them to act as digital inputs, I have to set them up with a 10k pull-up resistor and put them at about 4mm from the encoder disk. Then, they produce a 4Vpp square-ish wave. But with a 10k resistor, the normal RC filter I would use on the Hall effect sensors won't work, so I had to swap it for one with lower capacitance. The net result is a sensor signal that is less precise and more vulnerable to noise than Hall effect sensors would be.

Back to that in a minute. First, I made the awesome copper heat sink a more permanent feature by drilling and tapping 4-40 mounting holes for it:

Notice that I still have the wires coming straight off the board in the direction that minimizes coupling of the two Hall effect-based phase current sensors. I set up the load test rig on what has become the Table of Load Test Rigs:

Notice the face-to-face dynamometer in the background.

The software on my laptop might look familiar. It's the same GUI and data logging setup I used for Cap Kart and Pneu Scooter - very handy tool. One thing that's nice about DirectDrive is that, for whatever reason, it doesn't cause my USB port to freak out when it's under load. So far I have not had to use the XBee radio to collect data.

I somehow managed to get the right sensor and phase combinations on the first try, and was happy to see that  the motor spun up nicely. The current sensors, temperature sensor, and other bits and pieces seemed to be working properly. But the motor was drawing way too much current, even no-load (with the fan rotor removed). By that I mean it was drawing almost as much current with the fan as without. Now, this is a load test, so in some sense that's good, but I would prefer the majority of the power to get dumped into the air, not the motor.

After a day of debating (grad student-ing), I decided that the most likely cause was the shady optical sensor rig. On a hunch, I took the data I had collected from the test run and did a histogram of the sensor states. There are six: 001, 011, 010, 110, 100, and 101. If everything is working properly, they should all occur with the same frequency.

If instead your sensor histogram is giving you the middle finger, well then you know you have issues. You can even figure out what the issue is with a little bit of logic:

The top set is what the sensor signals should look like if things are working properly. The bottom set has Phase A shifted left a bit. The result adds time to states 3 and 4 and removes time from states 2 and 5. And guess what:

That was exactly the problem.

I was able to tweak the position of the Phase A, and it definitely helped, but I think the motor still draws a lot more no-load current than it could if the sensor timing were more consistent. The edges of the square waves are also pretty soft, and I'm relying on the input pin Schmitt triggers to make it work. It only gets uglier at higher speeds.

Speaking of high speeds, there is another reason why this is a stupid load test. Thus far, the fastest motor I've run with my FOC code is the 40,000rpm 2-pole inrunner from my RC car. But at those speeds, the rotor position estimate starts to become imprecise and unreliable. Now this is a 20,000rpm 8-pole outrunner. The electrical frequency is over 1,000Hz. Trying to fit a sine wave at 10kHz onto 1,000Hz is almost useless. High speed FOC is an interesting problem, but not one that I want to solve simultaneously while load-testing a brand new controller design.

So, sadly, I may have to abandon my new load tester. It can get to high currents, since the motor has such a low resistance. De-tuning the timing by even a few degrees in either direction causes the current to quickly shoot up, even at low speeds. So I ran it at 50A, and nothing seemed to mind, but it's 50A at something like 6V output instead of the 50A at 40V output, which would be a much more interesting test. Unless I can get the fan rotor up above 10,000rpm, which isn't going to happen easily, there's just no way to get any power through it.

Time for a new plan.

DirectDrive: A Simple MechE Solution

The trivial solution to decoupling my Hall effect phase current sensors:

With the three phase outputs coming off the bottom of the board (top in this picture) rather than the side, they don't all pass over the Phase A current sensor, messing with its reading. With this new arrangement, the coupling between phases is much less. Here's the before and after:

Before.

After.

This quick fix brings the coupling down to tolerable levels for moving on to other testing. I'm amazed at how close the actual gains are (~15LSB/A) to what the first coupling matrix came up with. I guess linear algebra does work. With these gains, the maximum phase current that can be sensed is about 100A, so if I make it past that mark I will have to reconfigure the traces for a less sensitive current measurement. At that point, I will need bigger wires anyway.

I'm still leaning towards a return to the ACS714 integrated-conductor Hall effect current sensors, but before I give up on the through-the-board sensors, I will also try shielding the wires and/or sensors in such a way that they can only pick up the field from the traces passing under them. Then, I may be able to re-route the wires the way I want, which is off the side of the board.

The next milestone was a light load test on a single phase with a current-limited bench supply. Using the SepEx motor field as a giant thermal sink, I ran one phase for 10 minutes at about 350W (48V/7.5A in, 24V/15A out) with passive heat sinking only. No problems passing this test. The temperature reading was clean and the rate of temperature rise on the sink was a mere 0.5ºC/min. Ballpark thermal estimates (the only type I can do) suggest this is reasonable for such a light load.

At this point I'm past the bench supply stage and the next thing to do is run off a battery. If destruction is to occur, this is the point at which it will happen. Shoot-through on a power supply is survivable, but with a large battery pack ready to shove in hundreds of amps, almost any failure is a catastrophic one for the controller. I will also need a suitable load, since the SepEx was already pretty unhappy after sinking 350W for 10 minutes. The next target to hit will be about 2.5kW, in full three-phase operation. Perhaps I need something that cools itself..........

DirectDrive: Well, it certainly looks nice...

I finished soldering up the first prototype of DirectDrive, my new higher-power three-phase controller. Without a doubt I can say it's certainly the nicest looking controller I've made, to date. But if history is any indicator, it is most likely doomed to failure like almost all of my other v1.0 controllers. The only real question is: Will it be some fundamental design flaw, a layout problem, noise issues, or a fiery death?. Or all of the above? Well, 

In the last post I mentioned that the ACNW-3190 gate drivers I wanted to use were in fact not the package I thought they were, and so I went back to the HCPL-3120, my standard high-current gate drive solution since Cap Kart. They have "only" 2.5A of gate drive, though, which is a bit weak for driving four of the DirectFETs. Using 20Ω gate resistors, the switching waveforms looked like this:

The trace that starts high is the Vds. The trace that starts low is Vgs.

I learned a lot about MOSFET switching characteristics, including that the length of the Miller plateau depends on the voltage across the MOSFET. So to test the true switching time, I applied 36V across the FET and measured both the gate voltage and the drain-to-source voltage. The switching time, where the FET is dissipating the most power, begins when the gate voltage reaches the threshold voltage (about 3V) and ends after the Miller charge is satisfied. I measured this to be about 290ns. That's right in line with what I would predict, but my initial calculations suggested that these switching losses would make 50V/200A operation very difficult to achieve. So, I am trying out 10Ω gate resistors:

Wow, that's ugly.

While it's definitely shorter, down to about 110ns, the switching waveforms have much more ringing now. The gate drive traces are fairly long and wander around to get out from under the DirectFETs and bus capacitors. I was definitely worried about the inductance, and here's a clear example of why it helps to put the gate drivers as close as possible to the FETs. The good news is that this was measured up by the TVS diodes that "protect" the gate:

Measuring right at the gate instead reveals a moderately cleaner signal:

As ugly as it is, I've seen worse, and I'm tempted for now to just leave the 10Ω gate resistors in for the rest of the testing phase. On to the next problem!

After I tested a collection of low-side FETs, I attempted to get one full half-bridge up and running. In doing so, I was temporarily stopped by another issue that I swear I've had to solve on several occasions in past motor controller projects. The problem is that the HCPL-3120 gate drivers have a very unforgiving undervoltage lock-out that will shut down the output if the gate drive supply voltage drops below 11V. This isn't a problem for the low-side, which is fed directly by the 15V switching supply. But the high side is bootstrapped and as it turns out, I needed a bigger bootstrap cap to keep the high side on. So, I switched to 4.7μF and the problem went away. With the half-bridges working properly, I finished soldering the rest of the board.

I discovered the first real board flaw when none of my gate drives would turn on, despite all three channels of PWM being active. I've used a hex inverter (74xx04) before to generate the complementary PWM signals, but I guess I forgot that the 74LS series doesn't work on 3.3V. So I'll have to get some 74HCs. In the mean time, I'm not above little-blue-wire hacks:

Little yellow wire...whatever.

I also soldered a current sensor in upside down, but nevermind that. After a few minor fixes, everything seems to be up and running. The tiny temperature sensor and phase current sensors both provide stable zero outputs and the three phases do what they should in response to PWM signals. Moving on to light load testing...

It's a light load, I swear.

Cap Kart's SepEx motor has a 1.3Ω field winding that makes a terrific power resistor. It's big enough to not get hot for a while and it has an assload of inductance, so the current going into it will be smooth at any reasonably PWM frequency. However, for some reason, it has killed a number of controllers in its lifetime, including a Victor HV. So I was a little nervous about hooking it up, but it seemed like the best light-load option.

Mainly, I was looking to test the through-the-board Hall effect current sensors. (If the FETs have issues with this ~20A load, then I'd be pretty much screwed.) The good news is that both current sensors produce a repeatable, stable, and clean output and can resolve current to better than 1A. The range is about +/-80A as configured by copper braid jumpers on the bottom of the board. The bad news is that the current measurements are disappointingly coupled...

Through the magic ways of Gilbert Strang, I was able to produce this coupling coefficient matrix which shows just how bad it is. The lowercase i is the sensor reading and the uppercase I is the actual phase or DC current. The coefficients show how much of each component of actual current winds up coupling into the sensed current on phase A and C. It's not all bad news: the 14.1 and -13.4 make perfect sense (lol) given the  gains I expected and the fact that one current sensor is "upside down". The cross-coupling on the C phase is not terrible; it picks up a bit of A and a bit of DC. But the coupling from phase C onto the A sensor (the -10.5 value) is really bad. It means that the A sensor is picking up almost as much C phase current as A phase current. Physically, this all makes some sense: All the wires pass over the A sensor, while the C sensor sits sort-of off to the side. But it's very not good for current control...

So, the options I am now considering:

1. Presumably if I can find a coupling matrix, I can find a decoupling matrix to recover the true currents from the sensor readings. This is a horrible idea that I will probably try out of morbid curiosity.
2. Re-routing the wires to come straight off the board instead of passing sideways over the phase A sensor. This is a quick fix that might minimize the coupling, but it's not space efficient and I probably wouldn't be satisfied even if it got rid of a lot of the coupling.
3. Returning to the ACS714 current sensor and using the back of the board to create an epic bypass shunt to change it from a +/-30A sensor to a +/-200A sensor. It's still a Hall effect sensor, but with an internal conductor and measurement, so the coupling should be much less of a problem. This is the solution I am leaning towards.
4. Switching to a shunt resistor measurement. I don't really want to think about the isolation issues, but it would be the most accurate. The other problem with small shunts for 200A is they will have very low voltage drops and be hard to amplify.

So I'll have to do a v1.1 to implement a more permanent fix for the current sensing. But in the mean time, Option 2 will probably allow me to continue testing with this board, and I won't feel as bad if I destroy it under heavy load testing. More to come.

Pan-Project Update 6/16/11

I got a little distracted last weekend...

...by F1 cars.

I took a spontaneous trip to the F1 Canada Grand Prix, the only F1 race held in North America. It turned out to be a very rainy weekend, but even so the F1 cars were impressively fast and loud:

It's literally not possible to capture the sound of an F1 car passing 15 feet in front of you with my camera. The microphone just saturates and it just sounds like an explosion. Then again, that's sort-of what it sounds like in real life too, when your eardrum saturates. Combine the sound with the ominous sprays of water shooting 20 feet above the treeline on the far side of the track and it's like something out of a monster movie: You know it's coming for you next. Max has a more thorough summary of the experience, plus some better video.

But since we ran into car trouble (lol) on the way back from Montreal, I've had to spend a few days catching up with work. I made a bit of progress on some projects before and after the weekend, but not enough to justify an entire post for any individual one. So, I will do the thing I hate doing and make a Pan-Project Update to make excuses for highlight the lack of  progress on each.

First and easiest,

Sensorless Field-Oriented Control

I've made no progress on this. I have a decent idea of how to start, and I maintain my opinion that you can do pretty much anything in software if you spend enough time messing with it. Some day soon I will do it, and nobody will care because it's software and has no tangible meaning, but then I'll just laugh at everyone.

Moving on then,


Flinch

I got the M3 screws I needed to finish mounting Flinch's four gearmotors, so I did that:

Flinch is a straightforward 4WD robot layout, so there were no surprises here. It's essentially the same size and shape as mini4WDbot:

In fact, as a starting point I just transfered mini4WDbot's entire electrical system over to Flinch. That includes four repurposed VS-11 servo drivers, an Arduino Nano Carrier, and a 7.4V LiPo. I wanted to test the open-loop performance of the FingerTech mini-Mecanum wheels before investing significant effort into the inertial sensors for high-speed Mecanum-ing.

Unfortunately the low-speed tests didn't work out so well. I've worked with larger Mecanum wheels before and even those are very sensitive to weight distribution, driving surface, and the condition of the rollers. The rollers on these wheels are rubber with brass axles riding in plastic wheel hubs. Off the ground, they roll just fine. But under axial loading, the steel washer spacing the rubber roller out from the wheel does not make a very good thrust bearing. Maybe with a lot of tweaking they might do something Mecanum-like, but I don't have the patience for that.

Plan B involves putting real rolling-contact bearings on each roller axle. FingerTech sells these (an implicit admission that the regular axles leave something to be desired?), but they're needle bearings, which won't help much with friction between axial-contact surfaces. So I instead opted for SR144ZZ tiny ball bearings. At least with these I can use tiny shaft spacers to keep the washer from making contact with the side of the wheel. Of course, this means carefully drilling out each roller axle and pressing/gluing in a tiny bearing. After that, another open-loop test to evaluate the new level of Mecanumosity.

Next,

DirectDrive

I'm starting work on my larger motor controller, called DirectDrive because it uses a crapload of DirectFETs. I ordered a single board for testing, since usually my v1.0 motor controllers wind up failing spectacularly in some way anyway. But I can still be hopeful, right? Plus, I get to play with a new toy:

Add it to the list of things that are absurdly cheap if you buy them from China, a bagel toaster programmable reflow oven. DirectFETs cannot be soldered with an iron, since the gate and source pads are under the device. I was planning to use a hot air station, but this is way faster and I've never done it before so it was an opportunity to learn. It's pretty simple:

Step 1: Apply paste haphazardly without a stencil.

Step 2: Place MOSFETs in the correct orientation.

Step 3: Toast for 7 minutes or until lightly browned.

Actually there are a few little DirectFET-specific tricks I learned along the way that I would definitely use in the future:

1. DirectFETs are ever so slightly magnetic. This is great because you can pick them up with a small neodymium magnet (instead of tweezers) and carefully lower them onto the paste. Once they touch the paste, surface adhesion is enough to pull them off the magnet.
   
   
2. You can look at the board edge-on to verify that there is still a gap between the gate and the nearest row of source pads. If not, you probably want to clean off that one and try placing it again. After reflow, this gap is usually still visible. I did see a few after reflow where the gap was no longer visible. But upon measurement, they did not appear to be shorted.
   
   
3. The drain tabs and source pads need a lot of paste. Screw stencils.You can lay down a thick line. It's got to conduct a lot of current anyway, and much of the volume of the paste is flux, so it gets thinner as it evaporates. It's not like a BGA IC where you have to worry about shorting adjacent balls. There is only one critical point (between the gate and source) and by preferentially steering the line of solder paste toward the far side of the source pads, you can avoid bridging that.
   
   
4. You can and should test the MOSFETs after they have been reflowed. I test to make sure there are no shorts from gate to drain or gate to source. (If you shorted drain to source, you did something terribly wrong.) I also check the capacitance from gate to source, which should be near the datasheet spec and consistent across all FETs. And finally I check the on-state resistance.

As far as alignment goes, some of the FETs are visibly rotated by a few degrees. However, they are very flat, something I was concerned about for heat sinking. I'm happy with the procedure and will be even more confident in recommending it after I load test this board.

One minor problem was that the ACNW-3190 gate drivers that I was so excited about last post turned out to be 400mil DIP packages instead of 300mil. I should have RTFDS more carefully. Anyway, that means I will have to go back to the 2.5A HCPL-3120 drivers. Though maybe I can, you know, stack them on top of each other or something.
And finally,


???

The mysterious four-wheeled Edgerton Center Summer Engineering Workshop 2011 project. It's not quite ready for a reveal yet, but here's a teaser:

DirectDrive v1.0

"Hey Shane, why don't you build a larger controller that does more current?"

-Everyone.

Because...I...don't.....ok, whatever.

Rather than mess around with a new 3ph revision, I'm just going to start a brand new controller series, to try out some of the crazy stuff I've been wanting to try that's too risky to test on controllers I actually need. 3ph v3.1 works nicely at 40V and 40A. It's finally free of noise issues and has been running on Pneu Scooter for almost half a year now. But in the interest of satisfying some more demanding brushless motor applications, I'm shooting for 50V (DC) and 200A (peak phase current). So I'm going back to v1.0 and I will call this series DirectDrive...

...because it uses a crapload of DirectFETs. DirectFETs are one of the big things I've been meaning to try out on a motor controller. They're an International Rectifier proprietary package that eliminates plastic and bond wires in favor of...just...metal. It's about as minimalist a package for a power MOSFET as you can imagine, and in addition to low resistance due to increased die area, they can also get rid of heat more easily thanks to exposed metal cans that can be directly attached to a heat sink. 

They're also less than 0.7mm tall.

The particular part being used on this controller is the IRF7759L2TRPbF, a 75V FET with a typical on-resistance of 1.8mΩ. There are four in parallel for each leg of the three-phase bridge. The layout is one I've been thinking about for a long time that uses the DirectFET package (can) as a sort-of bus bar to augment the current-carrying capability of the traces and to jump the three phase outputs across the negative bus to the outer edge of the board:

It even looks like a three-phase bridge. The phases are arranged in three columns and the phase output is the giant strip of through-hole pads at the bottom edge of the board. All the high side FETs are connected together at the can (drain). There are traces that link them and the bus capacitors on the top of the board, but for the most part current will go straight through the cans themselves. Likewise, the phase outputs jump over the negative DC rail by way of the low-side FET cans. Conductive FET packages are like having an extra PCB layer to play with. Of course, the can resistance (measured to be about 0.15mΩ) will add to the total heat dissipation.

Here's what it looks like on the bottom.

One of the risks of using the DirectFETs that's prevented me including them on a controller so far is the fact that they are impossible to solder with an iron. The gate and source terminals are on the underside of the FET. IR has a 33-page app note entirely about how to reflow the DirectFET packages. I don't have regular access to a reflow oven, but this video convinced me that it would be possible to do with just a hot air station. I tried it out on one of Matthew's test boards, without the stencil, and it seemed to work okay. The measured resistance after soldering was about 2mΩ. How the array of 24 will behave, especially in terms of overall straightness and flatness post-soldering, will be an interesting experiment.

The reason flatness came to mind as a potential problem is because of the massive heat sinking requirement of this board. Even if it were 99% efficient, a 50V/200A controller would have to shed 100W somehow. The DirectFETs provide plenty of area for extracting heat, but we're still talking about the sort of cooling requirements you'd have in a beastly processor. So, what isn't pictured above is the sizable heat sink and fan that will be required to actually run at 200A for any extended period of time. For a quick burst, though, the 1/4" slab of aluminum will provide some thermal mass buffering. Between the sink and the FETs will be a 0.5mm silicone thermal interface material, to fill the gaps and isolate the sink from the electrically conductive cans.

This will also be, oddly enough, the first controller I've ever designed with on-board temperature measurement. I wanted to use a linear temperature sensing IC instead of having to calibrate thermistor curves, but they don't make one that would fit in the gap between the board and the heat sink...

...oh wait yes they do. The TMP20 sensor from Texas Instruments is a mere 0.5mm tall, making it actually shorter than the DirectFETs. On the board, it takes up less than 2mm x 2mm, which means it's basically invisible and probably very difficult to solder.

The thing next to it is a 0603 thermistor...

Because it basically doesn't even exist, I could put it in a tiny gap at the intersection of the high side and low side FETs on one of the phases. It will be in contact with the heat sink, and has a local ground plane to conduct heat into it. But it's so small that it probably instantly assumes the temperature of whatever it's touching anyway. It's also right next to the logic side of the board, allowing easy access for 3.3V, signal ground, and the analog output. Just in case it folds itself up into nothingness or explodes due to dV/dt induced nastiness, I put a 0603 thermistor footprint right next to it.

The power layout of this board was probably one of the most fun layouts I've done, ever. I had it basically finished a few weeks ago, after I converged on a very nice interleaved bus capacitor arrangement:

You might have to use your 3D imagination skills a little here. It jumps between layers a lot. The vias will need to be filled with solder to carry the full current, but I think that's standard practice for high power-density controllers. There are five 18mm surface-mount electrolytic capacitors on board for a total of 3300μF at 63V. The capacitance is high enough, but the ESR may cause problems running at 200A. External capacitance is not out of the question. Additionally, there are software games you can play to minimize the ripple on the bus capacitors in a three-phase inverter.

I have no idea how it will perform, but I also really like the way the gate drive escapes from the power section up to the top of the board. Crossing over traces under the capacitors frightens me a little bit, but it cleans the layout up nicely and I think gate signals are low-enough impedance to blast through any EMI issues. I think... 

Speaking of EMI, although the 3ph controllers since v3.0 have made good use of the IRS21844 half-bridge integrated gate drivers, I've decided to retreat to the comfort and safety of the optocoupled gate drive that I used in 3ph 2.1 and, the ultimate FET killer, Cap Kart. The idea is fairly straightforward:

Each MOSFET is driven by a gate drive optocoupler, formerly the HCPL-3120. The output of the gate driver is a push-pull driver that runs on 15V, either directly from a 15V supply (low side) or a bootstrap capacitor (high side). The input is just an LED. If the LED is on, output is driven high, if off, the output is driven low. The LEDs are connected in anti-parallel. A simple inverter and low-pass filter circuit ensures that a) both LEDs can't be on at the same time and b) there is a suitable delay between turn-off of one LED and turn-on of the other. This is passive shoot-through protection. Importantly, the logic side is entirely isolated from the noisy power side by virtue of the optical interface.

Switching four parallel IRF7759L2TRPbF FETs is a tall order for the 2.5A HCPL-3120, though. The total gate charge per FET is 200nC and the "switch charge" is 73nC. Even if the gate driver were operating at 2.0A for the entire switching period, it would take 4*200nC/2A=400ns to fully turn on or off the FETs. It's similar in switching effort to Cap Kart's half-bridge, but unlike Cap Kart it's being designed to run at 15.6kHz and has three phases.

This is not a happy gate drive.

Avago Technologies to the rescue. It's been a couple years since I browsed the gate drive optocoupler selection, and in that time a new, 5A version has come out. The ACNW3190 is more-or-less pin compatible with the HCPL-3120, and should be able to switch the four parallel FETs in a more reasonable amount of time. This will be the first time I'm trying them out, though.

There's one more "new" trick I am trying out, probably the most risky one of all. You may have noticed the odd, broken traces on the A and C phase:

And the islanded SOIC8 chip on the top layer. This is, in fact, an attempt at through-the-board Hall effect current sensing. The chip is a LEM FHS 40-P current sensor. Actually, it's more like a magnetometer, measuring field strength to the right, looking down on the chip. The traces passing under the chip produce a magnetic field according to the right-hand rule. 

I've use Hall effect current sensors before, but never a remote-sensing one like this. It is a little worrying because they can easily pick up stray magnetic fields. I've taken a few steps to minimize this: I used the A and C phases to keep them as far away from each other as possible. Also, all the power wires leave the board perpendicular to the current-carrying traces designed to be sensed. This way, they do not contribute to the measured field. Presumably, any static errors can be calibrated out, but there's also the potential for external fields from things with magnets in them, like perhaps motors. Of course, this would be a problem with regular Hall effect current sensors as well. Only one way to find out how they perform.

Oh yeah, I forgot to mention the purpose of the broken traces. The FHS 40-P is designed for, at most, 100A sense current through the board, with a single large trace running directly under the center of the chip. At the definite expense of resolution and the possible risk of lower noise immunity, I'm trying to sense an even larger current by moving the current-carrying wires farther away from the center of the chip. The broken traces can be selectively jumpered to "program"  the gain of the current sensor to my liking.

To improve the noise immunity of the current sensor signal Because I am too lazy to route the traces, the current sensors are actually connected to the logic side of the board via external three-wire cables, almost as if they were separate modules altogether. As an added bonus, if they don't work out, I could possibly use external current sensors anyway. Though in reality I would probably consider that a big enough failure to merit a v2.0 design revision. The two phase currents, as well as the Hall effect encoder and throttle signals, come in to the logic board via two rows of headers:

There's also an auxiliary current sense input which could be used for sensing DC current, as well as a spare analog channel. Differential voltage sensing is also available, though it comes in through a separate input near the bottom of the logic section. The logic board and power supply are the same as on 3ph 3.1, including the DCR021205 isolated regulator that saved the day last time. It will run my field-oriented control code for the STM32F103, so there shouldn't be any software surprises.

The entire controller is just about 4"x3"x1", or one standard EAGLE brick. (3ph 3.1 is an EAGLE half-brick.) The power to area ratio is quite high, which means that cooling will be a big challenge if it is to actually run at 200A. But even having a nice 100A continuous controller around will be handy, I think.

Board have been ordered. Actually, since it's v1.0, I only ordered one board. For some reason, my v1.0 motor controllers never seem to work. (And I know v1.0 of everything is usually not a complete success, but I'm talking about spectacular failures here.) So I'm not going to get my hopes up right away. But it's nice to finally be working on motor controllers again.