Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: john larkin <jl@glen--canyon.com>
Newsgroups: sci.electronics.design
Subject: Re: KA7500 vs TL494
Date: Sun, 13 Apr 2025 10:45:27 -0700
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <0otnvjlvnt26fesfcgn5a1ula8v2ph17fh@4ax.com>
References: <h9b5uj1g7bl5ie2l321qoduc2a7tu7d8it@4ax.com> <m5mb0gFnu6sU1@mid.individual.net> <uotcvjtkop72srb39j9rrq3mbopd6iips0@4ax.com> <rm5dvj9h9fqjrv3egnql8s8nc5ss8vpa78@4ax.com> <cjdlvjtobfcj8j9f282cjpd904ef2mt2ah@4ax.com> <2nhlvj96dl0updulr6r21lh9qs2n0dr4q8@4ax.com> <qulnvj980r40l5tnlfn798ur49o2kj9rol@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 13 Apr 2025 19:45:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="715de108789c05ffa89b1a97c41de877";
	logging-data="3588638"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18wBDbRmLZ8v8FZzrwV0gAZ"
User-Agent: ForteAgent/8.00.32.1272
Cancel-Lock: sha1:g6pYHkEo6W61Q0pst/dj9Uhk3wQ=

On Sun, 13 Apr 2025 11:37:11 -0400, legg <legg@nospam.magma.ca> wrote:

>On Sat, 12 Apr 2025 13:07:19 -0700, john larkin <jl@glen--canyon.com>
>wrote:
>
>>On Sat, 12 Apr 2025 15:08:18 -0400, legg <legg@nospam.magma.ca> wrote:
>>
>>>On Wed, 09 Apr 2025 08:51:52 -0700, john larkin <jl@glen--canyon.com>
>>>wrote:
>>>
>>>>On Wed, 09 Apr 2025 09:42:22 -0400, legg <legg@nospam.magma.ca> wrote:
>>>>
>>>>>On Tue, 8 Apr 2025 21:22:37 -0700, Joerg <news@analogconsultants.com>
>>>>>wrote:
>>>>>
>>>>>>On 3/25/25 6:25 AM, legg wrote:
>>>>>>> Chinese commodity power supplies have tended to use recognizable
>>>>>>> configurations from times gone by. In doing so, it's easy to
>>>>>>> miss some of the 'small stuff' that actually produced a reliable
>>>>>>> product, in the day.
>>>>>>> 
>>>>>>> Even more so, when pricing reaches the 'replace vs repair' threshold
>>>>>>> - why even bother with burn-in, in that case? If no burn-in or field
>>>>>>> return failure analysis is ever consudered, the small errors persist,
>>>>>>> particularly if vendors play wack-a-mole with the same hardware
>>>>>>> offered under different brand names and paperwork.
>>>>>>> 
>>>>>>
>>>>>>Burn-in? Doesn't that happen at the customer? :-)
>>>>>
>>>>>No, burn-in is a well-defined process control step used in the 
>>>>>manufacturing of equipment to achieve and maintain low failure 
>>>>>rates (ppm).
>>>>>
>>>>
>>>>What fraction of the parts and equipment that you buy has been
>>>>burned-in? And how do you know?
>>>>
>>>>I'd expect 0%, and that you don't know.
>>>
>>>Purchases of assembled hardware, here, are generally consumer 
>>>grade, with no obvious indication that infant mortality has 
>>>been addressed. 
>>>
>>>Some incoming aql levels are specified in the data sheets at 
>>>the component level. Things like pumps, motors and power supply 
>>>units are included in this category.
>>>
>>>Designs or products that go out the door can only achieve ppm 
>>>failure rates if a burn-in strategy is included after final assy.
>>>Nuts and bolts can fail just as often at this stage.
>>>
>>>RL
>>
>>With modern electronics, burnin isn't necessary or feasible.
>>
>>Temperature cycling and vibration would improve reliability a bit, but
>>that's not practical either.
>>
>>The biggest failure cause is bad engineering.
>>
>>Modern electronics, except for the obvious cheap junk, is remarkably
>>reliable.
>
>Apart from the price, there's nothing 'obvious' about modern 
>electronic reliability. Modern's got nothing to do with it.

ICs are more reliable than tubes.

Transistors don't have their wire bonds sheared by bad epoxy shrinking
much these days, or breaking from Purple Plague. Fraction-of-a-cent
surface mount resistors don't fail at all.

>
>Off-shore hardware can suffer 200% tarrifs and still be 
>competative at the retail level. There's plenty of room 
>for quality control.

Great, let's have some.

>
>Those margins are, instead, being absorbed by shareholders; 

The CCP, mostly.




>hence the stock market sensitivity at that end.
>
>RL