TIP: Click on subject to list as thread! ANSI
echo: aust_avtech
to: Bob Lawrence
from: Rod Gasson
date: 1997-02-10 20:50:02
subject: 24-12 converters

G'day Bob,



09 Feb 97 09:05, Bob Lawrence wrote to Rod Gasson:



 BL>> He, he. I'm not fazed by that. I've designed sets with inherent

 BL>> faults that no tech *ever* found. A tech's approach is to keep

 BL>> things working; an engineer's approach is to make things fail.



 RG>> You didn't happen to work for Akai by any chance? 



 BL>   (grin)



I'll take that as a 'yes' 



 RG>> I realise that this is slightly different to the audio amps

 RG>> under discussion, and correct me if I'm wrong, but don't many

 RG>> HF circuits actually use the PCB tracks themselves as part of a

 RG>> resonant circuit?



 BL>   Yes... at 10-100MHz. Roy was talking about an oscillation at 1MHz

 BL> in the broadcast band (and so was I).



I realise that (see above)..   This was my way of suggesting that this

may have been where Roy got his idea from.



 RG>> Surely layout would then be very important for stability.



 BL>   Not at 1 MHz. Pay attention. To make a power supply oscillate at

 BL> 1MHz you would need Paul Edwards to wire it up.



LOL.  -  It'll have no flicker though. 



 BL>> *no* experience of) and it fails, there is a sudden stockpile

 BL>> of 100,000 repairs! Therefore, I



 RG>> Sounds like Akai to me. 



 BL>   I've never understood Akai. It costs the same to make a good set as

 BL> a shit set (within $1), so why doesn't someone fix the awful design

 BL> and their bloody-awful factory?



That what many of my customers ask me when I show them Akai service

sheets that cover many models over a several year period. It seems to

me that they find it easier to update their service sheets than to

actually fix the problem.  :-(



 BL> It must mean that the Akai sales

 BL> group simply doesn't care.



That's my opinion too.



 BL>   I was talking to Roy, who had just modified a small-run power

 BL> supply, and I started to explain that "mods" can be
dangerous. He got

 BL> up my nose, so I let him have both barrels.



 BL>   But he is right too. Roy deals with small-run stuff that is very

 BL> likely to have design faults built in, simply because no one ever put

 BL> the effort into it. There is no excuse for Akai. A large factory can

 BL> and should spend the time to get it right, which means that when a

 BL> tech sees a faulty set he's pretty sure it's faulty... not built that

 BL> way.



One of these days, what should be, and what is, may actually coincide.

I'll not hold my breath though.



 BL>   I see quite a few design faults and I get the factory to fix them,

 BL> but it's not easy to convince Japanese or Koreans!



Ain't that the truth.



 BL>> Most of the time, all you guys have to do is fix something that

 BL>> an engineer designed right,



Yup.



 RG>> That's the theory, but surely you are not implying that

 RG>> everything designed by an engineer is flawless or couldn't be

 RG>> improved upon?



 BL>   Most of it is, actually. The Japs are particularly good at making

 BL> each new design a development of the one before, so the breed slowly

 BL> becomes perfect...



Yeah, and just as they reach that stage they hire a new design team

that starts the cycle all over again. :-(   (so it seems)



 RG>> Crap. I've repaired zillions of electronic faults, and not once

 RG>> have I needed to shonk a repair by redesigning the circuit...

 RG>> the exceptions being to perform 'standard modifications' from

 RG>> manufacturers fault/data sheets.



 BL>   At some stage, some tech has found the fault that led to the
"mod"

 BL> sheet, so there is a fatal flaw in your logic. All design faults come



OK, I tell a lie....   'cos I have been responsible for identifying

(and modifying) at least 3 design flaws in various machines, and my

mods were taken up by the manufacturers.



 BL> back from the field, in spite of what the factory implies. What you

 BL> do, is develop a list of reliable techs who get it right, and when

 BL> they say they've found something "funny" you check it out - quick!



Yeah right....   the scenario is more like, "there's no design flaws

in our machines - this is just an isolated case"

After several months of these "isolated cases" (seen in the workshop

on a daily basis, THEN they might take a look into the problem).

I should explain, that the times in question I was working for Radio

Rentals (which are/were largely owned by Phillips), and we (Radio

Rentals) were one of the 'frontline' service centres for their

products -  They did tend to take our reports/recommendations

seriously, but not as 'quick' as they should have.



These days are long gone (for me) though...   since branching out on

my own I don't seem to have the same 'respect' from manufacturers that

I used to have - should I find a design flaw now I'm treated like any

one of the other 1000's of "backyard techs".



 BL>> all the time in the world to get it right. I offered you a

 BL>> little of that



 RG>> Pity that more of them don't actually use this time then. Even

 RG>> a lowly service tech like myself could do better than some of

 RG>> the designs I've seen :-(



 BL>   No, you couldn't (grin). A good tech makes a lousy engineer.



Touche



Seriously, I really do hate having to redesign a circuit to get it

going (or reliable), and the times it has arisen have been so rare

that its not really worth considering..  From a servicing P.O.V I have

two philosophys.

1. If its on the market it is safe to assume it doesn't need

   re-designing.

2. However weird or difficult the fault, it is never the

   microprocessor.



Naturally there are exceptions to these rules, but when I keep them in

mind I tend to save myself a lot of time and $$$.



 BL>   As I said at the beginning, it's a totally different mindset. An



Agreed.



 BL> engineer takes a circuit and tries to make it fail even when it is

 BL> working perfectly, so that at the end he knows it's foolproof. A tech

 BL> will tip-toe away from something that is finally working, and often



Agreed.



 BL> never knows if he has found *the* fault. This is not to say that



Nope, I dissagree with you here...  about the only time he's never

sure if he's found the fault or not is when they've had to modify the

circuit to get it going.

If I find a shorted transistor and replace it, causing the machine to

spring back to life, it is safe to assume the fault has been found.

Whether the fault has an underlying and intermittent cause is another

matter though.



 BL> there isn't crossover in the mindset. What you call a "failed

 BL> engineer" is just a fiddler, but there are nevertheless true techs

 BL> who have the true engineering attitude, and vice versa.



Yup...  There has to be a crossover point somewhere, but as you say,

it does take a different approach/mindset when designing circuits than

it does when faultfinding them.



 BL>   In the early days of transistor radios when I was fixing them for

 BL> money (at 6 an hour), I was the best tech in Sydney at that. You

 BL> suspend all thought and just *go* to the fault. You "know" the set

 BL> and hardly ever use a multimeter, let alone the CRO an engineer can't

 BL> live without.



Yeah...  I know I've got a bitch of a fault when I need to get out the

MM ...  and when I have to power up the CRO (about half dozen times a

year) the customer is looking at expensive repairs.



 BL>   In fact, that's the most obvious difference between a tech and an

 BL> engineer. The engineer has a CRO, the tech only has a soldering iron.



For most faults, that's all a competent tech needs.  (plus a

reasonable sense of smell, and temperature sensitive fingers).



Cheers,

Rod



___ QWKRR128 V4.50 [F]



--- FMail 0.94
* Origin: QWKRR test point (Aust) (3:800/409.128)
SEEN-BY: 50/99 54/99 620/243 623/630 640/820 711/413 430 934 712/311 407 505
SEEN-BY: 712/506 517 610 623 624 704 713/317 714/906 800/1 2 409 419 422 442
SEEN-BY: 800/446 447 453 455 456 459 462 805 810 812 816 822 843 846
@PATH: 800/409 1 712/624 711/934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.