quadFormer

quadFormer/Ferrite Pole Pig is an 10KVA ferrite transformer built for the sole purpose of drawing arcs. It's actually the second iteration of this transformer; the original arced over after a few runs and died.

Lots of delicious ferrite

The transformer in this case is four transformers in series, each capable of handling ~3KW. The primaries are three turns, and the secondaries are around 150 turns each, so theoretically it will produce 15KV peak when running on 300V primary.
One end of each secondary is tied to each core, and the cores all float roughly 3KV away from the secondary. This makes secondary-to-core insulation a breeze - 3KV can't really do much. Each secondary is wound with 28AWG magnet wire.
The primaries are all isolated from the floating cores. The idea here is that its much easier to insulate a primary than to insulate a secondary (if necessary, the primaries can have insulation on them that can hold off 15KV by sheer brute force!). The downside of this is if there is ever an arcover, the driver is likely to die, and of course, floating cores is death waiting to happen.

My friend Tyler built the driver for this transformer (he also came up with the concept of giant-transformer-for-brute-force-arcs) The driver is an SLR driver using a full-bridge of CM400DU-12F IGBT's running off of 3-phase. To summarize, normally a transformer presents itself as an inductive load (because of the leakage inductance). Driving a purely inductive load is tough on the driver since it will switch at the peaks of the current waveform, leading to tremendous losses and excessive voltage overshoot.

Hard-switched sadness

To compensate for this, we put a capacitor in series with the inductor. If we switch at the resonant frequency of  the tank, the current and voltage will be exactly in phase and the driver will be happy:

Soft and almost happy

Now we see another problem - even completely unloaded, the transformer draws immense amounts of current (the above simulation shows the tank current increasing as the driver adds energy cycle after cycle). This would result in an uncontrolled ringup on the secondary side, not to mention high conduction losses in the driver.
In order to prevent this, we kill the ringing after a half-cycle.

SLR Happiness

In this case we still draw some reactive current. In this case the no-load current is given by V/sqrt(L/C). We can reduce this by increasing L, but magnetics are bulky, so the usual tradeoffs apply (losses vs. component size/power density).

Construction photos:

And here are the equations to make sure the transformer doesn't saturate:

P is the target transformer (peak) power, V_pri is the primary drive voltage, u_r is the relative permeability, B_max is the maximum permitted core field, A is the core cross-sectional area, and l_c is the core magnetic path length. N gives the minimum primary turns, l_g gives the minimum gap size.
These equations assume a square primary voltage waveform.

oneTesla

Update 11/7/2013: oneTesla has gained a life of its own and transcended to a new plane of existence! You can get a kit for one here.

oneTesla is a small DRSSTC with the entire driver (tank cap, voltage doubler, bridge, and logic) all on one PCB.
Tech specs:

• Inverter: half-bridge of FGH40N60SMDF IGBT's
• Tank capacitor: CDE940C30S68K-F, 0.068 uF@3KV
• Primary: 4.5 turns of 14 AWG on a 3.5" PVC former
• Secondary: 2.5x7", 36 AWG with a 2x7" topload. Resonant frequency is ~320KHz

200Apk, 270V bus, 40 uS ON@200BPS, 60VA out of the wall. Sparks are ~6" long

The interrupter lives in a separate box, and is coupled into the driver with coaxial cable. This works OK, though there are still some noise issues that cause the pulsewidth to fluctuate.

Schematic:

Get the Eagle board files [here] if you want to make one...its not quite perfectly reliable yet (in particular, it probably needs a optoisolated interrupter), but it does 6 or 7 inches at 100W fine.
If you're incredibly lazy, the DigiKey order for the most of the components (not the 40N60's), is [here]

Crappy phone video:

Random photos:

Board ready to etch

Primary current

Assembled board

Blindingly bright blue lights

Brickscooter Part II: Buscaps are good, I think

Brickscooter is a...thing...first documented here.
With two weeks to go before the due date (yes, that thing was homework), it was time to punt life, hide at MITERS, and build build build!
And so here's the saga of how I built, destroyed, rebuilt, redestroyed, repaired, and destroyed yet again, a 300A 3-phase motor controller. Oh, and there was a scooter attached to it too.

