Critical Redundancy - One LED fails, another takes over ?

Consider traffic lights, warning lights, similar.

It's not as simple as dividing the drive current
in half because LED brightness is not strictly
linear to the current.

Searches really don't bring up much here.

Yea, there are more complex solutions ... but
what can be done with the fewest, simplest,
most robust parts ?

Not strictly Linux, but we DO sometimes wanna
drive external displays. Usenet electronics
groups ... dismal at this point.

LEDs are great, but never "forever". They DO
fail - but for some safety apps you can't
just HAVE things go black.

--
033-33

On Tue, 26 Nov 2024 02:24:12 -0500, 186282@ud0s4.net wrote:

> Critical Redundancy - One LED fails, another takes over ?

Complicated question. For a complete catastrophic failure where the LED is
either open or shorted a couple of transistors might do it. Even that
would be difficult if a PWM dimmer is used.

Even worse the degradation may be light output and/or color rather than a
simple go / no go.

Then you get into the human part of the equation:

https://learn.sparkfun.com/tutorials/light/visible-light

I'd actually been playing with PWM output in a Pico with C. The Uno piles
a lot of sugar on it with analogWrite rather than the Pico SDK
hardware_pwn

https://cec-code-lab.aps.edu/robotics/resources/pico-c-api/
group__hardware__pwm.html

I've got to play with it a little more but simply incrementing the duty
cycle isn't too smooth perceptually.

On 26. Nov 2024 at 08:24:12 CET, "186283@ud0s4.net" <186283@ud0s4.net>
wrote:

> LEDs are great, but never "forever". They DO
> fail - but for some safety apps you can't
> just HAVE things go black.

Hmm, just a thought:
If I understood the problem correctly, you want the LED to show some
failstate, right?

What if you switch the LED on when everything is fine and off would signal
a fail?

If the LED is off then you know it´s either a fail or the LED is broken.
Either way you have to do something.

186282@ud0s4.net <186283@ud0s4.net> wrote:
> Critical Redundancy - One LED fails, another takes over ?
>
> Consider traffic lights, warning lights, similar.
>
> It's not as simple as dividing the drive current in half because LED
> brightness is not strictly linear to the current.

LED's are, at a low level, 'current' responsive lights. Driving them
with a current source is the best way to drive them.

> Searches really don't bring up much here.
>
> Yea, there are more complex solutions ... but what can be done with
> the fewest, simplest, most robust parts ?

fewest, simplest, most robust -- you get to pick two....

The simplest (if you can assume the upstream power supply will be
functional [1]) is to drive each in parallel with their own current source
(fixed current driver). I.e.:

PSU
|
+-------+-------+
| |
driver driver
| |
LED LED
| |
+-------+-------+
|
Gnd

Then if one led (or its driver) fails, the other continues to operate,
because it does not depend upon the first one.

But this is far from 'fewest' parts, as you need one driver per led.
While some driver chips can be had for pennies each in 1K quantities,
that still adds to the BOM cost in the end.

> Not strictly Linux, but we DO sometimes wanna drive external
> displays. Usenet electronics groups ... dismal at this point.
>
> LEDs are great, but never "forever". They DO fail - but for some
> safety apps you can't just HAVE things go black.

Most LED's that fail do so because they are being driven hard [2]
(right at the limits that they are rated for, if not well beyond
sometimes). If you derate your drive by a fair amount you'll find they
do, in fact, appear to last nearly forever. But then you will need
more LED's for an equivalent amount of lumens of light output.

[1] redundant PSU's are a different matter

[2] And they are being driven hard because the Shenzen engineer
optimized for lowest BOM cost posible without regard to lifespan of the
device.

Rich <rich@example.invalid> wrote:
> 186282@ud0s4.net <186283@ud0s4.net> wrote:
> LED's are, at a low level, 'current' responsive lights. Driving them
> with a current source is the best way to drive them.
>
>> Searches really don't bring up much here.
>>
>> Yea, there are more complex solutions ... but what can be done with
>> the fewest, simplest, most robust parts ?
>
> fewest, simplest, most robust -- you get to pick two....
>
> The simplest (if you can assume the upstream power supply will be
> functional [1]) is to drive each in parallel with their own current source
> (fixed current driver). I.e.:
>
> PSU
> |
> +-------+-------+
> | |
> driver driver
> | |
> LED LED
> | |
> +-------+-------+
> |
> Gnd
>
>
> Then if one led (or its driver) fails, the other continues to operate,
> because it does not depend upon the first one.

Unless the driver chip fails short-circuit, causing the PSU to shut
down power to both drivers.

> But this is far from 'fewest' parts, as you need one driver per led.
> While some driver chips can be had for pennies each in 1K quantities,
> that still adds to the BOM cost in the end.

If the PSU has regulated voltage output, or LED brightness can vary
with the supply voltage (such as from a battery), then a resistor
would do instead of the LED drivers.

>> Not strictly Linux, but we DO sometimes wanna drive external
>> displays. Usenet electronics groups ... dismal at this point.
>>
>> LEDs are great, but never "forever". They DO fail - but for some
>> safety apps you can't just HAVE things go black.
>
> Most LED's that fail do so because they are being driven hard [2]
> (right at the limits that they are rated for, if not well beyond
> sometimes). If you derate your drive by a fair amount you'll find they
> do, in fact, appear to last nearly forever. But then you will need
> more LED's for an equivalent amount of lumens of light output.

Or use high-brightness LEDs where low-brightness ones would
normally be sufficient at their maximum current.

But unless there's something specific that makes these LEDs more
likely to go wrong, I'd expect the drive circuitry and wiring to
be as common a point of failure as the LEDs themselves. To detect
open-circuit/short-circuit, you could pass a small current through
them and use that to tell whether the LED is OK (current is correct
for the LED's forward voltage drop specification), triggering a
single bulb-failure warning if it's not (possibly simpler in
practice than duplicating every LED on a display panel, even if
the total number of components is similar).

--
__ __
#_ < |\| |< _#

Computer Nerd Kev <not@telling.you.invalid> wrote:
> Rich <rich@example.invalid> wrote:
>> 186282@ud0s4.net <186283@ud0s4.net> wrote:
>> LED's are, at a low level, 'current' responsive lights. Driving them
>> with a current source is the best way to drive them.
>>
>>> Searches really don't bring up much here.
>>>
>>> Yea, there are more complex solutions ... but what can be done with
>>> the fewest, simplest, most robust parts ?
>>
>> fewest, simplest, most robust -- you get to pick two....
>>
>> The simplest (if you can assume the upstream power supply will be
>> functional [1]) is to drive each in parallel with their own current source
>> (fixed current driver). I.e.:
>>
>> PSU
>> |
>> +-------+-------+
>> | |
>> driver driver
>> | |
>> LED LED
>> | |
>> +-------+-------+
>> |
>> Gnd
>>
>>
>> Then if one led (or its driver) fails, the other continues to operate,
>> because it does not depend upon the first one.
>
> Unless the driver chip fails short-circuit, causing the PSU to shut
> down power to both drivers.

fewest, simplest, most robust -- you get to pick two.....

>> But this is far from 'fewest' parts, as you need one driver per led.
>> While some driver chips can be had for pennies each in 1K quantities,
>> that still adds to the BOM cost in the end.
>
> If the PSU has regulated voltage output, or LED brightness can vary
> with the supply voltage (such as from a battery), then a resistor
> would do instead of the LED drivers.

Yes, and you still have the same potential for a possible "fail short"
with a current limiting resistor, which would then drive that led with
too much current. And if it happens to fail short when overdriven too
much, you are back to your 'fail short' for the "drivers".

>>> Not strictly Linux, but we DO sometimes wanna drive external
>>> displays. Usenet electronics groups ... dismal at this point.
>>>
>>> LEDs are great, but never "forever". They DO fail - but for some
>>> safety apps you can't just HAVE things go black.
>>
>> Most LED's that fail do so because they are being driven hard [2]
>> (right at the limits that they are rated for, if not well beyond
>> sometimes). If you derate your drive by a fair amount you'll find they
>> do, in fact, appear to last nearly forever. But then you will need
>> more LED's for an equivalent amount of lumens of light output.
>
> Or use high-brightness LEDs where low-brightness ones would
> normally be sufficient at their maximum current.

Or, the meaning of "derate" when doing component selection.

> But unless there's something specific that makes these LEDs more
> likely to go wrong,

Over driving them too hard, and insufficient heat dissipation for
whatever drive level you choose for them, are by far the big two
reasons for them to go wrong. Must every other failure will either be
infant mortality or very very rare occurrence possibilities.

And, note, there is a huge overlap in "over drive" and "insufficient
heat sinking" such that over driven LED's are often also insufficiently
heat sinked for the actual amount of heat the driving will generate.

If you don't try to squeeze every last ounce of "performance" out of a
given LED, and you adequately remove the waste heat, they will (at
least everything but Shenzen junk) last nearly forever.

> I'd expect the drive circuitry and wiring to be as common a point of
> failure as the LEDs themselves. To detect
> open-circuit/short-circuit, you could pass a small current through
> them and use that to tell whether the LED is OK (current is correct
> for the LED's forward voltage drop specification), triggering a
> single bulb-failure warning if it's not (possibly simpler in practice
> than duplicating every LED on a display panel, even if the total
> number of components is similar).

Yes, you could design a "detector" that could detect open/short for the
LED and/or its driver. But then that means you've excluded "fewest
parts" (at least) from the design selection criteria. And, depending
upon how 'robust' you really need to be, you'd need to detect failures
of the detection circuitry itself as well.

Another commenter's statement of inverting the indicator, where "on"
means "situation normal" and "off" means "abnormal" is probably the
absolute simplest way to go. But then the "LED indicator" fights human
psychology that senses a new stimuli appearing in the environment (lamp
turning on) far more readily and quickly than noticing that a continual
low level stimuli has disappeared (light has gone out).

On 11/26/24 3:40 AM, rbowman wrote:
> On Tue, 26 Nov 2024 02:24:12 -0500, 186282@ud0s4.net wrote:
>
>> Critical Redundancy - One LED fails, another takes over ?
>
> Complicated question. For a complete catastrophic failure where the LED is
> either open or shorted a couple of transistors might do it. Even that
> would be difficult if a PWM dimmer is used.

I can kinda think of a few multi-transistor solutions, but
was hoping for a one-transistor or no-transistor fix. The
more trans/diodes you have to go thru the more the voltage
drop.

> Even worse the degradation may be light output and/or color rather than a
> simple go / no go.
>
> Then you get into the human part of the equation:
>
> https://learn.sparkfun.com/tutorials/light/visible-light
>
> I'd actually been playing with PWM output in a Pico with C. The Uno piles
> a lot of sugar on it with analogWrite rather than the Pico SDK
> hardware_pwn
>
> https://cec-code-lab.aps.edu/robotics/resources/pico-c-api/
> group__hardware__pwm.html
>
> I've got to play with it a little more but simply incrementing the duty
> cycle isn't too smooth perceptually.

