OUTSMARTING TODAY'S SMART CARS
When computerized engine controls were introduced, it ushered
in the era of the "smart" car. The engineers who designed these
vehicles realized that some type of self-diagnostic capability
would be necessary to troubleshoot all the electronics. With
fuel management, spark timing, emissions control and other powertrain functions interwoven electronically, pinpointing
faults is nearly impossible without some type of help. Thus
onboard diagnostics was born, and with it a whole new way to
outsmart today's smart cars.
The basic idea behind onboard self-diagnostics is fairly
simple. The vehicle's computer (or computers in applications
where there are separate control modules for the transmission,
antilock brake system, climate control system, etc.) monitors the
constant flow of inputs from its various sensors. These inputs
are necessary to carry out the computer's control functions, so
the computer makes sure that (1) it is receiving data from its
various inputs, (2) that the data it does receive is within
acceptable norms or limits, (3) that the data received from any
given sensor agrees with that from other sensors where a direct
relationship exists, and (4) that its commands are being carried
out via various feedback mechanisms.
As long as there as everything works as intended, the smart
car runs great. But when a fault arises such as loss of input
from a vital sensor, input data that doesn't make sense (out of
range or doesn't match inputs from other sensors), or loss of a
return signal from an actuator, it triggers the self-diagnostics
What happens next depends on the nature of the problem, the
diagnostic capabilities of the system, the smart system that's
involved (powertrain control module, ABS module, body control
module, air bag system, or climate control system) and the
vehicle application. In most cases where input from a key sensor
circuit is lost or out of range, the computer generates and/or
stores a fault code.
If a fault is within the engine or electronic transmission
control system, the powertrain control module (PCM) will
illuminates the "Malfunction Indicator Lamp" or MIL (which is the
new "generic" term for the Check Engine or Power Loss warning
light). If the sensor's input is essential for continued engine
operation, the computer may go into a "limp-in" or "fail-safe"
mode where artificial data is substituted for the missing sensor
data to keep the engine running. The engine may not run properly
but it will at least run.
For example, say the computer loses the signal from the
throttle position sensor (TPS) or manifold absolute pressure
(MAP) sensor. Without this data, the computer has no way of
knowing if the engine is under load or not (a condition which
typically requires a somewhat richer fuel mixture and changes in
spark timing). So to compensate, the computer may substitute
bogus data until the problem can be fixed. The engine, meanwhile,
may hesitate under sudden acceleration or lack power under load
but it will continue to run.
Loss of input from either the coolant sensor or oxygen sensor
will cause most systems to revert to an open loop mode of
operation. In open loop, the fuel mixture will be fixed
(unchanging) and will be richer than normal, causing an increase
in emissions and reduced fuel economy. As before, the engine
will continue to run but won't perform as well as it should.
If the distributor reference signal or crankshaft sensor
signal is lost, however, there's no way for the system to
substitute data for the missing information. The distributor
reference signal or crankshaft sensor signal (on engines with
distributorless ignition systems) are absolutely essential for
switching the ignition coil on and off (ignition firing), and
injector pulsing on most applications with multiport fuel
injection. Without the key rpm signal, the engine won't start or
Sometimes a fault occurs when the data from a particular
sensor is outside the normal range of values or it doesn't change
or react appropriately in response to other changes that are
occurring. The oxygen sensor, for example, should normally
produce a signal that fluctuates between 0.1 and 0.9 volts. If
the computer suddenly sees a signal outside this range, it will
interpret it as a fault. Likewise, if the oxygen sensor signal
fails to change and remains fixed at a constant high or low
voltage when the engine is at normal operating temperature (low
"cross counts"), the computer will set a code.
The exact conditions under which a fault code might be set
are spelled out in many shop manuals. Referring to this
information may help you better understand why a particular code
might have been set and what might have caused it.
That's the essence of how self-diagnostics works. There's no
magic or hocus pocus involved. The computer simply monitors the
incoming data, compares the data to a list of "acceptable" values
and conditions under which the data is supposed to change, and if
things don't match up it logs a fault code or fault message that
corresponds to the problem.
Some fault codes are "hard" codes, meaning the computer
stores a numeric code in its memory that corresponds to the
problem. Most hard codes will cause the MIL or other warning
lamp to come on and remain on, but some types of problems may
only cause the lamp to come on while the problem is actually
occurring. It depends on the application and how the
self-diagnostics of the system are programmed. In instances where
there is an intermittent problem and the lamp goes out, a code
will remain in memory for later retrieval. But on many
applications, the code will be erased if the problem doesn't
reoccur within 50 ignition cycles. On others, though, the code
will remain in the computer's memory indefinitely until it is
erased with a scan tool or by disconnecting the computer's power
supply (which doesn't work if the computer has a nonvolatile
Fault codes or messages can be read by putting the vehicle's
computer into a special diagnostic mode. The exact procedure
varies from application to application, but as a rule it involves
grounding or jumping terminals on the system's diagnostic
connector, hooking up a scan tool, analyzer or analog voltmeter
to the diagnostic connector, or on certain Buick and Corvette
applications pressing certain buttons on the vehicle's automatic
climate control panel or driver information center to read out
codes. On many import applications, codes are displayed by
colored LED lights on the control module itself. Always refer to
a shop manual if you're not familiar with the exact procedure
that's required for the vehicle you're servicing.
Once the system is in the diagnostic mode, stored codes can
be retrieved, various tests can be performed (including dynamic
tests and actuator tests depending on the application), and live
sensor data can be read provided the system provides serial data
information and you have the proper scan tool.
Stored codes are usually displayed in numeric sequence. On
many vehicles, the fault codes are proceeded by an "indicator"
code that tells you to get ready because the system is going to
read out any fault codes that are present or stored in memory.
The fault codes may then be followed by a second indicator code
that tells you "end of message." The codes may then repeat for a
fixed number of times or continuously depending on the
On vehicles that provide "manual" code retrieval, the check
engine, power loss or malfunction indicator warning light on the
instrument panel may be used to display "flash" codes. With this
method, the light blinks on and off in a series of flashes when
the system is in the diagnostic mode. You decipher the code by
counting flashes. But to interpret what the numbers mean, you
have to refer to a service manual.
On older Fords, early Toyota Cressidas and Supras, an analog
voltmeter can be used to manually read codes. When the
voltmeter's leads are connected to certain terminals on the
diagnostic connector and the system is put into the diagnostic
mode, the needle on the voltmeter jumps as the codes feed out.
By counting the sweeps of the meter needle, you read the codes.
READING CODES & LIVE DATA
Reading numbers on a digital display on a scan tool or
analyzer is much easier than trying to count flashes of light or
sweeps of a voltmeter needle. You're less apt to make a mistake,
and you're usually able to extract more useful information from
On vehicles that provide live serial data through the
diagnostic connector (most GM, newer Ford & Chrysler, all Lexus,
Geo Metro & Spectrum, most Mazda, Mitsubishi, Hyundai and
Chrysler imports, and some Isuzu, Nissan, Subaru, Suzuki &
Toyota), a scan tool lets you peer into the inner workings of the
system. In addition to retrieving fault codes, you can read
various live sensor inputs to determine whether or not a sensor
is responding correctly in a given situation. Some applications
(Chrysler, for example) also allow you to perform various
actuator tests to see if the injectors, canister purge solenoid
and other relays are responding to computer commands.
Most older import applications as well as older Fords and
Chryslers, however, do not provide live serial data through the
diagnostic connector. Even so, there are aftermarket scan tools
and analyzers available that can be plugged directly into the
computer's harness to tap the flow of data within the system.
UNDERSTANDING FAULT CODES
The most important thing to remember about fault codes is
that codes by themselves are NOT the final diagnosis. They are
only a starting point to begin further diagnosis. In other
words, codes only tell you where to start, not what to replace.
When you find a fault code using either a manual retrieval
procedure or electronically with a scan tool or analyzer,
therefore, do not replace anything until you've done further
testing to determine what's actually causing the problem. The
only thing the code tells you is that something abnormal has
occurred in a particular circuit. So until you do additional
testing, there's no way to know for sure which component is bad.
To isolate a fault you must usually proceed through a
detailed step-by-step diagnostic procedure using a digital
multimeter and a service manual as your guide. Some diagnostic
charts can be quite lengthy and involved, but all of the steps
are usually necessary to rule out all other possibilities and
arrive at the correct conclusion. Skipping steps to save time or
failing to perform the required tests correctly won't help you
nail down the problem. If anything, shortcuts will lead you
astray and you'll end up replacing the wrong part -- which puts
you right back where you started because you failed to fix the
Isolating faults is usually the most time-consuming part of
the job. Is it the sensor, a bad wiring connector, a wiring open
or short, or a problem within the computer itself? You have no
way of knowing until you start performing the various tests. By
a process of elimination, you should be able to narrow down the
list of possibilities until you arrive at some sort of
conclusion. This is supposed to eliminate much of the guesswork
and trial-and-error diagnosis that runs up unnecessary repair
bills -- in theory, that is. The catch is fault codes don't
always reveal the true nature of a problem. And there are all
kinds of problems that are beyond the detection capabilities of
most onboard self-diagnostic systems (problems in the secondary
side of the ignition system or mechanical problems, for example,
like loss of compression or a bad timing chain).
SEEING SENSOR PROBLEMS
One of the best tools for outsmarting today's smart cars is
an oscilloscope or a scan tool with scope capabilities.
Sometimes you'll encounter a problem but won't find a fault code.
Intermittent problems can sometimes happen in such a way that the
glitch fails to set a code. So for situations like these, it
helps if you can display sensor outputs directly as traces on a
screen. You can then "see" what's going on and compare known
good traces to the sensor in question.
Displaying several related sensor traces simultaneously is a
fast way to detect problems that would be difficult if not
impossible to detect reading digital information alone. For
example, finding a momentary glitch in a throttle position
sensor, or a damaged sensor ring for a wheel speed sensor. The
more sophisticated scopes will even do a complete "sweep" of the
system and red flag any sensors that are out of their normal
ranges. But a red flag doesn't always indicate there's a problem
with a sensor. A sensor may be giving a "borderline" reading
that's a little too high or too low compared to the norm, yet
cause no noticeable emissions or driveability problem. In such
cases you have to use a certain amount of judgment to decide
whether or not an "apparent" problem is in fact a real problem
that requires further investigation.
USING A SENSOR SIMULATOR
Another useful tool that can speed up the diagnostic process
whether or not you have a fault code is a "sensor simulator" tool
or an analyzer with this kind of software capability. . A sensor
simulator can simulate various voltage, frequency and resistance
inputs to help you determine if a problem is in a sensor, the
sensor's wiring circuit or the control module. If substituting a
simulated signal for the real thing either at the sensor
connector or through a breakout box solves the problem, it tells
you the wiring and module are okay and that the problem is in the
sensor. If there's no change in performance or operation with a
simulated signal, on the other hand, it tells you the signal is
not getting through to the computer (a wiring problem requiring
further continuity checks) or that the signal is not being
processed correctly (a bad control module).
For example, let's say an engine is running rich, the "Check
Engine" light is on and there's a fault code for the O2 sensor.
Is the O2 sensor bad or is it something else? To find out,
disconnect the O2 sensor, set the sensor simulator to produce an
O2 sensor signal (which you can vary from a fixed lean reading to
a rich signal), connect the test leads to the O2 sensor's wiring
connector, start the engine and see what happens. If there's no
change in the fuel mixture when you switch the input signal back
and forth from lean to rich, the problem isn't a bad O2 sensor.
It's in the wiring or PCM.
A sensor simulator can also be used to alter the operation of
a computerized engine control system when performing other
diagnostic tests. By simulating a hot or cold input signal from
the coolant sensor, you can change the operation of the computer
from closed loop to open loop. This type of substitution may be
helpful when performing a power balance test on some vehicles.
Running in open loop prevents the computer from changing the idle
speed when cylinders are deactivated.
Some other uses of this type of diagnostic tool include:
* Simulating a throttle position (TPS) sensor signal to vary the
idle fuel mixture (changes the duration of the injector pulses).
* Simulating a barometric pressure sensor or MAP sensor signal
to switch the fuel mixture and timing between "high altitude" and
* Simulating a manifold absolute pressure (MAP) sensor signal to
check for changes in ignition timing and fuel enrichment.
* Simulating a mass airflow (MAF) sensor signal to monitor
changes in fuel enrichment.
FAULT OR NO FAULT?
Great as onboard self-diagnostics are, sometimes they're not
much help. An intermittent warning light is one such problem
that can drive you nuts. With some onboard self-diagnostic
programs, certain intermittent faults cause the warning light to
come on only when the problem is occurring. The rest of the
time, the light remains off. That doesn't mean the smart car has
fixed itself. The problem is still there -- so check for codes
even if there's no light.
Sometimes you'll find an intermittent warning light but no
code. Is there a problem or isn't there? One way to find out is
to test drive the vehicle with a portable "flight recorder"
device attached to the onboard electronics. The recorder
captures the live data stream information so a "snap shot" of the
data can be recorded when the problem occurs. By analyzing the
data later, you may then be able to determine if indeed there's a
problem. But this technique only works on vehicles that provide
access to the data stream. And it only works if somebody presses
the record button to capture a window of data when the problem
occurs. One of the limitations of flight recorders is that they
don't read data continuously but rather take samples of data
every little bit. If a momentary glitch occurs between data
samples, the recorder may not catch it. That's why some
technicians prefer to display and watch live sensor data on a
scope so they can see intermittent problems that don't show up
well on most scan tools or flight recorders.
Intermittent faults are the worst to nail down because the
pass/fail tests that are part of most diagnostic procedures may
not catch an intermittent problem if the problem isn't acting up
when a particular test is performed. Consequently, you continue
along the wrong path and end up making the wrong diagnosis and
replacing the wrong part. Or you reach the end of the diagnostic
tree (and your rope) only to find yourself no closer to solving
the problem than when you started. Everything apparently checks
out okay but the problem is still there. Now what?
The only way to find an intermittent fault is to try to
duplicate the operating conditions that are present when the
fault occurs. Heat, cold, vibration and moisture are four
variables that may play a role in causing an intermittent fault.
Anything that causes a momentary short or open in a circuit will
cause a change in the circuit's voltage. A loose wiring
connector that breaks contact momentarily when it gets hot, wet
or vibrates is a classic cause of many intermittent faults.
Test driving a vehicle until the fault appears is one way to
get an intermittent fault to repeat. But test driving can eat up
a lot of time. And there's no guarantee the fault will reoccur.
Nor is there any guarantee that a flight recorder will catch it
either. A better approach might be to try duplicating in the
service bay what happens during a test drive. Start the engine
and allow it to reach normal operating temperature. With a scan
tool or computerized analyzer connected to the vehicle, see if
you can create a momentary glitch by wiggling, blowing hot air,
spraying water, etc. on the suspected wiring connectors or
components. Sometimes this approach works and sometimes it
"False" codes are another glitch that can sometimes create
ghosts in a smart car. A voltage spike or transient electrical
surge may trigger a code for a problem that doesn't exist. An
arcing plug wire, an open diode, electromagnetic interference
from a spark plug wire that's routed too near a sensor circuit,
etc., may all be potential causes of false codes.
On older GM C3 systems, for example, arcing between the
ignition coil and ground or at the spark plug wires can sometimes
cause an intermittent Check Engine light but no trouble code. So
can an open diode across the air conditioner compressor clutch,
intermittent shorts or grounds in the wiring harness (grounding
terminals A and U or applying battery voltage to terminals C and
False codes can also be triggered while performing certain
test procedures or making repairs. Sometimes you'll find old
codes that have been left in memory from a previous problem that
has since been repaired (a good reason for always erasing codes
after repairs have been completed).
The only way to be really sure whether or not there is a real
problem is to
(1) read and record all stored codes, then
erase them with a scan tool or by removing the module's fuse, and
(3) test drive the vehicle or run a self-test (Ford) to see if
the same code or codes reappear.
Don't disconnect the battery to
erase stored codes because you'll also erase all the settings in
the electronic radio and climate control system. Also do not
disconnect anything electrical when the key is on or while the
motor is running. Doing so may create a voltage spike that could
damage sensitive electronic components.
For some kinds of false code problems, a manufacturer may
issue a Technical Service Bulletin (TSB) describing the nature of
the problem and how to fix it. In some cases the cure may
involve rerouting wiring or replacing a component with a new or
revised part. So the only way to outsmart these kinds of
problems is to have access to the factory TSBs, which you can get
from All-Data, Chilton or Mitchell.