Audio Power Amplifier Design book- Douglas Self wants your opinions

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Michael . So interesting you say this . I had an application where protection was important ( industrial ) . In the end I added a under run CCS power supply . Simple and 100 % effective . Then I remembered a critical review of the Naim NAP 250 saying the famed power supply was nothing more than a constant current source . Correct and not correct . I find it a mystery why conventional current limiting is used . I doubt it works to anyone's benefit ? The type of CCS I refer to is one that will provide up to that current ( R load requiring far less ) . They are lovely in that they come on gently in most cases .

Surely you mean a current limited source, not a CCS?

These days I find it best to use a microcontroller to handle protection details. Depending on implementation and software you can do any protection scheme you desire. Want it to shut down the amp? No problem. Foldback limiting? No problem. If testing reveals the SOA protection to be inadequate (or excessive), a simple software change can correct it. Of course, the same uC can also monitor other faults, such as OV, UV, DC offset, etc.

Whats more, since the uC already monitors output voltage, current, and temperature it is natural to use it for bias control. Dynamic bias control is a nice option in such a case, especially for MOSFET outputs.
 
Surely you mean a current limited source, not a CCS?

These days I find it best to use a microcontroller to handle protection details. Depending on implementation and software you can do any protection scheme you desire. Want it to shut down the amp? No problem. Foldback limiting? No problem. If testing reveals the SOA protection to be inadequate (or excessive), a simple software change can correct it. Of course, the same uC can also monitor other faults, such as OV, UV, DC offset, etc.

Whats more, since the uC already monitors output voltage, current, and temperature it is natural to use it for bias control. Dynamic bias control is a nice option in such a case, especially for MOSFET outputs.

