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 #160
Joined: Mon Feb 13 2006, 02:07AM
Location: Melbourne, Australia
Posts: 938
Just wondering if anyone has tried paralleling MOSFETs for more current carrying capability in SSTC use? And if not then the reasons why it isn't a good idea. Being relatively cheap compared to IGBTs ( for some ), I imagine it would be a cost effective way of beefing up an SSTC or even making DRSSTC with this method.
1. Steady-state current sharing 2. Dynamic current sharing 3. Parasitic oscillation 4. Providing sufficient gate drive
(In linear applications thermal runaway also becomes a concern.)
Only parallel connect devices of the same type, manufacturer and batch, mount close-together on the same heatsink, keep layout symmetrical and use seperate gate resistors, don't parallel directly at device terminals like in that sketch.
Registered Member #135
Joined: Sat Feb 11 2006, 12:06AM
Location: Anywhere is fine
Posts: 1735
I've had success with slow speed switching of high current half wave power, but that requires additional design work. My boss needed a half wave switch designed for load switching of Anodize power supplies that was good for single phase or 3-phase half wave where you can't interrupt the power. I think it would fail quickly for switching faster then a few kilohertz or maybe tens of kilohertz. The heating in the die is your major concern, aka how they share the current.
1. Steady-state current sharing 2. Dynamic current sharing 3. Parasitic oscillation 4. Providing sufficient gate drive
(In linear applications thermal runaway also becomes a concern.)
Only parallel connect devices of the same type, manufacturer and batch, mount close-together on the same heatsink, keep layout symmetrical and use seperate gate resistors, don't parallel directly at device terminals like in that sketch.
-Richie,
I just used two paralleled fullbridges for SSTC like Christopher m. ... was that really just a pointless overkill and waste of resources? I thought for a while whether I should just parallel the devices or use split primary...
Registered Member #160
Joined: Mon Feb 13 2006, 02:07AM
Location: Melbourne, Australia
Posts: 938
Thanks Richie, I was looking for that irf article yesterday but the page wasn't coming up. I thought of some of your points when I first posted, namely current sharing and gate drive, and thought that with the mosfet drivers around today it should have enough current to drive them all. Current sharing would need a very precise topology as you stated, mounting close together and such, the gate resistors would also need to be closely matched in resistance, small deviations would cause differences in gate current and therefore different switch on times? Is that correct to say? As for parasitic oscillation, this would be a problem only on the gate side? and therefore solved by driving through separate resistors? Of course all this would be mounted on a massive heatsink and fan cooled. Chris, Marko, look forward to seeing if the design works. Let us know how you go Marko.
Just bought 20 from Jamaica as well, we'll see if it gets to Australia before I move. Movin' to the country, gonna eat a lot of peaches.
Registered Member #1232
Joined: Wed Jan 16 2008, 10:53PM
Location: Doon tha Toon!
Posts: 881
In a bridge leg with paralleled switching devices generous deadtime is wise to allow the slowest device time to fully turn off before the fastest device on the other side begins to turn on. If this is not done you can get conduction overlap between say the last device to turn off at the bottom and the first device to turn on at the top. This causes shoot-through down the bridge leg, albeit only through two devices. Generally turn-off wants to be as fast as possible, and turn-on slightly slower but its all in those papers.
If you want to parallel complete H-bridge sub-assemblies, it is best to add some series inductance between the bridge outputs and the commoning point. This raises the effective output impedance of each bridge and improves dynamic current sharing. This added inductance seen between inverters also limits the rate at which "shoot-between" currents can build if the switching instants of the distributed inverters are not perfectly synchronised. The 3rd schematic down on a white background here shows how this can work for an induction heating application:
When you parallel power semiconductors in high frequency applications it is better to parallel them at a high impedance point rather than directly at the device terminals. The inductors raise the impedance at that point without dissipating any power. In an induction heater or RF amplifier the added inductors simply become part of the matching network. In a SSTC they effectively add to the primary inductance, resulting in an effective drop in coupling factor.
Registered Member #89
Joined: Thu Feb 09 2006, 02:40PM
Location: Zadar, Croatia
Posts: 3145
Of course all this would be mounted on a massive heatsink and fan cooled. Chris, Marko, look forward to seeing if the design works. Let us know how you go Marko.
The paralleled SSTC bridges thing doesn't seem to work well to me, actually, it is defying all reason.
I'll try to be most clear about what I did and what is happening:
I'm using two fullbridges, sharing same supply. Their outputs are separate and led to two primary coils wound together around the resonator. (no electrical contact at all between bridge outputs, all gate drive is isolated!)
When I used one bridge alone (either of those two) they worked very well.
But if I tried to use them both together they wouldn't work. Coil wouldn't oscillate, dead silence.
Tried running fullwave rectified and CW; no difference. (the circuit works just fine with fullwave rectified!)
But, what is most amazing, if I just leave both bridges together on the power supply and gate drive, but if I connect only one primary and leave another bridge output floating, it *still* doesn't work! No matter how I changed the CT I could do nothing about it.
How in a world can this another bridge affect the first one from just being connected to same supply? I verified it's gate drive and phase before and it was allright.
There was pretty surely no shootthrough on this bridge. If I remove the bridge from the power supply - everything works fine!
Later I tried putting a lightbulb on the unused bridge output - the coil worked for few seconds, the bulb lit, and then lost feedback, after that I couldn't it make turn on anymore until I disconnected the second bridge again!
Only after leaving the system to ''rest'' for a while, I could do the ''bulb'' trick again, but only for few seconds! wtf?
I hoped and still hope it's just some stupid mistake, since I've never seen as bizzare SSTC inverter behavior like this.
But I disassembled the bridges like 10-15 times now and pretty much confirmed everything in above post.
The driver schematic needed fixing but I hope it's OK now if anyone wants to see it. Two pairs of drivers driving a dual-primary GDT, feedback directly from a CT. I measured the clamped CT output and it produces very good squarewave (very high sinewave voltage clamped to 12V) on it's own even at quite low power levels, so I thought I don't need a schmitt trigger in between.
Registered Member #1225
Joined: Sat Jan 12 2008, 01:24AM
Location: Beaumont, Texas, USA
Posts: 2253
somewhat like this.would it work? the mosfets of course can not be the exact same gain and all that,but if one uses more it should heat up.wouldn't that cause more resistance therefor making it draw less current and let the others do more work?i am a beginner so i cant be sure if it would work or not.worth a try?because i have a sstc with a 555 timer i would love to see if i could get more current into the primary because i get 2 amps peak into it :(
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.