Welcome
Username or Email:

Password:


Missing Code




[ ]
[ ]
Online
  • Guests: 47
  • Members: 0
  • Newest Member: omjtest
  • Most ever online: 396
    Guests: 396, Members: 0 on 12 Jan : 12:51
Members Birthdays:
No birthdays today

Next birthdays
04/28 Steve Conner (46)
04/29 GODSFUSION (37)
04/29 Zajcek (37)
Contact
If you need assistance, please send an email to forum at 4hv dot org. To ensure your email is not marked as spam, please include the phrase "4hv help" in the subject line. You can also find assistance via IRC, at irc.shadowworld.net, room #hvcomm.
Support 4hv.org!
Donate:
4hv.org is hosted on a dedicated server. Unfortunately, this server costs and we rely on the help of site members to keep 4hv.org running. Please consider donating. We will place your name on the thanks list and you'll be helping to keep 4hv.org alive and free for everyone. Members whose names appear in red bold have donated recently. Green bold denotes those who have recently donated to keep the server carbon neutral.


Special Thanks To:
  • Aaron Holmes
  • Aaron Wheeler
  • Adam Horden
  • Alan Scrimgeour
  • Andre
  • Andrew Haynes
  • Anonymous000
  • asabase
  • Austin Weil
  • barney
  • Barry
  • Bert Hickman
  • Bill Kukowski
  • Blitzorn
  • Brandon Paradelas
  • Bruce Bowling
  • BubeeMike
  • Byong Park
  • Cesiumsponge
  • Chris F.
  • Chris Hooper
  • Corey Worthington
  • Derek Woodroffe
  • Dalus
  • Dan Strother
  • Daniel Davis
  • Daniel Uhrenholt
  • datasheetarchive
  • Dave Billington
  • Dave Marshall
  • David F.
  • Dennis Rogers
  • drelectrix
  • Dr. John Gudenas
  • Dr. Spark
  • E.TexasTesla
  • eastvoltresearch
  • Eirik Taylor
  • Erik Dyakov
  • Erlend^SE
  • Finn Hammer
  • Firebug24k
  • GalliumMan
  • Gary Peterson
  • George Slade
  • GhostNull
  • Gordon Mcknight
  • Graham Armitage
  • Grant
  • GreySoul
  • Henry H
  • IamSmooth
  • In memory of Leo Powning
  • Jacob Cash
  • James Howells
  • James Pawson
  • Jeff Greenfield
  • Jeff Thomas
  • Jesse Frost
  • Jim Mitchell
  • jlr134
  • Joe Mastroianni
  • John Forcina
  • John Oberg
  • John Willcutt
  • Jon Newcomb
  • klugesmith
  • Leslie Wright
  • Lutz Hoffman
  • Mads Barnkob
  • Martin King
  • Mats Karlsson
  • Matt Gibson
  • Matthew Guidry
  • mbd
  • Michael D'Angelo
  • Mikkel
  • mileswaldron
  • mister_rf
  • Neil Foster
  • Nick de Smith
  • Nick Soroka
  • nicklenorp
  • Nik
  • Norman Stanley
  • Patrick Coleman
  • Paul Brodie
  • Paul Jordan
  • Paul Montgomery
  • Ped
  • Peter Krogen
  • Peter Terren
  • PhilGood
  • Richard Feldman
  • Robert Bush
  • Royce Bailey
  • Scott Fusare
  • Scott Newman
  • smiffy
  • Stella
  • Steven Busic
  • Steve Conner
  • Steve Jones
  • Steve Ward
  • Sulaiman
  • Thomas Coyle
  • Thomas A. Wallace
  • Thomas W
  • Timo
  • Torch
  • Ulf Jonsson
  • vasil
  • Vaxian
  • vladi mazzilli
  • wastehl
  • Weston
  • William Kim
  • William N.
  • William Stehl
  • Wesley Venis
The aforementioned have contributed financially to the continuing triumph of 4hv.org. They are deserving of my most heartfelt thanks.
Forums
4hv.org :: Forums :: Tesla Coils
« Previous topic | Next topic »   

Would this be a viable controller?

1 2 3 
Move Thread LAN_403
StormInABottle
Wed Jul 30 2014, 11:36AM Print
StormInABottle Registered Member #9252 Joined: Fri Jan 04 2013, 06:27AM
Location: Andromeda
Posts: 253
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?
Back to top
Sigurthr
Thu Jul 31 2014, 12:46AM
Sigurthr Registered Member #4463 Joined: Wed Apr 18 2012, 08:08AM
Location: MI's Upper Peninsula
Posts: 597
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.
Back to top
StormInABottle
Thu Jul 31 2014, 01:53AM
StormInABottle Registered Member #9252 Joined: Fri Jan 04 2013, 06:27AM
Location: Andromeda
Posts: 253
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 ?
Back to top
Sigurthr
Thu Jul 31 2014, 02:48AM
Sigurthr Registered Member #4463 Joined: Wed Apr 18 2012, 08:08AM
Location: MI's Upper Peninsula
Posts: 597
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.
Back to top
StormInABottle
Thu Jul 31 2014, 05:25AM
StormInABottle Registered Member #9252 Joined: Fri Jan 04 2013, 06:27AM
Location: Andromeda
Posts: 253
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.

Back to top
Sigurthr
Thu Jul 31 2014, 06:21AM
Sigurthr Registered Member #4463 Joined: Wed Apr 18 2012, 08:08AM
Location: MI's Upper Peninsula
Posts: 597
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).
Back to top
StormInABottle
Thu Jul 31 2014, 06:55AM
StormInABottle Registered Member #9252 Joined: Fri Jan 04 2013, 06:27AM
Location: Andromeda
Posts: 253
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..
Back to top
Steve Conner
Thu Jul 31 2014, 07:12AM
Steve Conner Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
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.
Back to top
StormInABottle
Thu Jul 31 2014, 07:49AM
StormInABottle Registered Member #9252 Joined: Fri Jan 04 2013, 06:27AM
Location: Andromeda
Posts: 253
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
Back to top
Steve Conner
Thu Jul 31 2014, 01:40PM
Steve Conner Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
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.
Back to top
1 2 3 

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

Go to:

Powered by e107 Forum System
 
Legal Information
This site is powered by e107, which is released under the GNU GPL License. All work on this site, except where otherwise noted, is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. By submitting any information to this site, you agree that anything submitted will be so licensed. Please read our Disclaimer and Policies page for information on your rights and responsibilities regarding this site.