Ah, I know that one ... mostly due to internal capacitance,
esp in 'consumer-grade' LEDS, the devices may not 'saturate'
from very brief pulses. So, your 5% PWM pulse doesn't look
like 5% to the device while your 95% pulse does. The
advertised color assumes 100% saturation at the spec voltage
and current levels.

Two and a half "easy" fixes :

Decrease your PWM base frequency - maybe down to 100hz or
even 60hz. This gives even the short pulses a chance to
saturate the device.

Or ... bring the device ALMOST up to emission threshold.
Alas this takes a voltage-divider and maybe a diode. The
idea is that you put static DC potential on the thing -
like 2.0 volts for a 2.3 volt device. The amps do not have
to be very much at all. Thus 'primed' they will be more
responsive.

LEDs used for like fiber-optic links are engineered to
have lower capacitance plus a few other tweaks to make
them respond faster. That they're generally driven
binary at 0% or 100% for such uses also helps.

Another ugly trick can be to just intentionally add
more capacitance - a tiny cap - so your PWM does not
really directly drive the LED but can instead be seen
as just charging the cap. The leftover voltage in the
cap will kinda keep the LED near threshold, as mentioned
above (gotta match the cap to the PWM freq).

Rich <rich@example.invalid> wrote:
> Computer Nerd Kev <not@telling.you.invalid> wrote:
>> Rich <rich@example.invalid> wrote:
>>>
>>> PSU
>>> |
>>> +-------+-------+
>>> | |
>>> driver driver
>>> | |
>>> LED LED
>>> | |
>>> +-------+-------+
>>> |
>>> Gnd
>>>
>>>
>>> Then if one led (or its driver) fails, the other continues to operate,
>>> because it does not depend upon the first one.
>>
>> Unless the driver chip fails short-circuit, causing the PSU to shut
>> down power to both drivers.
>
> fewest, simplest, most robust -- you get to pick two.....
>
>>> But this is far from 'fewest' parts, as you need one driver per led.
>>> While some driver chips can be had for pennies each in 1K quantities,
>>> that still adds to the BOM cost in the end.
>>
>> If the PSU has regulated voltage output, or LED brightness can vary
>> with the supply voltage (such as from a battery), then a resistor
>> would do instead of the LED drivers.
>
> Yes, and you still have the same potential for a possible "fail short"
> with a current limiting resistor, which would then drive that led with
> too much current. And if it happens to fail short when overdriven too
> much, you are back to your 'fail short' for the "drivers".

You can get "fusible resistors" that are supposed to fail
open-circuit if overloaded.

>> I'd expect the drive circuitry and wiring to be as common a point of
>> failure as the LEDs themselves. To detect
>> open-circuit/short-circuit, you could pass a small current through
>> them and use that to tell whether the LED is OK (current is correct
>> for the LED's forward voltage drop specification), triggering a
>> single bulb-failure warning if it's not (possibly simpler in practice
>> than duplicating every LED on a display panel, even if the total
>> number of components is similar).
>
> Yes, you could design a "detector" that could detect open/short for the
> LED and/or its driver. But then that means you've excluded "fewest
> parts" (at least) from the design selection criteria. And, depending
> upon how 'robust' you really need to be, you'd need to detect failures
> of the detection circuitry itself as well.

Depends on the details. Say you have flashing warning lights
driven by a microcontroller which also has spare remapable ADC
inputs: You could add a capacitor in parallel with the LED+resistor
and switch the micro's pin from HIGH digital output into ADC input
mode to turn the LED off. While the light fades from on to off,
measure the discharge of the capacitor - too fast means a short,
too slow means open-circuit. Yet there's only one more component
per LED if you already have a suitably capable microcontroller
there.

For traffic lights to look normal, you could flash so quickly that
it's not noticable to the eye (if you've got surplus brightness).

Now the problem is that capacitors tend to fail short-circuit more
often than most other common components including LEDs. So you can
detect the failure, but the failure is now more likely.

> Another commenter's statement of inverting the indicator, where "on"
> means "situation normal" and "off" means "abnormal" is probably the
> absolute simplest way to go. But then the "LED indicator" fights human
> psychology that senses a new stimuli appearing in the environment (lamp
> turning on) far more readily and quickly than noticing that a continual
> low level stimuli has disappeared (light has gone out).

Flashing to indicate a warning instead of turning permanently off
would help there. Need to retrain everyone to use traffic lights
which always have two lights on if applied to that example
application though, so probably not a solution there.

--
__ __
#_ < |\| |< _#

On 11/26/24 4:00 AM, Bernd Froehlich wrote:
> On 26. Nov 2024 at 08:24:12 CET, "186283@ud0s4.net" <186283@ud0s4.net>
> wrote:
>
>> LEDs are great, but never "forever". They DO
>> fail - but for some safety apps you can't
>> just HAVE things go black.
>
> Hmm, just a thought:
> If I understood the problem correctly, you want the LED to show some
> failstate, right?
>
> What if you switch the LED on when everything is fine and off would signal
> a fail?
>
> If the LED is off then you know it´s either a fail or the LED is broken.
> Either way you have to do something.

The fail state can (usually) be detected just past the
current-limiting resistor. If the voltage there suddenly
equals the supply voltage then the LED is not conducting.
Again though, more electronics.

COULD use that elevated voltage to trip a 'relay' trans
connected to LED-2 however.

For some apps, you may just be able to look and SEE which
LED is illuminated. If you normally light the right-side
one, but peeking in shows the left-side one lit, then
you have a problem.

