Monday, December 31, 2012

DRSSTC Δt3: Driver Testing

To start with, the MITERS-originated oneTesla Kickstarter is now up (and already funded!), so you can now buy your very own musical Tesla coil kit. It's pretty amazing: up to 23" sparks from a 10" coil using regular old TO-X IGBTs. And the custom MIDI interrupter can play up to two MIDI notes at the same time.

Anyway, work has been progressing on my Dual-Resonant Solid-State Tesla Coil. I finished most of the mechanical construction in Δt1 and Δt2, so that mostly left soldering and testing of the driving electronics. The power electronics comprise a MOSFET H-bridge, using just one IRFP4668 and one APT100S20B Schottky diode per leg (with the option to add a second FET per leg for higher power). This, combined with 2000uF of electrolytic bus capacitor and the ACNW3190 optically-isolated gate drivers form the power board, which rests on a large heat sink directly below the coil.

I found 10ft of energy chain and bought 10ft of shielding from the last Swapfest for making a a long run of shielded cable to go from the power board to the signal board.

The cable has 15V power, ground, and four differential gate drive signals, each in a cable shielded with signal ground. The gate drive signals are relatively low-impedance, since they drive the opto gate drive LEDs. At least a few mA is required to change their state, so they should be relatively immune to EMI, compared to logic-level signals. However, it's still very, very necessary that the LED drive lines be tightly grouped and shielded. The outer shielding is connected to RF ground at the base of the coil, and is mostly there to protect against arc strikes on the cable assembly.

The whole thing coils up for clean storage.
On the signal end, a wootstick 2.0 running an STM32F103CBT6 at 72MHz provides the brains. I was finally able to get the ARM micro to run at full speed (72MHz in this case). Over a year ago when I was first venturing into sensorless motor control I ran into a mysterious problem that was limiting me to 56MHz. Turns out it was a flash memory access latency setting, explained on page 60 out of 1096 in The F-Ing Manual. In case anyone else is having the same problem (I doubt it, since almost everyone else uses the standard peripheral library), the missing line of code was just:

FLASH->ACR |= 2;

Anyway, having full 72MHz operation is nice because even though there isn't much processor-intensive control code, the frequencies and timing on the Tesla coil are much faster than those of the motor controller.

The switches and lights on the right side control and indicate various levels of arming the coil, including the 15V gate drive power supply, a precharge and a main relay, and the logic power supply. In order to isolate the microcontroller logic supply from the 15V gate drive supply, I use the DCR021205 that worked so well on my 3ph v3.1 motor controllers.

Next up, my favorite part: testing gate drivers! For starters, I set up one of the timers on the STM32 to put out a ~150kHz gate drive waveform. (Two complementary pairs, 180º out of phase with each other.)

Having confirmed, that the timers and outputs were working, I hooked up the 10-foot signal cable and did my best to scope the gate signals themselves. I switched back to the analog scope, because it's just not possible to get as clean a picture of the rise/fall on the crappy digital ones (yes, I am a scope hipster). I also made myself a hack low-inductance differential probe for measuring the high side gate signal:

Since I chose all the gate resistor values with two FETs in parallel, the gate drive on a single FET was a little faster than I would have wanted. (Switching too fast causes major di/dt and dv/dt transients as the frequency content of the switching waveform starts to excite the parasitics of the gate drive and MOSFET.) So, to slow things down just a little bit, I added a bit more external resistance to the output of the gate drivers:

I swear this was the best way to do this...
With a total external gate resistance of about 8Ω, here's the low side turn-off and high side turn-on with no voltage on the bus:

The rise/fall times are ~100ns and the deadtime is about 377ns, using 220-ohm / 1.5nF on the deadtime generating circuit. With bus voltage, the turn-on and turn-off will be longer due to the Miller plateau, but it should still be well shorter than the deadtime. At 150kHz, two 377ns deadtimes accounts for about 11% of the PWM cycle. This would be a bit long for motor controller operation, but it's okay for the Tesla coil driver, which will spend most of it's on-time operation at or near 50% anyway.

As usual, I built a Visual Basic GUI to control the whole thing:

It sets the drive frequency of the resonant circuit (for tuning to the resonant frequency), as well as the duty cycle profile over a finite number of cycles that make up a single "pulse" sent to the primary. The duty cycle for each cycle can be ramped up to some maximum value, held, and then ramped down. The GUI also sets the frequency at which the pulses are generated, which is what will ultimately be used to play MIDI notes. Here's a quick video showing the GUI tuning process with just the primary:

You can seem me playing with the pulse lengths, as well as the drive frequency and some other parameters. A single pulse on the primary with no secondary present looks like this:

The current on the primary (measured using a current transformer) rings up to some maximum value quickly as the square wave voltage excites the resonant circuit. (The current itself is mostly sinusoidal.) Then, after the drive pulse ends, the energy in the primary is slowly dissipated in its resistance. With a secondary in place, energy would be coupled into the secondary coil and the primary current would look a lot different. But for testing purposes, using the primary alone at low voltage allows me to actually scope things.

