Page 18 - Troubleshooting Analog Circuits

Methodical, Logical Plans Ease Troubleshooting 5

questions-as explicitly as possible-of yourself or your technician or whoever was
working on the project. For example, if your roommate called you to ask for a lift
because the car had just quit in the middle of a freeway, you would ask whether any-
thimg else happened or if the car just died. If you’re told that the headlights seemed to
be getting dimmer and dimmer, that’s a clue.

Ask Questions; Take Notes; Record Amount of Funny
When you ask these four questions, make sure to record the answers on paper-
preferably in a notebook. As an old test manager I used to work with, Tom Milligan,
used to tell his technicians, “When you are taking data, if you see something funny,
Record Amount of Funny.” That was such a significant piece of advice, we called it
“Milligan’s Law.” A few significant notes can save you hours of work. Clues are
where you find them; they should be saved and savored.
Ask not only these questions but also any other questions suggested by the an-
swers. For example, a neophyte product engineer will sometimes come to see me
with a batch of ICs that have a terrible yield at some particular test. I’ll ask if the
parts failed any other tests, and I’ll hear that nobody knows because the tester doesn’t
continue to test a part after it detects a failure. A more experienced engineer would
have already retested the devices in the RUN ALL TESTS mode, and that is exactly
what I instruct the neophyte to do.
Likewise, if you are asking another person for advice, you should have all the facts
laid out straight, at least in your head, so that you can be clear and not add to the
confusion. I’ve worked with a few people who tell me one thing and a minute later
start telling me the opposite. Nothing makes me lose my temper faster! Nobody can
help you troubleshoot effectively if you aren’t sure whether the circuit is running
from +12 V or f12 V and you start making contradictory statements.
And, if I ask when the device started working badly, don’t tell me, “At 3:25 PM.”
I’m looking for clues, such as, “About two minutes after I put it in the 125 “C oven,”
or, “Just after I connected the 4 R load.” So just as we can all learn a little more about
troubleshooting, we can all learn to watch for the clues that are invaluable for fault
diagnosis.

Methodical, Logical Plans Ease Troubleshooting

Even a simple problem with a resistive divider offers an opportunity to concoct an
intelligent troubleshooting plan. Suppose you had a series string of 128 1 k0 resistors.
(See Figure 1.2.) If you applied 5 V to the top of the string and 0 V to the bottom, you
would expect the midpoint-of the string to be at 2.5 V. If it weren’t 2.5 V but actually
0 V, you could start your troubleshooting by checking the voltage on each resistor,
working down from the top, one by one. But that strategy would be absurd! Check
the voltage at, say, resistor #E%, the resistor which is halfway up from the midpoint to
the top. Then, depending on whether that test is high, low, or reasonable, try at #112
or #8&at 5/8 or 7/8 of the span-then at #120 or #lo4 or #88 or #72, branching
along in a sort of binary search-that would be much more effective. With just a few
trials (about seven) you could find where a resistor was broken open or shorted to
ground. Such branching along would take a lot fewer than the 64 tests you would
need to walk all the way down the string.
Further, if an op-amp circuit’s output were pegged, you would normally check the
circuit’s op amp, resistors, or conductors. You wouldn’t normally check the capaci-
tors, unless you guessed that a shorted capacitor could cause the output to peg.