Interesting, have you tried a true SOA protection implemented with a microcontroller? Asking because SOA catastrophic failures happen usually in much less than <1uS. Unless you are using a very fast microcontroller (definitely a PIC or Atmel won't do), the time required to detect, process an interrupt and actuate will be significantly larger than that. Kinda very fast, but not fast enough fuse...

IMO, regular microcontrollers would work well for output DC offset, power on/off sequencing, temperature monitoring, fan control, overcurrent protection, and other such utilities, but for true SOA protection they are either largely ineffective or non-economical.
 
These days I find it best to use a microcontroller to handle protection details. Depending on implementation and software you can do any protection scheme you desire. Want it to shut down the amp? No problem. Foldback limiting? No problem. If testing reveals the SOA protection to be inadequate (or excessive), a simple software change can correct it. Of course, the same uC can also monitor other faults, such as OV, UV, DC offset, etc.

Whats more, since the uC already monitors output voltage, current, and temperature it is natural to use it for bias control. Dynamic bias control is a nice option in such a case, especially for MOSFET outputs.
Would you post a simple example of your work?

If you are reluctant to post the whole thing, could you tell us how you actually limit current/signal or shut down the amp?
 
Interesting, have you tried a true SOA protection implemented with a microcontroller? Asking because SOA catastrophic failures happen usually in much less than <1uS. Unless you are using a very fast microcontroller (definitely a PIC or Atmel won't do), the time required to detect, process an interrupt and actuate will be significantly larger than that. Kinda very fast, but not fast enough fuse...

If you had to go for a fast microcontroller, you'd not want to waste time on interrupts, you'd be dedicating it to this function, continuously digitizing output current and voltage (because ADCs are cheap and often included) and doing the necessary math. An ARM at 72MHz (genuinely 72 million 32bit instructions per second) costs a couple of $ nowadays. 200MHz, maybe $5.
 
Does the 3 slope circuit take account of time constants? I ask because when I've looked at SOA curves, they're time dependent - the 10uS one is considerably different from the 10mS. At some point, with the progress of uCs, it will become less and less cost-effective to oversize the output stage vs using a uC.
 
Interesting, have you tried a true SOA protection implemented with a microcontroller? Asking because SOA catastrophic failures happen usually in much less than <1uS. Unless you are using a very fast microcontroller (definitely a PIC or Atmel won't do), the time required to detect, process an interrupt and actuate will be significantly larger than that. Kinda very fast, but not fast enough fuse...

IMO, regular microcontrollers would work well for output DC offset, power on/off sequencing, temperature monitoring, fan control, overcurrent protection, and other such utilities, but for true SOA protection they are either largely ineffective or non-economical.

Yes, true SOA. Whether it's economical in any given application depends on the price point of the finished product. It's probably not cost effective for a consumer integrated amp, but it may be for something like an expensive, high power pro audio amp.

Would you post a simple example of your work?

If you are reluctant to post the whole thing, could you tell us how you actually limit current/signal or shut down the amp?

Unfortunately, it's covered by an NDA, so I cannot discuss details. However, as with other schemes the basic premise is to shunt drive away from the output stage. The only real difference is that the control is done by a uC and a pair of DACs rather than discrete analog circuitry.

If you had to go for a fast microcontroller, you'd not want to waste time on interrupts, you'd be dedicating it to this function, continuously digitizing output current and voltage (because ADCs are cheap and often included) and doing the necessary math. An ARM at 72MHz (genuinely 72 million 32bit instructions per second) costs a couple of $ nowadays. 200MHz, maybe $5.

A 32 bit device is overkill, but they are getting so cheap it doesn't really matter. The biggest thing is handling data from several high speed ADCs and processing that continuous data in an efficient manner. As with many other uC based control systems, LUTS significantly reduce the computational load, allowing a lower performance processor to be used.

Yes they are very cost effective (my employer is a big supplier of these things BTW). But a controller running flat out is not as elegant as a 3 slope SOA circuit IMV. However, as I noted earlier, I've just gone down the over sizing route with fast response on over current.

Actually, the uC is more elegant. It allows you to create an SOA protection envelope with an arbitrary shape, which is not practical with a conventional approach.

But then you need to concern yourself with whether the uC always running is degrading the sound through some interference interaction - yes, always solvable but then that solution may start to cost money ... it's always a big picture approach ...

These same concerns exist in any digital audio circuitry. The methods for eliminating interference from the digital circuitry are well understood and pose no unique challenges in this application.
 
AX tech editor
Joined 2002
Paid Member
Asking because SOA catastrophic failures happen usually in much less than <1uS. Unless you are using a very fast microcontroller (definitely a PIC or Atmel won't do), the time required to detect, process an interrupt and actuate will be significantly larger than that. Kinda very fast, but not fast enough fuse...

Are you implying that your analog circuit and/or fuse is faster than 1uS?
I'd really would like to see that circuit!

Jan
 
Last edited:
If you had to go for a fast microcontroller, you'd not want to waste time on interrupts, you'd be dedicating it to this function, continuously digitizing output current and voltage (because ADCs are cheap and often included) and doing the necessary math. An ARM at 72MHz (genuinely 72 million 32bit instructions per second) costs a couple of $ nowadays. 200MHz, maybe $5.

One of the most advanced MCU's today, an ARM R4 running at 80-160MHz, the TMS570 from TI (costs anywhere between $5 and $20 in 1000's), is doing 12bit sample + hold and full conversions in 600nS. See the data sheet at pp. 112.

Not fast enough, even before considering the time required to compute and actuate. I would appreciate if you or Defiant could indicate a proper MCU for this application, I can't find any. Of course, there is always the possibility of an external fast DAC but then IMO this goes well over the level of complexity (and cost) that would make sense for such an application. But then if there is a place in the audio market that would justify such, so be it.

I must admit I'm rather tired of the "under NDA" type of arguments when it comes to the details of such extravagant solutions.

P.S. "A/D Conversion complete" is always an interrupt.
 
Last edited:
just speculating - but how does 1 us enter the picture with audio signal, passive load?

what fault(s) are capable of violating SOA on that time scales?

any normal speaker load Z, audio signal I,V locus will not have the speed
so simple "overdrive" protection shouldn't need 1 us speed
 
just speculating - but how does 1 us enter the picture with audio signal, passive load?

what fault(s) are capable of violating SOA on that time scales?

any normal speaker load Z, audio signal I,V locus will not have the speed
so simple "overdrive" protection shouldn't need 1 us speed

Of course this is not about normal speaker loads and signal I,V. Think about clipping conditions, worst case reactive and/or load shorts.
 
just speculating - but how does 1 us enter the picture with audio signal, passive load?

what fault(s) are capable of violating SOA on that time scales?

any normal speaker load Z, audio signal I,V locus will not have the speed
so simple "overdrive" protection shouldn't need 1 us speed

At a second thought, I find this SOA protection strategy essentially not much different than clipping protection strategy.

There are two options: the easy way is to make sure that the output devices never enter the danger SOA region. This doesn't require in particular fast circuits, and neither does a circuit that is soft limiting the input signal, so that no clipping conditions occur.

The second approach is to pull out the devices from the SOA danger region, this is much more difficult and requires high speed circuitry. So is providing an amplifier controlled clipping circuit, by e.g. killing the loop gain. This also requires circuitry with controlled response up to the ULGF frequencies.
 
AX tech editor
Joined 2002
Paid Member
I guess we are talking different things. The standard dual slope SOA protection scheme (with 2 transistors and a few resistors and Zener diodes) can do well under 100nS, unless slowed down on purpose.

Yes is can switch in that time, but that's not the issue, is it?
You have to DECIDE when to switch first.
How much time you you need to decide that your are approaching the 1uS - or any other - SOA limit?

Jan
 
Yes is can switch in that time, but that's not the issue, is it?
You have to DECIDE when to switch first.
How much time you you need to decide that your are approaching the 1uS - or any other - SOA limit?

You lost me - this is about analog electronics, there's nothing like deciding and branching. There is no 1uS SOA limit, it's about how much a device can survive outside the SOA limits (that is, until the hot spots melt end short the device). That's well under 1uS.

Think non destructive SOA testing, lots of references about in the last 20 years.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.