Re: Bizzare behaviour from SG/UC3525


Fritz Schlunder wrote:

> "Pooh Bear" <rabbitsfriendsandrelations@xxxxxxxxxxx> wrote in message
> news:42B8B135.8312B355@xxxxxxxxxxxxxx
> > Hi,
> >
> > you may have noted my posts about problems recently with my attempts to
> > make a high power smps.
> >
> > I'll give a quick overview.
> >
> > The application is a high power pro-audio amplifier.
>
>
> > I noted in passing that the 3525 seemed to be sensitive to noise on the
> > shutdown pin. Odd, since the IC block diagram shows that to be a 'slow'
> > input. It has to discharge the soft-start cap. Soft-start is working
> > fine. But my grounds should be clean - I've got a Kelvin connection to
> > the low-side IGBT emitter mere cm away.
> >
> > Right now I feel like I'm going slightly mad. Maybe the pcb guy did
> > something wacky I've totally missed - but he's rarely that useless.
> >
> > Does unequal duty cycle on OutA and OutB ring any bells with 3525 users
> > ? It's baffling me !
>
> It sounds like this is for your employment.

Yes.

> Therefore my first
> recommendation is that you might consider using an off the shelf powersupply

Not even remotely competitive with regard to price. Usually 2-3 X out of the
ball park. Been there looked at it many times with regard to smaller flyback
supplies. Also the 'form factor' needs to suit our product - not the other way
round ! We're also not making 100,000 + of these so they won't tool up a special
for us.

> or working with a company that specializes in designing and manufacturing
> SMPS designs specially for people such as yourself.

We did investigate a guy some yrs back who promoted himself in this respect. He
came up with a design that's astonishingly similar to that I mentioned elsewhere
in this thread that's made by one of the leading pro-audio amplifier
manufacturers ( actually their Mark One version of amp with smps supply ). I'm
not sure which one came first. His price was idiotic IMHO. I also know a company
that actually engaged him to do indeed what you suggest and he made plenty of
bangs himself and it took ages to tame !


> You could spend all day
> (weeks/months/perhaps even years) banging your head against the wall in
> frustration. In the end you might end up with a product that seems reliable
> and meets your requirements to your satisfaction only to find in your horror
> that once deployed in the field it experiences all sorts of unanticipated
> failures.

I'm normally the guy who then gets employed to fix it ! I have a track record of
resolving 'runaways' for other ppl. That's another story ( or several ).

Also - getting it right means we have the skill in house and can trot it out
thereafter every time we need it - which will be often - trust me. Once we have
the technology tamed we won't be using big line freq TXs anymore.

> It is very easy to overlook things in an SMPS even when it seems
> to be operating well. If you are a generalist doctor (or even a podiatrist)
> you probably have no business performing heart transplants when there are
> plenty of heart surgeons available.

But this is no ordinary heart. It's not a type of design that neatly falls into
most categories that an average psu designer would have met anyway !


> Nevertheless for your own edutainment it would still be very valuable to
> pursue the causes of your current SMPS ailments on your own time.

I've done the required development very successfully in my employment time with
regard to flyback designs.

Are you simply suggesting 'get someone else' who'll take another yr to make
something that half works ? I've seen companies do that. I've seen what 'blokes
who know' design. I'm not sure sometimes if I should laugh or cry. There is *no*
way we can afford to be so sloppy. Managers like this approach though since it
isolates them from responsibility - i.e. blame culture.

Anyway - that's not going to happen. I've never failed to take a project to a
succesful conclusion.

I'm not one who shrinks from acquiring new skills. I also design audio DSP now.
I didn't do that a couple of yrs back either. My effects ( reverb etc )
algorithms have been *very* well received ( i.e. bettter than what's typically
available from OEMs out there ). That's the point of learning to do it yourself
- You're in control and can make it *better* than the usual junk. It's what I
call R&D.


> By the sounds of it your design has multiple weaknesses/problems which may
> or may not be directly related to each other.
>
> In particular the IR2110 seems to have attracted your intense scrutiny,
> however I would venture to guess it is probably only an innocent victim.

Quite possibly so.

> As
> for the OutA/OutB jitter/unequal pulse width problems (as well as the human
> hand near the design and it changes performance), this can probably be
> explained by either your implementation of or your understanding of 3525
> pins 1, 2, 8, 9, and 10 (for dual inline package).

1 and 2 are tied since we only need max duty cycle. 9 is therefore open - we
don't use the error amp at all. 8 has the usual cap to gnd.

> These are all extremely
> important pins which are normally driven by relatively high impedance
> signals. They are quite sensitive and are quite integral to the control
> loop and the general proper functioning of your device.
>
> In particular the shutdown pin is not "slow acting" like you have theorized.
> It would appear from the block diagram that even a very momentary high
> signal on this pin will instantly turn off the output NOR gates, as well as
> set the PWM latch thus keeping the outputs off until at the very least the
> next cycle of the oscillator. How fast the outputs turn back on depends on
> what happened to the soft start capacitor.

As far as I saw, the shutdown pin simply discharges the soft start cap. I *know*
it does this slowly since asserting shutdown briefly *doesn't* immediately reset
the duty cycle to zero. This is a failure in someone else's implementation of
this part that I'm aware of. I put a 555 mono there to stop that. It gets a damn
good long shutdown signal from me.


> As for your IR2110 fizzling... It seems to me that if the output IGBTs
> haven't failed,

They do normally !

> then clearly something is very wrong. I guess that is
> obvious since the IR2110 failed...

