ECSEW V: tinyKart

Believe it or not (I don't), this is the fifth year of the Edgerton Center Summer Engineering Workshop, an ad-hoc team of like-minded engineering students interested in things you can ride. Of all my past projects, I think the ones that I've enjoyed the most have been the Workshop ones. Since 2007, we've made:

• The DIY Segway, probably definitely our most popular vehicle, which helped spawn a new era of smaller, lighter, cheaper, simpler DIY self-balancing...things.
• The Cap Kart, our largest, most ambitious vehicle, which underwent a revision in 2010. Its name comes from the 16V/110F capacitor that gives it a speed boost from a bit of regenerated energy.
• BWD Scooter, which led me in the direction of brushless motor design and control that occupies so much of my time these days.

But for 2011, we are returning to four wheels to create an ultralight go-kart. (Okay, maybe not this ultralight.) One of the drawbacks of Cap Kart, even the newer, lighter version, is that it takes three people and a truck to move around. With tinyKart, the target weight is something like "less than one of Cap Kart's old batteries."

Cap Kart's original 53lb deep-cycle marine batteries.

So obviously we're gonna need lighter batteries. Cap Kart v2.0 uses 42lbs of LiFePO4 batteries from Thundersky, now Winston Battery Limited. For that weight, you get 1.58kWh of energy storage and a peak power of 7.5kW. The only way to do better than that, in terms of power and energy density, is with lithium polymer.

tinyKart will use between two and four 10S, 4500mAh LiPos, making it only marginally less of a fire hazard than a gas go-kart. At a maximum, this gives 0.67kWh of energy storage. But since they specialize in absurdly high power density, there is the possibility of using just two batteries, a weight of just over 6lbs, to power the whole kart for a few minutes at a time.

Next comes the question of propulsion. The ultralight kart as I've always imagined it was powered by two short Magmotors, but they're just not cost-effective anymore. For less than the cost of one Magmotor, we got a set of four Turnigy SK6374-170 brushless outrunners. They're not the biggest brushless motors, but two will certainly propel a go-kart and four would make it a competitor for Cap Kart, in terms of acceleration. (One of the emerging themes of this project seems to be modularity; we can change the number of motors and batteries quickly to go between the lightest configuration and the most powerful.)

The drivetrain is really simple: RWD with independent belt drives on each wheel. This is enabled by the cheap and light aluminum rims from electricscooterparts, which have a 72-tooth belt pulley integrated into the rim casting. The rim and tire together weigh less than 2lbs. The motors are light enough to face-mount to a 1/4" aluminum plate and ball bearings on an eccentric standoff provide adjustable belt tension. As-pictured, the gear ratio is 4.5:1, yielding a top speed of about 30mph with the 8" wheel.

These wheels are designed for electric scooter use, where they would fit on 10mm shafts supported on both sides by the rear fork of a scooter. One of the easily-overlooked little details that I think makes this all possible is 6903 bearings. These are the same O.D. (30mm) as the 6200 bearings normally used in these rims, but they have a 17mm I.D. instead of 10mm. Thus tinyKart's four wheels are supported by cantilevered 17mm aluminum shafts.

Ask Max why the plate is at a weird angle like that...

One of the things I've always had in mind for an independent RWD electric kart is torque vectoring, a neat trick where you force more current into the motor driving the outside wheel to help shove the vehicle into the turn. This of course requires measurement of the steering wheel angle, but that's not hard. It might make up for the natural understeer of a kart that has 70+% of its weight on the rear wheels.

Between all of us, we have a ton of experience building electrically-propelled drivetrains, so I'm not very worried about the propulsion side of things. What makes this project interesting is that, unlike Cap Kart, we're building the entire chassis from scratch. And as you can probably tell from the CAD, it is not a typical go-kart build. We briefly debated the idea of making a welded tube frame, but then decided that 80/20 is the only structural material we know how to utilize ultimate expression of lightweight structural modularity.

The kart chassis is split into two halves: the front, which has a lot of platework for aligning steering linkages, and the back, which contains drivetrain components and the seat. The overall width is about 34" and the length is 48", though it can easily be made an few inches longer or shorter to accommodate different drivers. The front and back overlap by an adjustable amount to provide rigidity.

The front wheels are also electricscooterparts rims, but with brake disks instead of drive pulleys. We'll machine off the drive pulleys on those wheels and face the brake mount inwards. This will cause a bit of an issue on the left side, since the brake disk hubs are threaded and the braking force will tend to unscrew that side's hub. But I suspect this problem is easy to solve with enough Loctite.

I went with a relatively low-tech method for working out the geometry of the brake caliper mounts:

The other tricky bit of geometry to solve in the front of the kart was the steering linkage.

From above, it's a pretty straightforward Ackermann steering geometry, with a drive link off the steering column very similar to Cap Kart. But I tried my hardest to contain the entire thing in the 1" vertical space between the plates, which meant that I couldn't use ball joints on the steering pivots. Instead, the two degrees of freedom are split into a horizontal and a vertical pin joint:

The horizontal pin joint is just a shoulder screw with some brass washers. The vertical pin joint, which is far enough inside the kart not to interfere with the plates, attaches to threaded rod that goes to the drive plate on the steering column. Since I know nothing about proper steering geometry, everything is adjustable. The only thing we've sacrificed from Cap Kart's steering is the caster angle, which is by necessity zero in this design. To make up for it (or do nothing at all, idk), the center of the front wheels is just slightly behind the kingpin pivots.

Since the 1/8" aluminum plates don't really provide much rigidity, the gap between the 80/20 rails framing the front of the kart are spanned above and below by 1/4" steering reinforcement plates, which also hold the radial kingpin bearings. The thrust bearings are between the 1/8" plates. It might be overkill, but flimsy steering is one failure that we don't want to deal with.

There are plenty of other little details that went into the design so far, but I'm sure we'll be highlighting them as they get built. For now, we're waiting on parts and I'm on my first real vacation in a long time. The build begins next week and it will drive by mid-August.

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.