S.I.M.P.L.E. protection indicators

[unclejed613]

had an idea i'd like to bounce off everybody.....

i've seen LEDs used for protection indicators, but usually with comparators, complicated detection circuits, even microprocessors, but my thought was to KISS (Keep It Simple Stupid).

i have been using an "offset sniffer" LED where i work. i built it from a 2 color (red-blue) LED, i've also found it useful to connect LEDs to the protection transistors in amplifiers i'm troubleshooting to see which ones are triggering (as well as under which conditions they are triggering), i got to thinking that putting these LEDs in place permanently might not be a bad idea, since it would bypass about 1/2 hour or more of poking around to find out what is causing an amp to shut down. i work on a lot of surround receivers where the amp section is buried beneath layers and layers of pc board puzzle pieces, and having some simple indicators built in to the amps and protection circuits certainly would save a lot of time on the bench. most receivers have protection shutdown performed by a microprocessor, but rarely does a manufacturer have a system that tells you why it's shutting down, and even the ones that do, don't tell you which channel has a problem. some pro-audio amps have overcurrent and offset indicators on the front panel, but these are usually driven with complex circuits to keep from getting false triggers. my idea would be to have simple indicators on the amp board itself, so the complexity could be greatly reduced because you're looking for an LED that lights up between turn-on and shutdown, and you aren't necessarily concerned what the LEDs do during normal operation of the amp.

S.I.M.P.L.E. Simple Indicating Multiple Protection Light Emitters (is it bad form to use a word in an acronym that the acronym spells out?)

any thoughts?

[juma]

Originally posted by unclejed613
.... (is it bad form to use a word in an acronym that the acronym spells out?)...

It's called recursion and it might be fun:
GNU (GNU's Not Unix)
PHP (PHP: Hypertext Preprocessor)

[AndrewT]

the problem might be seeing the LED flashing on then off as the protection shutsdown the amplifier.
It could all be over in a few milliseconds.

Latching the indicator LEDs adds a lot of non-SIMPLE.

[Eva]

Don't discard microcontrollers, my current project uses one and gives over 10 different error codes by blinking just a single led. It can keep track of the latest errors too, and does the job of hundreds of discrete parts.

[unclejed613]

while the micros are useful for shutting down before (usually) the damage spreads, the LEDs would give an indication of a) which channel(s) have a problem, and b) an idea what the failure is. or with a multichannel amp without a micro, powering the amp up using the light bulb trick would give enough information from the LEDs where the problem lies. i was thinking it would be a helpful idea with or without a micro. and, a latching LED probably would be too complicated. i was just thinking of providing each channel with a red/blue LED for dc offset, and one (maybe yellow) LED for overcurrent. and maybe green LEDs for each power supply rail and if i got LED-happy enough, blown fuse indicators..... (i posted a while back about a tech that asked me not to embarass him by pointing out a blown fuse on an amp he was working on, so i showed him how to troubleshoot the amp, beginning with the unlit FL display, and working backwards a step at a time until we found...... a blown fuse..... )

[wg_ski]

Originally posted by Eva
Don't discard microcontrollers, my current project uses one and gives over 10 different error codes by blinking just a single led. It can keep track of the latest errors too, and does the job of hundreds of discrete parts.

Please tell me you're not running embedded Winbl*ws NT/XP (like Agilent)...... 4 Gig of RAM is cheap these days, but ridiculous for an AUDIO AMPLIFIER

[unclejed613]

actually most of the receivers i see are running DSP code with an RTOS, mostly ADI blackfin or Sharc. DSP chips have just enough brains to do the DSP and receiver functions and talk to the front panel buttons and FL display. it's blu-ray players, DVD recorders and DVR's that are using embedded versions of window$ or linux. you can tell the ones using embedded window$, they're the ones that take 5 minutes or so to "boot" before being able to play a disk.

[wg_ski]

Originally posted by unclejed613
you can tell the ones using embedded window$, they're the ones that take 5 minutes or so to "boot" before being able to play a disk.

Don't I know it... the DVR and satellite receiver are border on ridiculous when the power glitches or the signal gets interrupted for an instant by weather. And our newer equipment in the lab at work - (don't get me started) turn it on and go to lunch. The calibration folks wonder why we jealously hold on to our old HP8510's and 8340/50's instead of dumping them.

The last uC app I did was to control some power-on sequencing and required 236 BYTES of code. Not k, not Meg. Assembly language.

[unclejed613]

one of my current projects is a SDR (software defined radio) app, using a DSP, a couple of AD/DA blocks, and a radio transciever. the interface will be TCP/IP, small scanned keyboard and small LCD graphic display using a combo of embedded linux for the interface and DSP/RTOS for the radio. nothing that takes more than a few seconds to self-test and begin operating. there's no need for the layers of .VXD, .DLL, and whatever that even small embedded window$ apps need. it doesn't seem like microsoft has ever fixed their memory reshuffling when an app closes, there's still a long delay between closing an app, and the memory it used becoming available for other apps. there's even a bit of a delay from when you close an app, and are able to open it again. i don't know if that applies to embedded versions but i still see it in PC versions. i did have a compaq/hp pocket PC and you actually had to go into the memory manager to close an app and free up memory, even if you hit the exit or close button in the app. the app would stay running in memory until you went to the memory manager and stopped it.

amps and receivers don't need a whole lot of processing horsepower, but i'm seeing a trend towards surround receivers that download their own firmware upgrades over the internet, download new surround "venues" and "talk" to other equipment connected to them. i just got an email from the HDMI Institute last month annoncing that they have released HDMI 1.4, which among other things, now passes TCP/IP traffic over the HDMI cable.

[currentflow]

unclejed613 - You appear to have the necessary skills to develop code for a microcontroller, which has the potential to fulfil the requirement. I agree with Eva in that these devices can be used to monitor, process and indicate many conditions without having to build much discrete circuitry.

My preference is the Atmel 8-bit RISC series of devices. These are cheap, readily available and can be programmed via a parallel port (if you still have one!) using only 4 resistors, or via an inexpensive USB programmer under either Windows or Linux platforms. The assembler / compiler is free to download (WinAVR) and you can choose between assembler or C. There is also BASIC, although I'm not sure if there's currently a free version.

The devices have a built-in RC clock, which is adequate for non-critical timing purposes and saves a crystal and two capacitors. A built-in UART would give remote monitoring and control. The possibilities are endless...

A useful amplifier health-monitoring program should easily fit into several K bytes of program memory even if programming in C.

Regards,

Steve
(I don't have any vested interest in ATMEL btw!)