The first thing to check is the primary resonant frequency. From the design, I was targeting something in the range of 135-150kHz. Tapping the real-life primary coil at approximately 6 turns gave me a resonant frequency of 154.5kHz, measured by sweeping the drive frequency around to find the maximum ring-up. This gives a primary inductance at 6 turns of 10.6μH, since the primary capacitance was easily measured to be almost exactly 100nF. So, I'll probably have to move the tap out a little to get it in tune with the secondary. (The target frequencies for best coupling were 151kHz and 136kHz.)

Next, I wanted to use the decay time to estimate the real-life primary resistance. I could probably have just put in the peak values as initial conditions in a SPICE simulation of just the primary LRC resonant circuit. But, since I have a full SPICE simulation of the driver already, I decided to make things more complicated by having my VB GUI export gate drive waveforms to the SPICE sim, which would simulate the entire pulse sequence. I then tweaked the resistance value until the decay envelope on the SPICE sim matched up exactly with the one on the scope:

The magic number in this case was about 90mΩ, which seems accurate given that the skin depth on my 8AWG grounding wire is probably making it act more like 14AWG wire. But anyway, I now have a more precise simulation of the exact pulse sequence, including ramping and duty cycle control. This should be useful when it comes time to ramp up the power.

Speaking of which, I discovered the USB limit for this power system. As is also the case on many of my motor controllers, USB communication and high power simply don't mix and above a certain current (40A in this case) the GUI starts to get comm. errors. Typically, the micro and all the logic circuity can continue to operate without any issues - it's just a problem with the serial communication. Since I suspected this might be an issue, the plan is to use an XBee link to between my laptop and the logic board, the same trick I use to get data off of motor controllers while they're running. It may seem like running an RF link instead of a wired connection would be a bad idea in a Tesla coil environment, but I've been down this decision path before and the XBee always seems to win...

Next step: ramping up the power, tuning, and hopefully generating the first sparks!

Wednesday, December 12, 2012 Space!

This might seem like a radical departure from the normal content of my blog, but I assure you that by the end of the post you will see that it is not. But yes, for I think the very first time I am going to post about a computer game! I'm not much of a gamer: the only game for which I ever achieved "fan" status was Gran Turismo, an epic racing game that frustrates most players because of the hyper-realistic physics engine.

Now I think I have achieved fan status for a new game: Kerbal Space Program, an epic space game that frustrates most players because of the hyper-realistic physics engine.

The Kerbals are a race of tiny green men who choose to go to the moon and do other things, not because it is easy, and not because it is hard, but because they seemingly have nothing better to do with their time and no monetary constraints or self-preservation instincts to keep them tied to the ground on their home planet, Kerbin.

"This will certainly go somewhere when we press the launch button."
The game has been under development for two years and is still pre-release. I was introduced to it by my brother back when there was only Kerbin and one moon. There is now a free version (v0.13.3) and a paid version (v0.18.1 at the time of writing). The paid version includes a vast solar system, more parts, and more features such as EVA (spacewalking) and docking. The real benefit of the paid version is that it gets you access to any and all future updates including the release version.

Thus far the pre-release versions have been true "open-world" games...except even that concept ceases to capture the nature of the game when there are six worlds and many moons to explore. While future versions will likely have "career" modes with a set of missions and a budget, the game right now has no concept of money or points. You build a spacecraft out of a set of parts, and then fly it to wherever you want.

Including, if you want, the top of the vehicle assembly building.
The parts inventory is made more entertaining by the descriptions of what each part does, which reflect the essential character of the Kerbals to some extent:
"The TR-18A Stack Decoupler is equipped with a (hopefully) small explosive charge, that will sever the structural linkage between itself and whatever it's connected to."
 "A monster of an engine for heavy lifting purposes, the Mainsail's power rivals that of entire small nations."
Also, parts are not limited to spacecraft: newer versions of the game include jet engines and aircraft parts, as well as a horizontal runway for commencing normal flight:

But although the sandbox aspect and the snap-together rockets and relatively humorous Kerbals make the game seem like it would be a good iPad app to kill time on the bus, the real nature and challenge of the game comes from the physics engine, which is based on real orbital mechanics in the Kerbol System, where planets are generally smaller but denser than those of the actual solar system. (Kerbin has the same surface gravity, 9.81m/s², as Earth, but is only 600km in radius.)

The first thing KSP teaches you is just how damn hard it actually is to get something into orbit. Getting into orbit is not the same as getting into space. A balloon can get into space (almost). To get into orbit, you have to both get out of the atmosphere and build up enough horizontal velocity so that you no longer need to spend fuel to fight gravity. (You fall as fast as the planet curves away from you.) For low Kerbin orbit, this requires a speed of about 2,000m/s.

