Sensing \"indicator\" failures...

[Don Y]

I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

The idea of having an \"indicator (lamp) test\" isn\'t intuitive
in the usage pattern for these devices -- unlike an automobile dash,
for example. Any approach that required the user to verify
the proper operation of the indicators will fall short.

For LEDs, I figured I could monitor the drop across the diode
over time (i.e., don\'t even worry about what it\'s \"initial,
theoretical value\" should be... just \"take notes\" and watch
for changes). A diode that opens or shorts would be identifiable
with such a technique. I\'m not sure I can learn/deduce anything
from gradual changes, over time...

I\'ve encountered a few LED clocks with fried segments as well as
wall warts (bricks) with similarly failed \"power indicators\" so
assume failures DO happen.

The solution should apply equally to all LED doping chemistries
(yeah, the voltage across the junction will differ but that\'s why
you observe and track instead of \"hard code\" a fault value)

[I rarely use ADCs that come inside MCUs so it\'s a virtual certainty
that I have such channels to spare]

I also use small \"vibrators\" as haptic indicators. I assume
these are just cheap little DC motors (PM?) -- though I\'ve not
disassembled any to verify.

For these, I figure I could drive them with a current source
and, again, monitor the voltage across the device. An open
load would be obvious as should a short (or stalled rotor?).

Again, I\'d have to find an operating point that would allow the
approach to work for a variety of such different \"indicators\".

The goal in all this is to alert the user of a problem before
he notices it (or, FAILS to notice it!).

Any likely faults that I\'m missing? (note that if the \"detection
hardware\" fails, I can determine this because I can watch to see
how it responds to deliberate changes in the indicators\' state)

 

[Cydrome Leader]

Don Y <blockedofcourse@foo.invalid> wrote:

I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

The idea of having an \"indicator (lamp) test\" isn\'t intuitive
in the usage pattern for these devices -- unlike an automobile dash,
for example. Any approach that required the user to verify
the proper operation of the indicators will fall short.

For LEDs, I figured I could monitor the drop across the diode
over time (i.e., don\'t even worry about what it\'s \"initial,
theoretical value\" should be... just \"take notes\" and watch
for changes). A diode that opens or shorts would be identifiable
with such a technique. I\'m not sure I can learn/deduce anything
from gradual changes, over time...

I\'ve encountered a few LED clocks with fried segments as well as
wall warts (bricks) with similarly failed \"power indicators\" so
assume failures DO happen.

I\'ve got some equipment with failed power LEDs too. It\'s pretty sad. Some
go short-ish and emit little to no light, a few other failed LEDs I\'ve
seen just open up completely. Going nearly short and ending up dim seems
more common from what I\'ve seen. I have a red T1 led on my desk right now
that failed this way.

Maybe you can poll the current on the common side of your displays, if you
have one to look for a mismatch between what\'s \"normal\" and \"bad\".

Even stuff that\'s supposed to fail safe and be reliable like fire alarm
sytems don\'t test if the LEDs are working for you. There\'s the lamp test
mode for that.

The next question is, if it\'s too hard to look at the LEDs for a lamp test
mode, who cares if they fail?

The solution should apply equally to all LED doping chemistries
(yeah, the voltage across the junction will differ but that\'s why
you observe and track instead of \"hard code\" a fault value)

[I rarely use ADCs that come inside MCUs so it\'s a virtual certainty
that I have such channels to spare]

I also use small \"vibrators\" as haptic indicators. I assume
these are just cheap little DC motors (PM?) -- though I\'ve not
disassembled any to verify.

For these, I figure I could drive them with a current source
and, again, monitor the voltage across the device. An open
load would be obvious as should a short (or stalled rotor?).

Again, I\'d have to find an operating point that would allow the
approach to work for a variety of such different \"indicators\".

The goal in all this is to alert the user of a problem before
he notices it (or, FAILS to notice it!).

Any likely faults that I\'m missing? (note that if the \"detection
hardware\" fails, I can determine this because I can watch to see
how it responds to deliberate changes in the indicators\' state)

 

[Don Y]

On 10/11/2020 10:03 PM, Cydrome Leader wrote:

The next question is, if it\'s too hard to look at the LEDs for a lamp test
mode, who cares if they fail?

My point was that there is no natural point in typical usage where an automatic
lamp test could be inserted (unlike an automobile where the driver routinely
STARTS the vehicle and can be coerced to noticing the set of indicators
being tested on the dash). I would have to insert a MANUAL \"test lamps now\"
command (pushbutton, etc.) and then discipline users to do this \"at some
frequency\" (just how often SHOULD you test the indicators in your dashboard?
I suspect far less than \"every time you start the vehicle\" -- if you\'re just
looking to probabilistically catch an \"indicator failure\" before it \"has
consequences\").

You likely have smoke/CO detectors in your home. With nice big TEST buttons
in easily accessible locations. How often do you invoke that test MANUALLY?
And, one would assume that a device intended to save one\'s life would be a
great incentive to disciplining yourself to take the time to perform that test!

Ditto GFCI/AFCIs.

And, you likely only have a handful of such devices in your home. Imagine
having hundreds scattered around an industrial establishment. Do you task
your \"safety\" officer with *routinely* making the rounds and pressing the
\"lamp test\" buttons? How often? What\'s the TCO consequence of this -- vs.
having the device check itself and REPORT when it (infrequently) needs to
be serviced?

 

[Martin Brown]

On 12/10/2020 01:54, Don Y wrote:

I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

Your problem is making the indicator failure sensor method reliable
enough that it is not the source of really annoying phantom errors.

My car has these sort of smarts and regularly reports \"parking light
failure\" when the lamp itself is clearly working but there is an
intermittent fault in the parking light sensor feedback wiring harness.

Not even remotely economically sensible to try and repair!

Any likely faults that I\'m missing?  (note that if the \"detection
hardware\" fails, I can determine this because I can watch to see
how it responds to deliberate changes in the indicators\' state)

Most gross failures are either becomes open circuit or dead short. LED
indicators are generally so reliable as not to be worth the effort.

Filament bulbs used to go pop with monotonous regularity - especially
those inside illuminated transparent button switches that moved with the
filament hot.

--
Regards,
Martin Brown

 

[Don Y]

On 10/12/2020 7:26 AM, Martin Brown wrote:

On 12/10/2020 01:54, Don Y wrote:
I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

Your problem is making the indicator failure sensor method reliable enough that
it is not the source of really annoying phantom errors.

My car has these sort of smarts and regularly reports \"parking light failure\"
when the lamp itself is clearly working but there is an intermittent fault in
the parking light sensor feedback wiring harness.

Circuit boards tend not to have problems with foils becoming unreliable. :>

Also, an automotive environment tends to see folks (often unskilled)
\"tinkering\" with things. E.g., I noticed a neighbor\'s tail light being
\"out\" a week or so ago. When I mentioned it to her, she commented that she
had replaced the bulb several times (uh-oh!). Turns out, someone had
replaced the lamp socket with an aftermarket replacement and miswired it.

I don\'t imagine anyone opting to \"service\" my boards out of ignorance;
the bar is a fair bit higher than some car owner/weekend mechanic seeing
a light socket as a \"simple\" repair.

Automobiles also see regular maintenance. That\'s typically not true of
electronic devices (ADDING that requirement increases TCO).

> Not even remotely economically sensible to try and repair!

You\'re not looking to repair the indicator but, rather, to know when
it is not serving its intended function.

When I engage a servo motor, I expect to see consequences of the motion
that it is imparting to the mechanism it is driving -- either directly
(e.g., monitoring the motor shaft) or indirectly (e.g., monitoring the
driven mechanism\'s motion OR the consequences of that motion).

If I *don\'t* see motion, then I know -- before the user/operator -- that
something is not behaving as I expect it to behave. Why should I wait for
the user/operator to notice he\'s just produced \"scrap\"?

Note that I mentioned I\'m looking for *gross* failures. I\'m not trying to
verify some specific light output (if that was important, I\'d incur the
costs of calibration).

Any likely faults that I\'m missing? (note that if the \"detection
hardware\" fails, I can determine this because I can watch to see
how it responds to deliberate changes in the indicators\' state)

Most gross failures are either becomes open circuit or dead short. LED
indicators are generally so reliable as not to be worth the effort.

\"Reliable\" is a subjective term. If you are designing a product that
will be replaced/upgraded every few years AND the cost of replacement
is not \"noticed\" by the customer, then any component having an MTBF
of 20KHrs or more can effectively be ignored in the analysis. OTOH,
a commercial/industrial customer who has to pay someone to service
hundreds/thousands of such items with some regularity starts to
look unfavorably on your \"recommended service schedule\".

[We replace smoke detectors at 10 year intervals because we know
that homeowners won\'t do it more frequently than that. We also
require them to be AC mains powered, now. And, design with 10 year
batteries -- cuz folks are loath to do something as simple as
replacing a battery in a device designed to SAVE THEIR LIFE!]

At 6 years, you\'re hitting the 50KHrs point. And, a decade brings you
close to 100KHrs. Additionally, if you try to precompensate for expected
changes of light output over such a time period, you end up driving the
device harder than you would for a shorter usage span (or, try to change
the drive, over time, to compensate) which accelerates failures.

Filament bulbs used to go pop with monotonous regularity - especially those
inside illuminated transparent button switches that moved with the filament hot.

I can count the number of times I\'ve had to replace a \"lamp\" (never
a dashboard indicator) on all the cars I\'ve owned on one hand. Yet,
auto manufacturers add cost to vehicles to detect these things. Why?
Because there are consequences to lamps going out that more than
offset the costs of the extra kit to monitor them.

 

[Ricketty C]

On Monday, October 12, 2020 at 10:26:33 AM UTC-4, Martin Brown wrote:

On 12/10/2020 01:54, Don Y wrote:
I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

Your problem is making the indicator failure sensor method reliable
enough that it is not the source of really annoying phantom errors.

This is more a matter of perspective. Consider the failure detector to be part of the indicator and you have simply reduced the MTBF of the indicator, a reasonable trade off for knowing when the indicator has failed.

My car has these sort of smarts and regularly reports \"parking light
failure\" when the lamp itself is clearly working but there is an
intermittent fault in the parking light sensor feedback wiring harness.

Not even remotely economically sensible to try and repair!

So you experienced a failure in part of your car. What is the actual failure rate for this? Your entire car has wiring. Is everything in your car with wiring failing intermittently?

My point is your anecdote does not prove your point.

Any likely faults that I\'m missing?  (note that if the \"detection
hardware\" fails, I can determine this because I can watch to see
how it responds to deliberate changes in the indicators\' state)

Most gross failures are either becomes open circuit or dead short. LED
indicators are generally so reliable as not to be worth the effort.

Filament bulbs used to go pop with monotonous regularity - especially
those inside illuminated transparent button switches that moved with the
filament hot.

The lower failure rate of an LED does not eliminate the need to detect a failure for a critical indicator.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[Clifford Heath]

On 13/10/20 1:26 am, Martin Brown wrote:

On 12/10/2020 01:54, Don Y wrote:
I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

Your problem is making the indicator failure sensor method reliable
enough that it is not the source of really annoying phantom errors.

No problem. Just add a failure indicator to the failure indicator.
Then you\'ll get a warning that your failure indicator isn\'t working.


CH

 

[Tom Gardner]

On 12/10/20 23:48, Clifford Heath wrote:

On 13/10/20 1:26 am, Martin Brown wrote:
On 12/10/2020 01:54, Don Y wrote:
I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

Your problem is making the indicator failure sensor method reliable enough
that it is not the source of really annoying phantom errors.

No problem. Just add a failure indicator to the failure indicator.
Then you\'ll get a warning that your failure indicator isn\'t working.

The traditional failure indicator is that the entire machine stops
until the faulty indicator is replaced.

 

[Ricketty C]

On Monday, October 12, 2020 at 6:48:41 PM UTC-4, Clifford Heath wrote:

On 13/10/20 1:26 am, Martin Brown wrote:
On 12/10/2020 01:54, Don Y wrote:
I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

Your problem is making the indicator failure sensor method reliable
enough that it is not the source of really annoying phantom errors.

No problem. Just add a failure indicator to the failure indicator.
Then you\'ll get a warning that your failure indicator isn\'t working.


CH

You laugh, but we are using two limit switches, staggered with one being activated on a regular basis and the other as a fail safe so the device can still be used when the first fails.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[Clifford Heath]

On 13/10/20 11:12 am, Ricketty C wrote:

On Monday, October 12, 2020 at 6:48:41 PM UTC-4, Clifford Heath wrote:
On 13/10/20 1:26 am, Martin Brown wrote:
On 12/10/2020 01:54, Don Y wrote:
I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

Your problem is making the indicator failure sensor method reliable
enough that it is not the source of really annoying phantom errors.

No problem. Just add a failure indicator to the failure indicator.
Then you\'ll get a warning that your failure indicator isn\'t working.


CH

You laugh, but we are using two limit switches, staggered with one being activated on a regular basis and the other as a fail safe so the device can still be used when the first fails.

And that is the right way to do it - parallel (redundant) checks, not
series ones. \"Fault Tolerance\" is a great subject that contains
surprisingly many good, non-obvious ideas. But the most important idea
missing from folk who are unfamiliar with the subject is the difference
in definitions between \"fault\" and \"failure\". Fault Tolerant systems
suffer faults like any do, but without failing.

CH

 

[Michael Terrell]

On Monday, October 12, 2020 at 10:21:51 AM UTC-4, Don Y wrote:

And, you likely only have a handful of such devices in your home. Imagine
having hundreds scattered around an industrial establishment. Do you task
your \"safety\" officer with *routinely* making the rounds and pressing the
\"lamp test\" buttons? How often? What\'s the TCO consequence of this -- vs.
having the device check itself and REPORT when it (infrequently) needs to
be serviced?

The old VOA radio station in Bethany, Ohio had a full time tech on duty around the clock to go around and test the lamps in the control panels. They were 327 midget flanged base in Master Specialties indicating box switches. He had over 100 new lamps on his work cart, to get through a shift. That station was Secondary Master Control, in case something happened to the main station in Washington, DC. I toured the facility during it\'s upgrade in 1970. The site is now a museum, and the former tower site is a golf course. It was replaced with a transponder on a satellite. They could run up to 500KW from 160M to 30 MHZ, or ten individual 50 KW signals.

 

[Klaus Kragelund]

On Monday, October 12, 2020 at 2:54:38 AM UTC+2, Don Y wrote:

I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

The idea of having an \"indicator (lamp) test\" isn\'t intuitive
in the usage pattern for these devices -- unlike an automobile dash,
for example. Any approach that required the user to verify
the proper operation of the indicators will fall short.

For LEDs, I figured I could monitor the drop across the diode
over time (i.e., don\'t even worry about what it\'s \"initial,
theoretical value\" should be... just \"take notes\" and watch
for changes). A diode that opens or shorts would be identifiable
with such a technique. I\'m not sure I can learn/deduce anything
from gradual changes, over time...

I\'ve encountered a few LED clocks with fried segments as well as
wall warts (bricks) with similarly failed \"power indicators\" so
assume failures DO happen.

The solution should apply equally to all LED doping chemistries
(yeah, the voltage across the junction will differ but that\'s why
you observe and track instead of \"hard code\" a fault value)

[I rarely use ADCs that come inside MCUs so it\'s a virtual certainty
that I have such channels to spare]

I also use small \"vibrators\" as haptic indicators. I assume
these are just cheap little DC motors (PM?) -- though I\'ve not
disassembled any to verify.

For these, I figure I could drive them with a current source
and, again, monitor the voltage across the device. An open
load would be obvious as should a short (or stalled rotor?).

Again, I\'d have to find an operating point that would allow the
approach to work for a variety of such different \"indicators\".

The goal in all this is to alert the user of a problem before
he notices it (or, FAILS to notice it!).

Any likely faults that I\'m missing? (note that if the \"detection
hardware\" fails, I can determine this because I can watch to see
how it responds to deliberate changes in the indicators\' state)

Will a failing LED, ie lower light emitting output, really affect the voltage drop vs current?

If not, then the measurement strategy won\'t work, except for a device to measure that the LED is in fact working

Cheers

Klaus

 

[Piotr Wyderski]

Don Y wrote:

For LEDs, I figured I could monitor the drop across the diode
over time (i.e., don\'t even worry about what it\'s \"initial,
theoretical value\" should be... just \"take notes\" and watch
for changes).  A diode that opens or shorts would be identifiable
with such a technique.  I\'m not sure I can learn/deduce anything
from gradual changes, over time...

LEDs are very fast, so instead of monitoring some static values you can
turn the diodes on for a microsecond periodically and check the params
synchronously with that. Human eye will not notice.

For these, I figure I could drive them with a current source
and, again, monitor the voltage across the device.  An open
load would be obvious as should a short (or stalled rotor?).

Those probably are based on brushed motors, so maybe it would better to
monitor the AC noise/switching component and compare it to a reference?
That way you will be able to discover the rotational frequency and
decide if it is within the limits. A low-resolution DFT is cheap even on
an 8-bitter.

> Any likely faults that I\'m missing?

I am not sure if Juvenile was an EE, but by asking \"Quis custodiet ipsos
custodes?\" he had a point...

Best regards, Piotr

 

[Don Y]

On 10/13/2020 7:14 AM, Klaus Kragelund wrote:

On Monday, October 12, 2020 at 2:54:38 AM UTC+2, Don Y wrote:
I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

The goal in all this is to alert the user of a problem before he notices
it (or, FAILS to notice it!).

Any likely faults that I\'m missing? (note that if the \"detection hardware\"
fails, I can determine this because I can watch to see how it responds to
deliberate changes in the indicators\' state)

Will a failing LED, ie lower light emitting output, really affect the
voltage drop vs current?

That\'s not the goal. I\'ll design to L70 and, possibly, increase the
drive (duty cycle) when that point in time occurs. Note that decreased
output will, at worst, shift color of RGB indicators -- but, not in
a way that confuses \"violet\" with \"red\" or \"blue\".

[There are, apparently, some things you CAN deduce by observing the forward
voltage -- at a given operating current. I\'ve received a packet of information
from one manufacturer (under NDA) that I\'m currently reviewing to determine
if any of those issues are worth monitoring. Or, if they will naturally lead
to more drastic \"gross failures\" and rely on catching them, there.]

But, once I release the design to manufacturing, I can\'t guarantee
that some twit won\'t substitute a \"cheaper\" (deliberate choice of
words!) component that might CLAIM to have the same specs, on paper,
but, in reality, is inferior in durability. (i.e., from \"We Makum
Velly Blight Lights\" -- you like? :< )

[Such a substitution happened at a client of mine many years ago.
The increased warranty repair costs made the product a flop and left
a really bad taste in customers\' mouths.]

If not, then the measurement strategy won\'t work, except for a device to
measure that the LED is in fact working

Note:
\"I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.\"

I\'m trying to detect the case of an indicator (or portion of an
indicator, if that indicator is a composite device) not being
capable of \"indicating\" when called on.

Many devices include \"lamp tests\" (e.g., illuminating all of the segments
on a 7-segment digit; illuminating all of the \"idiot lights\" on a car\'s
dashboard; etc.) that allows an OBSERVANT user to notice that some
portion of the display/indicator is not functioning properly. This, so
that he isn\'t misinformed/uninformed when some datum of significance
needs to be conveyed.

Imagine an RGB LED losing one component emitter and \"yellow\" erroneously
appearing as \"red\" or \"green\" (depending on which component has failed)
each, presumably, indicative of some OTHER condition/state!

[relying on red and green as different states is, itself, a design flaw]

But, without a natural/intuitive place to insert such a test (because
the device runs 24/7/365), you\'re reliant on the user manually
invoking such a test. This adds cost and decreases overall reliability
(because now the fallible human is a key part of your strategy).

IME, making devices signal actual or impending problems leaves
customers a lot more satisfied with their purchase choices -- instead
of continuously being vigilant for unexpected/unnoticed failures.

 

[Don Y]

On 10/13/2020 8:30 AM, Piotr Wyderski wrote:

Don Y wrote:

For LEDs, I figured I could monitor the drop across the diode
over time (i.e., don\'t even worry about what it\'s \"initial,
theoretical value\" should be... just \"take notes\" and watch
for changes). A diode that opens or shorts would be identifiable
with such a technique. I\'m not sure I can learn/deduce anything
from gradual changes, over time...

LEDs are very fast, so instead of monitoring some static values you can turn
the diodes on for a microsecond periodically and check the params synchronously
with that. Human eye will not notice.

Exactly my strategy. You have to test every indicator state, not just
the state that is currently being indicated! (so, you can\'t have a
*purely* static display)

For these, I figure I could drive them with a current source
and, again, monitor the voltage across the device. An open
load would be obvious as should a short (or stalled rotor?).

Those probably are based on brushed motors, so maybe it would better to monitor
the AC noise/switching component and compare it to a reference?
That way you will be able to discover the rotational frequency and decide if it
is within the limits. A low-resolution DFT is cheap even on an 8-bitter.

Computational power isn\'t an issue. Note that you don\'t have to continuously
monitor for any of these things -- if you assume that failures are persistent.

But, I\'d not like to have to add any recurring costs (or very little) for the
express purpose of JUST detecting these failures. E.g., using an unused ADC
to give me a non-binary assessment of the potential across an emitter or
motor is essentially free. OTOH, adding some gain to drag switching noise
out of the mud means adding components -- unless the commutation noise
is very visible, relaative to the drive signal.

Any likely faults that I\'m missing?

I am not sure if Juvenile was an EE, but by asking \"Quis custodiet ipsos
custodes?\" he had a point...

One can likewise question the reliability of the software, processor,
wiring, power supplies, human user, etc. <grin> And, for each new
level of protection, consider the need for yet another, /ad infinitum/.

If you were worried about reliability, you\'d use different approaches
to solving the same problem with an eye towards minimizing any common
assumptions/reliances.

[E.g., when I design mechanism controllers, the software queries the
actual position of the mechanism under control and interprets that
in the context of how the mechanism is currently being COMMANDED
(i.e., if command is \"move right\" then motion had better be rightward
and not stopped or leftward!). Hardware comparators monitor the
same positional sensors to override the controls if the software
fails to act before the mechanism moves to an extreme. Mechanical
limit switches interrupt the power to the mechanism if the comparator
circuit fails to act. And, mechanical stops are the last hope to
prevent the mechanism from causing damage/injury. The likelihood of
ALL failing is intended to be zero. Despite this, when it comes
to \"safety interlocks\", you\'re often faced with a motivated user who
has decided his need to bypass your protections outweighs the
risks that you are trying to minimze... \"can\'t win\"!]

Instead you fall back on worrying about SINGLE failures (or, some
number of independent failures). If you want to guard against any
undetectable failures, the solution is to simply never apply power
to the device! <grin>

 

[Don Y]

On 10/13/2020 6:43 AM, Michael Terrell wrote:

On Monday, October 12, 2020 at 10:21:51 AM UTC-4, Don Y wrote:

And, you likely only have a handful of such devices in your home. Imagine
having hundreds scattered around an industrial establishment. Do you task
your \"safety\" officer with *routinely* making the rounds and pressing the
\"lamp test\" buttons? How often? What\'s the TCO consequence of this -- vs.
having the device check itself and REPORT when it (infrequently) needs to
be serviced?

The old VOA radio station in Bethany, Ohio had a full time tech on duty
around the clock to go around and test the lamps in the control panels. They
were 327 midget flanged base in Master Specialties indicating box switches.
He had over 100 new lamps on his work cart, to get through a shift. That
station was Secondary Master Control, in case something happened to the main
station in Washington, DC. I toured the facility during it\'s upgrade in
1970. The site is now a museum, and the former tower site is a golf course.
It was replaced with a transponder on a satellite. They could run up to
500KW from 160M to 30 MHZ, or ten individual 50 KW signals.

Interesting. I\'d heard similar stories of maintaining tube (valve)
based systems (and, that PM actually DECREASED reliability!).

People too easily dismiss the costs of these \"little things\" because they
can\'t wrap their heads around how the cost scales. E.g., replacing
lights in a home is a relatively low frequency/cost activity. OTOH,
replacing them in a hotel becomes a full-time job!

 

[bitrex]

On 10/13/2020 1:57 PM, Don Y wrote:

On 10/13/2020 7:14 AM, Klaus Kragelund wrote:
On Monday, October 12, 2020 at 2:54:38 AM UTC+2, Don Y wrote:
I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

The goal in all this is to alert the user of a problem before he notices
it (or, FAILS to notice it!).

Any likely faults that I\'m missing? (note that if the \"detection
hardware\"
fails, I can determine this because I can watch to see how it
responds to
deliberate changes in the indicators\' state)

Will a failing LED, ie lower light emitting output, really affect the
voltage drop vs current?

That\'s not the goal.  I\'ll design to L70 and, possibly, increase the
drive (duty cycle) when that point in time occurs.  Note that decreased
output will, at worst, shift color of RGB indicators -- but, not in
a way that confuses \"violet\" with \"red\" or \"blue\".

[There are, apparently, some things you CAN deduce by observing the forward
voltage -- at a given operating current.  I\'ve received a packet of
information
from one manufacturer (under NDA) that I\'m currently reviewing to determine
if any of those issues are worth monitoring.  Or, if they will naturally
lead
to more drastic \"gross failures\" and rely on catching them, there.]

But, once I release the design to manufacturing, I can\'t guarantee
that some twit won\'t substitute a \"cheaper\" (deliberate choice of
words!) component that might CLAIM to have the same specs, on paper,
but, in reality, is inferior in durability.   (i.e., from \"We Makum
Velly Blight Lights\" -- you like?  :< )

[Such a substitution happened at a client of mine many years ago.
The increased warranty repair costs made the product a flop and left
a really bad taste in customers\' mouths.]

If not, then the measurement strategy won\'t work, except for a device to
measure that the LED is in fact working
Note:
    \"I\'m looking for inexpensive schemes to detect *gross* failures of
    indicators intended to remain in service for decades.\"

I\'m trying to detect the case of an indicator (or portion of an
indicator, if that indicator is a composite device) not being
capable of \"indicating\" when called on.

Many devices include \"lamp tests\" (e.g., illuminating all of the segments
on a 7-segment digit; illuminating all of the \"idiot lights\" on a car\'s
dashboard; etc.) that allows an OBSERVANT user to notice that some
portion of the display/indicator is not functioning properly.  This, so
that he isn\'t misinformed/uninformed when some datum of significance
needs to be conveyed.

Imagine an RGB LED losing one component emitter and \"yellow\" erroneously
appearing as \"red\" or \"green\" (depending on which component has failed)
each, presumably, indicative of some OTHER condition/state!

[relying on red and green as different states is, itself, a design flaw]

But, without a natural/intuitive place to insert such a test (because
the device runs 24/7/365), you\'re reliant on the user manually
invoking such a test.  This adds cost and decreases overall reliability
(because now the fallible human is a key part of your strategy).

IME, making devices signal actual or impending problems leaves
customers a lot more satisfied with their purchase choices -- instead
of continuously being vigilant for unexpected/unnoticed failures.

It\'s probably possible to detect dead segments in a 7 segment LED
display by using common cathode displays and driving them constant
voltage, with a constant voltage source in the cathode, and monitoring
current with a single low-value sense R, or looking at the feedback loop
voltage.

A wild idea I thought of for automated lamp-test of many LEDS, maybe not
useful but since we\'re brainstorming I thought I\'d mention it.

Couple each LED to phototransistor/optical switch, and stack the
switches in a binary tree. Turn all lights on and force a current down
each of the two main branches of the binary switch tree, using feedback
to equalize them, and monitor the feedback loop voltage. If there\'s a
fault somewhere in the tree the loop voltage will swing out of
tolerance, and the direction it swings should show which branch of the
tree the fault is in, and how much should show what level. And then if
it\'s a single open failure which lamp has failed can maybe be detected
by active probing.

I think that scheme would be able to localize single open failures and
at least detect multiple. There is probably a dual arrangement by
measuring tree current that can be used to detect the shorted condition.

 

[bitrex]

On 10/13/2020 2:20 PM, bitrex wrote:

On 10/13/2020 1:57 PM, Don Y wrote:
On 10/13/2020 7:14 AM, Klaus Kragelund wrote:
On Monday, October 12, 2020 at 2:54:38 AM UTC+2, Don Y wrote:
I\'m looking for inexpensive schemes to detect *gross* failures of
indicators intended to remain in service for decades.

The goal in all this is to alert the user of a problem before he
notices
it (or, FAILS to notice it!).

Any likely faults that I\'m missing? (note that if the \"detection
hardware\"
fails, I can determine this because I can watch to see how it
responds to
deliberate changes in the indicators\' state)

Will a failing LED, ie lower light emitting output, really affect the
voltage drop vs current?

That\'s not the goal.  I\'ll design to L70 and, possibly, increase the
drive (duty cycle) when that point in time occurs.  Note that decreased
output will, at worst, shift color of RGB indicators -- but, not in
a way that confuses \"violet\" with \"red\" or \"blue\".

[There are, apparently, some things you CAN deduce by observing the
forward
voltage -- at a given operating current.  I\'ve received a packet of
information
from one manufacturer (under NDA) that I\'m currently reviewing to
determine
if any of those issues are worth monitoring.  Or, if they will
naturally lead
to more drastic \"gross failures\" and rely on catching them, there.]

But, once I release the design to manufacturing, I can\'t guarantee
that some twit won\'t substitute a \"cheaper\" (deliberate choice of
words!) component that might CLAIM to have the same specs, on paper,
but, in reality, is inferior in durability.   (i.e., from \"We Makum
Velly Blight Lights\" -- you like?  :< )

[Such a substitution happened at a client of mine many years ago.
The increased warranty repair costs made the product a flop and left
a really bad taste in customers\' mouths.]

If not, then the measurement strategy won\'t work, except for a device to
measure that the LED is in fact working
Note:
     \"I\'m looking for inexpensive schemes to detect *gross* failures of
     indicators intended to remain in service for decades.\"

I\'m trying to detect the case of an indicator (or portion of an
indicator, if that indicator is a composite device) not being
capable of \"indicating\" when called on.

Many devices include \"lamp tests\" (e.g., illuminating all of the segments
on a 7-segment digit; illuminating all of the \"idiot lights\" on a car\'s
dashboard; etc.) that allows an OBSERVANT user to notice that some
portion of the display/indicator is not functioning properly.  This, so
that he isn\'t misinformed/uninformed when some datum of significance
needs to be conveyed.

Imagine an RGB LED losing one component emitter and \"yellow\" erroneously
appearing as \"red\" or \"green\" (depending on which component has failed)
each, presumably, indicative of some OTHER condition/state!

[relying on red and green as different states is, itself, a design flaw]

But, without a natural/intuitive place to insert such a test (because
the device runs 24/7/365), you\'re reliant on the user manually
invoking such a test.  This adds cost and decreases overall reliability
(because now the fallible human is a key part of your strategy).

IME, making devices signal actual or impending problems leaves
customers a lot more satisfied with their purchase choices -- instead
of continuously being vigilant for unexpected/unnoticed failures.

It\'s probably possible to detect dead segments in a 7 segment LED
display by using common cathode displays and driving them constant
voltage, with a constant voltage source in the cathode, and monitoring
current with a single low-value sense R, or looking at the feedback loop
voltage.

If the supply is 5 volts and they\'re red-segment displays a TL431
configured as a zener and a 1 ohm sense shunt in line to ground might
work OK for a 10 bit ADC.

 

[Piotr Wyderski]

Don Y wrote:

Exactly my strategy.  You have to test every indicator state, not just
the state that is currently being indicated!  (so, you can\'t have a
*purely* static display)

But is not being static a problem? Human eye stops perceiving discrete
events if the repetition rate is more than about 20Hz. TV is based on
that fact.

But, I\'d not like to have to add any recurring costs (or very little)
for the
express purpose of JUST detecting these failures.  E.g., using an unused
ADC
to give me a non-binary assessment of the potential across an emitter or
motor is essentially free.  OTOH, adding some gain to drag switching noise
out of the mud means adding components -- unless the commutation noise
is very visible, relaative to the drive signal.

I have no idea what the noise level is, but I do know that this kind of
AC component sensing was used by old Polish gramophones to stabilise the
rotation speed of the platter. So it could have not been based on an
FPGA; the commies had to do it with a simple circuit, as transistors
were expensive back then. The low-noise BC413 was even kind of
worshipped. Give this option a try if only to learn something.

One can likewise question the reliability of the software, processor,
wiring, power supplies, human user, etc.  <grin

And one should. \"Being reliable is like being a lady. If you have to
tell people you are, you aren\'t\". ;-)

Best regards, Piotr

 

[Don Y]

On 10/13/2020 11:36 AM, Piotr Wyderski wrote:

Don Y wrote:

Exactly my strategy. You have to test every indicator state, not just
the state that is currently being indicated! (so, you can\'t have a
*purely* static display)

But is not being static a problem? Human eye stops perceiving discrete events
if the repetition rate is more than about 20Hz. TV is based on that fact.

Understood. My point is that the indicator\'s state can be expected to change
(moreso than a \"power indicator\" or \"check engine\" light).

But, I\'d not like to have to add any recurring costs (or very little) for the
express purpose of JUST detecting these failures. E.g., using an unused ADC
to give me a non-binary assessment of the potential across an emitter or
motor is essentially free. OTOH, adding some gain to drag switching noise
out of the mud means adding components -- unless the commutation noise
is very visible, relaative to the drive signal.

I have no idea what the noise level is, but I do know that this kind of AC
component sensing was used by old Polish gramophones to stabilise the rotation
speed of the platter. So it could have not been based on an FPGA; the commies
had to do it with a simple circuit, as transistors were expensive back then.
The low-noise BC413 was even kind of worshipped. Give this option a try if only
to learn something.

I\'ll drag out a \'scope and have a look at it. I\'d be concerned, however,
that it might not be a repeatable characteristic (motor to motor, vendor
to vendor). I\'m concerned that most vendors seem to be chinese. This is
not necessarily a \"problem\" but there doesn\'t appear to be any \"established\"
vendors with long histories and reputations to rely upon; one gets the
feeling that a vendor may be here-today-gone-tomorrow... or, worse, that
a product may incur changes that are solely intended to drive cost down
(given that most of these seem to be used in cell phones -- which aren\'t
considered to be long-lived products)

One can likewise question the reliability of the software, processor,
wiring, power supplies, human user, etc. <grin

And one should. \"Being reliable is like being a lady. If you have to tell
people you are, you aren\'t\". ;-)