I'm not a fan of using a microcontroller to protect anything valuable like loudspeakers. Microprocessor circuits - unless very carefully crafted, and themselves protected with watchdog timers, brown-out detection, etc. can go into locked-up states, undefined states, or endless loops.
The protection circuitry should be the simplest, hence most reliable, possible.
The protection circuitry should be the simplest, hence most reliable, possible.
I presume you mean this project:
Project 111 - PIC Based Speaker Protection
Firstly, while I share Steerpike's concern of using computers and their necessary and complex software for "critical tasks," I don't see failure at protecting a loudspeaker, even a very expensive one, to be a critical task. If you want to see where computer-related failure of critical tasks costs more than money, such as personal safety and lives, check out comp.risks. The worst case in loudspeaker failure might be in a PA system where failure to warn the public of a danger might cost lives, but that seems a very unusual situation. I doubt anyone involved with design of PA systems would be using microcontrollers in this way, if at all. I've written code for microcontrollers where an error would have worse, if only remotely possible, outcomes.
That said ...
I see the use of microcontrollers as an excellent application for protecting powered speakers where amplifiers are matched to the drivers, and the driver characteristics are well known. A common speaker failure mode is voice coil overheating. Voice coil temperature can easily be simulated through software by reading the voltage driving the voice coil and knowing the driver characteristics (which are discovered by tested to damage or failure at various power levels and frequency ranges). When the temperature approaches a harmful level the processor can turn on a warning LED and lower the gain of the amp until the VC has sufficiently cooled off.
This protection could as well be done with analog circuits, with the driver voltage going to a squarer (multiplier with the driver voltage for both input) for real-time calculation of power, an averager (R-C circuit) to simulate the VC temperature, and a comparator for the temperature limit, though a good model of the VC temperature might be more complex than could easily be simulated in a few analog components.
Looking closer at the link above, most of the protection detection appears to be provided by some diodes and capacitors detecting a sudden DC offset, and a thermisitor detecting output transistor temperature. While this is amplifier protection (and speaker protection against amplifier faults rather than sustained high signal level), what the controller does in this case doesn't look like a lot.
Project 111 - PIC Based Speaker Protection
Firstly, while I share Steerpike's concern of using computers and their necessary and complex software for "critical tasks," I don't see failure at protecting a loudspeaker, even a very expensive one, to be a critical task. If you want to see where computer-related failure of critical tasks costs more than money, such as personal safety and lives, check out comp.risks. The worst case in loudspeaker failure might be in a PA system where failure to warn the public of a danger might cost lives, but that seems a very unusual situation. I doubt anyone involved with design of PA systems would be using microcontrollers in this way, if at all. I've written code for microcontrollers where an error would have worse, if only remotely possible, outcomes.
That said ...
I see the use of microcontrollers as an excellent application for protecting powered speakers where amplifiers are matched to the drivers, and the driver characteristics are well known. A common speaker failure mode is voice coil overheating. Voice coil temperature can easily be simulated through software by reading the voltage driving the voice coil and knowing the driver characteristics (which are discovered by tested to damage or failure at various power levels and frequency ranges). When the temperature approaches a harmful level the processor can turn on a warning LED and lower the gain of the amp until the VC has sufficiently cooled off.
This protection could as well be done with analog circuits, with the driver voltage going to a squarer (multiplier with the driver voltage for both input) for real-time calculation of power, an averager (R-C circuit) to simulate the VC temperature, and a comparator for the temperature limit, though a good model of the VC temperature might be more complex than could easily be simulated in a few analog components.
Looking closer at the link above, most of the protection detection appears to be provided by some diodes and capacitors detecting a sudden DC offset, and a thermisitor detecting output transistor temperature. While this is amplifier protection (and speaker protection against amplifier faults rather than sustained high signal level), what the controller does in this case doesn't look like a lot.
To clarify: I wouldn't trust a microcontroler to keep 50V DC off my $3000 loudspeaker. If part of the amplifier PSU has a catastrphic meltdown, sparks, surges, etc can put the microcontroller out of action and stop it isolating the speakers.
3 or 4 really resilient transistors I trust far more.
More gentle overload conditions, yes - a microcontroller can be useful.
3 or 4 really resilient transistors I trust far more.
More gentle overload conditions, yes - a microcontroller can be useful.
I agree completely that a microcontroller protection system that would work well for most serious faults is not a good idea simply because it would require an extensive setup (its own power supply for one). That said, I am planning on adding a mcu to control the amp mute, and am going to look at muting the amp if DC is detected... in addition to my solid state protection that is already in use (and has already saved my speakers).
I don't understand! It's perfect advice.
The microprocessor watch-dog timer (WDT) is present for exactly this puropse; it keeps the micro from getting stuck in an undefined state, or in an endless loop, (regardless of whether the cause was a software bug, or a hardware glitch) so that it can't neglect its critical duties for any loger than the timeout period of the WDT - a few milliseconds usually.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.