Day 1: Nothing exciting here, panic mode had yet to set in, so I finished machining my busbars.
Day 2: ...and, Digi-Key fails at 2-day shipping when I need it most. WHERE ARE MY GATE DRIVERS???
Day 3: Why hello there, gate drivers! The driver chip I'm used was the IR2183, a 2A bootstrapped half-bridge driver. After all that ranting about high performance gate drives, I'm using 2A to drive a brick. Fortunately, this is not too bad as the MOSFETs I was using have a gate charge of a few hundred nC. Turn-on times in the microsecond range are acceptable when the fastest I'd ever be PWM'ing is 10 KHz. The microcontroller I'm using is the Mbed, a 96 MHZ Cortex-M3 on a cute little board. It comes with a not-terribly-useful-but-still-acceptable online compiler, and, more importantly, has nice firmware that makes it easy to program (as well as being broken out into a DIP form factor).
After a moment of extreme derp when I realized my gate resistors were off by a factor of 4 (I'm used to 9A drivers), I had working drivers and a controller board etched and ready to go.
Day 4: I ♥ this document soooo much. It even gives you the commutation table! A little code later, I had a working motor controller. Well, it didn't work the first time, but after a bit of swapping of phases I had the motor turning, albeit without PWM. This lead into...Day 5: ...as I stayed up for 30+ hour trying to get the thing ready for the "official" vehicle checkoff time. Turns out machining after drinking a quart of Monster is hard. I ended up getting it running under its own power at out 9PM that night, but I deemed it too dangerous to take it for a maiden voyage (it still had no PWM), so I went to bed.
Day 6: More code resulted in a working PWM controller. Remarkably uneventful day here, nothing to see.
Day 7: I had a completed scooter! Or did I? One of the motor leads fell off during testing, resulting in a voltage spike that avalanched one of my MOSFETs and killed it. I replaced the FET, and it kind of worked.
The hard thing about debugging a 3-phase motor controller is that it has numerous failure modes, most of which do not result in the motor not turning. A lot of these failure modes are akin to the loss of phase, upon which the motor will continue to turn, but loudly and inefficiently. I replaced the other transistor from the failed phase, and all was well.
I actually rode brickscooter that night, but the throttle was real sketchy (seeing as it was a 10-turn trimpot).
Day 8: Hmm, I blew up the motor controller and I don't know why. Oh well, replace everything and try again. I realized I had serious belt slippage issues, so I attempted to redo the drivetrain, and mostly succeeded.
Day 9: Oh hi there, uninflated tire! Inflating the tire was harder than anticipated, especially since I had punctured the tube in multiple places from doing burnouts while it was uninflated. I disassembled the drivetrain and replaced the wheel. Unfortunately, I also bumped one of my non-circularly-symmetric standoffs, and shot through a phase of the controller. Replaced it, and spent the night trying to sort out the remainder of my drivetrain issues. While testing the drivetrain (and doing burnouts in the hallway), I did The Thing again, and bumped another standoff. Fixed that AGAIN, and this time, the controller failed for mysterious reasons. Replaced it again, and I went to bed with a working scooter.
Day 10: I had another weird failure, where the MOSFET would die with the gate failed dead short. I spent the night frantically trying to figure out why it was happening (I was running out of transistors at this point!). This had happened several times previously, and I had just shrugged it off.
Day 11: Found an error in the commutation table, which explained some of the failures. At this point, the bridge was probably half sketchy transistors, so I no longer dared to run it at full power before getting it checked off. Yes, sometimes I do care about grades...
Day 12: Got it checked off, and suddenly realized that the wire loop going from my batteries to the bridge probably had several microhenries of inductance. At 80A/uS dI/dt. that translated into perhaps a couple hundred volts of ringing, enough to break down the bricks. sigh the one time I don't use a giant buscap on the bridge, it bites me in the ass. I also concluded that too many brave transistors had given their lives in my quest to troll 2.007, so I stopped working on the scooter. Perhaps someday, in late June, I'll finish it, though that realistically means "sometime in the next two years I'll try to finish it".

And so ends the story of Brickscooter. Thirteen brave MOSFETs gave their lives, and the scooter still stands unfinished. The moral of the story? BUSCAP!!!