On Tue, 16 Apr 2024 11:10:40 -0400, "Edward Rawde"
<invalid@invalid.invalid> wrote:

>"Don Y" <blockedofcourse@foo.invalid> wrote in message
>news:uvl2gr$phap$2@dont-email.me...
>> On 4/15/2024 8:33 PM, Edward Rawde wrote:
>>
>> [Shouldn't that be Edwar D rawdE?]
>>
>
>I don't mind how you pronounce it.
>
>>
>...
>>
>> A smoke detector that beeps once a day risks not being heard
>
>Reminds me of a tenant who just removed the battery to stop the annoying
>beeping.

My experience has been the smoke detectors too close (as the smoke
travels) to the kitchen tend to suffer mysterious disablement.
Relocation of the smoke detector usually solves the problem.

Joe Gwinn

On Tue, 16 Apr 2024 09:45:34 +0100, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:

>On 15/04/2024 18:13, Don Y wrote:
>> Is there a general rule of thumb for signalling the likelihood of
>> an "imminent" (for some value of "imminent") hardware failure?
>
>You have to be very careful that the additional complexity doesn't
>itself introduce new annoying failure modes. My previous car had
>filament bulb failure sensors (new one is LED) of which the one for the
>parking light had itself failed - the parking light still worked.
>However, the car would great me with "parking light failure" every time
>I started the engine and the main dealer refused to cancel it.
>
>Repair of parking light sensor failure required swapping out the
>*entire* front light assembly since it was built in one time hot glue.
>That would be a very expensive "repair" for a trivial fault.
>
>The parking light is not even a required feature.
>
>> I suspect most would involve *relative* changes that would be
>> suggestive of changing conditions in the components (and not
>> directly related to environmental influences).
>>
>> So, perhaps, a good strategy is to just "watch" everything and
>> notice the sorts of changes you "typically" encounter in the hope
>> that something of greater magnitude would be a harbinger...
>
>Monitoring temperature, voltage supply and current consumption isn't a
>bad idea. If they get unexpectedly out of line something is wrong.
>Likewise with power on self tests you can catch some latent failures
>before they actually affect normal operation.

The real way to reduce failure rates is by designing carefully.

Sometimes BIST can help ensure that small failures won't become
board-burning failures, but an RMA will happen anyhow.

I just added a soft-start feature to a couple of boards. Apply a
current-limited 48 volts to the power stages before the real thing is
switched on hard.

"Don" <g@crcomp.net> wrote in message news:20240416a@crcomp.net...
> Don Y wrote:
>> Is there a general rule of thumb for signalling the likelihood of
>> an "imminent" (for some value of "imminent") hardware failure?
>>
>> I suspect most would involve *relative* changes that would be
>> suggestive of changing conditions in the components (and not
>> directly related to environmental influences).
>>
>> So, perhaps, a good strategy is to just "watch" everything and
>> notice the sorts of changes you "typically" encounter in the hope
>> that something of greater magnitude would be a harbinger...
>
> A singular speculative spitball - the capacitive marker:
>
> In-situ Prognostic Method of Power MOSFET Based on Miller Effect
>
> ... This paper presents a new in-situ prognosis method for
> MOSFET based on miller effect. According to the theory
> analysis, simulation and experiment results, the miller
> platform voltage is identified as a new degradation
> precursor ...
>
> (10.1109/PHM.2017.8079139)

Very interesting but are there any products out there which make use of this
or other prognostic methods to provide information on remaining useful life?

>
> Danke,
>
> --
> Don, KB7RPU, https://www.qsl.net/kb7rpu
> There was a young lady named Bright Whose speed was far faster than light;
> She set out one day In a relative way And returned on the previous night.
>

"Don Y" <blockedofcourse@foo.invalid> wrote in message
news:uvl2gr$phap$2@dont-email.me...
> On 4/15/2024 8:33 PM, Edward Rawde wrote:
>
> [Shouldn't that be Edwar D rawdE?]

I don't mind how you pronounce it.

>
>
> Again, the goal is to be an EARLY warning, not an "Oh, Shit! Kill the
> power!!"
>
> As such, software is invaluable as designing PREDICTIVE hardware is
> harder than designing predictive software (algorithms).

Two comparators can make a window detector which will tell you whether some
parameter is in a specified range.
And it doesn't need monthly updates because software is never finished.

>
> You don't want to tell the user "The battery in your smoke detector
> is NOW dead (leaving you vulnerable)" but, rather, "The battery in
> your smoke detector WILL cease to be able to provide the power necessary
> for the smoke detector to provide the level of protection that you
> desire."
>
> And, the WAY that you inform the user has to be "productive/useful".
> A smoke detector beeping every minute is likely to find itself unplugged,
> leading to exactly the situation that the alert was trying to avoid!

Reminds me of a tenant who just removed the battery to stop the annoying
beeping.
Better to inform the individual who can get the replacement done when the
tenant isn't even home.

>
>
> I'm not looking for speculation. I'm looking for folks who have DONE
> such things (designing to speculation is more expensive than just letting
> the devices fail when they need to fail!)

Well I don't recall putting anything much into a design which could predict
remaining life.
The only exceptions, also drawing from other replies in this thread, might
be be temperature sensing,
voltage sensing, current sensing, air flow sensing, noise sensing, iron in
oil sensing,
and any other kind of sensing which might provide information on parameters
outside or getting close to outside expected range.
Give that to some software which also knows how long the equipment has been
in use, how often
it has been used, what the temperature and humidity was, how long it's been
since the oil was changed,
and you might be able to give the operator useful information about when to
schedule specific maintenance.
But don't give the software too much control. I don't want to be told that I
can't use the equipment because an oil change was required 5 minutes ago and
it hasn't been done yet.

>
>
....

"Joe Gwinn" <joegwinn@comcast.net> wrote in message
news:4l5t1jtefudrcq5dmpcv993l5jqsg1k8tc@4ax.com...
> On Tue, 16 Apr 2024 11:10:40 -0400, "Edward Rawde"
> <invalid@invalid.invalid> wrote:
>
>>"Don Y" <blockedofcourse@foo.invalid> wrote in message
>>news:uvl2gr$phap$2@dont-email.me...
>>> On 4/15/2024 8:33 PM, Edward Rawde wrote:
>>>
>>> [Shouldn't that be Edwar D rawdE?]
>>>
>>
>>I don't mind how you pronounce it.
>>
>>>
>>...
>>>
>>> A smoke detector that beeps once a day risks not being heard
>>
>>Reminds me of a tenant who just removed the battery to stop the annoying
>>beeping.
>
> My experience has been the smoke detectors too close (as the smoke
> travels) to the kitchen tend to suffer mysterious disablement.

Oh yes I've had that too. I call them burnt toast detectors.

> Relocation of the smoke detector usually solves the problem.
>
> Joe Gwinn

On 4/16/2024 9:02 AM, Edward Rawde wrote:
>> Again, the goal is to be an EARLY warning, not an "Oh, Shit! Kill the
>> power!!"
>>
>> As such, software is invaluable as designing PREDICTIVE hardware is
>> harder than designing predictive software (algorithms).
>
> Two comparators can make a window detector which will tell you whether some
> parameter is in a specified range.

Yes, but you are limited in the relationships that you can encode
in hardware -- because they are "hard-wired".

> And it doesn't need monthly updates because software is never finished.

Software is finished when the design is finalized. When management
fails to discipline itself to stop the list of "Sales would like..."
requests, then it's hard for software to even CLAIM to be finished.

[How many hardware products see the addition of features and new
functionality at the rate EXPECTED of software? Why can't I drive
my car from the back seat? It's still a "car", right? It's not like
I'm asking for it to suddenly FLY! Why can't this wall wart deliver
400A at 32VDC? It's still a power supply, right? It's not like I'm
asking for it to become an ARB!]

>> You don't want to tell the user "The battery in your smoke detector
>> is NOW dead (leaving you vulnerable)" but, rather, "The battery in
>> your smoke detector WILL cease to be able to provide the power necessary
>> for the smoke detector to provide the level of protection that you
>> desire."
>>
>> And, the WAY that you inform the user has to be "productive/useful".
>> A smoke detector beeping every minute is likely to find itself unplugged,
>> leading to exactly the situation that the alert was trying to avoid!
>
> Reminds me of a tenant who just removed the battery to stop the annoying
> beeping.

"Dinner will be served at the sound of the beep".

[I had a friend who would routinely trip her smoke detector while cooking.
Then, wave a dishtowel in front of it (she was short) to try to "clear" it.]

Most places have specific rules regarding the placement of smoke detectors
to 1) ensure safety and 2) avoid nuisance alarms. (I was amused to disover
that our local fire department couldn't cite the local requirements when
I went asking!)

Add CO and heat detectors to the mix and they get *really* confused!

> Better to inform the individual who can get the replacement done when the
> tenant isn't even home.

So, a WiFi/BT link to <whatever>? Now the simple smoke detector starts
suffering from feeping creaturism. "Download the app..."

Remind the occupants once a week (requiring acknowledgement) starting
a month prior to ANTICIPATED battery depletion. When the battery is on
it's last leg, you can be a nuisance.

Folks will learn to remember at the first (or second or third) reminder
in order to avoid the annoying nuisance behavior that is typical of
most detectors. (there is not a lot of $aving$ to replacing the
battery at the second warning instead of at the "last minute")

[We unconditionally replace all of ours each New Years. Modern units
now come with sealed "10 year" batteries -- 10 years being the expected
lifespan of the detector itself!]

>> I'm not looking for speculation. I'm looking for folks who have DONE
>> such things (designing to speculation is more expensive than just letting
>> the devices fail when they need to fail!)
>
> Well I don't recall putting anything much into a design which could predict
> remaining life.

Most people don't. Most people don't design for high availability
*or* "costly" systems. When I was designing for pharma, my philosophy was
to make it easy/quick to replace the entire control system. Let someone
troubleshoot it on a bench instead of on the factory floor (which is
semi-sterile).

When you have hundreds/thousands of devices in a single installation,
then you REALLY don't want to have to be playing wack-a-mole with whichever
devices have crapped out, TODAY. If these *10* are likely to fail in
the next month, then replace all ten of them NOW, when you can fit
that maintenance activity into the production schedule instead of
HAVING to replace them when they DISRUPT the production schedule.

> The only exceptions, also drawing from other replies in this thread, might
> be be temperature sensing,
> voltage sensing, current sensing, air flow sensing, noise sensing, iron in
> oil sensing,
> and any other kind of sensing which might provide information on parameters
> outside or getting close to outside expected range.

> Give that to some software which also knows how long the equipment has been
> in use, how often
> it has been used, what the temperature and humidity was, how long it's been
> since the oil was changed,
> and you might be able to give the operator useful information about when to
> schedule specific maintenance.

I have all of those things -- with the exception of knowing which sensory data
is most pertinent to failure prediction. I can watch to see when one device
fails and use it to anticipate the next failure. After many years (of 24/7
operation) and many sites, I can learn from actual experience.

Just like I can learn that you want your coffee pot started 15 minutes after
you arise -- regardless of time of day. Or, that bar stock will be routed
directly to the Gridley's. Because that's what I've *observed* you doing!

> But don't give the software too much control. I don't want to be told that I
> can't use the equipment because an oil change was required 5 minutes ago and
> it hasn't been done yet.

Advisories are just that; advisories. They are there to help the user
avoid the "rudeness" of a piece of equipment "suddenly" (as far as the
user is concerned) failing. They add value by increasing availability.

If you choose to ignore the advisory (e.g., not purchasing a spare to have
on hand for that "imminent" failure), then that's your perogative. If
you can afford to have "down time" and only react to ACTUAL failures,
then that's a policy decision that YOU make.

OTOH, if there is no oil in the gearbox, the equipment isn't going to
start; if the oil sensor is defective, then *it* needs to be replaced.
But, if the gearbox is truly empty, then it needs to be refilled.
In either case, the equipment *needs* service -- now. Operating in
this FAILED state presumably poses some risk, hence the prohibition.

[Cars have gas gauges to save the driver from "discovering" that he's
run out of fuel!]

On 17/04/2024 1:22 am, John Larkin wrote:
> On Tue, 16 Apr 2024 09:45:34 +0100, Martin Brown <'''newspam'''@nonad.co.uk> wrote:
>> On 15/04/2024 18:13, Don Y wrote:

<snip>

> Sometimes BIST can help ensure that small failures won't become
> board-burning failures, but an RMA will happen anyhow.

Built-in self test is mostly auto-calibration. You can use temperature
sensitive components for precise measurements if you calibrate out the
temperature shift and re-calibrate if the measured temperature shifts
appreciably (or every few minutes).

It might also take out the effects of dopant drift in a hot device, but
it wouldn't take it out forever.

> I just added a soft-start feature to a couple of boards. Apply a
> current-limited 48 volts to the power stages before the real thing is
> switched on hard.

Soft-start has been around forever. If you don't pay attention to what
happens to your circuit at start-up and turn-off you can have some real
disasters.

At Cambridge Instruments I once replaced all the tail resistors in a
bunch of class-B long-tailed-pair-based scan amplifiers with constant
current diodes. With the resistors tails, the scan amps drew a lot of
current when the 24V rail was being ramped up and that threw the 24V
supply into current limit, so it didn't ramp up. The constant current
diodes stopped this (not that I can remember how).

This was a follow-up after I'd brought in to stop the 24V power supply
from blowing up (because it hadn't had a properly designed current limit).

The problem had shown up in production - where it was known as the three
back problem because when things did go wrong the excursions on the 24V
rail destroyed three bags of components.

--
Bill Sloman, Sydney

Edward Rawde wrote:
> Don wrote:
>> Don Y wrote:
>>> Is there a general rule of thumb for signalling the likelihood of
>>> an "imminent" (for some value of "imminent") hardware failure?
>>>
>>> I suspect most would involve *relative* changes that would be
>>> suggestive of changing conditions in the components (and not
>>> directly related to environmental influences).
>>>
>>> So, perhaps, a good strategy is to just "watch" everything and
>>> notice the sorts of changes you "typically" encounter in the hope
>>> that something of greater magnitude would be a harbinger...
>>
>> A singular speculative spitball - the capacitive marker:
>>
>> In-situ Prognostic Method of Power MOSFET Based on Miller Effect
>>
>> ... This paper presents a new in-situ prognosis method for
>> MOSFET based on miller effect. According to the theory
>> analysis, simulation and experiment results, the miller
>> platform voltage is identified as a new degradation
>> precursor ...
>>
>> (10.1109/PHM.2017.8079139)
>
> Very interesting but are there any products out there which make use of this
> or other prognostic methods to provide information on remaining useful life?

Perhaps this popular application "rings a bell"?

Battery and System Health Monitoring of Battery-Powered Smart Flow
Meters Reference Design

<https://www.ti.com/lit/ug/tidudo5a/tidudo5a.pdf>

Danke,

--
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

On Tue, 16 Apr 2024 08:16:04 -0700, John Larkin
<jjSNIPlarkin@highNONOlandtechnology.com> wrote:

>On Tue, 16 Apr 2024 10:19:00 -0400, Joe Gwinn <joegwinn@comcast.net>
>wrote:
>
>>On Mon, 15 Apr 2024 16:26:35 -0700, john larkin <jl@650pot.com> wrote:
>>
>>>On Mon, 15 Apr 2024 18:03:23 -0400, Joe Gwinn <joegwinn@comcast.net>
>>>wrote:
>>>
>>>>On Mon, 15 Apr 2024 13:05:40 -0700, john larkin <jl@650pot.com> wrote:
>>>>
>>>>>On Mon, 15 Apr 2024 15:41:57 -0400, Joe Gwinn <joegwinn@comcast.net>
>>>>>wrote:
>>>>>
>>>>>>On Mon, 15 Apr 2024 10:13:02 -0700, Don Y
>>>>>><blockedofcourse@foo.invalid> wrote:
>>>>>>
>>>>>>>Is there a general rule of thumb for signalling the likelihood of
>>>>>>>an "imminent" (for some value of "imminent") hardware failure?
>>>>>>>
>>>>>>>I suspect most would involve *relative* changes that would be
>>>>>>>suggestive of changing conditions in the components (and not
>>>>>>>directly related to environmental influences).
>>>>>>>
>>>>>>>So, perhaps, a good strategy is to just "watch" everything and
>>>>>>>notice the sorts of changes you "typically" encounter in the hope
>>>>>>>that something of greater magnitude would be a harbinger...
>>>>>>
>>>>>>There is a standard approach that may work: Measure the level and
>>>>>>trend of very low frequency (around a tenth of a Hertz) flicker noise.
>>>>>>When connections (perhaps within a package) start to fail, the flicker
>>>>>>level rises. The actual frequency monitored isn't all that critical.
>>>>>>
>>>>>>Joe Gwinn
>>>>>
>>>>>Do connections "start to fail" ?
>>>>
>>>>Yes, they do, in things like vias. I went through a big drama where a
>>>>critical bit of radar logic circuitry would slowly go nuts.
>>>>
>>>>It turned out that the copper plating on the walls of the vias was
>>>>suffering from low-cycle fatigue during temperature cycling and slowly
>>>>breaking, one little crack at a time, until it went open. If you
>>>>measured the resistance to parts per million (6.5 digit DMM), sampling
>>>>at 1 Hz, you could see the 1/f noise at 0.1 Hz rising. It's useful to
>>>>also measure a copper line, and divide the via-chain resistance by the
>>>>no-via resistance, to correct for temperature changes.
>>>
>>>But nobody is going to monitor every via on a PCB, even if it were
>>>possible.
>>
>>It was not possible to test the vias on the failing logic board, but
>>we knew from metallurgical cut, polish, and inspect studies of failed
>>boards that it was the vias that were failing.
>>
>>
>>>One could instrument a PCB fab test board, I guess. But DC tests would
>>>be fine.
>>
>>What was being tested was a fab test board that had both the series
>>via chain path and the no-via path of roughly the same DC resistance,
>>set up so we could do 4-wire Kelvin resistance measurements of each
>>path independent of the other path.
>
>
>Yes, but the question was whether one could predict the failure of an
>operating electronic gadget. The answer is mostly NO.

Agree.

>We had a visit from the quality team from a giant company that you
>have heard of. They wanted us to trend analyze all the power supplies
>on our boards and apply a complex algotithm to predict failures. It
>was total nonsense, basically predicting the future by zooming in on
>random noise with a big 1/f component, just like climate prediction.

Hmm. My first instinct was that they were using MIL-HNBK-317 (?) or
the like, but that does not measure noise. Do you recall any more of
what they were doing? I might know what they were up to. The
military were big on prognostics for a while, and still talk of this,
but it never worked all that well in the field compared to what it was
supposed to improve on.

>>>We have one board with over 4000 vias, but they are mostly in
>>>parallel.
>>
>>This can also be tested , but using a 6.5-digit DMM intended for
>>measuring very low resistance values. A change of one part in 4,000
>>is huge to a 6.5-digit instrument. The conductivity will decline
>>linearly as vias fail one by one.
>>
>>
>
>Millikelvin temperature changes would make more signal than a failing
>via.

Not at the currents in that logic card. Too much ambient thermal
noise.

>>>>The solution was to redesign the vias, mainly to increase the critical
>>>>volume of copper. And modern SMD designs have less and less copper
>>>>volume.
>>>>
>>>>I bet precision resistors can also be measured this way.
>>>>
>>>>
>>>>>I don't think I've ever owned a piece of electronic equipment that
>>>>>warned me of an impending failure.
>>>>
>>>>Onset of smoke emission is a common sign.
>>>>
>>>>
>>>>>Cars do, for some failure modes, like low oil level.
>>>>
>>>>The industrial method for big stuff is accelerometers attached near
>>>>the bearings, and listen for excessive rotation-correlated (not
>>>>necessarily harmonic) noise.
>>>
>>>Big ships that I've worked on have a long propeller shaft in the shaft
>>>alley, a long tunnel where nobody often goes. They have magnetic shaft
>>>runout sensors and shaft bearing temperature monitors.
>>>
>>>They measure shaft torque and SHP too, from the shaft twist.
>>
>>Yep. And these kinds of things fail slowly. At first.
>
>They could repair a bearing at sea, given a heads-up about violent
>failure. A serious bearing failure on a single-screw machine means
>getting a seagoing tug.
>
>The main engine gearbox had padlocks on the covers.
>
>There was also a chem lab to analyze oil and water and such, looking
>for contaminamts that might suggest something going on.
>
>
>>
>>
>>>I liked hiding out in the shaft alley. It was private and cool, that
>>>giant shaft slowly rotating.
>>
>>Probably had a calming flowing water sound as well.
>
>Yes, cool and beautiful and serene after the heat and noise and
>vibration of the engine room. A quiet 32,000 horsepower.
>
>It was fun being an electronic guru on sea trials of a ship full of
>big hairy Popeye types. I, skinny gawky kid, got my own stateroom when
>other tech reps slept in cots in the hold.
>
>Have you noticed how many lumberjack types are afraid of electricity?
>That can be funny.

Oh yes. And EEs frightened by a 9-v battery.

Joe Gwinn

"Don Y" <blockedofcourse@foo.invalid> wrote in message
news:uvmaet$1231i$2@dont-email.me...
> On 4/16/2024 9:02 AM, Edward Rawde wrote:
>>> Again, the goal is to be an EARLY warning, not an "Oh, Shit! Kill the
>>> power!!"
>>>
....
> Add CO and heat detectors to the mix and they get *really* confused!
>
>> Better to inform the individual who can get the replacement done when the
>> tenant isn't even home.
>
> So, a WiFi/BT link to <whatever>? Now the simple smoke detector starts
> suffering from feeping creaturism. "Download the app..."

No thanks. I have the same view of cameras.
They won't be connecting outbound to a server anywhere in the world.
But the average user does not know that and just wants the pictures on their
phone.

>
>> The only exceptions, also drawing from other replies in this thread,
>> might
>> be be temperature sensing,
>> voltage sensing, current sensing, air flow sensing, noise sensing, iron
>> in
>> oil sensing,
>> and any other kind of sensing which might provide information on
>> parameters
>> outside or getting close to outside expected range.
>
>> Give that to some software which also knows how long the equipment has
>> been
>> in use, how often
>> it has been used, what the temperature and humidity was, how long it's
>> been
>> since the oil was changed,
>> and you might be able to give the operator useful information about when
>> to
>> schedule specific maintenance.
>
> I have all of those things -- with the exception of knowing which sensory
> data
> is most pertinent to failure prediction.

That's one reason why you want feedback from people who use your equipment.

>
>
> OTOH, if there is no oil in the gearbox, the equipment isn't going to
> start; if the oil sensor is defective, then *it* needs to be replaced.

Preferably by me purchasing a new sensor and being able to replace it
myself.

>...

"Bill Sloman" <bill.sloman@ieee.org> wrote in message
news:uvmao8$124q1$1@dont-email.me...
> On 17/04/2024 1:22 am, John Larkin wrote:
>> On Tue, 16 Apr 2024 09:45:34 +0100, Martin Brown
>> <'''newspam'''@nonad.co.uk> wrote:
>>> On 15/04/2024 18:13, Don Y wrote:
>
> <snip>
>
>> Sometimes BIST can help ensure that small failures won't become
>> board-burning failures, but an RMA will happen anyhow.
>
> Built-in self test is mostly auto-calibration. You can use temperature
> sensitive components for precise measurements if you calibrate out the
> temperature shift and re-calibrate if the measured temperature shifts
> appreciably (or every few minutes).
>
> It might also take out the effects of dopant drift in a hot device, but it
> wouldn't take it out forever.
>
>> I just added a soft-start feature to a couple of boards. Apply a
>> current-limited 48 volts to the power stages before the real thing is
>> switched on hard.
>
> Soft-start has been around forever. If you don't pay attention to what
> happens to your circuit at start-up and turn-off you can have some real
> disasters.

Yes I've seen that a lot.
The power rails in the production product came up in a different order to
those in the development lab.
This caused all kinds of previously unseen behaviour including an expensive
flash a/d chip burning up.

I'd have it in the test spec that any missing power rail does not cause
issues.
And any power rail can be turned on and off any time.
The equipment may not work properly with a missing power rail but it should
not be damaged.

>
> At Cambridge Instruments I once replaced all the tail resistors in a bunch
> of class-B long-tailed-pair-based scan amplifiers with constant current
> diodes. With the resistors tails, the scan amps drew a lot of current when
> the 24V rail was being ramped up and that threw the 24V supply into
> current limit, so it didn't ramp up. The constant current diodes stopped
> this (not that I can remember how).
>
> This was a follow-up after I'd brought in to stop the 24V power supply
> from blowing up (because it hadn't had a properly designed current limit).
>
> The problem had shown up in production - where it was known as the three
> back problem because when things did go wrong the excursions on the 24V
> rail destroyed three bags of components.
>
> --
> Bill Sloman, Sydney
>
>
>

On 4/16/2024 10:25 AM, Edward Rawde wrote:
>>> Better to inform the individual who can get the replacement done when the
>>> tenant isn't even home.
>>
>> So, a WiFi/BT link to <whatever>? Now the simple smoke detector starts
>> suffering from feeping creaturism. "Download the app..."
>
> No thanks. I have the same view of cameras.
> They won't be connecting outbound to a server anywhere in the world.
> But the average user does not know that and just wants the pictures on their
> phone.

There is no need for a manufacturer to interpose themselves in such
"remote access". Having the device register with a DDNS service
cuts out the need for the manufacturer to essentially provide THAT
service.

OTOH, the manufacturer wants to "keep selling toilet paper" and
has used that business model to underwrite the cost of the "device".

Everything, here, is wired. And, my designs have the same approach:
partly because I can distribute power over the fabric; partly because
it removes an attqck surface (RF jamming); partly for reliability
(no reliance on services that the user doesn't "own"); partly for
privacy (no information leaking -- even by side channel inference).
My wireless connections are all short range and of necessity
(e.g., the car connects via wifi so the views from the external
cameras can be viewed on it's LCD screen as it pulls out/in).

>>> Give that to some software which also knows how long the equipment has
>>> been
>>> in use, how often
>>> it has been used, what the temperature and humidity was, how long it's
>>> been
>>> since the oil was changed,
>>> and you might be able to give the operator useful information about when
>>> to
>>> schedule specific maintenance.
>>
>> I have all of those things -- with the exception of knowing which sensory
>> data
>> is most pertinent to failure prediction.
>
> That's one reason why you want feedback from people who use your equipment.

All they know is when something BREAKS. But, my device also knows that
(unless EVERY "thing" breaks at the same time). The devices can capture
pertinent data to adjust it's model of when those other devices are
likely to suffer similar failures because the failed device shared
its observations with them (via a common knowledge base).

>> OTOH, if there is no oil in the gearbox, the equipment isn't going to
>> start; if the oil sensor is defective, then *it* needs to be replaced.
>
> Preferably by me purchasing a new sensor and being able to replace it
> myself.

If it makes sense to do so. Replacing a temperature sensor inside an
MCU is likely not cost effective, something folks are capable of doing nor
supported as an FRU.

"Don Y" <blockedofcourse@foo.invalid> wrote in message
news:uvmjmt$140d2$1@dont-email.me...
> On 4/16/2024 10:25 AM, Edward Rawde wrote:
>>>> Better to inform the individual who can get the replacement done when
>>>> the
>>>> tenant isn't even home.
>>>
>>> So, a WiFi/BT link to <whatever>? Now the simple smoke detector starts
>>> suffering from feeping creaturism. "Download the app..."
>>
>> No thanks. I have the same view of cameras.
>> They won't be connecting outbound to a server anywhere in the world.
>> But the average user does not know that and just wants the pictures on
>> their
>> phone.
>
> There is no need for a manufacturer to interpose themselves in such
> "remote access". Having the device register with a DDNS service
> cuts out the need for the manufacturer to essentially provide THAT
> service.

Not for most users here.
They tried to put me on lsn/cgnat not long ago.
After complaining I was given a free static IPv4.
Most users wouldn't know DDNS from a banana, and will expect it to work out
of the box after installing the app on their phone.

>
>...

On 4/16/2024 8:37 AM, Edward Rawde wrote:
> "Don" <g@crcomp.net> wrote in message news:20240416a@crcomp.net...
>> Don Y wrote:
>>> Is there a general rule of thumb for signalling the likelihood of
>>> an "imminent" (for some value of "imminent") hardware failure?
>>>
>>> I suspect most would involve *relative* changes that would be
>>> suggestive of changing conditions in the components (and not
>>> directly related to environmental influences).
>>>
>>> So, perhaps, a good strategy is to just "watch" everything and
>>> notice the sorts of changes you "typically" encounter in the hope
>>> that something of greater magnitude would be a harbinger...
>>
>> A singular speculative spitball - the capacitive marker:
>>
>> In-situ Prognostic Method of Power MOSFET Based on Miller Effect
>>
>> ... This paper presents a new in-situ prognosis method for
>> MOSFET based on miller effect. According to the theory
>> analysis, simulation and experiment results, the miller
>> platform voltage is identified as a new degradation
>> precursor ...
>>
>> (10.1109/PHM.2017.8079139)
>
> Very interesting but are there any products out there which make use of this
> or other prognostic methods to provide information on remaining useful life?

Wanna bet there's a shitload of effort going into sorting out how to
prolong the service life of batteries for EVs?

It's only a matter of time before large organizations and nations start
looking hard at "eWaste" both from the standpoint of efficient use of
capitol, resources and environmental consequences. If recycling was
mandated (by law), how many vendors would rethink their approach to
product design? (Do we really need to assume the cost of retrieving
that 75 inch TV from the customer just so we can sell him ANOTHER?
Is there a better way to pitch improvements in *features* instead of
pels or screen size?)

Here, you have to PAY (typ $25) for someone to take ownership of
your CRT-based devices. I see Gaylords full of LCD monitors discarded
each week. And, a 20 ft roll-off of "flat screen TVs" monthly.

Most businesses discard EVERY workstation in their fleet on a
2-3 yr basis. The software update cycle coerces hardware developers
to design for a similarly (artificially) limited lifecycle.

[Most people are clueless at the volume of eWaste that their communities
generate, regularly.]

On 4/16/2024 12:43 PM, Edward Rawde wrote:
> "Don Y" <blockedofcourse@foo.invalid> wrote in message
> news:uvmjmt$140d2$1@dont-email.me...
>> On 4/16/2024 10:25 AM, Edward Rawde wrote:
>>>>> Better to inform the individual who can get the replacement done when
>>>>> the
>>>>> tenant isn't even home.
>>>>
>>>> So, a WiFi/BT link to <whatever>? Now the simple smoke detector starts
>>>> suffering from feeping creaturism. "Download the app..."
>>>
>>> No thanks. I have the same view of cameras.
>>> They won't be connecting outbound to a server anywhere in the world.
>>> But the average user does not know that and just wants the pictures on
>>> their
>>> phone.
>>
>> There is no need for a manufacturer to interpose themselves in such
>> "remote access". Having the device register with a DDNS service
>> cuts out the need for the manufacturer to essentially provide THAT
>> service.
>
> Not for most users here.
> They tried to put me on lsn/cgnat not long ago.
> After complaining I was given a free static IPv4.

Most folks, here, effectively have static IPs -- even if not guaranteed
as such. But, most also have AUPs that prohibit running their own servers
(speaking about consumers, not businesses).

> Most users wouldn't know DDNS from a banana, and will expect it to work out
> of the box after installing the app on their phone.

There's no reason the app can't rely on DDNS. Infineon used to make
a series of "power control modules" (think BSR/X10) for consumers.
You could talk to the "controller" -- placed on YOUR network -- directly.
No need to go THROUGH a third party (e.g., Infineon).

If you wanted to access those devices (through the controller) from
a remote location, the controller -- if you provided internet access
to it -- would register with a DDNS and you could access it through
that URL.

It is only recently that vendors have been trying to bake themselves into
their products. Effectively turning their products into "rentals".
You can buy a smart IP camera that will recognize *people*! For $30.
Plus $6/month -- forever! (and, if you stop paying, you have a nice
high-tech-looking PAPERWEIGHT).

I rescued another (APC) UPS, recently. I was excited that they FINALLY
had included the NIC in the basic model (instead of as an add-in card
as it has historically been supplied - at additional cost).

[I use the network access to log my power consumption and control the
power to attached devices without having to press power buttons]

Ah, but you can't *talk* to that NIC! It exists so the UPS can talk to the
vendor! Who will let you talk to them to get information about YOUR UPS.

So, you pay for a NIC that you can't use -- unless you agree to their
terms (I have no idea if there is a fee involved or if they just want
to spy on your usage and sell you batteries!)

In addition to the sleeze factor, it's also a risk. Do you know what
the software in the device does? Are you sure it is benevolent? And,
not snooping your INTERNAL network (it's INSIDE your firewall)? Maybe
just trying to sort out what sorts of hardware you have (for which they
could pitch additional products/services)? Are you sure the product
(if benign) can't be hacked and act as a beachhead for some other
infestation?

And, what, exactly, am I *getting* for this risk that I couldn't get
with the "old style" NIC?

On Tue, 16 Apr 2024 13:25:07 -0000 (UTC), "Don" <g@crcomp.net> wrote:

>Don Y wrote:
>> Is there a general rule of thumb for signalling the likelihood of
>> an "imminent" (for some value of "imminent") hardware failure?
>>
>> I suspect most would involve *relative* changes that would be
>> suggestive of changing conditions in the components (and not
>> directly related to environmental influences).
>>
>> So, perhaps, a good strategy is to just "watch" everything and
>> notice the sorts of changes you "typically" encounter in the hope
>> that something of greater magnitude would be a harbinger...
>
>A singular speculative spitball - the capacitive marker:
>
> In-situ Prognostic Method of Power MOSFET Based on Miller Effect
>
> ... This paper presents a new in-situ prognosis method for
> MOSFET based on miller effect. According to the theory
> analysis, simulation and experiment results, the miller
> platform voltage is identified as a new degradation
> precursor ...
>
> (10.1109/PHM.2017.8079139)
>
>Danke,

Sounds like they are really measuring gate threshold, or gate transfer
curve, drift with time. That happens and is usually no big deal, in
moderation. Ions and charges drift around. We don't build opamp
front-ends from power mosfets.

This doesn't sound very useful for "in-situ" diagnostics.

GaN fets can have a lot of gate threshold and leakage change over time
too. Drive them hard and it doesn't matter.

"Don Y" <blockedofcourse@foo.invalid> wrote in message
news:uvmqve$15hl7$2@dont-email.me...
> On 4/16/2024 12:43 PM, Edward Rawde wrote:
>> "Don Y" <blockedofcourse@foo.invalid> wrote in message
>> news:uvmjmt$140d2$1@dont-email.me...
>>> On 4/16/2024 10:25 AM, Edward Rawde wrote:
>>>>>> Better to inform the individual who can get the replacement done when
>>>>>> the
>>>>>> tenant isn't even home.
>>>>>
>>>>> So, a WiFi/BT link to <whatever>? Now the simple smoke detector
>>>>> starts
>>>>> suffering from feeping creaturism. "Download the app..."
>>>>
But vendors know that most people want it easy so the push towards
subscription services and products which phone home isn't going to change.

Most people don't know or care what their products are sending to the
vendor.

I like to see what is connecting to what with https://www.pfsense.org/
But I might be the only person in 100 mile radius doing so.

I can also remote desktop from anywhere of my choice, with the rest of the
world unable to connect.

Pretty much all of my online services are either restricted to specific IPs
(cameras, remote desktop and similar).
Or they have one or more countries and other problem IPs blocked. (web sites
and email services).

None of that is possible when the vendor is in control because users will
want their camera pictures available anywhere.

On 4/16/2024 6:25 AM, Don wrote:
> Don Y wrote:
>> Is there a general rule of thumb for signalling the likelihood of
>> an "imminent" (for some value of "imminent") hardware failure?
>>
>> I suspect most would involve *relative* changes that would be
>> suggestive of changing conditions in the components (and not
>> directly related to environmental influences).
>>
>> So, perhaps, a good strategy is to just "watch" everything and
>> notice the sorts of changes you "typically" encounter in the hope
>> that something of greater magnitude would be a harbinger...
>
> A singular speculative spitball - the capacitive marker:
>
> In-situ Prognostic Method of Power MOSFET Based on Miller Effect
>
> ... This paper presents a new in-situ prognosis method for
> MOSFET based on miller effect. According to the theory
> analysis, simulation and experiment results, the miller
> platform voltage is identified as a new degradation
> precursor ...

With the levels of integration we now routinely encounter, this
is likely more of interest to a component vendor than an end designer.
I.e., sell a device that provides this sort of information in a
friendlier form.

Most consumers/users don't care about which component failed.
They just see the DEVICE as having failed.

The Reliability Engineer likely has more of an interest -- but,
only if he gets a chance to examine the failed device (how many
"broken" devices actually get returned to their manufacturer
for such analysis? Even when covered IN warranty??)

When I see an LCD monitor indicating signs of imminent failure,
I know I have to have a replacement on-hand. (I keep a shitload).
I happen to know that this particular type of monitor (make/model)
*tends* to fail in one of N (for small values of N) ways. So,
when I get around to dismantling it and troubleshooting, I know
where to start instead of having to wander through an undocumented
design -- AGAIN.

[I've standardized on three different (sized) models to make this
process pretty simple; I don't want to spend more than a few minutes
*repairing* a monitor!]

If the swamp (evaporative) cooler cycles on, I can monitor the rate
of water consumption compared to "nominal". Using this, I can infer
the level of calcification of the water valve *in* the cooler.
To some extent, I can compensate for obstruction by running the
blower at a reduced speed (assuming the cooler can meet the needs
of the house in this condition). With a VFD, I could find the sweet
spot! :>

So, I can alert the occupants of an impending problem that they might
want to address before the cooler can't meet their needs (when the
pads are insufficiently wetted, you're just pushing hot, dry air into
the house/office/business).

A "dumb" controller just looks at indoor temperature and cycles
the system on/off based on whether or not it is above or below
the desired setpoint (which means it can actually make the house
warmer, the harder it tries to close the loop!)

john larkin wrote:
> Don wrote:
>>Don Y wrote:
>>> Is there a general rule of thumb for signalling the likelihood of
>>> an "imminent" (for some value of "imminent") hardware failure?
>>>
>>> I suspect most would involve *relative* changes that would be
>>> suggestive of changing conditions in the components (and not
>>> directly related to environmental influences).
>>>
>>> So, perhaps, a good strategy is to just "watch" everything and
>>> notice the sorts of changes you "typically" encounter in the hope
>>> that something of greater magnitude would be a harbinger...
>>
>>A singular speculative spitball - the capacitive marker:
>>
>> In-situ Prognostic Method of Power MOSFET Based on Miller Effect
>>
>> ... This paper presents a new in-situ prognosis method for
>> MOSFET based on miller effect. According to the theory
>> analysis, simulation and experiment results, the miller
>> platform voltage is identified as a new degradation
>> precursor ...
>>
>> (10.1109/PHM.2017.8079139)
>
> Sounds like they are really measuring gate threshold, or gate transfer
> curve, drift with time. That happens and is usually no big deal, in
> moderation. Ions and charges drift around. We don't build opamp
> front-ends from power mosfets.
>
> This doesn't sound very useful for "in-situ" diagnostics.
>
> GaN fets can have a lot of gate threshold and leakage change over time
> too. Drive them hard and it doesn't matter.

Threshold voltage measurement is indeed one of two parameters. The
second parameter is Miller platform voltage measurement.
The Miller plateau is directly related to the gate-drain
capacitance, Cgd. It's why "capacitive marker" appears in my
original followup.
Long story short, the Miller Plateau length provides a metric
principle to measure Tj without a sensor. Some may find this useful.

Danke,

--
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

On Tue, 16 Apr 2024 08:16:04 -0700, John Larkin wrote:

<clip>
>
> The main engine gearbox had padlocks on the covers.

Padlocks went on every reduction gearbox in the USN in the summer of 1972,
after CV60's departure to Vietnam was delayed by 3 days due to a bucket of
bolts being dumped into #3 Main Machinery Room reduction gear. The locks
were custom made for the application and not otherwise available, to serve
as a tamper-evident seal. You could easily cut one off but you couldn't
get a replacement. #3 main gear was cleaned up and large burrs filed off,
but still made a thump with every revolution for the entire 'Nam cruise.
(This followed a 3 fatality fire in 3-Main which delayed departure by 3
weeks, done skillfully enough to be deemed an accident.)

I was assigned to 3-Main on CV60 for the shipyard overhaul following the
'Nam cruise and heard the stories from those who were there. The
reduction gear thump went away entirely after a full power run following
overhaul, something rarely done except for testing on account of the
~million gallon a day fuel consumption.

>>>I liked hiding out in the shaft alley. It was private and cool, that
>>>giant shaft slowly rotating.
>>
>>Probably had a calming flowing water sound as well.
>
> Yes, cool and beautiful and serene after the heat and noise and
> vibration of the engine room. A quiet 32,000 horsepower.

So not claustrophobic and like cool and quiet - you would have made a good
submariner.

Glen

On Tue, 16 Apr 2024 13:20:34 -0400, Joe Gwinn <joegwinn@comcast.net>
wrote:

>On Tue, 16 Apr 2024 08:16:04 -0700, John Larkin
><jjSNIPlarkin@highNONOlandtechnology.com> wrote:
>
>>On Tue, 16 Apr 2024 10:19:00 -0400, Joe Gwinn <joegwinn@comcast.net>
>>wrote:
>>
>>>On Mon, 15 Apr 2024 16:26:35 -0700, john larkin <jl@650pot.com> wrote:
>>>
>>>>On Mon, 15 Apr 2024 18:03:23 -0400, Joe Gwinn <joegwinn@comcast.net>
>>>>wrote:
>>>>
>>>>>On Mon, 15 Apr 2024 13:05:40 -0700, john larkin <jl@650pot.com> wrote:
>>>>>
>>>>>>On Mon, 15 Apr 2024 15:41:57 -0400, Joe Gwinn <joegwinn@comcast.net>
>>>>>>wrote:
>>>>>>
>>>>>>>On Mon, 15 Apr 2024 10:13:02 -0700, Don Y
>>>>>>><blockedofcourse@foo.invalid> wrote:
>>>>>>>
>>>>>>>>Is there a general rule of thumb for signalling the likelihood of
>>>>>>>>an "imminent" (for some value of "imminent") hardware failure?
>>>>>>>>
>>>>>>>>I suspect most would involve *relative* changes that would be
>>>>>>>>suggestive of changing conditions in the components (and not
>>>>>>>>directly related to environmental influences).
>>>>>>>>
>>>>>>>>So, perhaps, a good strategy is to just "watch" everything and
>>>>>>>>notice the sorts of changes you "typically" encounter in the hope
>>>>>>>>that something of greater magnitude would be a harbinger...
>>>>>>>
>>>>>>>There is a standard approach that may work: Measure the level and
>>>>>>>trend of very low frequency (around a tenth of a Hertz) flicker noise.
>>>>>>>When connections (perhaps within a package) start to fail, the flicker
>>>>>>>level rises. The actual frequency monitored isn't all that critical.
>>>>>>>
>>>>>>>Joe Gwinn
>>>>>>
>>>>>>Do connections "start to fail" ?
>>>>>
>>>>>Yes, they do, in things like vias. I went through a big drama where a
>>>>>critical bit of radar logic circuitry would slowly go nuts.
>>>>>
>>>>>It turned out that the copper plating on the walls of the vias was
>>>>>suffering from low-cycle fatigue during temperature cycling and slowly
>>>>>breaking, one little crack at a time, until it went open. If you
>>>>>measured the resistance to parts per million (6.5 digit DMM), sampling
>>>>>at 1 Hz, you could see the 1/f noise at 0.1 Hz rising. It's useful to
>>>>>also measure a copper line, and divide the via-chain resistance by the
>>>>>no-via resistance, to correct for temperature changes.
>>>>
>>>>But nobody is going to monitor every via on a PCB, even if it were
>>>>possible.
>>>
>>>It was not possible to test the vias on the failing logic board, but
>>>we knew from metallurgical cut, polish, and inspect studies of failed
>>>boards that it was the vias that were failing.
>>>
>>>
>>>>One could instrument a PCB fab test board, I guess. But DC tests would
>>>>be fine.
>>>
>>>What was being tested was a fab test board that had both the series
>>>via chain path and the no-via path of roughly the same DC resistance,
>>>set up so we could do 4-wire Kelvin resistance measurements of each
>>>path independent of the other path.
>>
>>
>>Yes, but the question was whether one could predict the failure of an
>>operating electronic gadget. The answer is mostly NO.
>
>Agree.
>
>
>>We had a visit from the quality team from a giant company that you
>>have heard of. They wanted us to trend analyze all the power supplies
>>on our boards and apply a complex algotithm to predict failures. It
>>was total nonsense, basically predicting the future by zooming in on
>>random noise with a big 1/f component, just like climate prediction.
>
>Hmm. My first instinct was that they were using MIL-HNBK-317 (?) or
>the like, but that does not measure noise. Do you recall any more of
>what they were doing? I might know what they were up to. The
>military were big on prognostics for a while, and still talk of this,
>but it never worked all that well in the field compared to what it was
>supposed to improve on.
>
>
>>>>We have one board with over 4000 vias, but they are mostly in
>>>>parallel.
>>>
>>>This can also be tested , but using a 6.5-digit DMM intended for
>>>measuring very low resistance values. A change of one part in 4,000
>>>is huge to a 6.5-digit instrument. The conductivity will decline
>>>linearly as vias fail one by one.
>>>
>>>
>>
>>Millikelvin temperature changes would make more signal than a failing
>>via.
>
>Not at the currents in that logic card. Too much ambient thermal
>noise.
>
>
>>>>>The solution was to redesign the vias, mainly to increase the critical
>>>>>volume of copper. And modern SMD designs have less and less copper
>>>>>volume.
>>>>>
>>>>>I bet precision resistors can also be measured this way.
>>>>>
>>>>>
>>>>>>I don't think I've ever owned a piece of electronic equipment that
>>>>>>warned me of an impending failure.
>>>>>
>>>>>Onset of smoke emission is a common sign.
>>>>>
>>>>>
>>>>>>Cars do, for some failure modes, like low oil level.
>>>>>
>>>>>The industrial method for big stuff is accelerometers attached near
>>>>>the bearings, and listen for excessive rotation-correlated (not
>>>>>necessarily harmonic) noise.
>>>>
>>>>Big ships that I've worked on have a long propeller shaft in the shaft
>>>>alley, a long tunnel where nobody often goes. They have magnetic shaft
>>>>runout sensors and shaft bearing temperature monitors.
>>>>
>>>>They measure shaft torque and SHP too, from the shaft twist.
>>>
>>>Yep. And these kinds of things fail slowly. At first.
>>
>>They could repair a bearing at sea, given a heads-up about violent
>>failure. A serious bearing failure on a single-screw machine means
>>getting a seagoing tug.
>>
>>The main engine gearbox had padlocks on the covers.
>>
>>There was also a chem lab to analyze oil and water and such, looking
>>for contaminamts that might suggest something going on.
>>
>>
>>>
>>>
>>>>I liked hiding out in the shaft alley. It was private and cool, that
>>>>giant shaft slowly rotating.
>>>
>>>Probably had a calming flowing water sound as well.
>>
>>Yes, cool and beautiful and serene after the heat and noise and
>>vibration of the engine room. A quiet 32,000 horsepower.
>>
>>It was fun being an electronic guru on sea trials of a ship full of
>>big hairy Popeye types. I, skinny gawky kid, got my own stateroom when
>>other tech reps slept in cots in the hold.
>>
>>Have you noticed how many lumberjack types are afraid of electricity?
>>That can be funny.
>
>Oh yes. And EEs frightened by a 9-v battery.
>
>Joe Gwinn

I had an intern, an EE senior, who was afraid of 3.3 volts.

I told him to touch an FPGA to see how warm it was getting, and he
refused.

On Tue, 16 Apr 2024 13:39:07 -0400, "Edward Rawde"
<invalid@invalid.invalid> wrote:

>> On 17/04/2024 1:22 am, John Larkin wrote:
>>> On Tue, 16 Apr 2024 09:45:34 +0100, Martin Brown
>>> <'''newspam'''@nonad.co.uk> wrote:
>>>> On 15/04/2024 18:13, Don Y wrote:
>>

>Yes I've seen that a lot.
>The power rails in the production product came up in a different order to
>those in the development lab.
>This caused all kinds of previously unseen behaviour including an expensive
>flash a/d chip burning up.
>
>I'd have it in the test spec that any missing power rail does not cause
>issues.
>And any power rail can be turned on and off any time.
>The equipment may not work properly with a missing power rail but it should
>not be damaged.

Some FPGAs require supply sequencing, as may as four.

LM3880 is a dedicated powerup sequencer, most cool.

https://www.dropbox.com/scl/fi/gwrimefrgm729k8enqrir/28S662D_sh_19.pdf?rlkey=qvyip7rjqfy6i9yegqrt57n23&dl=0

On Tue, 16 Apr 2024 23:25:30 -0000 (UTC), "Don" <g@crcomp.net> wrote:

>john larkin wrote:
>> Don wrote:
>>>Don Y wrote:
>>>> Is there a general rule of thumb for signalling the likelihood of
>>>> an "imminent" (for some value of "imminent") hardware failure?
>>>>
>>>> I suspect most would involve *relative* changes that would be
>>>> suggestive of changing conditions in the components (and not
>>>> directly related to environmental influences).
>>>>
>>>> So, perhaps, a good strategy is to just "watch" everything and
>>>> notice the sorts of changes you "typically" encounter in the hope
>>>> that something of greater magnitude would be a harbinger...
>>>
>>>A singular speculative spitball - the capacitive marker:
>>>
>>> In-situ Prognostic Method of Power MOSFET Based on Miller Effect
>>>
>>> ... This paper presents a new in-situ prognosis method for
>>> MOSFET based on miller effect. According to the theory
>>> analysis, simulation and experiment results, the miller
>>> platform voltage is identified as a new degradation
>>> precursor ...
>>>
>>> (10.1109/PHM.2017.8079139)
>>
>> Sounds like they are really measuring gate threshold, or gate transfer
>> curve, drift with time. That happens and is usually no big deal, in
>> moderation. Ions and charges drift around. We don't build opamp
>> front-ends from power mosfets.
>>
>> This doesn't sound very useful for "in-situ" diagnostics.
>>
>> GaN fets can have a lot of gate threshold and leakage change over time
>> too. Drive them hard and it doesn't matter.
>
>Threshold voltage measurement is indeed one of two parameters. The
>second parameter is Miller platform voltage measurement.
> The Miller plateau is directly related to the gate-drain
>capacitance, Cgd. It's why "capacitive marker" appears in my
>original followup.
> Long story short, the Miller Plateau length provides a metric
>principle to measure Tj without a sensor. Some may find this useful.
>
>Danke,

When we want to measure actual junction temperature of a mosfet, we
use the substrate diode. Or get lazy and thermal image the top of the
package.

"John Larkin" <jjSNIPlarkin@highNONOlandtechnology.com> wrote in message
news:jr6u1j9vmo3a6tpl1evgrvmu1993slepno@4ax.com...
> On Tue, 16 Apr 2024 13:20:34 -0400, Joe Gwinn <joegwinn@comcast.net>
> wrote:
>
>>On Tue, 16 Apr 2024 08:16:04 -0700, John Larkin
>><jjSNIPlarkin@highNONOlandtechnology.com> wrote:
>>
>>>On Tue, 16 Apr 2024 10:19:00 -0400, Joe Gwinn <joegwinn@comcast.net>
>>>wrote:
>>>
>>>>On Mon, 15 Apr 2024 16:26:35 -0700, john larkin <jl@650pot.com> wrote:
>>>>
>>>>>On Mon, 15 Apr 2024 18:03:23 -0400, Joe Gwinn <joegwinn@comcast.net>
>>>>>wrote:
>>>>>
>>>>>>On Mon, 15 Apr 2024 13:05:40 -0700, john larkin <jl@650pot.com> wrote:
>>>>>>
>>>>>>>On Mon, 15 Apr 2024 15:41:57 -0400, Joe Gwinn <joegwinn@comcast.net>
>>>>>>>wrote:
>>>>>>>
>>>>>>>>On Mon, 15 Apr 2024 10:13:02 -0700, Don Y
>>>>>>>><blockedofcourse@foo.invalid> wrote:
>>>>>>>>
>>>>>>>>>Is there a general rule of thumb for signalling the likelihood of
>>>>>>>>>an "imminent" (for some value of "imminent") hardware failure?
>>>>>>>>>
.....
>>>>
>>>>>I liked hiding out in the shaft alley. It was private and cool, that
>>>>>giant shaft slowly rotating.
>>>>
>>>>Probably had a calming flowing water sound as well.
>>>
>>>Yes, cool and beautiful and serene after the heat and noise and
>>>vibration of the engine room. A quiet 32,000 horsepower.
>>>
>>>It was fun being an electronic guru on sea trials of a ship full of
>>>big hairy Popeye types. I, skinny gawky kid, got my own stateroom when
>>>other tech reps slept in cots in the hold.
>>>
>>>Have you noticed how many lumberjack types are afraid of electricity?
>>>That can be funny.
>>
>>Oh yes. And EEs frightened by a 9-v battery.
>>
>>Joe Gwinn
>
> I had an intern, an EE senior, who was afraid of 3.3 volts.
>
> I told him to touch an FPGA to see how warm it was getting, and he
> refused.
>

That's what happens when they grow up having never accidentally touched the
top cap of a 40KG6A/PL519

On 4/16/2024 3:19 PM, Edward Rawde wrote:
> But vendors know that most people want it easy so the push towards
> subscription services and products which phone home isn't going to change.

Until it does. There is nothing inherent in the design of any
of these products that requires another "service" to provide the
ADVERTISED functionality.

Our stove and refrigerator have WiFi "apps" -- that rely on a tie-in
to the manufacturer's site (no charge but still, why do they need
access to my stovetop?).

Simple solution: router has no radio! Even if the appliances wanted
to connect (ignoring their "disable WiFi access" setting), there's
nothing they can connect *to*.

> Most people don't know or care what their products are sending to the
> vendor.

I think that is a generational issue. My neighbor just bought
camera and, when she realized it had to connect to their OUTBOUND
wifi, she just opted to return it. So, a lost sale AND the cost
of a return.

Young people seem to find nothing odd about RENTING -- anything!
Wanna listen to some music? You can RENT it, one song at a time!
Wanna access the internet using free WiFi *inside* a business?
The idea that they are leaking information never crosses their
mind. They *deserve* to discover that some actuary has noted
a correlation between people who shop at XYZCo and alcoholism.
Or, inability to pay their debts. Or, cannabis use. Or...
whatever the Big Data tells *them*.

Like the driver who complained that his CAR was revealing his
driving behavior through OnStar to credit agencies and their
subscribers (insurance companies) were using that to determine
the risk he represented.

> I like to see what is connecting to what with https://www.pfsense.org/
> But I might be the only person in 100 mile radius doing so.
>
> I can also remote desktop from anywhere of my choice, with the rest of the
> world unable to connect.
>
> Pretty much all of my online services are either restricted to specific IPs
> (cameras, remote desktop and similar).
> Or they have one or more countries and other problem IPs blocked. (web sites
> and email services).

But IP and MAC masquerading are trivial exercises. And, don't require
a human participant to interact with the target (i.e., they can be automated).

I have voice access to the services in my home. I don't rely on the
CID information provided as it can be forged. But, I *do* require
the *voice* match one of a few known voiceprints -- along with other
conditions for access (e.g., if I am known to be HOME, then anyone
calling with my voice is obviously an imposter; likewise, if
someone "authorized" calls and passes the authentication procedure,
they are limited in what they can do -- like, maybe close my garage
door if I happened to leave it open and it is now after midnight).
And, recording a phrase (uttered by that person) only works if you
know what I am going to ASK you; anything that relies on your own
personal knowledge can't be emulated, even by an AI!

No need for apps or appliances -- you could technically use a "payphone"
(if such things still existed) or an office phone in some business.

I have a "cordless phone" in the car that lets me talk to the house from
a range of 1/2 mile, without relying on cell phone service. I can't
send video over the link -- but, I can ask "Did I remember to close
the garage door?" Or, "Did I forget to turn off the tea kettle?"
as I drive away.

> None of that is possible when the vendor is in control because users will
> want their camera pictures available anywhere.

No, you just have to rely on other mechanisms for authentication.

I have a friend who manages a datafarm at a large multinational bank.
When he is here, he uses my internet connection -- which is "foreign"
as far as the financial institution is concerned -- with no problems.
But, he carries a time-varying "token" with him that ensures he
has the correct credentials for any ~2 minute slice of time!

I rely on biometrics, backed with "shared secrets" ("Hi Jane!
How's Tom doing?" "Hmmm, I don't know anyone by the name of Tom")
because I don't want to have to carry a physical key (and
don't want the other folks with access to have to do so, either)

And, most folks don't really need remote access to the things
that are offering that access. Why do I need to check the state
of my oven/stove WHEN I AM NOT AT HOME? (Why the hell would
I leave it ON when the house is empty???) There are refrigerators
that take a photo of the contents of the frig each time you close
the door. Do I care if the photo on my phone is of the state of the
refrigerator when I was last IN PROXIMITY OF IT vs. it's most recent
state? Do I need to access my thermostat "online" vs. via SMS?
Or voice?