Yes, its live at last. You can find it here.
Let the coiling begin!
Friday, December 28, 2012
Sunday, December 9, 2012
SPUN TOROID
Turns out tuning your DRSSTC is a Good Thing.
Same pulse-widths as before, but the 8x2" (as opposed to 7x1.75") toroid, brings the coil into tune and gives much brighter sparks.
Some stills, captured from the above video:
Some stills, captured from the above video:
Saturday, September 29, 2012
Miscellaneous oneTesla fluff
Several people on the internet are attempting to replicate my work, so I guess I should make a consolidated blog post about oneTesla...
Firstly, random construction tips:
Firstly, random construction tips:
- Ground, ground, ground. It is absolutely essential that your secondary have a good ground; either a (good) mains ground, or a stake pounded several feet into the earth. Otherwise the driver (and other nearby electronics) will go berserk.
- Don't plug the thing into a GFI outlet.
- Don't get creative with the IGBT models; FGH60N60SMD's are currently $1.83 on Arrow, and are really the only transistors fast enough to comfortably drive a coil at 300KHz in musical duty.
- Keep your resonant frequency between 200 and 350KHz. Too low, and the tank capacitor will overvolt. Too high, and the inverter will suffer from excessive switching losses. Of course, you could always go lower and use an external tank cap.
- FOR THE LOVE OF TAYLOR SWIFT make sure the gate drive transformer is phased correctly; no amount of fuses will prevent your bridge from being destroyed if it shoots through with 50J in the bus capacitors.
- Use a variac if you have one.
Secondly, interrupters: there's a couple of Kramnik's MIDI interrupter boards floating around. If you would like to beta test it, drop me a message privately (preferably on 4HV, the project thread is here) and we'll work something out. The board file for the interrupter is [here]; contact me for the polyphonic code since it isn't quite ready for public consumption yet.
Next, there's a semi-comprehensive troubleshooting guide [here]; please use it and give me feedback!
Finally, oneTesla is going commercial! Expect a Kickstarter and a full kit available in a couple months at the latest; the kit will have everything you need to construct the coil and polyphonic interrupter, and hopefully will be cheap and beginner friendly. Coiling will be brought to the masses! Be afraid...
I'll end with a photo, courtesy of Gao Guangyuan ("loneoceans"):
I'll end with a photo, courtesy of Gao Guangyuan ("loneoceans"):
 |
| Serious business...also, GGY you're so good at taking coil photos! |
Friday, August 17, 2012
Saturday, August 11, 2012
The beginning of something wonderful...
...because anything with this many Tesla coils in it can't be bad, can it?
 |
| Eight mostly-populated oneTesla drivers |
Saturday, July 14, 2012
oneTesla update: Kramnik is magical
...because oneTesla was never supposed to be able to do this:
I believe that's something like a 2' ground strike off a 10" tall secondary.
All credit goes to Daniel Kramnik for figuring out to make the coil do that (something about less coupling, more current). FGH60N60SMD's are also pretty good - 300A and I've yet to see any damage.
 |
| 2' of spark! |
All credit goes to Daniel Kramnik for figuring out to make the coil do that (something about less coupling, more current). FGH60N60SMD's are also pretty good - 300A and I've yet to see any damage.
 |
| Long Exposure |
 |
| Ground Strike |
 |
| I <3 Ultrabright Green LED's |
Monday, June 25, 2012
oneTesla update (again)
Friday, June 8, 2012
oneTesla update
My friend Daniel Kramnik built a variant of this coil with an optocoupled interrupter that plays MIDI (as well as a re-routed controller) and it works great - on the high notes it does about 12" ground strikes at 140VA.
The optocoupling really helps - it stops the pulsewidth from jumping around, allowing for more reliable operation and better performance. The coil now uses FGH60N60SMD transistors, which cost a bit more than the old FGH40N60SMDF's I was using and are a bit slower, but seem to be just beefy enough for reliable 250A operation (which is what the peak current roughly is in the above video).
Wednesday, May 30, 2012
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.
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.
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:
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.
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.
 |
| 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 |
 |
| Soft and almost happy |
In order to prevent this, we kill the ringing after a half-cycle.
 |
| SLR Happiness |
Construction photos:
And here are the equations to make sure the transformer doesn't saturate:
These equations assume a square primary voltage waveform.
Saturday, May 26, 2012
oneTesla
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.
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]
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 |
Monday, May 14, 2012
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!!!
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!!!
Monday, April 2, 2012
Sunday, March 25, 2012
So I decided to build a scooter...
...and of course, it has bricks on it.
Behold, the monstrosity that is BrickScooter:
It's not finished yet (I have to hook up the drivetrain and, more importantly, build all the control electronics for the motor controller), but at least it's beginning to take shape.
The structural bits are made of machined aluminum plate, and the front fork is a stock Razor A3 steering column assembly (complete with stock wheel!). Motor is a Turnigy TR80-100-B motor, nominally rated for 6500W@130A, but actually good for quite a bit less in vehicle duty.
The bricks are mystery Semikron MOSFET modules. Because they were a custom run for GE, they have no public datasheets. Empirical testing says they are 110V, 2 mOhm, and given the usual brick dissipation of 1KW this puts them at 300A.
Why does it exist? I haven't a clue. I suppose motor controllers and scooters are very popular at MITERS, where I spend much of my time. And I like high power stuff, and bricks, and designing nice controllers for things (I'm intending for this to have sinusoidal output and current control).
Also, I fully intend to win the 2.007 drag race with this thing. A hundred amps and a full Melon should be hard to beat if I can get the mechanical stuff right.
Behold, the monstrosity that is BrickScooter:
 |