But because you're fighting gravity and aerodynamic drag on the way up, the actual amount of propulsion needed is much higher than would be required to go from 0 to 2km/s in space. In fact, the actual speed increase (ΔV) you would be able to achieve in space using the amount of fuel required to launch into low Kerbin orbit is something like 4.5km/s. To put any sizable payload, like a ship that can go to the moon (called Mun in the game) and back, into orbit requires a pretty large rocket.

Note the speed is still well below orbital velocity.
So the next thing the game teaches you is what spacecraft are mostly made of: fuel. The rocket equation tells you that the ΔV you can achieve with a particular rocket is limited by only two things: how fast the exhaust is, which is a property of the engine, and what fraction of the rocket's mass gets thrown out the back. Only the ratio of starting to ending mass matters, so a small rocket or a large rocket can get into orbit equally well if they have the same engine and are both 70% made of fuel. The only reason to use a larger rocket is so you can put more final mass into orbit.

The realistic physics lead you to create multistage rockets. Once on stage's fuel is used up, you detach it to get rid of the dead weight (thereby increasing the percentage of the remaining mass that is fuel). There are also trade-offs among different engines: some have higher exhaust velocity but too low of a burn rate to produce enough thrust to get into orbit. These are better for maneuvering in space. So you wind up having to think carefully about the design of the spacecraft if you want to go farther.

For example, you can go to Duna, the Kerbol System equivalent of Mars.
Another cool feature just recently added to the game is docking. If you think aiming for a small moon is hard, try aiming for another ship which has no gravitational attraction with which to pull you in when you get close enough. Maneuvering two ships in orbit to the point where they could be docked was by far the hardest thing I've had to do in the game so far. But the reward is an almost unlimited ability to build larger ships or refuel in space.

The game does not (yet) have an autopilot that will help you launch, land, dock, transfer orbits, etc. But it does have a nifty maneuver planner that will show you the anticipated result of a maneuver at some point in your orbit. It will show you which way to point your ship and give you a countdown of how long to burn your engines to get where you want to go. But you still control the pointing and burning, so it's still a bit hard to do really precise long-range orbital maneuvers. For example, it's possible to do single slingshots but something like a Voyager trip would be very hard to do without a more advanced planning and autopilot system.

So far, I have been able to make successful trips to the Mun and return. I also made a one-way trip to Duna, which was punctuated by a harrowing untested parachute descent which barely cleared a crater wall.

Clearing the crater wall by about 1km while still going 0.5km/s...
Looking out from the crater rim to the landing site.
My current spacecraft, designed from scratch for interplanetary travel in v0.18.1, looks like this:

Stage 1 is driven by four Mainsail engines, the largest in the game, and burns for the first ~75 seconds of the launch. Stage 2 has a single Mainsail engine and burns for another ~85 seconds. These two massive stages are able to produce a total ΔV of 3.39km/s (Yes, I calculated it. As an interesting comparison, the ΔV possible from the two stages combined into one, with five engines all burning, is about 2.92km/s.) While quite heroic given the massive payload, this is not enough to get into low Kerbin orbit, so Stage 3 has to do some work on the way up.

Stages 3 and 4 combined are the interplanetary portion of the ship, designed for taking three Kerbals to the far reaches of the Kerbol System, and maybe sometimes back.

Stage 3 uses four of the "atomic" engines (strange name since they run on normal liquid fuel...) which are the most efficient stock engine (highest exhaust velocity). But they have relatively low thrust, so they're not great for getting off the planet. They work best for long burns to perform transfer orbits. Stage 4 is the lander itself, which uses the "Poodle" engine. This engine has enough thrust to get off a small planet or moon. You can see it landed on the Mun in the first image of the post.

Stage 3 and 4 can produce a whopping 5.67km/s total ΔV. That should be plenty to go to most destinations and back from some. I think it can do a landing and return from Mun, Minimum, or Duna, although the latter two are untested. A Duna return in particular would be hard due to the uncertain amount of fuel required to land on and take off from Duna. (Minimus requires very little fuel for this since it's tiny and has no atmosphere.) Other planets are either too massive or too far (or both) for a landing and return trip, I think. But flybys and one-way trips to almost anywhere should be possible.

But, Stage 3 consumes about half its fuel just to get into Kerbin orbit. That's why I was so excited to try out the docking feature. Now I can combine two ships in Kerbin orbit and transfer full fuel to one of them. I can even use most of the remaining fuel in the second ship to boost the whole assembly out into deep orbit, a trick that should bump the whole mission's ΔV starting from low Kerbin Orbit to something like 6.52km/s. That amount of fuel should provide plenty of deep space maneuvering ability for going to check out places like Laythe, a potentially habitable moon of Jool (Kerbol Jupiter)...

So many possibilities.
And now I feel the need to apologize for any number of person-hours of productivity this post will cause to be lost forever into deep space.