The original LED traffic lights used a cluster of LEDs,
divided into individually-driven segments. If one failed
then only a segment went dark, but MOST of them would
keep working. It was always the greens that went bad.
TODAY, not sure - I fear they use some more monolithic
device that'll die all at once.

On 11/26/24 8:34 AM, Rich wrote:
> 186282@ud0s4.net <186283@ud0s4.net> wrote:
>> Critical Redundancy - One LED fails, another takes over ?
>>
>> Consider traffic lights, warning lights, similar.
>>
>> It's not as simple as dividing the drive current in half because LED
>> brightness is not strictly linear to the current.
>
> LED's are, at a low level, 'current' responsive lights. Driving them
> with a current source is the best way to drive them.

Agreed ... but it's extremely COMMON to voltage or PWM them.
Minimum parts count. For arg here, assume like a 12v or 24v
source with way more amp capacity than you need. Minimum setup
is the LED and a current-limiting resistor.

>> Searches really don't bring up much here.
>>
>> Yea, there are more complex solutions ... but what can be done with
>> the fewest, simplest, most robust parts ?
>
> fewest, simplest, most robust -- you get to pick two....

Wow - TWO ! :-)

> The simplest (if you can assume the upstream power supply will be
> functional [1]) is to drive each in parallel with their own current source
> (fixed current driver). I.e.:
>
> PSU
> |
> +-------+-------+
> | |
> driver driver
> | |
> LED LED
> | |
> +-------+-------+
> |
> Gnd
>
>
> Then if one led (or its driver) fails, the other continues to operate,
> because it does not depend upon the first one.

Yep - except for a couple of things. First off, brightness
goes down by 50% when an LED dies. In outdoor apps you may
not even be able to see it clearly. Second, you're burning
both LEDs - meaning LED-2 may also be near fail-time.

> But this is far from 'fewest' parts, as you need one driver per led.
> While some driver chips can be had for pennies each in 1K quantities,
> that still adds to the BOM cost in the end.
>
>> Not strictly Linux, but we DO sometimes wanna drive external
>> displays. Usenet electronics groups ... dismal at this point.
>>
>> LEDs are great, but never "forever". They DO fail - but for some
>> safety apps you can't just HAVE things go black.
>
> Most LED's that fail do so because they are being driven hard [2]
> (right at the limits that they are rated for, if not well beyond
> sometimes). If you derate your drive by a fair amount you'll find they
> do, in fact, appear to last nearly forever. But then you will need
> more LED's for an equivalent amount of lumens of light output.

Derating is most wise. Even the recommended power levels
are often 'optimistic'. Of course if you derate then you
have to use bigger/more LEDs. Also, LEDs can Just Die for
no immediately obvious reason - bad manufacturing or
maybe a nearby lightning hit. MTBF is a "mean" after all.

> [1] redundant PSU's are a different matter
>
> [2] And they are being driven hard because the Shenzen engineer
> optimized for lowest BOM cost posible without regard to lifespan of the
> device.

The simplest thing I can think of starts off with just
the current-limiting resistor and the LED. If the LED
is working properly the voltage at its + terminal will
be rather low, the LED is sucking-up most of the power.
If you bias an FET and attach it to said + terminal then
so long as the voltage there is low the FET won't turn on.
If the LED dies then the high voltage will turn on the
FET - which is attached to LED-2. COULD latch the FET
so it fer-sure goes to 100%

HAVE seen an LED or two fail mostly as a dead short ...
but almost never.

186282@ud0s4.net <186283@ud0s4.net> wrote:
> On 11/26/24 8:34 AM, Rich wrote:
>> 186282@ud0s4.net <186283@ud0s4.net> wrote:
>>> Critical Redundancy - One LED fails, another takes over ?
>>>
>>> Consider traffic lights, warning lights, similar.
>>>
>>> It's not as simple as dividing the drive current in half because LED
>>> brightness is not strictly linear to the current.
>>
>> LED's are, at a low level, 'current' responsive lights. Driving them
>> with a current source is the best way to drive them.
>
> Agreed ... but it's extremely COMMON to voltage or PWM them.

And because all the other Lemmings are walking off the cliff, that
means you should too?

You asked for 'robust' (albeit in combination with other factors).
Constant current drive will provide the most robust (from an LED
failure standpoint, but adding constant current drive brings in
'robustness' for the driver).

>> The simplest (if you can assume the upstream power supply will be
>> functional [1]) is to drive each in parallel with their own current source
>> (fixed current driver). I.e.:
>>
>> PSU
>> |
>> +-------+-------+
>> | |
>> driver driver
>> | |
>> LED LED
>> | |
>> +-------+-------+
>> |
>> Gnd
>>
>>
>> Then if one led (or its driver) fails, the other continues to operate,
>> because it does not depend upon the first one.
>
> Yep - except for a couple of things. First off, brightness
> goes down by 50% when an LED dies. In outdoor apps you may
> not even be able to see it clearly. Second, you're burning
> both LEDs - meaning LED-2 may also be near fail-time.

No different than if you resistor limited or pwm'ed both. If both are
lit at the same time, and one fails (and its failure does not take out
the other) you get 50% reduction in brightness.

Now, if you meant #2 was an idle spare waiting for #1 to fail before
turning on, well, then in that case, assuming the 'detection and
failover' circuit operated properly, no drop in brightness, and no
operating age on #2. Which you want is dependent on /what/ you really
want, and your initial post is ambigious enough that either of "run both,
but keep one going if the other fails" or "hold an idle spare off, turn
it on if main goes out" can fit the description.