| Rear Shot |
 |
| Full View |
 |
| Oh Hai, Bricks! |
 |
| Water cooling |
The structural bits are made of machined aluminum plate, and the front fork is a stock Razor A3 steering column assembly (complete with stock wheel!). Motor is a Turnigy TR80-100-B motor, nominally rated for 6500W@130A, but actually good for quite a bit less in vehicle duty.
The bricks are mystery Semikron MOSFET modules. Because they were a custom run for GE, they have no public datasheets. Empirical testing says they are 110V, 2 mOhm, and given the usual brick dissipation of 1KW this puts them at 300A.
Why does it exist? I haven't a clue. I suppose motor controllers and scooters are very popular at MITERS, where I spend much of my time. And I like high power stuff, and bricks, and designing nice controllers for things (I'm intending for this to have sinusoidal output and current control).
Also, I fully intend to win the 2.007 drag race with this thing. A hundred amps and a full Melon should be hard to beat if I can get the mechanical stuff right.
Friday, March 23, 2012
SR2 part 2
...time for the hex cores! So I found these processors on Ebay...
Above CPU-Z screenshot says it all. A0 Xeons are remarkably good at overclocking; 1.3 Vcore and 4 GHz is nothing to sneeze at (many Gulftowns require 1.4V+ to achieve this). The lower stock Vcore (1.0V) helps too I suppose.
Unfortunately the board can no longer hold the highest Turbo multiplier, meaning Turbo is out of the question, as during boot, a 23x multiplier will kick in, causing a crash. And it is well-accepted that going over 200 BCLK on air on an SR-2 is seriously past the point of diminishing returns, so 4GHz is my board-limited overclock.
Unfortunately the board can no longer hold the highest Turbo multiplier, meaning Turbo is out of the question, as during boot, a 23x multiplier will kick in, causing a crash. And it is well-accepted that going over 200 BCLK on air on an SR-2 is seriously past the point of diminishing returns, so 4GHz is my board-limited overclock.
Wednesday, February 29, 2012
Fun with a SR-2
As with many of my shenanigans, this one started with "I found these processors on Ebay'', and became an interesting adventure.
After more staring at Ebay searching for a better motherboard, I gave in to my dark desires and ordered an EVGA SR-2, the undisputed god of enthusiast boards.
First attempt at overclocking was at 180 BCLK, 1.375 Vcore, 1.35 Vtt. This resulted in a system that crashed after about 2 minutes of stress-testing under LinX. Fortunately, further inspection revealed that Vdroop was dropping Vcore down to about 1.30V, enough to destabilize the processors. Turning off Vdroop let the system pass several hours of LinX on the "all memory" setting.
Sadly, the overclock caused anywhere from 2 GB to 10 GB of RAM to disappear. Both Windows and the BIOS failed to detect it. This is not unheard of - Core i7 systems have been known to drop channels of memory, often due to a mis-seated heatsink or a bent pin. Reseating the heatsink didn't help, and neither did loosening the timings (I had my 9-9-9-24 DDR3-1333 running at 11-11-11-27 DDR3-1066 and it still vanished). Upping Vtt to dangerous levels (1.55V) didn't help either.
I eventually gave up, chucked the awful OCZ Gold DDR3-1333 I had (it was only $3.50 a GB from Directron), and ordered 24 GB of G.Skill DDR3-1600 from Newegg. This mostly cured the problems - the system still drops a channel once every few reboots, but it was stable when it did detect the memory.
Or was it? After about 3 days of running Folding@Home -bigadv, I got a BSOD. Upping Vtt a little helped, but it still crashes around once a week, usually when ambient temps are high. The SR2 currently folds 24/7 at 1.41875 Vcore, 1.425 Vtt, 1.4V ICH, and 11-11-11-28 timings on the memory. Temperatures are in the mid 30's idle, mid 70's load. The RAM itself is actually good for quite a bit more, but the memory controllers can't handle it.
And finally, the obligatory screenshot:
The board is benchmark-stable at higher BCLK's and voltages - in fact, it holds the #3 on the 8-CPU wPrime benchmark at 4357 MHz.
Actually, this one started with "I found this motherboard on Ebay", an Intel S5520UR to be exact. Unfortunately, the motherboard was either dead or lacked the appropriate microcode for the D0 ES CPU's I had, because it got stuck in a boot loop and refused to POST.
 |
| Version 1, featuring a derpy Intel board |
 |