Yeah - that really puzzled me. Only happened that way once after I put a 10nF
decoupling cap to gnd local to the shutdown pin. I haven't tested the theory
that the 2 are related since I'd run out of a supply of spare IR2110s at the
time !

> Without a schematic it is very hard to
> say exactly what you are doing and how turning off the 3525 might have
> effected the IR2110. What is the nature of your powersupply source for the
> 3525 and IR2110? Maybe one theory might be the IC bias powersupply is not
> properly regulated, and when the 3525 load was removed the voltage overshot
> way exceeding the IR2110 absolute maximum rating.

No. It's just a classic line freq TX with cap filter. It'll be a baby flyback
switcher in production / next incarnation. Used a line freq tx for now simply
for convenience. 1000uF of filter cap btw. Vsupervisory is about 14V typ. I'll
make it a couple of volts higher on the real thing. No significant ripple
voltage on it either.


> Another theory that I
> had, but consider quite unlikely, is that perhaps when the 3525 turned off
> the output effectively went high impedance, and perhaps stray capacitance
> was coupling the output of the IR2110 signal back to the inputs, thus
> causing it to oscillate at high frequency.

That theory would indeed tend to explain such 'odd' behaviour. I'd believe that,
if it wasn't that this certain company is making tens of thousand of these units
every year with proven reliability that are the industry norm that couples these
exact same 2 devices exactly the same way as me too !

> In this case, perhaps the IR2110
> internal power dissipation grew too large and it subsequently toasted. I
> find this theory unlikely however since the IR2110 inputs have schmitt
> triggers and internal pull down resistors, and the input/output phasing
> would have to be inverted for this to happen.
>
> Whatever the cause of this problem, it sounds like it has a relatively low
> chance of being directly related to your other pulse width/jitter problems.
> I would not look directly at the IR2110 for the source of your problem as
> much the circuitry surrounding and hooked up to the IR2110 for the root
> cause.

I think you're right.

> Aside from these considerations... Current limiting? You are using it
> right? Right??

Implemented my own way using a current sense R in the return path to the Vbus
centre tap.

I've got an LM393 looking at + - volts across the current sense shunt and
sending a level shifted signal to a 555 mono that then asserts shutdown on the
3525. I used a 555 since I saw in advance that shutdown on the 3525 wasn't fast
acting.

Been tested ( adjusted the sensitivity to play with it ) - works a treat. It
does that perfect 'burp mode'.


> Without it you are liable to get some kind of STD

STD ? I rather think you don't mean sexually transmitted disease ! That acronym
I'm not familiar with I regret.

> or
> something. Any high power SMPS which has any hope of being remotely
> reliable must implement some kind of highly effectual current limiting.

Perfectly understood.

> The
> soft start and shutdown pins of the 3525 may play some role in a given
> current limiting implementation, but it is up to you to decide exactly how
> best to do it in your application.

I agree.

> I personally like implementations that
> have two levels of safety. One level instantly shuts off the output as fast
> as possible (IE: <1us, preferably <<1us) upon detection of excessive
> instantaneous current, but doesn't latch the output off for very long (IE:
> perhaps only for the remainder of the given PWM cycle).

Cycle skipping in effect ?

> The other level of
> safety measures the time averaged current and shuts the device down for
> several cycles upon detection of excessive average current. The fast cycle
> by cycle current limit is the best, but unless it is extremely fast

Yes !

> it may
> not be able to keep the average duty cycle sufficiently small under all
> conditions, depending upon how it was implemented.

Which why I didn't follow brand X's method.

> Keep in mind that any
> current limiting scheme has the potential to interfere with the voltage
> control loop whenever it gets activated.

There is *no* voltage control loop. The psu is run open-loop. Vout = Vbus / tx
ratio. In fact in this instance being a half-bridge there's 160V typically
across the tx primary and the centre tapped secondaries on the main outputs are
also 80-0-80.

See my previous introductory comments about why this is done for huge audio
amplifiers. Actually this is the tiddler ! The bigger one will provide around +
- 130V @ 50 A pk ! Times 2 chs. And idle current is about 50mA !

Thanks for your detailed and considered input.

Regds Graham


.

Relevant Pages

  • Re: Bizzare behaviour from SG/UC3525
    ... > The application is a high power pro-audio amplifier. ... In particular the shutdown pin is not "slow acting" like you have theorized. ... next cycle of the oscillator. ... Any high power SMPS which has any hope of being remotely ...
    (sci.electronics.design)
  • Re: Making the case for repeat
    ... keep a straight face. ... The goal for API design is having simple parts that are easily ... I question the utility of some combining repeatand cycle() ... design of itertools), look at the classic Hughes' paper "Why ...
    (comp.lang.python)
  • Re: [PATCH 1/6] new timeofday core subsystem for -mm (v.B3)
    ... On Mon, 20 Jun 2005, john stultz wrote: ... for a reasonable range of timesource frequencies and interval ... the cycle values needs to be 64 bits wide and the mult/shift ... What's exactly wrong with old design and why wasn't possible to fix it ...
    (Linux-Kernel)
  • Re: Superscalar Out-of-Order Processor on an FPGA
    ... Only when I have some design which I believe would be reasonable I start ... Cycle C tells me right away that the architecture does what its ... I do recall my days at Inmos where the Transputer was all over very ... and much of it before any gate level simulation decades before ...
    (comp.arch.fpga)
  • Re: Six Stroke Engine
    ... The clever new six-stroke design was developed by 75-year-old mechanic ... owner of a company which produces high-performance cams and other engine ... the water immediately ... and then the six-stroke cycle begins again. ...
    (misc.rural)