Article 1

The ability to diagnose and correct is an important part of having a career in

computer technology or electronics in general, and we are going to have a
look at some of the strategies used in troubleshooting. And these strategies
include block diagram thinking, signal tracing, signal injection, diagnostic
software, observation, and substitution.

Block Diagram Thinking

The first one we'll look at is Block Diagram Thinking. And troubleshooting
complex electronic systems can be an overwhelming task; many systems are
too complex to be able to visualize all of the system details. One way to avoid
being overwhelmed is to logically troubleshoot the system from a block
diagram perspective. And earlier in this chapter we had looked at block
diagrams and we had observed that block diagrams gave us the big picture of
a system and didn't give us the detail and this often helpful when trying to
diagnose a problem in a large system because you don't want that much
detail, you get lost in the detail. So you want a bigger picture that a block
diagram can provide.

Signal Tracing
The next troubleshooting technique that we'll mention is Signal Tracing. This is
a technique that involves monitoring circuit quantities at various points
throughout the circuit. At each point, you evaluate whether the measurement
is good or bad with respect to the correct or measured value. Typically
oscilloscopes or voltmeters are used to do this. One of the important or
necessary skills in this is that you actually know what is the value that should
be measured at given points, and usually, with given systems, you'll have
technical manuals or schematics that will provide that information.
By tracing the signal through the system, particularly sequential systems, you
will reach a point where the signal is no longer what it should be. And at that
point, you determine this is probably where the fault is. One way to implement
signal tracing is called Divide and Conquer. And in this strategy measurements
are made in the middle of the system. And I guess if I can draw a very basic---
let's just pretend that here we have a given system and the signal comes in
here and the signal comes out over here, and let's pretend that we have test
points throughout this circuit and we could go in and we could measure every
single one of these tests points to determine when does the system fail. Or we
could go in and say ‘Let's measure right here' and we make a determination-
is that a good signal or is it a bad signal? And again you have to be familiar
enough with the system to determine is that a good signal or a bad- well if is
it a good signal then you know the problem is over here somewhere, so you'll
probably divide and conquer again and make a determination as to whether it
is here or here. So that's the concept of divide and conquer utilizing signal
tracing.

Diagnostic Software
Then Diagnostic Software, it is a powerful tool in the troubleshooting
endeavor. This specially designed software requires only limited system
capability in order to execute successfully. Diagnostic software is common in
troubleshooting- notice- in computer systems for memory and hardware
errors. And a couple of the diagnostic software programs that I am familiar
with are Norton Utilities, SiSoft Sandra… in fact, SiSoft Sandra is a free
download and it's an interesting program that you're using to diagnose
computer system faults. Diagnostic software based systems are also used in
automotive troubleshooting.

Observation
Observation; the most important tool in your troubleshooting toolkit is the
power of observation- when we say ‘observation' this is all of the senses, you
can see but you can also smell, and you can also hear, and often times in a
diagnostic system it is not always what you see, sometimes it's what you smell
that tells a lot. Those of you that have been around in this business you know
there that's smell of burning components that tells you something is very
wrong. Sometimes even you'll hear sounds that shouldn't be there.
Anyway, observation is very important in diagnosing faults; many defects can
be diagnosed simply by carefully observing the operation of the circuit.
Observation extends to three other important troubleshooting strategies
(besides specific observing) there is the user interview- what has the user
observed about the circuit, and then there's a concept… this particular term;
front panel milking, I hadn't heard before but this is the way your textbook
describes it, and what it is is the intentional operation of all the front panel
controls while observing the behavior of the system. And this just simply
means that you're putting a given system through all of its paces and
adjusting it and doing all the things that this system should be able to do and
observing its operation. Again, this is only going to be helpful if you know how
that system is supposed to operate, and then you notice something that's not
quite right as a technician you should be able to pick that up. But if you do
not know the correct operation of a given system this may or may not help.
The review of history using log books, log books can be of great value if they
are maintained, often times if a group of technicians is keeping a log of the
system they are maintaining they can diagnose weaknesses in the system and
then when it comes to a fault that comes up they can look in their log books
and say ‘Oh, that particular fault has been occurring frequently' and rather
than doing a… that they can just go directly to the fault based on
documentation.

