Welcome
Username or Email:

Password:


Missing Code




[ ]
[ ]
Online
  • Guests: 13
  • Members: 0
  • Newest Member: omjtest
  • Most ever online: 396
    Guests: 396, Members: 0 on 12 Jan : 12:51
Members Birthdays:
All today's birthdays', congrats!
cbfull (52)
Steve Ward (39)


Next birthdays
05/20 Vaxian (17)
05/21 Dalus (34)
05/21 Kizmo (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 »   

igbt speed

 1 2 3 4 
Move Thread LAN_403
Ben Solon
Wed Aug 08 2012, 03:24AM
Ben Solon Registered Member #3900 Joined: Thu May 19 2011, 08:28PM
Location:
Posts: 600
Destroyer of mosfets wrote ...

The warter would probably detune the coil (unless your driver can compensate)
You can't compensate for a detuned secondary period. Primary current feedback ensures that your primary's ~fres and your switching speed always match. Not whether your secondary is in tune. Not that it would it matters unless you're running fin or dan's coils: if the secondary became untuned then to keep the system in tune then you would have to physically alter the ~fres of the primary to match it.
Back to top
brandon3055
Wed Aug 08 2012, 04:57AM
brandon3055 Registered Member #4548 Joined: Mon Apr 23 2012, 03:52AM
Location: tasmania
Posts: 271
Oops I was thinking of an sstc
Back to top
Mads Barnkob
Wed Aug 08 2012, 01:46PM
Mads Barnkob Registered Member #1403 Joined: Tue Mar 18 2008, 06:05PM
Location: Denmark, Odense C
Posts: 1968
I made a couple of spreadsheets for switching speeds and gate drive.

60N60 thermal resistance is so low as corrected coresponding to datasheets Zrjc vs ontime.

Eon/Eoff for the CM300 are copies of the CM600 as I did not find these values.

Any comments on these calculations?
1344433568 1403 FT142897 Switching

1344433568 1403 FT142897 Gatedrive
Back to top
Kizmo
Wed Aug 08 2012, 02:52PM
Kizmo Registered Member #599 Joined: Thu Mar 22 2007, 07:40PM
Location: Northern Finland, Rovaniemi
Posts: 624
Looking good but Eon/Eoff values are for hard switching.

In perfect DRSSTC world you are not swithing any current so you only have to worry about conduction losses. Also switching delays are for hard swithing. (current rise/fall times)


1344437620 599 FT0 Fujidata


I have tested these IGBTS up to 2kApk @ 60kHz in my test setup.. no problems at all with phase lead driver.
Back to top
Mads Barnkob
Wed Aug 08 2012, 03:45PM
Mads Barnkob Registered Member #1403 Joined: Tue Mar 18 2008, 06:05PM
Location: Denmark, Odense C
Posts: 1968
Kizmo wrote ...

Looking good but Eon/Eoff values are for hard switching.

In perfect DRSSTC world you are not swithing any current so you only have to worry about conduction losses. Also switching delays are for hard swithing. (current rise/fall times)


1344437620 599 FT0 Fujidata


I have tested these IGBTS up to 2kApk @ 60kHz in my test setup.. no problems at all with phase lead driver.

Yeah I know its all data for hard switching, but its the numbers we have at hand :)

Conduction losses are as Terry Fritz also put it, highly neglect able with the very low duty cycles, by using the hard switching math, most IGBTs would run into MHz if only looking at the frequency limitation by temperature rise.

Are soft switching data normally available from the manufacturers?
Back to top
Kizmo
Wed Aug 08 2012, 03:56PM
Kizmo Registered Member #599 Joined: Thu Mar 22 2007, 07:40PM
Location: Northern Finland, Rovaniemi
Posts: 624
There is still simple thermal limit. Even with "just" conduction losses.

Have a look at IGBT die temp rise during single burst.. push hard enough and poor die just does not have time to dissapate all heat through its substrate.

EDIT:

Of course this does not limit switching speed. In (properly timed, phase lead) soft switghing applications even big IGBTs can operate at surprisingly high frequencies.

In brick world there is of course one limit that is like a brick wall (pun not intended..). Larger igbts have several dies in parallel and their busbars can have 50-100nH worth of inductance which is usually NOT equally spread along all paralled dies. Same thing with gate leads. Both of those combined will have large effect on how fast you can actually switch and still maintain current sharing and keep ringing down.

With properly set phase lead driver (Wards UD2.0 or Prediktor) there is no reason why dirty old CM300 could not operate past 100kHz without any issues at all.
Back to top
zzz_julian_zzz
Thu Aug 09 2012, 01:11AM
zzz_julian_zzz Registered Member #3964 Joined: Thu Jun 23 2011, 03:23AM
Location: Valenzuela City
Posts: 332
What's with the UDv2.0 PLC/Predictor? can someone post a schematic of this?
or if any like way circuits? Thanks
Back to top
Ben Solon
Thu Aug 09 2012, 02:59AM
Ben Solon Registered Member #3900 Joined: Thu May 19 2011, 08:28PM
Location:
Posts: 600
zzz_julian_zzz wrote ...

What's with the UDv2.0 PLC/Predictor? can someone post a schematic of this?
or if any like way circuits? Thanks

Steve gave me this link a while ago. its one of the non-released schematics, so don't go asking him to troubleshoot it for you if you have any problems.

those switching tables look fine. if i remember correctly i got some of the same times when i did the math a long time ago. just repeating that soft switching speeds are a bit faster.

people seem to be able to push cm300's to just under 100khz, so maybe the resonant switching formula should be:
Fresmax= (1/((Ton+Toff)*10))*1.6
that would correspond to some real data. look at how fast people switch these in their projects, and it looks reasonably accurate.

it also matches your thermal data. so we've got a new rule:Fresmax= (1/((Ton+Toff)*10))*1.6 unless the thermal data shows otherwise
Back to top
Kizmo
Thu Aug 09 2012, 09:58AM
Kizmo Registered Member #599 Joined: Thu Mar 22 2007, 07:40PM
Location: Northern Finland, Rovaniemi
Posts: 624
Link2

Good example :)
Back to top
Steve Conner
Thu Aug 09 2012, 10:10AM
Steve Conner Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706
There are a few different kinds of "CM300", for instance the CM300DY-12F (?) uses Powerex's 600V F-series dice. These are much faster than the usual 1200V H-series, and I've seen it used in tabletop coils in the 200kHz region.

I'm a little wary of the practice of using the transient thermal impedance. It's OK to use it to calculate junction temperature rise during the burst, but that is just a ripple on top of a slower rise.

When the coil is run repetitively for a long time, the die temperature will be determined by the average power dissipation (switching plus conduction) and the steady-state thermal resistance.

You should maybe add the temperature ripple to this to find the actual peak die temperature, but it's probably only a few degrees because the transient thermal impedance is so low, unless you are really pushing the device to destruction.

Steve Ward and Jimmy Hynes used PSpice to do full transient thermal simulations, with an electrical analogue of the thermal circuit.

As Kizmo points out above, package inductance in bricks is a serious problem because it causes the switching losses to be shared unevenly between dice, and no amount of spreadsheets will help you quantify that. Zero current switching of course is a great help.
Back to top
 1 2 3 4 

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.