>> Most LED's that fail do so because they are being driven hard [2]
>> (right at the limits that they are rated for, if not well beyond
>> sometimes). If you derate your drive by a fair amount you'll find
>> they do, in fact, appear to last nearly forever. But then you will
>> need more LED's for an equivalent amount of lumens of light output.
>
>
> Derating is most wise. Even the recommended power levels are often
> 'optimistic'.

Yes, even the value in the datasheet (assuming a part for which you can
get a datasheet, and that includes 'recommended operating values' is
often optimistic. Esp. for white LED's used for general illumination.

> Of course if you derate then you have to use bigger/more LEDs.

It is very hard to have your cake and eat it too. You can have few
parts (i.e. Shenzen like cheapo designs) but you very likely won't be
terribly obust against failure. Or you can add more parts for more
robustness and longer lifespan, but then you won't have fewer parts.

> Also, LEDs can Just Die for no immediately obvious reason - bad
> manufacturing or maybe a nearby lightning hit. MTBF is a "mean"
> after all.

True, and if the device takes a lightning hit (or nearby one) it is
likely going to fail. But you'll find if you derate a fair amount (and
provide proper adequate cooling) that once you shake out the infant
mortality portion of the bathtub curve, that the ones that make it past
infantcy will run a very long time afterward.

>> [1] redundant PSU's are a different matter
>>
>> [2] And they are being driven hard because the Shenzen engineer
>> optimized for lowest BOM cost posible without regard to lifespan of
>> the device.
>
> The simplest thing I can think of starts off with just
> the current-limiting resistor and the LED. If the LED
> is working properly the voltage at its + terminal will
> be rather low,

More correctly, it will be whatever the LED's forward voltage drop
value is, which is different depending what "color" LED is being used.

But "low" is relative, and depends upon supply voltage. Some LED's
have forward voltage drops of 2.5v or 3v. On a 3.3v supply, 2.5v and
3v are not at all "low".

> the LED is sucking-up most of the power. If you bias an FET and
> attach it to said + terminal then so long as the voltage there is
> low the FET won't turn on. If the LED dies then the high voltage
> will turn on the FET - which is attached to LED-2. COULD latch the
> FET so it fer-sure goes to 100%

Yeah, you could setup a suitably biased FET to turn on if the voltage
across the LED goes too high -- indicating an open in the LED. That
won't catch an LED that fails short however. So you'd only catch half
the possible failure modes. Provided you know your LED's always fail
open, it would work. But do you know they always fail open?

> HAVE seen an LED or two fail mostly as a dead short ... but almost
> never.

Diodes failing short do occur (think bridge rectifier diodes that do
sometimes fail short). Granted, they are different "chip dopings" than
LED's, but an LED is just a 'special diode'. There's no guarantee a
given LED will always fail open. It may be only 1% that fail short,
but if you are talking sufficient numbers of units even 1% becomes a
rather large physical count.

On 11/27/24 1:47 AM, Rich wrote:
> 186282@ud0s4.net <186283@ud0s4.net> wrote:
>> On 11/26/24 8:34 AM, Rich wrote:
>>> 186282@ud0s4.net <186283@ud0s4.net> wrote:
>>>> Critical Redundancy - One LED fails, another takes over ?
>>>>
>>>> Consider traffic lights, warning lights, similar.
>>>>
>>>> It's not as simple as dividing the drive current in half because LED
>>>> brightness is not strictly linear to the current.
>>>
>>> LED's are, at a low level, 'current' responsive lights. Driving them
>>> with a current source is the best way to drive them.
>>
>> Agreed ... but it's extremely COMMON to voltage or PWM them.
>
> And because all the other Lemmings are walking off the cliff, that
> means you should too?

Depends on the cost/benefit ratio :-)

If you can get the Desired Effect with two parts, or 20,
which do you choose ? That last one-percent of 'perfection'
may NOT be worth it.

It has been said of good automobiles that the Germans
achieve 'perfection' through deep complexity whereas
the Japanese achieve it through simplicity - reducing
things to their most basic elements.

It's why RAM chips don't cost $10,000 .....

> You asked for 'robust' (albeit in combination with other factors).
> Constant current drive will provide the most robust (from an LED
> failure standpoint, but adding constant current drive brings in
> 'robustness' for the driver).
>
>>> The simplest (if you can assume the upstream power supply will be
>>> functional [1]) is to drive each in parallel with their own current source
>>> (fixed current driver). I.e.:
>>>
>>> PSU
>>> |
>>> +-------+-------+
>>> | |
>>> driver driver
>>> | |
>>> LED LED
>>> | |
>>> +-------+-------+
>>>
>>> Gnd
>>>
>>>
>>> Then if one led (or its driver) fails, the other continues to operate,
>>> because it does not depend upon the first one.
>>
>> Yep - except for a couple of things. First off, brightness
>> goes down by 50% when an LED dies. In outdoor apps you may
>> not even be able to see it clearly. Second, you're burning
>> both LEDs - meaning LED-2 may also be near fail-time.
>
> No different than if you resistor limited or pwm'ed both. If both are
> lit at the same time, and one fails (and its failure does not take out
> the other) you get 50% reduction in brightness.

My worry is that 50% less - in bright daylight - may
equate to "invisible". Not every bit of tech functions
in some darkened lab corner .....