| Big box, little box...yes, I'm an EVGA fanboy |
The SR-2 is the spiritual successor to such greats as Skulltrail (Intel's OC'able dual-socket 771 board), the Asus L1N64-SLI WS (the only implementation of the AMD 4x4 "Quadfather" platform), the Asus PC-DL (somewhat overclockable dual P4 Xeon board), and the Abit BP6 (OC'able dual Celeron motherboard from the late 90's). With the possible exception of the BP6, all of the above boards had their issues - Skulltrail was unholy expensive and needed hot-running FB-DIMMs, Quadfather was slower than a single Core 2 Quad, and the PC-DL was plagued with overclocking bugs. The SR-2 is, in my opinion and that of many review sites, a perfect combination of implementation and timing. Unlike its predecessor Skulltrail, the SR-2 was released at a time when multithreaded software was already commonplace. The SR-2 also runs on Intel's first well-balanced multiprocessor platform - Nehalem eliminated the FSB bottleneck present in the Core-architecture Xeon platform.
You can read more about the SR-2 here. Guru3D documents an excellent benching run here, and it is (as of this writing) available from EVGA new for $550 or from B-Stock for $400.
Assembly and first boot was uneventful; CPU-Z showed a load speed of 3.06 GHz on the pair of Xeon X5560 processors I had installed, thanks to EVGA's out-of-spec implementation of Turbo Boost which could hold the turbo multi under full load on all four cores.
 |
| Boxen are sexier when naked |
First attempt at overclocking was at 180 BCLK, 1.375 Vcore, 1.35 Vtt. This resulted in a system that crashed after about 2 minutes of stress-testing under LinX. Fortunately, further inspection revealed that Vdroop was dropping Vcore down to about 1.30V, enough to destabilize the processors. Turning off Vdroop let the system pass several hours of LinX on the "all memory" setting.
Sadly, the overclock caused anywhere from 2 GB to 10 GB of RAM to disappear. Both Windows and the BIOS failed to detect it. This is not unheard of - Core i7 systems have been known to drop channels of memory, often due to a mis-seated heatsink or a bent pin. Reseating the heatsink didn't help, and neither did loosening the timings (I had my 9-9-9-24 DDR3-1333 running at 11-11-11-27 DDR3-1066 and it still vanished). Upping Vtt to dangerous levels (1.55V) didn't help either.
I eventually gave up, chucked the awful OCZ Gold DDR3-1333 I had (it was only $3.50 a GB from Directron), and ordered 24 GB of G.Skill DDR3-1600 from Newegg. This mostly cured the problems - the system still drops a channel once every few reboots, but it was stable when it did detect the memory.
Or was it? After about 3 days of running Folding@Home -bigadv, I got a BSOD. Upping Vtt a little helped, but it still crashes around once a week, usually when ambient temps are high. The SR2 currently folds 24/7 at 1.41875 Vcore, 1.425 Vtt, 1.4V ICH, and 11-11-11-28 timings on the memory. Temperatures are in the mid 30's idle, mid 70's load. The RAM itself is actually good for quite a bit more, but the memory controllers can't handle it.
And finally, the obligatory screenshot:
 |
| Why hello there, Taylor Swift |
Saturday, January 7, 2012
Hysteresis Control Simulations
Teravolt pointed out the existence of an excellent chip on 4HV - the LTC1041 is a complete bang-bang controller in a cute little 8-pin DIP package. It can only sample at 10KHz, but 10KHz should be plenty given we're trying to pass a 100Hz waveform through the modulator.
And happily, the chip is from Linear, which means LTSpice has a built-in model for it.
1/2 ohm load, near-zero deadband:
1/2 ohm load, 100 mV deadband. Notice the decreased switching frequency:
5 ohm load, small deadband. Now the change in the integrator formed by the output filter and load decreases the frequency:
The switching frequency depends on the load - the more we load the output, the faster the converter switches and the smaller the ripple becomes.
Inductor and capacitor currents (green is the capacitor current):
Same, but with smaller L. The output (red) is still acceptable, but now the capacitor ripple current is horrendous. The tradeoff between L and C essentially boils down to that - how much ripple can your capacitor tolerate? Smaller inductors are less lossy, but capacitors that can handle 100+ amps of ripple are bulky and expensive.
UPDATE: 4HV worked its magic as usual, and told me to put a feed-forward capacitor in parallel with the upper resistor of the divider. This worked very well, as it forces the controller to switch at higher frequencies.
LTSpice file is here if you want to play with it; Eagle symbol for the LTC1041 here.
Good morning! And, good night!
And happily, the chip is from Linear, which means LTSpice has a built-in model for it.
1/2 ohm load, near-zero deadband:
Inductor and capacitor currents (green is the capacitor current):
Same, but with smaller L. The output (red) is still acceptable, but now the capacitor ripple current is horrendous. The tradeoff between L and C essentially boils down to that - how much ripple can your capacitor tolerate? Smaller inductors are less lossy, but capacitors that can handle 100+ amps of ripple are bulky and expensive.
UPDATE: 4HV worked its magic as usual, and told me to put a feed-forward capacitor in parallel with the upper resistor of the divider. This worked very well, as it forces the controller to switch at higher frequencies.
LTSpice file is here if you want to play with it; Eagle symbol for the LTC1041 here.
Good morning! And, good night!
Subscribe to:
Posts (Atom)