Would this be a viable controller? / Tesla Coils / Forums

Forums

4hv.org :: Forums :: Tesla Coils

« Previous topic | Next topic »

Would this be a viable controller?

previous 1 2 3 next

Move Thread

LAN_403

StormInABottle

Thu Jul 31 2014, 06:23PM

Registered Member #9252 Joined: Fri Jan 04 2013, 06:27AM
Location: Andromeda
Posts: 253

Steve Conner wrote ...

In that case, the control problem is much easier. No need to worry about missing the zero current switching points as an untuned primary SSTC doesn't have zero current switching to begin with. The Arduino would probably work out fine.

That's fantastic to hear

Sigurthr

Thu Jul 31 2014, 11:49PM

Registered Member #4463 Joined: Wed Apr 18 2012, 08:08AM
Location: MI's Upper Peninsula
Posts: 597

The only issue will be ensuring the drive frequency doesn't droop below secondary resonance. I'm never much good at visualizing current commutations in bridges but I do know that every bridge I've ever built absolutely hates being run in the capacitive region. You can drive it above resonance as much as you like (with diminishing power transfer), but dip a bit below resonance and you're likely to blow some silicon if you don't bulletproof the bridge.

StormInABottle

Fri Aug 01 2014, 01:27AM

Registered Member #9252 Joined: Fri Jan 04 2013, 06:27AM
Location: Andromeda
Posts: 253

Sigurthr wrote ...

The only issue will be ensuring the drive frequency doesn't droop below secondary resonance. I'm never much good at visualizing current commutations in bridges but I do know that every bridge I've ever built absolutely hates being run in the capacitive region. You can drive it above resonance as much as you like (with diminishing power transfer), but dip a bit below resonance and you're likely to blow some silicon if you don't bulletproof the bridge.

Well, I do believe the frequency would stay at resonance if i utilize my idea

" Maybe also, Just maybe, We can make it auto tuning by setting the compare match to a variable, Said variable changes according to feedback from an antenna/bottom of resonator
Maybe.. "

If what i read steve ward's site correctly, The coil is always in tune if it runs from it's own noise.

Sigurthr

Fri Aug 01 2014, 03:48AM

Registered Member #4463 Joined: Wed Apr 18 2012, 08:08AM
Location: MI's Upper Peninsula
Posts: 597

Yes, but missed pulses from instruction execution will lower the actual output frequency. How much it lowers it is anyone's guess at this point. If you're missing 1% of pulses at 100KHz you're 10KHz under resonance, and from my tests with a direct VCO driven coil, 10KHz is more than enough to make a bridge very unhappy. That's 1%, if you're 2.5% out that's 25KHz.. miles away!

StormInABottle

Fri Aug 01 2014, 03:55AM

Registered Member #9252 Joined: Fri Jan 04 2013, 06:27AM
Location: Andromeda
Posts: 253

Hmm, I doubt that there would be any missing pulses if we compare the signals to each other
By the way, During your tests, Was everything shielded from the EM field?

Also i do not quite understand how the arduino can skip/extend pulses, I believe the pulses are as accurate as the 16 Mhz crystal on the arduino, Also as long as the auto tuning system is functioning, We should technically never get on the capacitive side

Sigurthr

Fri Aug 01 2014, 05:05AM

Registered Member #4463 Joined: Wed Apr 18 2012, 08:08AM
Location: MI's Upper Peninsula
Posts: 597

Yep, it was shielded.

At first I didn't hand write a program for the tests, as it was a quick look into the viability, and I'm not very experienced with arduino's lower level programming side. Basically I used a simple sketch that had you enter in a frequency via serial monitor and it would configure timer.1 to output pulses at the chosen frequency. I compared the output via scope and digital frequency counter. Ar 1MHz it was rather accurate, something like 999,400Hz. At 280KHz it was off by about 30KHz, somewhere around 250KHz. At 100KHz it was pretty accurate again. At direct fractions accuracy was good, at more distant fractions errors were introduced.

My initial impression was that it was something to do with the programming so I went and used a simple fixed variable and as little code as possible to see try and eliminate programming error. I hard coded in 10uS on and 10uS off, but still used digitalWrite functions. The result was ~37KHz. Clearly digitalWrite execution time was a problem. I looked into directly writing the IO registers but didn't give it a try, as at this point it was already proving to be too much hassle.

So, that's why I keep bringing up instruction execution delays. I literally had nothing other than standard setup, variable initialization, and two digitalWrite commands with variable calls and I couldn't get it to keep up. Assuming you write highly efficient code for timer.1 and the control loop, directly write to registers to avoid digitalWrite, and avoid any other high level instruction functions you may get something workable, but I don't know if you'll be able to set it to 50KHz and actually get 50KHz out. You might have to set it to 70KHz and get 51KHz out and call it good enough.

Steve Conner

Fri Aug 01 2014, 09:08AM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

You will need to do as much of the work as you can in the timer hardware to avoid issues like this. You also need to check that the timer you're using has enough resolution to generate an accurate frequency. The Arduino libraries do a great job of abstracting away differences in the hardware, but by the same token they also do a great job of hiding its limitations. Read the microcontroller datasheet very carefully.

I think the problem described by Sigurthr is really two separate problems. The first one was limited resolution of a hardware timer, the second was instruction execution delays.

If I had to build something like this tomorrow, I would use a 4046 PLL chip, a PIC, and a CPLD.

Ash Small

Fri Aug 01 2014, 10:32AM

Registered Member #3414 Joined: Sun Nov 14 2010, 05:05PM
Location: UK
Posts: 4245

I'm not familiar with the Arduino myself, but you will want to avoid any high level programming, as this does introduce significant dalays.

I used to write stuff in machine code years ago, which avoids all of the problems with high level language, as well as low level assembler stuff.

Typing in all those ones and zeros is pretty time consuming, though, especially if you make a mistake.

Linas

Fri Aug 01 2014, 12:46PM

Registered Member #1143 Joined: Sun Nov 25 2007, 04:55PM
Location: Vilnius, Lithuania
Posts: 721

PSoC5LP does have FPGA like analog and digital capability, aka hardware processing as well as Cortex M3 core for more advanced stuff.

Maybe some one would try to do something with it ?

if not, go to STM32F429, it can run at 200MHz, at his point you can do loops with 20ns precision ( GPIO toggle will go up to 100MHz)

Steve Conner

Fri Aug 01 2014, 06:31PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

As I said above, the resonant frequency of the coil changes during the burst, so it is not possible to achieve ZCS by just putting out a fixed frequency that you determined beforehand.

The method you described is more or less how I tune my PLL drivers by hand, but the frequency determined in this way is just a starting point, the driver will vary it during the course of the burst as it tries to maintain ZCS.

Finally, remember that a DRSSTC has two resonant frequencies, at least to start out with. Under exceptionally heavy streamer loading, or ground arcs, it collapses to a single frequency.

previous 1 2 3 next

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob