Page 21 - Troubleshooting Analog Circuits

8 I. First Things First

ship 525 of them, and some foolish person had bought only 535 PC (printed circuit)
boards. When less than half of the units worked, I found myself in the trouble-
shooting business because nobody else could imagine how to repair them. I discov-
ered that I needed my best-triggering scope and my best DVM. I burned a lot of mid-
night oil. I got half-a-dozen copies each of the schematic and of the board layout. I
scribbled notes on them of what the DC voltages ought to be, what the correct AC
waveforms looked like, and where I could best probe the key waveforms. I made
little lists of, “If this frequency is twice as fast as normal, look for 417 to be dam-
aged, but if the frequency is low, look for a short on bus B.”
I learned where to look for solder shorts, hairline opens, cold-soldered joints, and
intermittents. I diagnosed the problems and sent each unit back for repair with a neat
label of what to change. When they came back, did they work? Some did-and some
still had another level or two of problems. That’s the Onion Syndrome: You peel off
one layer, and you cry; you peel off another layer, and you cry some more. . . . By the
time I was done, I had fixed all but four of the units, and I had gotten myself one hell
of a good education in troubleshooting.
After I found a spot of trouble, what did ldo about it? First of all, I made some
notes to make sure that the problem really was fixed when the offending part was
changed. Then I sent the units to a good, neat technician who did precise repair
work-much better than a slob like me would do. Lastly, I sent memos to the manu-
facturing and QC departments to make sure that the types of parts that had proven
troublesome were not used again, and I confirmed the changes with ECOs
(Engineering Change Orders). It is important to get the paperwork scrupulously cor-
rect, or the alligators will surely circle back to vex you again.

Sloppy Documentation Can End in Chapter XI
I once heard of a similar situation where an insidious problem was causing nasty
reliability problems with a batch of modules. The technician had struggled to find the
solution for several days. Finally, when the technician went out for lunch, the design
engineer went to work on the problem. When the technician came back from lunch,
the engineer told him, “I found the problem; it’s a mismatch between 417 and R18.
Write up the ECO, and when I get back from lunch I’ll sign it.” Unfortunately, the
good rapport between the engineer and the technician broke down: there was some
miscommunication. The technician got confused and wrote up the ECO with an
incorrect version of what should be changed. When the engineer came back from
lunch, he initialed the ECO without really reading it and left for a two-week vacation.
When he came back, the modules had all been “fixed,” potted, and shipped, and
were starting to fail out in the field. A check of the ECO revealed the mistake-too
late. The company went bankrupt. It’s a true story and a painful one. Don’t get
sloppy with your paperwork; don’t let it happen to you.

Failure Analysis?
One of the reasons you do troubleshooting is because you may be required to do a
Failure Analysis on the failure. That’s just another kind of paperwork. Writing a
report is not always fun, but sometimes it helps clarify and crystallize your under-
standing of the problem. Maybe if a customer had forced my engineer friend to write
exactly what happened and what he proposed to do about it, that disaster would not
have occurred. When I have nailed down my little problem, I usually write down a
scribbled quick report. One copy often goes to my boss, because he is curious why
it’s been taking me so long. I usually give a copy to friends who are working on sim-