Substitution
Substitution; benefits and risks. Well, first what is substitution? Once localized,
the suspected component can be substituted and the circuit evaluated again
to verify the component operation. Well let's pretend that this is a radio, and
this one is bad; it doesn't work. And here we have another radio; this one is
good and the technician has this available. And this bad radio has come in and
he's supposed to repair it. So now typically, and this is probably a
communication system for an aircraft or something, it's probably a high-end
device. And most radios are going to have - we'll draw some line here- and
we're going to pretend that these are circuit cards or modules within this bad
radio. Now in the substitution method of troubleshooting what the technician
would do is he would simply pull out… so here we have circuit card one (in the
bad radio) and he would pull out circuit card one (from the good radio) and
replace it. Typically you would replace several before you got to the faulty one.
Now let's just pretend for the sake of discussion that he discovers circuit card
number four was the faulty component, and so he would probably go over to
his supply system and he would order circuit card number four, he would put
it into the radio and the radio is fixed.
And this is the concept of troubleshooting by the method of substitution
when you have a group of known good components.
Substitution can be used at nearly any level in the system integration. In
aviation when a system faults the entire system is often removed and
replaced, and we're going to look at aviation as an example. We talked about
that box in the previous example, let's pretend that in the aircraft the radio
system has failed, the pilot can't talk to ground and he's just landed and he's
got to take off soon. And he can't wait for technicians to fix this thing so what
they would do- and this is major substitution- they would just take this entire
black box out and take a known good black box, plug it in, the radio works
and the pilot flies away.
The bad box is now going to go down to the folks in maintenance, and
maintaining is going to fix this thing. So the technicians take the black box
apart and remove and replace modules until the box is fixed, so they would be
doing the process that we looked at before- substituting modules until they've
repaired the box.
When repaired the radio goes back to the supply system until needed by
another aircraft, so in this case this box now that it is fixed goes into the
supply system and it waits until another radio fails and is then plugged into an
aircraft and away it goes. So in this particular cycle the defective modules are
repaired by the maintenance personnel and this would typically involve going
down to the component level and repairing the faulty circuit card. And there is
no substitution here but in these two upper levels maintenance cycle
substitution is a very viable way of repairing systems.
Substitution is not always practical as the primary method of troubleshooting,
as it requires a tremendous inventory of spare parts in complex systems. Now
in the aviation industry there's a lot of revenue there and the need to make an
aircraft go immediately and so typically the supply system will be able to
support that, but in smaller systems that type of inventory wouldn't always be
available, so in that case substitution will not always be a viable alternative.
Occasionally, and this is another problem with substitution, system chassis will
short, damaging connected modules. And as known good modules are
plugged into the system it destroys them as well, for example most cars today
have an onboard computer, and occasionally the onboard computer will fail so
the technician notices this and says ‘I'll just replace it', and he replaces it only
to have the one he replaced it with go up in smoke as well. The problem
probably is that there is something in the chassis of that vehicle that is
shorting out the onboard computer, so the original problem wasn't the
onboard computer; it was a short in the chassis connected to the onboard
computer. So now he's got two broken computers. Substitution doesn't always
work. It requires experience and good judgment on the part of the technician
to be able to determine when substitution is going to work and when it is not
going to work.

Article 2

Good troubleshooting skills are vital to the electronics hobbyist. More often than not, a circuit is not
going to work perfectly on the first try, especially as a beginner. It can be very intimidating when a
component on a board gets hot, exhibits unexpected behavior, does nothing at all, or even explodes.
Where does one start troubleshooting? The answer is different for every situation and even with
practice one will come across errors that can't be immediately explained. Jedi-like troubleshooting
skills come only with experience, but there are some common problems that can be diagnosed
quickly, and understanding these common problems and how to check for them is a starting place
common to beginners and masters.
Let's say you plug in your circuit, and something is wrong. It could be not working at all, or behaving
in a way that you don't expect. There are issues you should ALWAYS check for before you even get
out the multimeter. These may seem obvious, but it's better to start simply than troubleshoot more
complex issues for hours just to find a silly mistake.

 Is power connected correctly? Connecting ground to a power connection and power to a

