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.
Registered Member #1538
Joined: Thu Jun 12 2008, 07:28PM
Location: Bonn, Germany
Posts: 28
Hi
At the moment I am building a DRSSTC for the „Physikshow“ at the University of Bonn, where I study physics. Since it’s not my first solid-state coil and I spend a lot of time reading, I lately got things running. I tried to stay close to Steve Ward’s “General Guide to DRSSTC Designâ€, especially for the driver, OCD and feedback loop. I use a H-bridge topology, primary is 10-15 µH, 66nF, secondary is 45cm (17,7in), 11cm (4,3in) diameter, 0,3mm (28AWG) wire. Resonant frequency with topload (14pF) is ~200 kHz. No big surprise so far, I hope. But I’m somewhat unhappy with the IGBT’s performance. I tried STGW39NC60VD (I_max = 80A, I_puls = 220A, Gate charge at 15V = 126nC, to247) and HGTG20N60A4D (I_max = 70A, I_puls = 280A, Gate charge at 15V = 142nC, to247). The STGW39NC60VD was able to survive the higher pulsed currents. Now I would like too know what you experienced about I_puls ratings: are they useful, or do you prefer “bigger†IGBT’s like the 40n60 or 50n60, although they might, in some cases, have lower pulsed ratings? My second question is about delay times: dose anybody know if a delay of about 300ns between the zero-crossing of the prim. current and the switching transition of the H-bridge’s output is about what is suspected for this circuit? It seems to me that the IGBT’s are already again carrying about ¼ * Imax than for ~150kHz operation. Is a turn-off delay time of about 200ns (STGW39NC60VD) to much?
Registered Member #1232
Joined: Wed Jan 16 2008, 10:53PM
Location: Doon tha Toon!
Posts: 881
The IGBTs will always switch sometime after the load current (primary current) has passed through zero. This is the case because it takes a finite time for the "zero crossing message" to propagate from the CT, through the control logic, gate drive amplifiers and GDTs to make the IGBTs eventually switch.
By the time the IGBTs switch in a DRSSTC, the current has already changed direction. It has left the active channel and started flowing in the co-pack diode long ago. This soft turn-off is the situation you want since it minimises turn-off current tailing in slow IGBTs. However, you don't want to wait too long after the zero crossing to switch both IGBTs because the one that turns on has to pick up a larger current from the opposing co-pack diode exacerbating reverse-recovery problems in that device.
Phase-lead networks (allpass filters) and PLL's are two ways to compensate for the effects of these propagation delays through the control and drive electronics. Using these techniques you can ensure that one device is turned off as soon as possible after the current reverses direction, and that the opposing device is turned on as soon as possible after the first device is out of conduction.
Registered Member #1538
Joined: Thu Jun 12 2008, 07:28PM
Location: Bonn, Germany
Posts: 28
Oh, yes, of course you are right. None of the IGBT’s has to switch off the current. It somehow twisted my mind!
But still one of them has to turn on while about ¼ Imax is flowing through the co-pack diode of the other device. This will hopefully be about 100A, which the IGBT has to pick up, as you mentioned. I am not that familiar with IGBT’s yet. 100A just seems high to me, because some of them have a SOA of “only†100 – 150 A at 300V. But, however, if you say 300ns is not WAY to much, I will try once again.
Can you also help me with the pulsed current ratings? I’m still unsure which is the right way: using an IGBT with a higher puls rating, or one with a higher current handling ability in general? To say some numbers, would you prefer something like the HGTG20N60A4D (I_max = 70A, I_puls = 280A) or the STGY50NC60WD (I_max = 110A, I_puls = 250A)?
Banned on 3/17/2009. Registered Member #487
Joined: Sun Jul 09 2006, 01:22AM
Location:
Posts: 617
Timo wrote ...
"To say some numbers, would you prefer something like the HGTG20N60A4D (I_max = 70A, I_puls = 280A) or the STGY50NC60WD (I_max = 110A, I_puls = 250A)?"
I would say go with the pulsed rating. I am using the hgtg20n60a4d IGBT's and they are great. They can handle quite alot of power. Also maybe go with the one with faster switching times.
Registered Member #1538
Joined: Thu Jun 12 2008, 07:28PM
Location: Bonn, Germany
Posts: 28
Hi Tom540
Thanks for this information. May I ask you if you use a circuit that delays the switching event noticeable, similar to Steve Ward’s? And if you do, would you tell me how much and what the maximum current is you allow for reliable operation? I’m somewhat interested in how much the current may rise before the IGBT takes over.
Banned on 3/17/2009. Registered Member #487
Joined: Sun Jul 09 2006, 01:22AM
Location:
Posts: 617
As far as delaying the interrupter I have used a similar circuit but i don't always use one. If I were to use primary feedback then I would say it is probably needed. The only delay for me is the paralleled resistor and Schottky's on the gates of the igbt's. I think my igbts are only running at half the rated pulsed current. Its been awhile since i've measure it though. Maybe Ill take a measurement today.
Registered Member #89
Joined: Thu Feb 09 2006, 02:40PM
Location: Zadar, Croatia
Posts: 3145
Hi guys;
One related thing. IGBT's in DRSSTC switch leading current which causes their integrated diodes to forcibly recover. This looks like a very short shoot-through condition and causes a short, spiky voltage transient at turn-on (the point where the IGBT ''takes over'' the current from the diode as you say, and slamming full supply voltage across it).
For some reason, lots of people were and still are *extremely worried* about these voltage transients, which ended probably as most blamed thing for IGBT failures (while in almost all cases some other reason is found later). People have gone through great lengths trying to remove those ''voltage spikes'' (ultra low inductance supply buses, huge amounts of decoupling caps, stacks of TVS's, slowing down the gate drive...)
To me, a simple logical way for removing the ''voltage spikes'' would be to introduce small commutating inductance across the bridge output, but before the CT, to provide few to few tens of amps of reactive current and make the system switch lagging current in overall.
This would introduce ZVS at cost of having somewhat hard switched turn-off, and we would not see those annoying spikes anymore.
The question is, of course, how would this make sense at all, since in a low duty cycle system like DRSSTC losses due to recovery and lack of ZVS are completely negligible, and commutating inductance may just do more damage than good by introducing additional current to be switched.
So, should we just explain everyone that the ''voltage spikes'' are *good*, and to stop worrying about them? Many still seem to think the IGBT will pop like a balloon if anything just touches over it's rated voltage, even if for just few ns.
Registered Member #1232
Joined: Wed Jan 16 2008, 10:53PM
Location: Doon tha Toon!
Posts: 881
Adding commutating inductance to pulsed high-power IGBT bridges in DRSSTC apps is in my opinion counter productive. Firstly average turn-on losses due to diode reverse-recovery are still relatively low even though peak dissipation may be high in a particular DRSSTC. Secondly, the addition of a commutating inductor to introduce enough lagging magnetising current to make the total inverter current lag would mean a significant circulating current would need to be supported by this inductor without saturating or incurring significant I²R losses. Thirdly, a net lagging inverter load current would mean IGBTs now have to interrupt significant load currents causing significant current tailing and turn-off losses in all but the fastest of devices. (You will also likely still see voltage spikes and ringing, this time due to the catch-diodes limited ability to pick up the tens or hundreds of amps being rapidly turned off by the IGBTs)
Finally another problem with a commutating inductor connected directly across the output of a PULSED bridge is in maintaining instantaneous volt-second balance to always keep the triangular current waveform symmetrical about the 0 amps line. The first half cycle actually needs to be artificially shortened to a quarter cycle in length. Otherwise the current will integrate up too far in the first half cycle and there will be a net DC bias to the magnetising current.
The best ways to deal with the turn-on current spikes resulting from forced diode reverse-recovery are as follows:-
1. Turn off the previously conducting IGBT device as quickly as possible after the load current goes through zero and commutates to the device's copack diode. 2. Turn on the opposing device to catch the free-wheeling current as soon as possible after the end of the first device's turn-off delay time. This prevents cross conduction. 3. Turn on the new device with a controlled gate voltage profile so that the stored charge in the free-wheel diode is swept out in a controlled manner with a limited peak current. The device is essentially progressively enhanced to support only the rising load current as it grows in amplitude without desaturating the IGBT. 4. Minimise stray inductance in the IGBT, diode, bus cap clamping loop.
Limiting peak reverse current through controlled turn-on and minimising DC bus stray inductance both limit the voltage spikes that result from excessive Ldi/dt.
Registered Member #89
Joined: Thu Feb 09 2006, 02:40PM
Location: Zadar, Croatia
Posts: 3145
Finally another problem with a commutating inductor connected directly across the output of a PULSED bridge is in maintaining instantaneous volt-second balance to always keep the triangular current waveform symmetrical about the 0 amps line. The first half cycle actually needs to be artificially shortened to a quarter cycle in length. Otherwise the current will integrate up too far in the first half cycle and there will be a net DC bias to the magnetising current.
You are right. That is exactly the same problem that happens with iron transformers when plugged into mains at voltage zero cross, which causes a quarter cycle of extra Vs, saturation and drawing of excessive currents.
The condition takes many cycles to resolve as real part of impedance removes the energy, so in DRSSTC I would practically have DC flowing through commutating inductor.
The best ways to deal with the turn-on current spikes resulting from forced diode reverse-recovery are as follows:-
1. Turn off the previously conducting IGBT device as quickly as possible after the load current goes through zero and commutates to the device's copack diode. 2. Turn on the opposing device to catch the free-wheeling current as soon as possible after the end of the first device's turn-off delay time. This prevents cross conduction. 3. Turn on the new device with a controlled gate voltage profile so that the stored charge in the free-wheel diode is swept out in a controlled manner with a limited peak current. The device is essentially progressively enhanced to support only the rising load current as it grows in amplitude without desaturating the IGBT. 4. Minimise stray inductance in the IGBT, diode, bus cap clamping loop.
Well, I guess that could be done with PLL as you said. My point was, aren't we actually worsening the condition by trying to somehow introduce lagging current just to remove the very ugly looking 'voltage spikes', which actually aren't any harm at all. We would get soft recovery and ZVS which are negligible benefit for a pulsed system.
IGBT's are usually advised to drive leading current to maximize zero current turnoff, even in CW, as their diodes are fast and output capacitances small compared to same rating mosfets.
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.