HFU HF Underground

Technical Topics => The RF Workbench => Topic started by: OgreVorbis on June 22, 2019, 2041 UTC

Title: Class D V2.0
Post by: OgreVorbis on June 22, 2019, 2041 UTC
So I have finished my new design with the NCP drivers and eight SiC FETs and I tested it. I am having a bit of a problem with it. Some of the NCPs are heating up and eventually blowing out. It is not happening on a single side of the amp. I currently have only four of the eight FETs along with four drivers populated and two of the four drivers keep blowing out.

Do they need to be balanced somehow? Maybe a current limiting resistor. Right now they are just running in parallel with the 5V square wave drive.

I left out R3 - R6
Here is the schematic:
(http://oi66.tinypic.com/23svvdc.jpg)
Title: Re: Class D V2.0
Post by: redhat on June 22, 2019, 2118 UTC
Since your using the on fet drivers with dual input, you could feed the clock into the inverting inputs on one half of the bridge, and non inverting input on the other.  That would allow you to eliminate the 74HCT14.

Also, depending on power, one turn through the output transformer may exceed the flux density of the material.  I would probably do a two turn primary, four turn secondary, made out of coax.  This would also help control your impedances and keep your strays down.

+-RH
Title: Re: Class D V2.0
Post by: Stretchyman on June 22, 2019, 2130 UTC
I'm in agreement with RH + parasitics can be a real issue with high power RF.

Start with a low Voltage on the FETs and monitor with a scope. You may have to set the trigger up so you capture short duration spikes.

Very layout dependant.

Try small Res in series with FET gates.

Do you have spec ani to monitor the RF O/P? Would help as you can see naughty things beginning to happen.

Need to see some scope traces...

Str.
Title: Re: Class D V2.0
Post by: redhat on June 22, 2019, 2148 UTC
Core saturation will be easy to detect with the trapazoid method under AM conditions.  Slowly increase tone modulation until you see non-linearity start to occur and this is most likely being caused by saturation.

I'm in the process of doing the same thing to my transmitter following a change in the output topology.

+-RH
Title: Re: Class D V2.0
Post by: OgreVorbis on June 22, 2019, 2157 UTC
Since your using the on fet drivers with dual input, you could feed the clock into the inverting inputs on one half of the bridge, and non inverting input on the other.  That would allow you to eliminate the 74HCT14.

Also, depending on power, one turn through the output transformer may exceed the flux density of the material.  I would probably do a two turn primary, four turn secondary, made out of coax.  This would also help control your impedances and keep your strays down.

+-RH

OK, I'll keep that in mind.

I'm in agreement with RH + parasitics can be a real issue with high power RF.

Start with a low Voltage on the FETs and monitor with a scope. You may have to set the trigger up so you capture short duration spikes.

Very layout dependant.

Try small Res in series with FET gates.

Do you have spec ani to monitor the RF O/P? Would help as you can see naughty things beginning to happen.

Need to see some scope traces...

Str.

I do have a spectrum analyzer and scope. I think the problem is likely something more simple than parasitics. The problem happens even with no voltage applied to the FETs. Voltage applied to the drivers is fine, but as soon as I input the square waves, the two drivers begin to heat.

It would be very hard for me to add the Res in series on my board. Plus the amfone guy that this board is based on didn't do that and he claims it works. Only thing I left out are those 330 ohm resistors on the driver's inputs. Not sure if that would help.

I am running the drivers at 18V btw.

Core saturation will be easy to detect with the trapazoid method under AM conditions.  Slowly increase tone modulation until you see non-linearity start to occur and this is most likely being caused by saturation.

I'm in the process of doing the same thing to my transmitter following a change in the output topology.

+-RH

OK, good to know. I'll try that when I get there.
Title: Re: Class D V2.0
Post by: Stretchyman on June 22, 2019, 2204 UTC
Ok, not sure wtf it could be then. You can switch those FETs with 12V, however 15V is marginally better, no need to go to 18V. You have decoupled the drivers VERY closely with 100nF's?

Str.
Title: Re: Class D V2.0
Post by: redhat on June 22, 2019, 2220 UTC
Have you looked at the drive waveforms on the gates to be sure they all look similar?

I had something similar happen recently.  For some reason, one of my rf fets got zinged and the gate had a breakdown.  This was causing excessive loading on the driver.  Replacement of the fet solved the problem.
Title: Re: Class D V2.0
Post by: OgreVorbis on June 22, 2019, 2224 UTC
Ok, not sure wtf it could be then. You can switch those FETs with 12V, however 15V is marginally better, no need to go to 18V. You have decoupled the drivers VERY closely with 100nF's?

Str.

Yep, pretty close.

Have you looked at the drive waveforms on the gates to be sure they all look similar?

I had something similar happen recently.  For some reason, one of my rf fets got zinged and the gate had a breakdown.  This was causing excessive loading on the driver.  Replacement of the fet solved the problem.

I'll check it.

Here is the actual board layout in case you see anything wrong. . .

(http://oi68.tinypic.com/25sagm1.jpg)
Title: Re: Class D V2.0
Post by: redhat on June 22, 2019, 2247 UTC
I'm not real fond of the meandering drive clock trace.  You could wind up with a propagation delay issue where the far end fets are being turned on and off slightly after the close in fets.  This can cause an overlap issue which will hurt your efficiency.

It appears as if your using through-hole parts in dead bug style construction for your bypass capacitors and loading resistors.  Is this correct?  I would use smt chip caps and resistors for this, less stray L, better bypassing and less opportunity for noise pickup.

+-RH
Title: Re: Class D V2.0
Post by: OgreVorbis on June 24, 2019, 0333 UTC
I'm not real fond of the meandering drive clock trace.  You could wind up with a propagation delay issue where the far end fets are being turned on and off slightly after the close in fets.  This can cause an overlap issue which will hurt your efficiency.

It appears as if your using through-hole parts in dead bug style construction for your bypass capacitors and loading resistors.  Is this correct?  I would use smt chip caps and resistors for this, less stray L, better bypassing and less opportunity for noise pickup.

+-RH

I see what you mean and if I ever do another board, I will try that.
But anyway, I don't think that is causing the problem.

My mind is really blown by this problem.

I tried direct driving the FETs with a signal generator and they seem to work. I guess they could be partially damaged or something, but I hooked up each pair and despite the signal generator not giving them their full drive, each pair made about 30W at 13.5V which makes me think they are probably not busted.

The condition when the problem happens is only with input drive to the drivers regardless of if the FETs are powered or not.
I looked at the scope and the waveforms entering the drivers are a little warped, but decent (probably just my cabling). The waves coming out of the drivers are not amped though; they are much less voltage (like 1V or so). They are clearly not working right. Now is it because my circuit is wrong or something with the FETs, I don't know.

My only thought at this point is to remove all the FETs (which will kill them in the process given my design) and power the drivers with no FETs attached. I really don't see what could be wrong with them though and why almost all of them have failed even though they are new.

None of this makes much sense. I have them wired directly to the FETs with no resistor, but I see stretchy and others do the same. I am using the same combination of FET and driver also. I don't see what else there is other than I just got bad parts. I see stretchy, you put a cap in series with the input pin of the driver. Could it be that?
Title: Re: Class D V2.0
Post by: Stretchyman on June 24, 2019, 0731 UTC
Kinda depends on the DC level at the I/P.

You could cut your traces and solder in some caps to see?

Tricky business isn't it!

You'll get there tho' I sure.

Str.
Title: Re: Class D V2.0
Post by: redhat on June 25, 2019, 0040 UTC
Agreed.  When chasing drive problems, I will often substitue a chip cap with the same capacity as your fets and look at the waveforms.  Also, after a repair I always check the gate waveforms and ensure they all look similar.  If not, there can be other bad parts in the circuit, or a weak or damaged driver.

You have checked the VCC at the driver IC's, right?

+-RH
Title: Re: Class D V2.0
Post by: OgreVorbis on June 25, 2019, 0848 UTC
Alright, I did a lot today.

What I found out is that, redhat, you were right about those clock traces. They were reducing the efficiency a bit and rounding the waves. I cut the traces to two of the drivers and inserted the clock directly into them. The waves were much more square after that. They do a little jumping around thing when the fets are powered and I'm not sure why, but they are very square. I switched from using my DDS module and used a signal generator instead cause my DDS got fried somehow.

I removed and replaced all the drivers and identified two broken fets, so I just cut them off the board. Now it seems to be working, but these drivers still get way too hot! I had to put little metal pieces on top of them and that helped, but I have to run them at 12V. If I run them at the 18V, they still get too hot.
Stretchy, you have actually tried these drivers, right? I made sure the waves are clean and measured the gate capacitance at 250pf w/o drivers attached. With them attached, it goes up to 2uF. I don't know if that's normal.

So I could make a new board with the clock traces improved, but these drivers seem no good, so I don't know what to do next. It's weird because the amfone guy used the same driver and fet combination.
Title: Re: Class D V2.0
Post by: Stretchyman on June 25, 2019, 0917 UTC
The drivers are fine and Yes of course I use them! I don't lie!

I had already posted up PCB layouts for single ended and a quad PCB with GaN or SiC.

Here it is again;

(https://i.imgur.com/IZxMwyr.png)

Top Layer in red and bottom layer in blue. Flood fill omitted.

NOTE, heavy decoupling of drivers , A.C. coupling of equidistant clock traces and close proximity of drivers to FET gates.

Str.
Title: Re: Class D V2.0
Post by: OgreVorbis on June 26, 2019, 1111 UTC
Nice. I haven't seen that one before. I found some little heatsinks for the drivers.
I am working on modifying the board now to be more like what you did here. I dropped the inverter chip and I am going to use the inverted inputs on the drivers. I replaced the long winding traces with a long bar that extends along each of them similar to what I have on the output of the fets, just smaller. I will drive with 13.8V or 15V instead of 18V because the efficiency didn't seem any better with that and they got hotter. For the decoupling caps, I switched to SMD. When I'm done I'll post the new board.

I notice you're not using the inverted inputs yourself. Are you driving it that way, or? I know it might be a little better to use an external circuit for that to do 40% duty, but the 50% duty seems to work fine for me.
Do those drivers get hot for you at all? I'm sure it's OK to get a little hot.
Title: Re: Class D V2.0
Post by: Stretchyman on June 26, 2019, 1144 UTC
In this, my 'older' design, I'm using the opposing op's of AD 9850. The drivers do get warm but not overly so. The GaN devices are far easily to drive BTW.

Make sure you A.C. couple the clock as I'm sure that may have caused your 'issues'

Str
Title: Re: Class D V2.0
Post by: redhat on June 26, 2019, 1814 UTC
Make sure you A.C. couple the clock as I'm sure that may have caused your 'issues'

Explain...

+-RH
Title: Re: Class D V2.0
Post by: Stretchyman on June 26, 2019, 1844 UTC
....as there may be DC bias present.

Str.