ground connection (rather, positive to negative and negative to positive) can damage a
device and will obviously not allow for proper behavior. Check for it. Even the most
experienced professionals will do this from time to time.
  Are the components soldered correctly? If an LED isn't lighting up, maybe the orientation of
the LED is incorrect. Is your square-shaped device soldered so that Pin 1 is where it's
supposed to be? Check for this early. Performing hours of troubleshooting to finally discover
that a chip is on backwards is about as frustrating as it gets.
 Are there solder jumpers/shorts on the board? Check your chips for solder jumpers between
pins. A quick visual inspection can be worth hours of debugging good code.
 Are there bad solder joints? One bad solder joint can hork an entire circuit. Make sure they
are all nice and shiny, and that the pins of a surface mount device are actually touching the
pad on the board and not just floating above with solder on them.

So -- you've preformed all of the tests above and something is still not working. This indicates a
potentially more complex problem, but still there are some general tests one should perform before
hooking up the logic analyzer.

 Is the board bad? This happens every now and then. Perform a continuity test between the
VCC and Ground traces on the board. Rather than risk damaging your devices, make sure
that the ground signals on the board are not shorting to VCC because of a board defect.
 Are your components the correct values? A perfectly soldered resistor is no good if it's not
the correct value. Maybe you accidentally used the 12MHz clock instead of the 16MHz you
meant to use.

The above tests can all be performed in about two minutes, and even though they're simple (and it
hurts a designer's ego to find out she/he made such a simple mistake) they rule out the biggest
common issues with improperly functioning circuits. If a circuit passes all these tests, then one can
start digging into manuals, debugging code, and checking voltages with a multimeter with the
knowledge that the error is not due to a simple common problem.
Example question:
You have a circuit board with the circuit shown below. You power the device, and the LED lights up,
but when you attempt to program the ATTiny, the programming fails. The ATTiny chip is soldered in
the correct orientation. Which of the following should you do next?
A) Check the VCC and GND traces on the board for a short
B) Check that the 330 Ohm resistor is the correct value
C) Inspect the soldering of the chip for cold joints and jumpers
Answer: C
The LED is functioning properly, so you know that there is no short from VCC to GND on the board.
The LED is lighting up, so the resistor is probably the correct value. The ATTiny is in the correct
orientation, so if it's not programming, it's likely not soldered properly to the board. A single cold
solder joint will cause bad connectivity and not allow programming. Check the board for "gray" (as in
not shiny) solder joints, as this is usually indicative of an incorrectly soldered pin.

Article 3:

Specific
Troubleshooting
Techniques
- Troubleshooting -- Theory And Practice