> Now, if you meant #2 was an idle spare waiting for #1 to fail before
> turning on, well, then in that case, assuming the 'detection and
> failover' circuit operated properly, no drop in brightness, and no
> operating age on #2. Which you want is dependent on /what/ you really
> want, and your initial post is ambigious enough that either of "run both,
> but keep one going if the other fails" or "hold an idle spare off, turn
> it on if main goes out" can fit the description.
>
>>> Most LED's that fail do so because they are being driven hard [2]
>>> (right at the limits that they are rated for, if not well beyond
>>> sometimes). If you derate your drive by a fair amount you'll find
>>> they do, in fact, appear to last nearly forever. But then you will
>>> need more LED's for an equivalent amount of lumens of light output.
>>
>>
>> Derating is most wise. Even the recommended power levels are often
>> 'optimistic'.
>
> Yes, even the value in the datasheet (assuming a part for which you can
> get a datasheet, and that includes 'recommended operating values' is
> often optimistic. Esp. for white LED's used for general illumination.

Yep, decidedly noticed THAT.

>> Of course if you derate then you have to use bigger/more LEDs.
>
> It is very hard to have your cake and eat it too. You can have few
> parts (i.e. Shenzen like cheapo designs) but you very likely won't be
> terribly obust against failure. Or you can add more parts for more
> robustness and longer lifespan, but then you won't have fewer parts.

But I want my cake !!!

>> Also, LEDs can Just Die for no immediately obvious reason - bad
>> manufacturing or maybe a nearby lightning hit. MTBF is a "mean"
>> after all.
>
> True, and if the device takes a lightning hit (or nearby one) it is
> likely going to fail. But you'll find if you derate a fair amount (and
> provide proper adequate cooling) that once you shake out the infant
> mortality portion of the bathtub curve, that the ones that make it past
> infantcy will run a very long time afterward.

I've seen electronics ruined by a NEARBY lightning
hit, one that went overhead, never touched the
building or power grid. Pure EMP.

Such effects CAN sometimes be moderated by using nothing
but a zener ... the amps are ultra-small, it's the volts
that kill the semiconductors.

>>> [1] redundant PSU's are a different matter
>>>
>>> [2] And they are being driven hard because the Shenzen engineer
>>> optimized for lowest BOM cost posible without regard to lifespan of
>>> the device.
>>
>> The simplest thing I can think of starts off with just
>> the current-limiting resistor and the LED. If the LED
>> is working properly the voltage at its + terminal will
>> be rather low,
>
> More correctly, it will be whatever the LED's forward voltage drop
> value is, which is different depending what "color" LED is being used.

Yep.

> But "low" is relative, and depends upon supply voltage. Some LED's
> have forward voltage drops of 2.5v or 3v. On a 3.3v supply, 2.5v and
> 3v are not at all "low".

Well, gotta do SOME calx :-)

>> the LED is sucking-up most of the power. If you bias an FET and
>> attach it to said + terminal then so long as the voltage there is
>> low the FET won't turn on. If the LED dies then the high voltage
>> will turn on the FET - which is attached to LED-2. COULD latch the
>> FET so it fer-sure goes to 100%
>
> Yeah, you could setup a suitably biased FET to turn on if the voltage
> across the LED goes too high -- indicating an open in the LED. That
> won't catch an LED that fails short however. So you'd only catch half
> the possible failure modes. Provided you know your LED's always fail
> open, it would work. But do you know they always fail open?
>
>> HAVE seen an LED or two fail mostly as a dead short ... but almost
>> never.
>
> Diodes failing short do occur (think bridge rectifier diodes that do
> sometimes fail short). Granted, they are different "chip dopings" than
> LED's, but an LED is just a 'special diode'. There's no guarantee a
> given LED will always fail open. It may be only 1% that fail short,
> but if you are talking sufficient numbers of units even 1% becomes a
> rather large physical count.

IMHO here, you design for the "most likely" cases and
trust to luck. Not "ideal", but simple and inexpensive.

Now, say, indicators and such in a nuke plant ... then
you have to cover both cases. In our examples here you'd
want the abovedescribed fix, but with an n and p FET
that both feed LED-2. Fails open, the n-channel, fails
closed, the p-channel.

Together, you're making a "voltage-range error" detector
and the indicator is LED-2.

