Welcome
Username or Email:

Password:


Missing Code




[ ]
[ ]
Online
  • Guests: 32
  • 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
05/27 Daniel Davis (54)
05/29 Zonalklism (34)
05/29 Dr Hankenstein (68)
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 :: Projects
« Previous topic | Next topic »   

Odin The All-Fragger: a large DRSSTC

Move Thread LAN_403
Steve Conner
Sun Jun 01 2014, 03:23PM
Steve Conner Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
Your idea might well work as most IGBTs are short circuit rated for 10us, which isn't that far off one cycle. I could never be bothered implementing desaturation detection though. The main problem is that we use the devices at much higher frequencies than they were intended for, so the di/dt voltages across the package inductance get high enough to fool the usual desat circuits.

Also, the most likely cause of desaturation is that the opposite bridge leg has just failed short. When using half-bridge modules, you have to throw the whole module away at this point anyway, so it's not worth the bother stopping the failure from cascading. With large single devices like the CM600, it might be worthwhile.

The cycle skipping current limit is nice, but it's skipping somewhat more cycles than I'd have liked. :< Maybe the primary needs to be higher impedance still. Will be interesting to see what happens when the OCD is turned up after next Friday.
Back to top
Uspring
Mon Jun 02 2014, 09:14AM
Uspring Registered Member #3988 Joined: Thu Jul 07 2011, 03:25PM
Location:
Posts: 711
The cycle skipping current limit is nice, but it's skipping somewhat more cycles than I'd have liked. :< Maybe the primary needs to be higher impedance still. Will be interesting to see what happens when the OCD is turned up after next Friday.
I was thinking along the same line. Where is loaded Q at now? Did you observe any frequency jumps?
Back to top
Steve Conner
Mon Jun 02 2014, 09:28AM
Steve Conner Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
I think the loaded Q is around 6.

The PLL can't track an instantaneous jump, and I didn't notice any extreme hard switching, so I don't think there were any frequency jumps. As the loading increases, the frequency probably collapses from the upper pole to somewhere around the middle of the passband.

I wonder if performing a STFT of the primary current waveform would shed any light on this? Is there any way to "deconvolve" the frequency spectrum of the driving voltage from the current, to get the impulse response of the resonator at a given point in time?
Back to top
Uspring
Mon Jun 02 2014, 11:21AM
Uspring Registered Member #3988 Joined: Thu Jul 07 2011, 03:25PM
Location:
Posts: 711
As long as there is no hard switching, the input to the VFO should be a good indicator of zcs frequency. Running the coil at some lower Vbus to avoid pulse skipping might also help analysis. Dunno if a STFT would help. There's always a delay between primary current and the secondaries response to it.

Edit: You could do a STFT on both primary voltage and current and divide them, which gives Z in the frequency domain.

Back to top
Steve Conner
Mon Jun 02 2014, 09:23PM
Steve Conner Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
Ooh, good idea, I think I will try that.

I measured the distance from the breakout point to the little burnt spots on the ceiling, 1.8m. So I haven't beaten the 2.1m output of the OLTC2 yet, but I don't think this will be too hard. smile
Back to top
Uspring
Tue Jun 03 2014, 08:47AM
Uspring Registered Member #3988 Joined: Thu Jul 07 2011, 03:25PM
Location:
Posts: 711
Been thinking about the frequency jumps, since they might be harmful to the electronics. I believe the jumps to happen only in the case, when, at the time Qsec drops below 1/k, primary fres is still below secondary fres. If secondary fres is then lower than primary fres, there will be no jumps. Where are the unloaded resonances?

Back to top
Steve Conner
Tue Jun 03 2014, 09:14PM
Steve Conner Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
With the tuning used in the video, the unloaded resonances are roughly 69 and 88kHz. The secondary alone resonates at 78kHz.
Back to top
Uspring
Wed Jun 04 2014, 09:33AM
Uspring Registered Member #3988 Joined: Thu Jul 07 2011, 03:25PM
Location:
Posts: 711
My guess is then, that primary and secondary fres are quite close to each other. With arc capacitance secondary fres would drop below primary fres and you won't see any frequency jumps.
Lowering primary fres will probably reduce pulse skipping at the risk of getting frequency jumps.

Back to top
Steve Conner
Wed Jun 04 2014, 10:22AM
Steve Conner Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
Yes. I started out with the primary and secondary tuned the same, and have been lowering the primary fres for each test run. Each time I lowered it, the amount of pulse skipping at full power decreased, and the spark output got bigger. On the last run, the pulse skipping duty cycle was up to about 75%.

Interestingly the detuning decreased the spark output at very low power. When I ramped up the DC bus voltage slowly from zero, the earliest breakout seemed to occur with the two coils exactly in tune. Any detuning delayed it, but once breakout happened the spark growth was more impressive.

I will continue to detune with each run until I run out of primary turns or the performance starts to fall off. Once I run out of primary turns, I could add more tank capacitance, but I guess that might be counterproductive as it would lower the impedance of the tank circuit?
Back to top
Uspring
Wed Jun 04 2014, 11:32AM
Uspring Registered Member #3988 Joined: Thu Jul 07 2011, 03:25PM
Location:
Posts: 711
Interestingly the detuning decreased the spark output at very low power. When I ramped up the DC bus voltage slowly from zero, the earliest breakout seemed to occur with the two coils exactly in tune. Any detuning delayed it, but once breakout happened the spark growth was more impressive.
That's unexpected from theory. The ordering of frequencies at low power from low to high would be:
flow, fpri, fsec, fup,
for lower pole, primary fres, secondary fres and upper pole. Lowering fpri should move fup, i.e. the f you're running on, closer to fsec, which would decrease Qpri and so lead to earlier breakout. I should redo the math here.

At large arc capacitances fsec drops below fpri, but fup still reamains above fpri, which increases the fup to fsec difference and thus increases Qpri. Lowering fpri will allow fup to follow fsec closer and so keep Qpri lower.

Once I run out of primary turns, I could add more tank capacitance, but I guess that might be counterproductive as it would lower the impedance of the tank circuit?
Yes, I think so too, but you might get away with increasing the MMC. There are 2 effects countering each other, lowering fpri, which decreases Qpri and decreasing tank impedance, which increases Qpri.
Back to top

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.