After applying some of the general troubleshooting tips to narrow the scope
of a problem’s location, there are techniques useful in further isolating it. Here
are a few:
Swap identical components
In a system with identical or parallel subsystems, swap components between
those subsystems and see whether or not the problem moves with the
swapped component. If it does, you’ve just swapped the faulty component; if
it doesn’t, keep searching! This is a powerful troubleshooting method, because
it gives you both a positive and a negative indication of the swapped
component’s fault: when the bad part is exchanged between identical systems,
the formerly broken subsystem will start working again and the formerly good
subsystem will fail. I was once able to troubleshoot an elusive problem with an
automotive engine ignition system using this method: I happened to have a
friend with an automobile sharing the exact same model of ignition system.
We swapped parts between the engines (distributor, spark plug wires, ignition
coil—one at a time) until the problem moved to the other vehicle. The
problem happened to be a “weak” ignition coil, and it only manifested itself
under heavy load (a condition that could not be simulated in my garage).
Normally, this type of problem could only be pinpointed using an ignition
system analyzer (or oscilloscope) and a dynamometer to simulate loaded
driving conditions. This technique, however, confirmed the source of the
problem with 100% accuracy, using no diagnostic equipment whatsoever.
Occasionally you may swap a component and find that the problem still exists,
but has changed in some way. This tells you that the components you just
swapped are somehow different (different calibration, different function), and
nothing more. However, don’t dismiss this information just because it doesn’t
lead you straight to the problem—look for other changes in the system as a
whole as a result of the swap, and try to figure out what these changes tell you
about the source of the problem. An important caveat to this technique is the
possibility of causing further damage. Suppose a component has failed
because of another, less conspicuous failure in the system. Swapping the
failed component with a good component will cause the good component to
fail as well. For example, suppose that a circuit develops a short, which “blows”
the protective fuse for that circuit. The blown fuse is not evident by inspection,
and you don’t have a meter to electrically test the fuse, so you decide to swap
the suspect fuse with one of the same rating from a working circuit. As a result
of this, the good fuse that you move to the shorted circuit blows as well,
leaving you with two blown fuses and two non-working circuits. At least you
know for certain that the original fuse was blown, because the circuit it was
moved to stopped working after the swap, but this knowledge was gained
only through the loss of a good fuse and the additional “down time” of the
second circuit. Another example to illustrate this caveat is the ignition system
problem previously mentioned. Suppose that the “weak” ignition coil had
caused the engine to backfire, damaging the muffler. If swapping ignition
system components with another vehicle causes the problem to move to the
other vehicle, damage may be done to the other vehicle’s muffler as well. As a
general rule, the technique of swapping identical components should be used
only when there is minimal chance of causing additional damage. It is an
excellent technique for isolating non-destructive problems. Example 1: You’re
working on a CNC machine tool with X, Y, and Z-axis drives. The Y axis is not
working, but the X and Z axes are working. All three axes share identical
components (feedback encoders, servo motor drives, servo motors). What to
do: Exchange these identical components, one at a time, Y axis and either one
of the working axes (X or Z), and see after each swap whether or not the
problem has moved with the swap. Example 2: A stereo system produces no
sound on the left speaker, but the right speaker works just fine. What to do: Try
swapping respective components between the two channels and see if the
problem changes sides, from left to right. When it does, you’ve found the
defective component. For instance, you could swap the speakers between
channels: if the problem moves to the other side (i.e. the same speaker that
was dead before is still dead, now that its connected to the right channel
cable) then you know that speaker is bad. If the problem stays on the same
side (i.e. the speaker formerly silent is now producing sound after having been
moved to the other side of the room and connected to the other cable), then
you know the speakers are fine, and the problem must lie somewhere else
(perhaps in the cable connecting the silent speaker to the amplifier, or in the
amplifier itself). If the speakers have been verified as good, then you could
check the cables using the same method. Swap the cables so that each one
now connects to the other channel of the amplifier and to the other speaker.
Again, if the problem changes sides (i.e. now the right speaker is now “dead”
and the left speaker now produces sound), then the cable now connected to
the right speaker must be defective. If neither swap (the speakers nor the
cables) causes the problem to change sides from left to right, then the
problem must lie within the amplifier (i.e. the left channel output must be
“dead”).
Remove parallel components
If a system is composed of several parallel or redundant components which
can be removed without crippling the whole system, start removing these
components (one at a time) and see if things start to work again. Example
1: A “star” topology communications network between several computers has
failed. None of the computers are able to communicate with each other. What
to do: Try unplugging the computers, one at a time from the network, and see
if the network starts working again after one of them is unplugged. If it does,
then that last unplugged computer may be the one at fault (it may have been
“jamming” the network by constantly outputting data or noise). Example 2: A
household fuse keeps blowing (or the breaker keeps tripping open) after a short
amount of time. What to do: Unplug appliances from that circuit until the fuse
or breaker quits interrupting the circuit. If you can eliminate the problem by
unplugging a single appliance, then that appliance might be defective. If you
find that unplugging almost any appliance solves the problem, then the circuit
may simply be overloaded by too many appliances, neither of them defective.
Divide system into sections and test
those sections
In a system with multiple sections or stages, carefully measure the variables
going in and out of each stage until you find a stage where things don’t look
right. Example 1: A radio is not working (producing no sound at the
speaker)) What to do: Divide the circuitry into stages: tuning stage, mixing
stages, amplifier stage, all the way through to the speaker(s). Measure signals
at test points between these stages and tell whether or not a stage is working
properly. Example 2: An analog summer circuit is not functioning properly.