On 11/27/24 12:12 AM, Computer Nerd Kev wrote:
> Rich <rich@example.invalid> wrote:
>> Computer Nerd Kev <not@telling.you.invalid> wrote:
>>> Rich <rich@example.invalid> wrote:
>>>>
>>>> PSU
>>>> |
>>>> +-------+-------+
>>>> | |
>>>> driver driver
>>>> | |
>>>> LED LED
>>>> | |
>>>> +-------+-------+
>>>> |
>>>> Gnd
>>>>
>>>>
>>>> Then if one led (or its driver) fails, the other continues to operate,
>>>> because it does not depend upon the first one.
>>>
>>> Unless the driver chip fails short-circuit, causing the PSU to shut
>>> down power to both drivers.
>>
>> fewest, simplest, most robust -- you get to pick two.....
>>
>>>> But this is far from 'fewest' parts, as you need one driver per led.
>>>> While some driver chips can be had for pennies each in 1K quantities,
>>>> that still adds to the BOM cost in the end.
>>>
>>> If the PSU has regulated voltage output, or LED brightness can vary
>>> with the supply voltage (such as from a battery), then a resistor
>>> would do instead of the LED drivers.
>>
>> Yes, and you still have the same potential for a possible "fail short"
>> with a current limiting resistor, which would then drive that led with
>> too much current. And if it happens to fail short when overdriven too
>> much, you are back to your 'fail short' for the "drivers".
>
> You can get "fusible resistors" that are supposed to fail
> open-circuit if overloaded.
>
>>> I'd expect the drive circuitry and wiring to be as common a point of
>>> failure as the LEDs themselves. To detect
>>> open-circuit/short-circuit, you could pass a small current through
>>> them and use that to tell whether the LED is OK (current is correct
>>> for the LED's forward voltage drop specification), triggering a
>>> single bulb-failure warning if it's not (possibly simpler in practice
>>> than duplicating every LED on a display panel, even if the total
>>> number of components is similar).
>>
>> Yes, you could design a "detector" that could detect open/short for the
>> LED and/or its driver. But then that means you've excluded "fewest
>> parts" (at least) from the design selection criteria. And, depending
>> upon how 'robust' you really need to be, you'd need to detect failures
>> of the detection circuitry itself as well.
>
> Depends on the details. Say you have flashing warning lights
> driven by a microcontroller which also has spare remapable ADC
> inputs: You could add a capacitor in parallel with the LED+resistor
> and switch the micro's pin from HIGH digital output into ADC input
> mode to turn the LED off. While the light fades from on to off,
> measure the discharge of the capacitor - too fast means a short,
> too slow means open-circuit. Yet there's only one more component
> per LED if you already have a suitably capable microcontroller
> there.
>
> For traffic lights to look normal, you could flash so quickly that
> it's not noticable to the eye (if you've got surplus brightness).
>
> Now the problem is that capacitors tend to fail short-circuit more
> often than most other common components including LEDs. So you can
> detect the failure, but the failure is now more likely.
>
>> Another commenter's statement of inverting the indicator, where "on"
>> means "situation normal" and "off" means "abnormal" is probably the
>> absolute simplest way to go. But then the "LED indicator" fights human
>> psychology that senses a new stimuli appearing in the environment (lamp
>> turning on) far more readily and quickly than noticing that a continual
>> low level stimuli has disappeared (light has gone out).
>
> Flashing to indicate a warning instead of turning permanently off
> would help there. Need to retrain everyone to use traffic lights
> which always have two lights on if applied to that example
> application though, so probably not a solution there.

There are 'critical' lights - traffic, railway, nuke-reactor -
that simply can't show "nothing". If those lights are outdoors
then half-bright may look like "nothing".

For the original question, I think using two FETs, an N
and P, linked to the + on LED-1 can form a "voltage-range
error" circuit without too many parts. LED-2 is the
indicator lamp. So, whether LED-1 fails open or closed
LED-2 still lights full. Attach an extra tiny red led
or piezo buzzer or whatever to it to indicate fail mode
if you can't just tell by looking.

186282@ud0s4.net <186283@ud0s4.net> wrote:
> On 11/27/24 12:12 AM, Computer Nerd Kev wrote:
>> Depends on the details. Say you have flashing warning lights
>> driven by a microcontroller which also has spare remapable ADC
>> inputs: You could add a capacitor in parallel with the LED+resistor
>> and switch the micro's pin from HIGH digital output into ADC input
>> mode to turn the LED off. While the light fades from on to off,
>> measure the discharge of the capacitor - too fast means a short,
>> too slow means open-circuit. Yet there's only one more component
>> per LED if you already have a suitably capable microcontroller
>> there.
>>
>> For traffic lights to look normal, you could flash so quickly that
>> it's not noticable to the eye (if you've got surplus brightness).
>>
>> Now the problem is that capacitors tend to fail short-circuit more
>> often than most other common components including LEDs. So you can
>> detect the failure, but the failure is now more likely.
>>
>>> Another commenter's statement of inverting the indicator, where "on"
>>> means "situation normal" and "off" means "abnormal" is probably the
>>> absolute simplest way to go. But then the "LED indicator" fights human
>>> psychology that senses a new stimuli appearing in the environment (lamp
>>> turning on) far more readily and quickly than noticing that a continual
>>> low level stimuli has disappeared (light has gone out).
>>
>> Flashing to indicate a warning instead of turning permanently off
>> would help there. Need to retrain everyone to use traffic lights
>> which always have two lights on if applied to that example
>> application though, so probably not a solution there.
>
>
> There are 'critical' lights - traffic, railway, nuke-reactor -
> that simply can't show "nothing".

I haven't been let into a reactor control room, but I'm pretty sure
I've caught traffic lights showing nothing during a blackout
before (and ample other times for that matter). The individual
traffic light units usually have redundancy by there being more
than one of them, in Australia at least. You just need a method
for detecting the failure and reporting it so it's fixed as soon
as possible.

I'm not sure what railway crossing lights do, as off is their
normal state. I assume they die too during a blackout and I
therefore slow sufficiently to be able to stop if I see a train
coming as I check both ways before crossing. Where there's little
space to see before reaching the line, sufficient slowing down can
annoy drivers behind. But tough luck to them, I won't trust my
life to a light, especially as I heard relatively recently that a
nearly railway line was closed after multiple crossing lights
failed to activate.

> For the original question, I think using two FETs, an N
> and P, linked to the + on LED-1 can form a "voltage-range
> error" circuit without too many parts. LED-2 is the
> indicator lamp. So, whether LED-1 fails open or closed
> LED-2 still lights full. Attach an extra tiny red led
> or piezo buzzer or whatever to it to indicate fail mode
> if you can't just tell by looking.

Well since you're defining "too many parts", one can't argue
with that. This topic is really too general for a universal
minimum-parts solution. The over-priced indicator lights on a
nuclear reactor control panel probably cost much more individually
than an excessive bunch of redundant components to drive them all.

