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 #599
Joined: Thu Mar 22 2007, 07:40PM
Location: Northern Finland, Rovaniemi
Posts: 624
I think the switching noise problem was something that mr. Ward had to correct in one of his UD2 revisions.
"C33 controls a "no switch" time after each output transition on the comparator. Originally i found C33 could be just 220pF, but recently using CM600DU-24NF modules with a loooong 1uS or so delay in switching, i found i had to boost C33 up to 2.2nF. This provided a longer period where the comparator has high immunity to noise, and without this there was severe "glitching" where the IGBT switch noise caused the comparator to switch several times instead of once per half-cycle."
Thats pretty much what my driver is doing. Only problem is that i have tried C33 values between 200p and 2n with no change.
EDIT:
Since this is starting to look like a noise problem i think its time to try to improve the shielding by a lot. Currently I have only the driver board inside of the metal box (mainly because fiber rx does not like electric fields). That works well for UD1.3. But should i have stuff like gate drive transformer, low voltage supply transformer and AC input filter inside of the box as well? Also i could convert feedback and overcurrent detection transformer leads from twisted pair to coaxial.
And how about proper grounding? I can see very potential switching noise loop in my current grounding style where I have IGBT heatsinks, driver box and mounting plate tied to mains ground. Also there is a clip-on emi filter ferrite on gdt primary leads and 100nF cap from Bus- to heatsink.
Registered Member #1403
Joined: Tue Mar 18 2008, 06:05PM
Location: Denmark, Odense C
Posts: 1968
Steve Conner wrote ...
Well, it would be easier to debug the problem if the scope results actually showed it.
What we are trying to establish is a chain of causation. We have the symptoms, we are trying to figure out the root cause. The problem is that the whole system is one big feedback loop, so the chain of causation could be circular.
I would be interested to see what happens when the feedback input is driven from a signal generator as opposed to the CT. This breaks the feedback loop so you can rule out any circular arguments.
I would also investigate the possibility of the switching spikes from the bridge getting back into the comparator. They can be pretty violent especially near the beginning of the burst when there's not enough current to achieve smooth commutation. And, now the comparator has hysteresis, a switching spike could permanently flip it instead of just temporarily glitching the output. (Did the UD1.x have hysteresis?)
The amount of switching spikes present in your CT signal is a system level issue, mainly down to your shielding and grounding schemes. But the driver's sensitivity to them is another matter. My PLL driver uses the type-1 phase detector which works on the average value, so it ignores the spikes completely.
Well... this is what the scope shots look like :)
The spike that appears at the output from the AND gate, it is only coming from pin3, there is not this spike present at pin6.
As my vacation is over and I start travelling again, I have packed the driver up and sent it to a German laboratory for tests. You might know this lab as being run by Sync :)
Registered Member #15
Joined: Thu Feb 02 2006, 01:11PM
Location:
Posts: 3068
Kizmo,
If I might add . . . if everything appears to be working correctly, and you are just getting "shitty" looking waveforms, a lot of the times it can be a result of just poor measurement equipment / practices.
A DRSSTC is an extremely noisy device and noise can be induced all over the place, including on the probes and ground clip loops themselves.
So when looking at your measurements, make sure what you are seeing is actually real, and not just an artificat from a noisy environment or improperly placed probe / ground clip etc....
If you can, try to scope what your actual ground plane looks like. You could be getting common mode spikes that are appearing on everything and not really having an effect on your actual circuit.
Registered Member #599
Joined: Thu Mar 22 2007, 07:40PM
Location: Northern Finland, Rovaniemi
Posts: 624
EasternVoltageResearch wrote ...
Kizmo,
If I might add . . . if everything appears to be working correctly, and you are just getting "shitty" looking waveforms, a lot of the times it can be a result of just poor measurement equipment / practices.
A DRSSTC is an extremely noisy device and noise can be induced all over the place, including on the probes and ground clip loops themselves.
So when looking at your measurements, make sure what you are seeing is actually real, and not just an artificat from a noisy environment or improperly placed probe / ground clip etc....
If you can, try to scope what your actual ground plane looks like. You could be getting common mode spikes that are appearing on everything and not really having an effect on your actual circuit.
Thank you for the reply.
Yes I am fully aware that these things are awful common mode noise generators. And thats why i take most of my measurements with high voltage differential probe which has excellent common mode noise rejection so i am expecting that what i see is more or less actually happening. These measurements can also be replicated with 3 different oscilloscopes.
And it is pretty easy to tell even without scope that this thing is far from happy runner. As we all know, normal DRSSTC should sound like nice and steady BZZZZZZZZ no matter what pulse width you use (of course longer pulse -> louder). Both of my UD2.x boards switch all over the place, skip entire primary current cycles, miss start of the bursts and do all kind of really weird stuff. I can hear and see the problem without any measuring equipment. It sounds like brbprp-ttttt-zz-brbrbr-zzz-bzz and i can see primary wires twitching as the sound changes :D
Some pulse widths seem to be working better than others as you can see here. Red trace is the primary current from pearson and yellow trace is actual H-bridge output voltage from differential probe.
Registered Member #15
Joined: Thu Feb 02 2006, 01:11PM
Location:
Posts: 3068
That is weird. Have you checked to ensure the parts you are using are indeed the correct ones that are specified in the UD parts list? I know there can be big differences in specs between the same part number chips but from different manufacturers. Or some chips can be counterfeit.
Just throwing that out there as I have seen issues like that arise in other projects I've worked on.
Registered Member #1403
Joined: Tue Mar 18 2008, 06:05PM
Location: Denmark, Odense C
Posts: 1968
EasternVoltageResearch wrote ...
That is weird. Have you checked to ensure the parts you are using are indeed the correct ones that are specified in the UD parts list? I know there can be big differences in specs between the same part number chips but from different manufacturers. Or some chips can be counterfeit.
Just throwing that out there as I have seen issues like that arise in other projects I've worked on.
We are pretty sure that is not the problem. Kizmo uses the original board files and SMd components. I get the same problems with homemade single sided board and through hole components. Tried different manufacturers of some of the ICs, Kizmo uses the TL3116 comparator and I use the MAX913. Those two drivers are about as different as they can get :)
Registered Member #510
Joined: Sat Feb 10 2007, 09:28AM
Location: Hannover
Posts: 12
At first, I am sorry that I could not write earlier, work and exams ate a lot of time lately.
As per Conners request I hooked Mads driver to two signal sources, the result can be seen here,
Traces from top to bottom:
Output to gate drivers
IC4B pin 10
Interruptor input
Input to comparator
From what I can see the comparator is triggering rock solid on the signal. There is the occasional extra pulse or glitch, but nothing major. Unfortunately I cannot generate signals with controlable phase relationship to each other at this point but I'm shopping for an arbitrary function generator.
The next step is to setup a small loaded tank and see how this thing behaves when connected to a real circuit.
Registered Member #599
Joined: Thu Mar 22 2007, 07:40PM
Location: Northern Finland, Rovaniemi
Posts: 624
FFFUUUUUUUUUUUUUUU
Now this is getting just stupid. What the hell i'm doing wrong with this thing?!
I went ahead and purchased 100% tested and working board from mr. Slawinski. This board has been used in his DRSSTC IV with great success.
My build is entirely new as well - CM600 H-bridge - 2 GDTs, 2.2ohm turn on and 4.4ohm turn off resistance, very nice gate waveforms. - 1:33:33 cascaded feedback ct (gdt and feedback ct are same ferrite material)
This new build has _nothing_ common with my old builds and yet still it does _exactly_ same thing! Some burst lengths work just like they should, tank wiring is getting nice and toasty with perfect waveforms. We are looking at actual inverter output voltage vs primary current reading from feedback CT before burden network. In this picture, ON time was set to 96µs.
Aaand then just couple ticks back, to 92µs and good old bzbzbbbpbzpbzpzbzpbz bpzbpzbbzpbzpzz is back!
Now seriously. It has been almost 3 years, and countless tries with UD2.x and result is nothing but piece of crap!
I am really goddamn close to do something really destructive with these builds...
Registered Member #30656
Joined: Tue Jul 30 2013, 02:40AM
Location: UK
Posts: 208
Take a look at this, it may be relevant to your issue: I know that I have seen some weirdness due to initial voltage on the cap at certain pulse-widths.
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.