Would this be a viable controller?

StormInABottle, Wed Jul 30 2014, 11:36AM

Hello, I have been thinking of replacing the typical SSTC/DRSSTC controller with an arduino board, Like the UNO or the Mega 2560, Would one of those programmed to give a pulsed signal that's the exact resonant frequency of a specific coil work as a viable controller? I am pretty sure you would need some Mosfets to amplify the output if you want to switch IGBTs, I am also sure you can set duty cycle and also play music
Is that viable?
Re: Would this be a viable controller?
Sigurthr, Thu Jul 31 2014, 12:46AM

Due to the way the uC functions and its lack of a RTC it cannot provide a stable enough stream of pulses for direct driving a TC. Likewise, you can't even precisely time any pulses shorter than 1mS or so. You start seeing delays not accounted for in code from the instruction execution time that muck everything up. There are a few libraries out there that user timer.1 built in timer chip but you're restricted to fractions of the 16MHz oscillator up to 1MHz in roughly 100KHz steps.
Re: Would this be a viable controller?
StormInABottle, Thu Jul 31 2014, 01:53AM

Sigurthr wrote ...

Due to the way the uC functions and its lack of a RTC it cannot provide a stable enough stream of pulses for direct driving a TC. Likewise, you can't even precisely time any pulses shorter than 1mS or so. You start seeing delays not accounted for in code from the instruction execution time that muck everything up. There are a few libraries out there that user timer.1 built in timer chip but you're restricted to fractions of the 16MHz oscillator up to 1MHz in roughly 100KHz steps.
For example, For 56Khz
Using timer 1, You can set the prescale to 1 and just set the compare match to 142
Are you saying that using Timer 1 will give more reliable results ?
Re: Would this be a viable controller?
Sigurthr, Thu Jul 31 2014, 02:48AM

It's more reliable but it isn't nearly reliable enough for TC operation. You're going to get hard switching and missed/extended pulses in the pulse train. I tried it once with a simple SSTC at around 300KHz and the bridge output looked horrid because a SSTC bridge does not tolerate running on the capacitive side well at all (below resonance). I wouldn't try it on a DR coil ever. Maybe at 56KHz there won't be as many errors in the pulse train, but my experiments didn't show it to be promising enough to try.

Also, you can't account for the dynamic load that the streamers present on the secondary and their detuning effect. This isn't a huge issue, I've run SSTCs off of a VCO before, and in some applications it is actually better than real feedback as output power fizzles out to nothing in case an on-looker comes too close and tries to touch the output. In terms of performance though it can't compare to feedback.
Re: Would this be a viable controller?
StormInABottle, Thu Jul 31 2014, 05:25AM

Hmmm, It should be noted that the arudino i have is the Mega 2560, So i have a couple more 16 Bit timers, Timer 3, 4 and 5 in addition to Timer 0, 1 and 2
I think there should be a way to make the signal more reliable.
Maybe have 2 timers running at the same frequency and then they are " Checked " against each other providing a cleaner, More reliable signal?
If 1 timer makes 5 mistakes in 5 places, The other makes 5 different mistakes in 5 different places, Checking them against each other should result in a more reliable signal.

Re: Would this be a viable controller?
Sigurthr, Thu Jul 31 2014, 06:21AM

Sounds like it is worth a try. I only have an UNO so it was already beyond it's capabilities (I'm sure I didn't write the most economical code).
Re: Would this be a viable controller?
StormInABottle, Thu Jul 31 2014, 06:55AM

Sigurthr wrote ...

Sounds like it is worth a try. I only have an UNO so it was already beyond it's capabilities (I'm sure I didn't write the most economical code).
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..
Re: Would this be a viable controller?
Steve Conner, Thu Jul 31 2014, 07:12AM

I've seen a uC based driver that works in just this way, and it was successful, however it is a serious real-time programming challenge. A DRSSTC burst lasts about 200 microseconds and within that time frame you have maybe 20 switching instants that you have to get right to within maybe 1-2us. And, you are aiming for a moving target, the resonant frequency of the coil changes during the burst as the streamer develops.

The driver I saw used a Cypress programmable system-on-chip (PSoC) and many of the timing functions were accelerated by custom hardware.
Re: Would this be a viable controller?
StormInABottle, Thu Jul 31 2014, 07:49AM

Steve Conner wrote ...

I've seen a uC based driver that works in just this way, and it was successful, however it is a serious real-time programming challenge. A DRSSTC burst lasts about 200 microseconds and within that time frame you have maybe 20 switching instants that you have to get right to within maybe 1-2us. And, you are aiming for a moving target, the resonant frequency of the coil changes during the burst as the streamer develops.

The driver I saw used a Cypress programmable system-on-chip (PSoC) and many of the timing functions were accelerated by custom hardware.
I would mainly be aiming for a continuous operation on a regular SSTC, A fiery thick arc is more interesting than interrupted DRSSTCs to me
Re: Would this be a viable controller?
Steve Conner, Thu Jul 31 2014, 01:40PM

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.
Re: Would this be a viable controller?
StormInABottle, Thu Jul 31 2014, 06:23PM

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 smile
Re: Would this be a viable controller?
Sigurthr, Thu Jul 31 2014, 11:49PM

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.
Re: Would this be a viable controller?
StormInABottle, Fri Aug 01 2014, 01:27AM

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.
Re: Would this be a viable controller?
Sigurthr, Fri Aug 01 2014, 03:48AM

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!
Re: Would this be a viable controller?
StormInABottle, Fri Aug 01 2014, 03:55AM

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
Re: Would this be a viable controller?
Sigurthr, Fri Aug 01 2014, 05:05AM

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.
Re: Would this be a viable controller?
Steve Conner, Fri Aug 01 2014, 09:08AM

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. smile
Re: Would this be a viable controller?
Ash Small, Fri Aug 01 2014, 10:32AM

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. wink
Re: Would this be a viable controller?
Linas, Fri Aug 01 2014, 12:46PM

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)

Re: Would this be a viable controller?
Steve Conner, Fri Aug 01 2014, 06:31PM

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.
Re: Would this be a viable controller?
StormInABottle, Fri Aug 01 2014, 10:41PM

Sigurthr wrote ...

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 wrote ...

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. smile

Ash Small wrote ...

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. wink


Noted, This should be a fairly interesting little project to try, I don't think coding an arduino can include an electrocution hazard or a mosfet-bullet-blowing-in-your-face hazard, Thanks for all the input :)


Linas wrote ...

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

Maybe sone 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)



The video shows as "This video has been removed by the user" :(


Re: Would this be a viable controller?
Antonio, Sat Aug 02 2014, 12:50PM

Some time ago I started a project for a drsstc controller using a PIC. The required functions could be easily programmed, but soon I hit the problem of lack of resolution in the high-frequency drive and did not proceed. I imagined solutions as skipping or adding clock cycles dynamically to keep reasonable precision, and even a method to make the PIC adjust the frequency of its own clock, but didn't experiment with them.