Though at Fukushima they were apparantly powering instruments with
car batteries when the building lost power, so redundancy only went
so far there. I thinkI remember the movie The China Syndrome showed
a fictional nuclear incident happening because a panel meter needle
was stuck.

--
__ __
#_ < |\| |< _#

On 11/28/24 4:06 PM, Computer Nerd Kev wrote:
> 186282@ud0s4.net <186283@ud0s4.net> wrote:
>> On 11/27/24 12:12 AM, Computer Nerd Kev wrote:
>>> Depends on the details. Say you have flashing warning lights
>>> driven by a microcontroller which also has spare remapable ADC
>>> inputs: You could add a capacitor in parallel with the LED+resistor
>>> and switch the micro's pin from HIGH digital output into ADC input
>>> mode to turn the LED off. While the light fades from on to off,
>>> measure the discharge of the capacitor - too fast means a short,
>>> too slow means open-circuit. Yet there's only one more component
>>> per LED if you already have a suitably capable microcontroller
>>> there.
>>>
>>> For traffic lights to look normal, you could flash so quickly that
>>> it's not noticable to the eye (if you've got surplus brightness).
>>>
>>> Now the problem is that capacitors tend to fail short-circuit more
>>> often than most other common components including LEDs. So you can
>>> detect the failure, but the failure is now more likely.
>>>
>>>> Another commenter's statement of inverting the indicator, where "on"
>>>> means "situation normal" and "off" means "abnormal" is probably the
>>>> absolute simplest way to go. But then the "LED indicator" fights human
>>>> psychology that senses a new stimuli appearing in the environment (lamp
>>>> turning on) far more readily and quickly than noticing that a continual
>>>> low level stimuli has disappeared (light has gone out).
>>>
>>> Flashing to indicate a warning instead of turning permanently off
>>> would help there. Need to retrain everyone to use traffic lights
>>> which always have two lights on if applied to that example
>>> application though, so probably not a solution there.
>>
>>
>> There are 'critical' lights - traffic, railway, nuke-reactor -
>> that simply can't show "nothing".
>
> I haven't been let into a reactor control room, but I'm pretty sure
> I've caught traffic lights showing nothing during a blackout
> before (and ample other times for that matter). The individual
> traffic light units usually have redundancy by there being more
> than one of them, in Australia at least. You just need a method
> for detecting the failure and reporting it so it's fixed as soon
> as possible.
>
> I'm not sure what railway crossing lights do, as off is their
> normal state. I assume they die too during a blackout and I
> therefore slow sufficiently to be able to stop if I see a train
> coming as I check both ways before crossing. Where there's little
> space to see before reaching the line, sufficient slowing down can
> annoy drivers behind. But tough luck to them, I won't trust my
> life to a light, especially as I heard relatively recently that a
> nearly railway line was closed after multiple crossing lights
> failed to activate.
>
>> For the original question, I think using two FETs, an N
>> and P, linked to the + on LED-1 can form a "voltage-range
>> error" circuit without too many parts. LED-2 is the
>> indicator lamp. So, whether LED-1 fails open or closed
>> LED-2 still lights full. Attach an extra tiny red led
>> or piezo buzzer or whatever to it to indicate fail mode
>> if you can't just tell by looking.
>
> Well since you're defining "too many parts", one can't argue
> with that. This topic is really too general for a universal
> minimum-parts solution. The over-priced indicator lights on a
> nuclear reactor control panel probably cost much more individually
> than an excessive bunch of redundant components to drive them all.

Well, the circuit I described doesn't use TOO many parts
and they're all cheap as dirt. a couple FETs and some
resistors by and large. You WILL get full brightness
from LED-2 and will NOT be burning LED-2 unless needed.

Anyway, visualizing The Problem as voltage-range-error
detection seems the simplest approach. Doesn't need
microcontrollers or current supplies or anything very
complex.

BlackOuts ... yea, they CAN happen (been through some
lasting nearly three weeks). After a little while almost
NO tech works - it's back to 1880. However decent design
at least DOES ease everybody into that old paradigm.

DO own a few kerosene/oil lamps and had to use them on
two occasions over the past 20 years. Old tech DOES
work ... just make sure they can't crash to the floor
and start a big fire. Oddly, can't get the Net with
them - what WERE they thinking ???

Traffic lights - esp since the LED conversions - more
and more DO have battery-backup that'll last for an
hour or two. Maybe not cost-effective everywhere, but
at major intersections ......

> Though at Fukushima they were apparantly powering instruments with
> car batteries when the building lost power, so redundancy only went
> so far there. I thinkI remember the movie The China Syndrome showed
> a fictional nuclear incident happening because a panel meter needle
> was stuck.

As I suggested elsewhere, 'redundancy' can only go SO far.
A tsunami/earthquake/melt-down ... kinda WAY off the spectrum.

Oh, car batts are NOT so bad - cheap and work. Fair cap.
Only maybe 2-3 year lifetime though.

Ah, Fukushima ... reported last week ... they finally got
a little robot in there - with a long 'fishing pole' probe
on it - and recovered a few tiny bits of core material.
Japan congratulated itself on that. Alas the radiation is
still SO high that it nukes all modern tech, hence the
'fishing pole'. Maybe they should look to vacuum tubes
or something, crude RC ......

There ARE 'cold-emitter array' valves these days which
are pretty small - kinda leveraging microchip tech to
make a mass of tiny 'points' that emit electrons. Then
you mechanically overlay a grid and anode. Can't do
TOO much logic/etc with those, but they would probably
hold up in a hyper-rad environment.