What to do: I would test the

passive averager network (the three resistors at the lower-left corner of the
schematic) to see that the proper (averaged) voltage was seen at the
noninverting input of the op-amp. I would then measure the voltage at the
inverting input to see if it was the same as at the noninverting input (or,
alternatively, measure the voltage difference between the two inputs of the
op-amp, as it should be zero). Continue testing sections of the circuit (or just
test points within the circuit) to see if you measure the expected voltages and
currents.
Simplify and rebuild
Closely related to the strategy of dividing a system into sections, this is
actually a design and fabrication technique useful for new circuits, machines,
or systems. It’s always easier begin the design and construction process in
little steps, leading to larger and larger steps, rather than to build the whole
thing at once and try to troubleshoot it as a whole. Suppose that someone
were building a custom automobile. He or she would be foolish to bolt all the
parts together without checking and testing components and subsystems as
they went along, expecting everything to work perfectly after its all assembled.
Ideally, the builder would check the proper operation of components along
the way through the construction process: start and tune the engine before its
connected to the drivetrain, check for wiring problems before all the cover
panels are put in place, check the brake system in the driveway before taking it
out on the road, etc. Countless times I’ve witnessed students build a complex
experimental circuit and have trouble getting it to work because they didn’t
stop to check things along the way: test all resistors before plugging them into
place, make sure the power supply is regulating voltage
adequately before trying to power anything with it, etc. It is human nature to
rush to completion of a project, thinking that such checks are a waste of
valuable time. However, more time will be wasted in troubleshooting a
malfunctioning circuit than would be spent checking the operation of
subsystems throughout the process of construction. Take the example of the
analog summer circuit in the previous section for example: what if it wasn’t
working properly? How would you simplify it and test it in stages? Well, you
could reconnect the op-amp as a basic comparator and see if its responsive to
differential input voltages, and/or connect it as a voltage follower (buffer) and
see if it outputs the same analog voltage as what is input. If it doesn’t perform
these simple functions, it will never perform its function in the summer circuit!
By stripping away the complexity of the summer circuit, paring it down to an
(almost) bare op-amp, you can test that component’s functionality and then
build from there (add resistor feedback and check for voltage amplification,
then add input resistors and check for voltage summing), checking for
expected results along the way.
Trap a signal
Set up instrumentation (such as a datalogger, chart recorder, or multimeter set
on “record” mode) to monitor a signal over a period of time. This is especially
helpful when tracking down intermittent problems, which have a way of
showing up the moment you’ve turned your back and walked away. This may
be essential for proving what happens first in a fast-acting system. Many fast
systems (especially shutdown “trip” systems) have a “first out” monitoring
capability to provide this kind of data. Example #1: A turbine control system
shuts automatically in response to an abnormal condition. By the time a
technician arrives at the scene to survey the turbine’s condition, however,
everything is in a “down” state and its impossible to tell what signal or condition
was responsible for the initial shutdown, as all operating parameters are now
“abnormal.” What to do: One technician I knew used a videocamera to record
the turbine control panel, so he could see what happened (by indications on
the gauges) first in an automatic-shutdown event. Simply by looking at the
panel after the fact, there was no way to tell which signal shut the turbine
down, but the videotape playback would show what happened in sequence,
down to a frame-by-frame time resolution. Example #2: An alarm system is
falsely triggering, and you suspect it may be due to a specific wire connection
going bad. Unfortunately, the problem never manifests itself while you’re
watching it! What to do: Many modern digital multimeters are equipped with
“record” settings, whereby they can monitor a voltage, current, or resistance over
time and note whether that measurement deviates substantially from a regular
value. This is an invaluable tool for use in “intermittent” electronic system
failures.