Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Fri Sept 21 2012, 06:03AMIm having troubles with With wards UD2.1b.
Most of the time the driver seems to be performing fine, phase lead works and i get beautiful waveforms. Then as i ramped the interrupter pulse width up and down, sometimes the coil (running without secondary in place at 100bps) went from nice solid bzzz to prptptptptptptptt (sounded like machine gun). I scoped around and found that when this happens, the inverter output was horribly wrong.
This glitch is visible at various places. It shows clearly at UCC gate driver chip inputs before actual P/N fet pairs that drive the GDT. Once coil enters into a glitched mode it usually comes out of it if i alter bus voltage (up or down) or turn phase lead inductor (direction doesnt matter)
I scoped pin 3 of the phase comparator IC and sweeped pulse width up and down. I also stopped and retriggered scope several times so that you can see how it jumps between normal and this glitched mode:
UD2.1 schmatic:
So far i have tried couple values for C33 (220p, 330p and 1n) I have also added 100k resistor in parallel with D1 and D2.
Suggested by mr. Ward i also added 330p between negative input and ground right on the phase comparator but it didnt help.
Coil spec:
105kHz resonant frequency
800nF tank cap
SKM150GB128D half bridge
340VDC input
1:33:33 feedback CT
OCD not in use
Coil works perfectly with UD1.3
Edit:
The interrupter signal scoped from 74hc stays solid square wave without any obvious issues all the time.
Edit2:
This thing came into my mind last night
Inverter section is done just like this. Could it be that under some conditions Q2 transistor is first one to switch and since there isnt whole lot voltage (ideally nothing) the driver cant get solid feedback and goes this weird operation mode?
Also i cant explain why it works perfectly with older driver. I guess i could try more conventional method of making half bridge (having cap divider) or just slap another igbt there to form a proper h-bridge..
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Goodchild, Tue Sept 25 2012, 04:17PM
Oh I know that problem all to well!!
This is an error in the board design with the feedback comparator. The reference divider and the feedback is routed incorrectly, check the schematic vs the board for the TL3116 you will find that error it is obvious once it's pointed out.
Cut a trace or two and add some solder and it should be working just fine.
Goodchild, Tue Sept 25 2012, 04:17PM
Oh I know that problem all to well!!
This is an error in the board design with the feedback comparator. The reference divider and the feedback is routed incorrectly, check the schematic vs the board for the TL3116 you will find that error it is obvious once it's pointed out.
Cut a trace or two and add some solder and it should be working just fine.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Tue Sept 25 2012, 09:50PM
Thanks for help.
I had a good 2 hour session trying to find out whats wrong with this thing.
Things done:
Switched to CM300 full bridge. Now it runs at 60kHz and almost looks like it made the problem even worse.
I traced all caps and resistors in the feedback circuit (even unsoldered bunch of SMD ceramics and measured them!)
Couldnt find misplaced components. I know this board has problem and i fixed it back when i first put this thing together. One trace to cut and one solder jumper. Pin 2 of the TL3116 is sitting nicely at around 1.6Volts so the divider part should be working. Connection between pin 2, R5 and R5 seem to be fine too. Also R26-C33 is connected correctly.
I guess its time to show another video i took:
Upper trace is GDT primary and lower is interrupter signal.
Im totally lost with this one. If i pop in older UD1.3 this circuit runs just fine. Of course there could still be some components misplaced by me but at least i couldnt find any.
EDIT 26.9.2012
Litte bit more work with UD2.1 today.
I made a new feedback CT with 1:500 ratio. Now there is plenty of signal for feedback. Did it help? No.
Interrupter vs primary current right before it goes into RL burden network
Edit 26.9.2012 -2
One more video:
GDT output vs interrupter setting. Is this normal? First without bridge power. You can clearly hear when i put power to the bridge (80VDC).
Im starting to think that this whole thing is cursed :(
Kizmo, Tue Sept 25 2012, 09:50PM
Thanks for help.
I had a good 2 hour session trying to find out whats wrong with this thing.
Things done:
Switched to CM300 full bridge. Now it runs at 60kHz and almost looks like it made the problem even worse.
I traced all caps and resistors in the feedback circuit (even unsoldered bunch of SMD ceramics and measured them!)
Couldnt find misplaced components. I know this board has problem and i fixed it back when i first put this thing together. One trace to cut and one solder jumper. Pin 2 of the TL3116 is sitting nicely at around 1.6Volts so the divider part should be working. Connection between pin 2, R5 and R5 seem to be fine too. Also R26-C33 is connected correctly.
I guess its time to show another video i took:
Upper trace is GDT primary and lower is interrupter signal.
Im totally lost with this one. If i pop in older UD1.3 this circuit runs just fine. Of course there could still be some components misplaced by me but at least i couldnt find any.
EDIT 26.9.2012
Litte bit more work with UD2.1 today.
I made a new feedback CT with 1:500 ratio. Now there is plenty of signal for feedback. Did it help? No.
Interrupter vs primary current right before it goes into RL burden network
Edit 26.9.2012 -2
One more video:
GDT output vs interrupter setting. Is this normal? First without bridge power. You can clearly hear when i put power to the bridge (80VDC).
Im starting to think that this whole thing is cursed :(
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Mads Barnkob, Wed Aug 28 2013, 06:05PM
Bringing thread up to date with posts from:
To this day these boards Kizmo have, do still not work.
Mads Barnkob, Wed Aug 28 2013, 06:05PM
Bringing thread up to date with posts from:
Goodchild wrote ...
Although this may sounds stupid, do you have the Tl3116 and the LM311 swapped? I only ask because I at one point did this on the UD2.1 and it lead to similar issues to what you were describing.
anyway I'm sorry to hear it's giving you grief... My advice, step through the circuit with a scope and signal gen on the input and check to see where the signal stops being correct.
Lastly your gate signals being in phase sounds to me like you have the phase jumpers set wrong, are both jumpers on the same part of the header?
-------------------Although this may sounds stupid, do you have the Tl3116 and the LM311 swapped? I only ask because I at one point did this on the UD2.1 and it lead to similar issues to what you were describing.
anyway I'm sorry to hear it's giving you grief... My advice, step through the circuit with a scope and signal gen on the input and check to see where the signal stops being correct.
Lastly your gate signals being in phase sounds to me like you have the phase jumpers set wrong, are both jumpers on the same part of the header?
Kizmo wrote ...
You pretty much nailed it. I had indeed those ICs mixed up. Now it works... just like the UD2.1 i had hard time about a year ago!
primary current vs inverter output voltage
You dont need oscilloscope to tell its not really working..
What kind of sorcery is this?
Same thing as before, i can drop in UD1.3 and it works perfecly.
-------------------You pretty much nailed it. I had indeed those ICs mixed up. Now it works... just like the UD2.1 i had hard time about a year ago!
primary current vs inverter output voltage You dont need oscilloscope to tell its not really working..What kind of sorcery is this?
Same thing as before, i can drop in UD1.3 and it works perfecly.Goodchild wrote ...
Unlike the UD2.1 the jumper by the inductor set a R or RL burdon network. ie you can disable the pheas lead functionality for debugging. I would try setting the jumper so just the R is in the burdon network and try it again.
From your previose scope shots it looks to me like a possible phase lead issue, maybe the wronge size inductor or somthing along those lines. If this goes away when you switch the network to just R this may be the issue.
-------------------Unlike the UD2.1 the jumper by the inductor set a R or RL burdon network. ie you can disable the pheas lead functionality for debugging. I would try setting the jumper so just the R is in the burdon network and try it again.
From your previose scope shots it looks to me like a possible phase lead issue, maybe the wronge size inductor or somthing along those lines. If this goes away when you switch the network to just R this may be the issue.
Kizmo wrote ...
I dont have inductor in place. Same with UD2.1, inductor value didnt have any effect.
-------------------I dont have inductor in place. Same with UD2.1, inductor value didnt have any effect.
Goodchild wrote ...
Without the inductor in place you are basically running that feedback input open circuit. Although technically it has a chopper network I have had bad things happen because it was left open.
Humor me on this, put your scope on the output of the TL3116 (pin 7 or 8) and take a scope shot in these three conditions.
First, just how you have it now, no inductor in place.
Second, with the inductor in place.
Third, with the jumper set such that only the R is in the feedback network.
This will also show if the problem you are having is an issue with that first part of the board which 90% time with these phase lead controllers that's usually where it is. Everything after the TL3116 is simple digital stuff and is usually not the issue.
-------------------Without the inductor in place you are basically running that feedback input open circuit. Although technically it has a chopper network I have had bad things happen because it was left open.
Humor me on this, put your scope on the output of the TL3116 (pin 7 or 8) and take a scope shot in these three conditions.
First, just how you have it now, no inductor in place.
Second, with the inductor in place.
Third, with the jumper set such that only the R is in the feedback network.
This will also show if the problem you are having is an issue with that first part of the board which 90% time with these phase lead controllers that's usually where it is. Everything after the TL3116 is simple digital stuff and is usually not the issue.
Kizmo wrote ...
I think this is somewhat complex problem. I see quite a lot of noise at the output of the phase comparator BUT its difficult to tell if its real or just common mode noise. I have to retest it with my differential probe which has very good common mode noise rejection.
Perhaps next test will be with differential probe and battery power for the driver. Right now there is so much common mode noise from bad switching timing that all it takes is a probe touch to the output of the phase comparator and whole thing will go from sort of working to not working at all.
Strange thing is that i have had this problem with two very different setups. First one was with ultra fast 150A semikron and this one is 24h series cm300 H-bridge. Only thing common with these two builds are builder and most of driver side parts.
-------------------I think this is somewhat complex problem. I see quite a lot of noise at the output of the phase comparator BUT its difficult to tell if its real or just common mode noise. I have to retest it with my differential probe which has very good common mode noise rejection.
Perhaps next test will be with differential probe and battery power for the driver. Right now there is so much common mode noise from bad switching timing that all it takes is a probe touch to the output of the phase comparator and whole thing will go from sort of working to not working at all.
Strange thing is that i have had this problem with two very different setups. First one was with ultra fast 150A semikron and this one is 24h series cm300 H-bridge. Only thing common with these two builds are builder and most of driver side parts.
To this day these boards Kizmo have, do still not work.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Mads Barnkob, Wed Aug 28 2013, 07:06PM
So far, most of the people that have been in over debugging this with Kizmo, have concluded that it is just weird.
I will not say that I feel lucky, but I managed to replicate this behaviour with my own custom single sided version of the UD2.1.
I still need to change C33 to larger value for running with CM600 bricks. Kizmo tried many values without any luck. Driver is housed in a aluminium enclosure, IEC filter on AC in, ferrite beads around GDT primaries.
Article about the whole DRSSTC construction:
Driver board front:
Driver board bottom:
There is a world to difference between the two drivers. But the problem is most likely in the phase lead section. I use a TL3116 equivalent, the MAX913.
The problem is the same as Kizmo describes. As I ramp through the duty cycle, no matter BPS and bus voltage, it will at some points start to jitter and the inverters output voltage looks horrible distorted.
At all times the inverter skips at the maximum primary current, I am not too sure about how this can happen, maybe phase shift of some sort.
When trying to scope the output of the phase lead comparator it becomes very clear that it is unstable. A single touch with the probe on non-inverted output pin 7, the coil can be heard buzzing weirdly, a single touch to inverted output pin 8 and it goes back to run normal. This can be done when its running at one of the points of duty cycle where its normally stable.
Here is a video of me skipping through whole duty cycle range, 0 to 400 uS. Primary current is channel 1, yellow trace, 1div/500A. Inverter voltage is channel 2, blue trace. Bus voltage was 100VDC, scope was not set up correctly for channel 2.
Kizmo would supply me with some pictures tomorrow of the drivers so I can compare, perhaps there is one small thing that is repeated. I hope it will be easier to spot with two so different boards.
Mads Barnkob, Wed Aug 28 2013, 07:06PM
So far, most of the people that have been in over debugging this with Kizmo, have concluded that it is just weird.
I will not say that I feel lucky, but I managed to replicate this behaviour with my own custom single sided version of the UD2.1.
I still need to change C33 to larger value for running with CM600 bricks. Kizmo tried many values without any luck. Driver is housed in a aluminium enclosure, IEC filter on AC in, ferrite beads around GDT primaries.
Article about the whole DRSSTC construction:
Driver board front:
Driver board bottom:
There is a world to difference between the two drivers. But the problem is most likely in the phase lead section. I use a TL3116 equivalent, the MAX913.
The problem is the same as Kizmo describes. As I ramp through the duty cycle, no matter BPS and bus voltage, it will at some points start to jitter and the inverters output voltage looks horrible distorted.
At all times the inverter skips at the maximum primary current, I am not too sure about how this can happen, maybe phase shift of some sort.
When trying to scope the output of the phase lead comparator it becomes very clear that it is unstable. A single touch with the probe on non-inverted output pin 7, the coil can be heard buzzing weirdly, a single touch to inverted output pin 8 and it goes back to run normal. This can be done when its running at one of the points of duty cycle where its normally stable.
Here is a video of me skipping through whole duty cycle range, 0 to 400 uS. Primary current is channel 1, yellow trace, 1div/500A. Inverter voltage is channel 2, blue trace. Bus voltage was 100VDC, scope was not set up correctly for channel 2.
Kizmo would supply me with some pictures tomorrow of the drivers so I can compare, perhaps there is one small thing that is repeated. I hope it will be easier to spot with two so different boards.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Steve Conner, Thu Aug 29 2013, 07:57AM
My personal theory is that the crud coming out of the unstable comparator confuses the flip-flop with runt pulses and causes it to hang up in an undefined state. Or rather, since it only has two possible states, the opposite state to what it needs to be right now. The gate drive gets turned off when it should be on.
The circuit is capable of asserting Pre and Clr at the same time, and data sheets from different flip-flop makers have different explanations about what happens in this case. Most makers say that the state will be determined by whichever input was deasserted last, but TI's datasheet says the state will be undefined. I would be interested to know if the users suffering this problem are using a TI flip-flop.
I was always suspicious of the whole feedback driver concept and preferred to use PLLs.
Steve Conner, Thu Aug 29 2013, 07:57AM
My personal theory is that the crud coming out of the unstable comparator confuses the flip-flop with runt pulses and causes it to hang up in an undefined state. Or rather, since it only has two possible states, the opposite state to what it needs to be right now. The gate drive gets turned off when it should be on.
The circuit is capable of asserting Pre and Clr at the same time, and data sheets from different flip-flop makers have different explanations about what happens in this case. Most makers say that the state will be determined by whichever input was deasserted last, but TI's datasheet says the state will be undefined. I would be interested to know if the users suffering this problem are using a TI flip-flop.
I was always suspicious of the whole feedback driver concept and preferred to use PLLs.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Mads Barnkob, Thu Aug 29 2013, 08:14AM
Today I will mod the shit of the comparator to eliminate any noise source, maybe except removing the socket.
I am by coincidence using a Motorola flip-flop on this driver. As you said the datasheet from Motorola also states that if both inputs goes high, the outputs are unpredictable.
Edit of modifications tried:
No effect: Add ferrite bead to V- and V+ for comparator MAX913, as described in datasheet.
No effect: Add 10uF tantalum capacitor in parallel with 0,1uF decoupling capacitor between V- and V+, as described in datasheet.
No effect: Add 33pF from IN+ to GND, found in schematics for a high precision clock using MAX913.
No effect: Add 100K and parallel with 0,1uF from IN- to GND, found in schematics for a high precision clock using MAX913.
No effect: Changed C33 from 220pF to 2,2nF, suggested value by Steve Ward for CM600 bricks.
No effect: Changed Motorola 74HC74 flip-flop for a TI 74HC74
No effect: Run without inductor in place, bridged over for resistive burden only.
No effect: Exchange Slot ten 5-09 inductor (16-42uH) for a open frame inductor (15-59uH)
No effect: Grounded the floating pin 1 on 74HC14, the inverting gate left out due to phasing of opto input
No effect: Added 10K pull-up resistors on MAX913 outputs
A question that still remains unanswered is: Is this really an unstable circuit when the double inverter voltage swing is always on the peak primary current?
Mads Barnkob, Thu Aug 29 2013, 08:14AM
Steve Conner wrote ...
My personal theory is that the crud coming out of the unstable comparator confuses the flip-flop with runt pulses and causes it to hang up in an undefined state. Or rather, since it only has two possible states, the opposite state to what it needs to be right now. The gate drive gets turned off when it should be on.
The circuit is capable of asserting Pre and Clr at the same time, and data sheets from different flip-flop makers have different explanations about what happens in this case. Most makers say that the state will be determined by whichever input was deasserted last, but TI's datasheet says the state will be undefined. I would be interested to know if the users suffering this problem are using a TI flip-flop.
I was always suspicious of the whole feedback driver concept and preferred to use PLLs.
My personal theory is that the crud coming out of the unstable comparator confuses the flip-flop with runt pulses and causes it to hang up in an undefined state. Or rather, since it only has two possible states, the opposite state to what it needs to be right now. The gate drive gets turned off when it should be on.
The circuit is capable of asserting Pre and Clr at the same time, and data sheets from different flip-flop makers have different explanations about what happens in this case. Most makers say that the state will be determined by whichever input was deasserted last, but TI's datasheet says the state will be undefined. I would be interested to know if the users suffering this problem are using a TI flip-flop.
I was always suspicious of the whole feedback driver concept and preferred to use PLLs.
Today I will mod the shit of the comparator to eliminate any noise source, maybe except removing the socket.
I am by coincidence using a Motorola flip-flop on this driver. As you said the datasheet from Motorola also states that if both inputs goes high, the outputs are unpredictable.
Edit of modifications tried:
No effect: Add ferrite bead to V- and V+ for comparator MAX913, as described in datasheet.
No effect: Add 10uF tantalum capacitor in parallel with 0,1uF decoupling capacitor between V- and V+, as described in datasheet.
No effect: Add 33pF from IN+ to GND, found in schematics for a high precision clock using MAX913.
No effect: Add 100K and parallel with 0,1uF from IN- to GND, found in schematics for a high precision clock using MAX913.
No effect: Changed C33 from 220pF to 2,2nF, suggested value by Steve Ward for CM600 bricks.
No effect: Changed Motorola 74HC74 flip-flop for a TI 74HC74
No effect: Run without inductor in place, bridged over for resistive burden only.
No effect: Exchange Slot ten 5-09 inductor (16-42uH) for a open frame inductor (15-59uH)
No effect: Grounded the floating pin 1 on 74HC14, the inverting gate left out due to phasing of opto input
No effect: Added 10K pull-up resistors on MAX913 outputs
A question that still remains unanswered is: Is this really an unstable circuit when the double inverter voltage swing is always on the peak primary current?
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Thu Aug 29 2013, 04:32PM
EDIT: Oh man, it has been almost a year when i started this thread
Yeah.. another day and yet still not working UD2
This time we are looking at Pin11 and Pin9 of the flipflop. Seems to be allright there.
Kizmo, Thu Aug 29 2013, 04:32PM
EDIT: Oh man, it has been almost a year when i started this thread
Yeah.. another day and yet still not working UD2
This time we are looking at Pin11 and Pin9 of the flipflop. Seems to be allright there.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Goodchild, Thu Aug 29 2013, 05:16PM
You know Kizmo,
The fact that you have tried so many different boards and so many different fixes kind of indicates to me that it may not be your boards. You know that the UD2 deign works because it has been used successfully by many different people.
At this point I would start to look at factors outside of the board. That's just my two bits.
Goodchild, Thu Aug 29 2013, 05:16PM
You know Kizmo,
The fact that you have tried so many different boards and so many different fixes kind of indicates to me that it may not be your boards. You know that the UD2 deign works because it has been used successfully by many different people.
At this point I would start to look at factors outside of the board. That's just my two bits.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Thu Aug 29 2013, 05:28PM
Does it matter that i can pop in UD1.3 without replacing anything else and make 3 meter sparks?
Kizmo, Thu Aug 29 2013, 05:28PM
Does it matter that i can pop in UD1.3 without replacing anything else and make 3 meter sparks?
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Goodchild, Thu Aug 29 2013, 06:23PM
Well the UD2 works on a slightly different set of parameters, so it doesn't surprise me that you can just drop in a UD1.3 and have it work. What works for the UD1.3 won't necessarily work for the UD2. The UD2 is a bit for finicky about its feedback input and proper tuning than the UD1.3 is. Simple things like this can affect the system drastically.
All I’m saying is that you may want to examine the rest of the system in more detail before you pin the problem on the controller. I'm still very skeptical of you feedback, it doesn't seem like you have checked this in much detail. I would really put your scope in two places, across the phase lead network and on the input of the comparator and look at what you are feeding into the system.
As a wise man once said "crap in = crap out"
Goodchild, Thu Aug 29 2013, 06:23PM
Well the UD2 works on a slightly different set of parameters, so it doesn't surprise me that you can just drop in a UD1.3 and have it work. What works for the UD1.3 won't necessarily work for the UD2. The UD2 is a bit for finicky about its feedback input and proper tuning than the UD1.3 is. Simple things like this can affect the system drastically.
All I’m saying is that you may want to examine the rest of the system in more detail before you pin the problem on the controller. I'm still very skeptical of you feedback, it doesn't seem like you have checked this in much detail. I would really put your scope in two places, across the phase lead network and on the input of the comparator and look at what you are feeding into the system.
As a wise man once said "crap in = crap out"
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Thu Aug 29 2013, 06:36PM
I would have scoped that long time ago but everything around the feedback comparator is eeextremely sensitive to scoping, even my differential probe is enough to throw it from kind of working to not working at all.
And funny thing is, Mads Barnkob has exactly same problem.. :l
Kizmo, Thu Aug 29 2013, 06:36PM
I would have scoped that long time ago but everything around the feedback comparator is eeextremely sensitive to scoping, even my differential probe is enough to throw it from kind of working to not working at all.
And funny thing is, Mads Barnkob has exactly same problem.. :l
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Mads Barnkob, Thu Aug 29 2013, 07:01PM
Here is a scope shot of IN- on the comparator, I am a little vary about that the ringing being a problem as the voltage phase shift only happens on the the peak primary current. But the ringing also seems to seize after the primary current starts to ring down. Perhaps it is just interference from the primary?
Mads Barnkob, Thu Aug 29 2013, 07:01PM
Here is a scope shot of IN- on the comparator, I am a little vary about that the ringing being a problem as the voltage phase shift only happens on the the peak primary current. But the ringing also seems to seize after the primary current starts to ring down. Perhaps it is just interference from the primary?
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Steve Conner, Thu Aug 29 2013, 09:30PM
The challenge is to clean this noisy signal up and produce a nice drive waveform for the bridge even while the system is basically being struck by lightning 200 times per second.
It strikes me that differentiating it with a series inductor maybe isn't the best way to start, as it could amplify the high-frequency noise considerably.
Mads did a test that disproved my flip-flop hypothesis, so here's another one that might fit the new evidence better: Current spikes from the CT get exaggerated by the phase lead inductor and drive the comparator outside of its common-mode range, causing it to latch up.
Another thought: What happens when you remove the phase lead network from the UD2.x (and maybe fit it to the UD1.x?)
Steve Conner, Thu Aug 29 2013, 09:30PM
Goodchild wrote ...
As a wise man once said "crap in = crap out"
A Tesla coil is an extremely noisy system, so there is always going to be "crap in". Switching spikes from the bridge are bad enough, never mind the high frequency hash from ground strikes.As a wise man once said "crap in = crap out"
The challenge is to clean this noisy signal up and produce a nice drive waveform for the bridge even while the system is basically being struck by lightning 200 times per second.
It strikes me that differentiating it with a series inductor maybe isn't the best way to start, as it could amplify the high-frequency noise considerably.Mads did a test that disproved my flip-flop hypothesis, so here's another one that might fit the new evidence better: Current spikes from the CT get exaggerated by the phase lead inductor and drive the comparator outside of its common-mode range, causing it to latch up.
Another thought: What happens when you remove the phase lead network from the UD2.x (and maybe fit it to the UD1.x?)
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Fri Aug 30 2013, 02:24AM
i dont have phase lead inductor in place.
Kizmo, Fri Aug 30 2013, 02:24AM
i dont have phase lead inductor in place.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Mads Barnkob, Fri Aug 30 2013, 06:02AM
I thought about that, because the elevated signal from the feedback CT is approximately up to 2,5V, input range for the comparator is -0,2V to 3,5V, so the spikes in the above scope shot at 3,68V might be it. But the problem also exists at very low duty cycles, where the noise is not yet passing the 3,5V mark.
I tried removing the inductor in the phase lead network and also tried with another type of inductor, it did not change anything.
Yellow: CT input, Blue: Comparator input.
Yellow: Comparator output Q, Blue: Comparator input
Yellow: Comparator output !Q, Blue: Comparator input
Yellow: Comparator output Q, Blue flip-flop Q
Yellow: Pin3 AND gate out, Blue: Pin6 AND gate out (phasing)
Yellow: Pin3 AND gate tout, Blue: Inverter voltage
Yellow: IC9 MOSFET driver, OUT A, Blue OUT B
Yellow, IC9 driven GDT primary, Blue: IC8 driven GDT primary
That last very short peak seen on the GDT primaries, I could only track it back to the AND gate outputs for the phasing, this could be what makes the double inverter voltage?
EDIT 1539CET:
No effect: I tried adding ferrite beads to the supply rails and a 10uF tantalum in parallel with the 0,1uF for the 74HC08 (AND gate)
No effect: Change 74HC08 for another manufacturer, checked soldering and path fot pin6, cleaned out between traces.
Mads Barnkob, Fri Aug 30 2013, 06:02AM
Steve Conner wrote ...
The challenge is to clean this noisy signal up and produce a nice drive waveform for the bridge even while the system is basically being struck by lightning 200 times per second. It strikes me that differentiating it with a series inductor maybe isn't the best way to start, as it could amplify the high-frequency noise considerably.
Mads did a test that disproved my flip-flop hypothesis, so here's another one that might fit the new evidence better: Current spikes from the CT get exaggerated by the phase lead inductor and drive the comparator outside of its common-mode range, causing it to latch up.
Another thought: What happens when you remove the phase lead network from the UD2.x (and maybe fit it to the UD1.x?)
Goodchild wrote ...
As a wise man once said "crap in = crap out"
A Tesla coil is an extremely noisy system, so there is always going to be "crap in". Switching spikes from the bridge are bad enough, never mind the high frequency hash from ground strikes.As a wise man once said "crap in = crap out"
The challenge is to clean this noisy signal up and produce a nice drive waveform for the bridge even while the system is basically being struck by lightning 200 times per second.
It strikes me that differentiating it with a series inductor maybe isn't the best way to start, as it could amplify the high-frequency noise considerably.Mads did a test that disproved my flip-flop hypothesis, so here's another one that might fit the new evidence better: Current spikes from the CT get exaggerated by the phase lead inductor and drive the comparator outside of its common-mode range, causing it to latch up.
Another thought: What happens when you remove the phase lead network from the UD2.x (and maybe fit it to the UD1.x?)
I thought about that, because the elevated signal from the feedback CT is approximately up to 2,5V, input range for the comparator is -0,2V to 3,5V, so the spikes in the above scope shot at 3,68V might be it. But the problem also exists at very low duty cycles, where the noise is not yet passing the 3,5V mark.
I tried removing the inductor in the phase lead network and also tried with another type of inductor, it did not change anything.
Yellow: CT input, Blue: Comparator input.
Yellow: Comparator output Q, Blue: Comparator input
Yellow: Comparator output !Q, Blue: Comparator input
Yellow: Comparator output Q, Blue flip-flop Q
Yellow: Pin3 AND gate out, Blue: Pin6 AND gate out (phasing)
Yellow: Pin3 AND gate tout, Blue: Inverter voltage
Yellow: IC9 MOSFET driver, OUT A, Blue OUT B
Yellow, IC9 driven GDT primary, Blue: IC8 driven GDT primary
That last very short peak seen on the GDT primaries, I could only track it back to the AND gate outputs for the phasing, this could be what makes the double inverter voltage?
EDIT 1539CET:
No effect: I tried adding ferrite beads to the supply rails and a 10uF tantalum in parallel with the 0,1uF for the 74HC08 (AND gate)
No effect: Change 74HC08 for another manufacturer, checked soldering and path fot pin6, cleaned out between traces.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Fri Aug 30 2013, 12:41PM
Because scope shots are nice.
Red: feedback CT input
Yellow: feedback comparator input
These were captured with conventional probes and full 100MHz bw.
Here its kind of working. It sounds like drsstc but burst beginning is still messed up.
Same up close.
And here its glitching heavily. From constant bzzzz to brpbrpbprbprpbprpbrbrbrr.
And closer
At the same time my burst starts look like this:
yellow trace: H-bridge output measured with high voltage differential probe
red trace: primary current measured with pearson current transformer
Kizmo, Fri Aug 30 2013, 12:41PM
Because scope shots are nice.
Red: feedback CT input
Yellow: feedback comparator input
These were captured with conventional probes and full 100MHz bw.
Here its kind of working. It sounds like drsstc but burst beginning is still messed up.
Same up close.
And here its glitching heavily. From constant bzzzz to brpbrpbprbprpbprpbrbrbrr.
And closer
At the same time my burst starts look like this:
yellow trace: H-bridge output measured with high voltage differential probe
red trace: primary current measured with pearson current transformer
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Steve Conner, Fri Aug 30 2013, 09:14PM
Mads, the big series of scope shots you just posted, are these with the circuit operating properly, or is it glitching? They all look fine... :|
Steve Conner, Fri Aug 30 2013, 09:14PM
Mads, the big series of scope shots you just posted, are these with the circuit operating properly, or is it glitching? They all look fine... :|
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Mads Barnkob, Fri Aug 30 2013, 09:51PM
This is with the circuit working without jittering, but still with the weird inverter voltage phase shift. If I had turned the duty cycle pot meter just a little it would jitter all over the screen and give the brpbrpbrpbrpbrpbrp sound
Mads Barnkob, Fri Aug 30 2013, 09:51PM
Steve Conner wrote ...
Mads, the big series of scope shots you just posted, are these with the circuit operating properly, or is it glitching? They all look fine... :|
Mads, the big series of scope shots you just posted, are these with the circuit operating properly, or is it glitching? They all look fine... :|
This is with the circuit working without jittering, but still with the weird inverter voltage phase shift. If I had turned the duty cycle pot meter just a little it would jitter all over the screen and give the brpbrpbrpbrpbrpbrp sound
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Steve Conner, Sat Aug 31 2013, 11:42AM
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.
Steve Conner, Sat Aug 31 2013, 11:42AM
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.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Sat Aug 31 2013, 01:02PM
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.
Kizmo, Sat Aug 31 2013, 01:02PM
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.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Mads Barnkob, Sat Aug 31 2013, 02:42PM
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 :)
Mads Barnkob, Sat Aug 31 2013, 02:42PM
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, 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 :)
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Sat Aug 31 2013, 04:17PM
I tried to shield everything to mains earth grounded foil and even made Faraday shielded feedback transformer just like mr. Conner suggested.
Absolutely no change. Still as bad as it is without any shielding.
This must be by far the ugliest thing i have made.
Kizmo, Sat Aug 31 2013, 04:17PM
I tried to shield everything to mains earth grounded foil and even made Faraday shielded feedback transformer just like mr. Conner suggested.
Absolutely no change. Still as bad as it is without any shielding.
This must be by far the ugliest thing i have made.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
HV Enthusiast, Sat Aug 31 2013, 07:27PM
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.
HV Enthusiast, Sat Aug 31 2013, 07:27PM
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.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Sat Aug 31 2013, 07:59PM
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.
Kizmo, Sat Aug 31 2013, 07:59PM
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.
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.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
HV Enthusiast, Mon Sept 02 2013, 10:58PM
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.
HV Enthusiast, Mon Sept 02 2013, 10:58PM
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.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Mads Barnkob, Tue Sept 03 2013, 02:35PM
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 :)
Mads Barnkob, Tue Sept 03 2013, 02:35PM
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.
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 :)
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Sync, Wed Sept 25 2013, 05:50PM
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:
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.
Sync, Wed Sept 25 2013, 05:50PM
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.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Fri Nov 08 2013, 08:49PM
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...
Kizmo, Fri Nov 08 2013, 08:49PM
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...
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Hydron, Sat Nov 09 2013, 02:13AM
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.
Hydron, Sat Nov 09 2013, 02:13AM
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.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Sat Nov 09 2013, 11:21AM
Some of those scope shots do look very familiar!
I will try to see what happens if i put a power resistor across the bridge output. This may just explain why it works on ud1.3 since it has much more sensitive feedback.
Kizmo, Sat Nov 09 2013, 11:21AM
Some of those scope shots do look very familiar!
I will try to see what happens if i put a power resistor across the bridge output. This may just explain why it works on ud1.3 since it has much more sensitive feedback.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Sat Nov 09 2013, 05:08PM
5k 20W resistor over the H-bridge output did the trick!
Now its nice and clean running at any settings. Phew!
Only took like 3 years and 3 entirely different boards to get this thing figured out..
Hydron: PM me your paypal address (if you have one..) I want to give you a small gift :p
Kizmo, Sat Nov 09 2013, 05:08PM
5k 20W resistor over the H-bridge output did the trick!
Now its nice and clean running at any settings. Phew!
Only took like 3 years and 3 entirely different boards to get this thing figured out..
Hydron: PM me your paypal address (if you have one..) I want to give you a small gift :p
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Mads Barnkob, Sat Nov 09 2013, 09:48PM
This is very exciting news :)
I hope Steve Ward will one day find time to update his website to contain all links to the vast amount of useful information he have online but unlinked :)
I will report back when I have my driver back from Sync.
Mads Barnkob, Sat Nov 09 2013, 09:48PM
This is very exciting news :)
I hope Steve Ward will one day find time to update his website to contain all links to the vast amount of useful information he have online but unlinked :)
I will report back when I have my driver back from Sync.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Dr. Dark Current, Sat Nov 09 2013, 09:57PM
Hehe, good to hear you got it fixed. Strange that since I started thinking about DRSSTCs (though still not built a serious one), I've always seen the need for a discharge resistor which sets the initial charge on the cap. But I have not linked it with your problem, even though the solution was at the back of my head all the time.
Dr. Dark Current, Sat Nov 09 2013, 09:57PM
Hehe, good to hear you got it fixed. Strange that since I started thinking about DRSSTCs (though still not built a serious one), I've always seen the need for a discharge resistor which sets the initial charge on the cap. But I have not linked it with your problem, even though the solution was at the back of my head all the time.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Hydron, Sun Nov 10 2013, 05:51AM
Glad to have been able to help sort this frustrating problem. On the bright side, it sounds like Kizmo has a spare bridge and controller for another coil (twins?)!
In testing my coil I hadn't noticed any issue with startup at certain initial voltages, but I had noticed changes in the voltage spikes for the first cycle or two, depending on initial voltage. As this wasn't causing me any issue I didn't bother investigating further at the time.
I subsequently came across Steve's paper while looking for something else, and it inspired me to add a resistor to my bridge when I made some other changes to it. I haven't yet investigated the effect it had, though I intend to do so, as it could be helpful for perfecting phase lead on early cycles.
Anyway, credit is definitely due to Steve Ward for his investigation, and to the other contributors to this thread, it was just good luck that I'd been thinking about the capacitor voltage issue when the thread got new replies and I checked it!
Hydron, Sun Nov 10 2013, 05:51AM
Glad to have been able to help sort this frustrating problem. On the bright side, it sounds like Kizmo has a spare bridge and controller for another coil (twins?)!
In testing my coil I hadn't noticed any issue with startup at certain initial voltages, but I had noticed changes in the voltage spikes for the first cycle or two, depending on initial voltage. As this wasn't causing me any issue I didn't bother investigating further at the time.
I subsequently came across Steve's paper while looking for something else, and it inspired me to add a resistor to my bridge when I made some other changes to it. I haven't yet investigated the effect it had, though I intend to do so, as it could be helpful for perfecting phase lead on early cycles.
Anyway, credit is definitely due to Steve Ward for his investigation, and to the other contributors to this thread, it was just good luck that I'd been thinking about the capacitor voltage issue when the thread got new replies and I checked it!
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Sun Nov 10 2013, 05:09PM
Aaand the plot thickens.
After getting this UD2.1 i got from slawinski running fine I went ahead and took my trusty old trouble maker UD2.5 out and guess what: It still wont work correctly!
Now it starts fine but still skips half cycles, switching several times at transitions and other weirdness described before. Then i swapped Slawinskis UD2.1 back and it works really well again.
WTF?
Kizmo, Sun Nov 10 2013, 05:09PM
Aaand the plot thickens.
After getting this UD2.1 i got from slawinski running fine I went ahead and took my trusty old trouble maker UD2.5 out and guess what: It still wont work correctly!
Now it starts fine but still skips half cycles, switching several times at transitions and other weirdness described before. Then i swapped Slawinskis UD2.1 back and it works really well again.
WTF?
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Intra, Mon Nov 11 2013, 07:05AM
check the interrupter output PWM generator signal. 555's out or whatever you use.. once upon a time, I had issue, that some positions of uSec had in 1 pulse multiply - 20-30 same uSec pulses with few off time parts inside 1 pulse. that's was bad 555 timer.
Intra, Mon Nov 11 2013, 07:05AM
check the interrupter output PWM generator signal. 555's out or whatever you use.. once upon a time, I had issue, that some positions of uSec had in 1 pulse multiply - 20-30 same uSec pulses with few off time parts inside 1 pulse. that's was bad 555 timer.
Re: Weird intermittent problem with a DRSSTC driver (edit4: fixed?)
Kizmo, Sun Jan 05 2014, 09:27AM
I think this issue is finally fixed for good.
For some reason with phase lead enabled it required even heavier bleeder resistor. Right now everything works just beautiful and phase lead does its thing.
Final bleeder resistor was 4x 10k in parallel. Works well up to 700V bus.
Kizmo, Sun Jan 05 2014, 09:27AM
I think this issue is finally fixed for good.
For some reason with phase lead enabled it required even heavier bleeder resistor. Right now everything works just beautiful and phase lead does its thing.
Final bleeder resistor was 4x 10k in parallel. Works well up to 700V bus.
Print this page