When a customer appears at the parts counter with a "check engine" light problem, the scenario is supposed to go something like this: The counterperson goes out to the customer's car and attaches a basic trouble code retrieving tool to the diagnostic connector. Then he retrieves a diagnostic trouble code (DTC) from the vehicle's computerized on-board, self-diagnostic memory. To "make the light go out," the counterperson prescribes an oxygen sensor if the DTC happens to be an oxygen sensor code. If a throttle sensor DTC appears, he prescribes a new throttle sensor. And, to quote Jerry Seinfeld, "Yadda, yadda, yadda..."
But can it all be true? Yes and no, because Store A says it can sell more parts by providing a basic code reading service for customers who might have a "Check Engine" problem. The underlying theory is that $100 goes a lot farther in buying parts than buying expensive diagnostic services at the local auto repair shop.
Store B on the other hand, says that store A's inexperienced technical advice can lead to expensive diagnostic errors that will anger many more customers than it will please. For this reason, Store B would rather see the money spent on an accurate diagnosis done by a member of its independent dealer base.
So which side is right in this on-going debate? Let's start by looking at a few vehicles from my current diagnostic casebook. A 1988 Camaro parked in my service bay right now provides a straightforward example of how an average OBD I (up to model year 1995) trouble code diagnosis would work. The Camaro's computer or electronic control module (ECM) has stored a mass airflow (MAF) sensor code (DTC 33) and a rich fuel mixture code (DTC 45).
How does a computer store a DTC in its self-diagnostic memory? Starting with basics, the engine's ECM or computer is designed to recognize an electronic failure by measuring voltage signals transmitted from the ECM to an electronic sensor and back to the ECM.
A five-volt "reference" signal is sent from the ECM to the sensor. A change in electrical resistance caused by variations in temperature, pressure or mechanical position of a throttle sensor or switch will increase or decrease the voltage that returns from the sensor to the ECM. A throttle position sensor, for example, receives a five-volt signal at its connector and returns a voltage to the ECM that ranges from 0.5 volts at closed throttle to 4.5 volts at wide-open throttle.
Let's go back to how the DTC 33 would be stored in the Camaro's ECM. The ECM knows, for example, how much air should flow into a 2.8-liter engine at idle speed. It detects 0.5 volts coming from the closed throttle sensor at an engine speed of 750 rpm. At idle, the airflow sensor should be sending an electronic voltage frequency of 40 impulses per second (40 hertz) to the ECM. Instead of 40 hertz, the frequency sent to the Camaro's ECM is 168 hertz. The ECM's programmed calculations recognize that it's very unlikely that the throttle and engine speed sensors would fail simultaneously, so it decides the MAF frequency is incorrect and stores a DTC 33 in the ECM.
This process of comparing inputs from three or more sensors to detect a failure in one is called rationalization. Because rationalization depends very much on how correctly the computer is programmed, a defective throttle sensor or engine speed sensor could, in reality, set a false MAP sensor code. This would be caused by a mathematical error in the computer's software rather than a mechanical or electrical failure.
Now, let's go to the DTC 45 or "rich" code. In contrast to other sensors, the Camaro's zirconia oxygen sensor is unique because it creates its own voltage. The flow of hydrogen atoms from atmospheric oxygen, through the zirconia oxide coating inside the sensor, and into the exhaust gas stream coming from the engine's cylinders creates a very small electrical current that switches between 0.2 and 0.8 volts. If the ECM sees more than 0.5 volts coming from the O2 sensor for more than five minutes of operating time, it may store a "rich" code in the diagnostic memory.
In the case of the Camaro, the MAF was over-estimating the airflow into the engine, which caused the ECM diagnostic logic to store a DTC 45 "rich" code. So the DTC 45 isn't a problem in itself, but rather a symptom of an underlying problem, which is the excessively high-frequency signal from the MAF.
The fatal flaw is that most OBD I systems don't have enough computing capacity to recognize anything except open, shorted or grounded circuit failures. Sensor calibration failures caused by electrical degradation usually result in a "no-code" driveability complaint, which often eludes the diagnostic efforts of the amateur technician.
THE OBD II REVOLUTION
The OBD II systems introduced in 1996 were specifically designed to detect degraded sensors functioning at incorrect electrical values. Like OBD I, OBD II detects degradation by using rationalization to compare voltage inputs from three or more sensors. But OBD II compares these inputs during specific intervals and types of driving conditions, which makes the self-diagnostic process much more accurate. For this reason, most OBD II failures produce diagnostic trouble codes.
THE OBD II CASEBOOK
But the story doesn't end there because the self-diagnostic strategy in an OBD II vehicle follows a very exceedingly tortuous and complex path. To illustrate, let's look at a 1997 Dodge pickup truck that occasionally turns on the OBD II Malfunction Indicator Light (MIL) and stores a DTC P0107, which indicates a Manifold Absolute Pressure (MAP) sensor failure.
This should be a straightforward diagnosis, right? But, now, for the rest of the story: An experienced OBD II driveability technician will usually scan technical service bulletins (TSBs) and pattern failure files before, not after, making expensive parts purchases. The TSB file on Dodge trucks revealed, for example, that the DTC P0107 could be caused by an incorrect altitude calibration that would cause the MIL to illuminate when the vehicle coasts downhill at closed throttle during high-altitude operating conditions. To correct this false DTC, Dodge offers a recalibration or "re-flash" of the PCM itself. The technician checks the PCM for the applicable calibration tag and then continues with his diagnosis.
Clearly, a parking lot diagnosis wouldn't catch the root cause of this MIL problem because few counterpersons would have the time or expertise to research the problem before selling the part. A DTC diagnosis would likely result in the customer buying an expensive MAP sensor before the complaint is finally resolved.
To further illustrate false DTCs, I've encountered another interesting case on a Dodge Dakota with a DTC P1398. The DTC P1398 is a factory-specific code indicating a problem with the PCM's ability to "learn" the mechanical position of the crankshaft position sensor (CKP). In other words, a loosely mounted CKP sensor could create this particular DTC. But further research reveals that the P1398 can also be caused by an unrelated failure, like a defective cell in the engine's battery. The reduced voltage supply during cranking causes the PCM to "forget" the "learned" position of the crankshaft.
THEORY AND REALITY
Try as they may, factory engineers still haven't devised a foolproof on-board diagnostic system. Sure, the modern OBD II self-diagnostic system is far more accurate than the old OBD I system, but the in-field technician must take any DTC with a figurative grain of salt until he gathers enough data from testing and research to support installing a new part.
For the untrained counterperson, a parking lot diagnosis is a statistical crapshoot that can result in an unhappy customer. In some cases, a simple diagnostic trouble code can lead a talented DIYer to solve a code-related problem by replacing suspect parts. In other cases, well, that's where guys like me come in - with our lab scopes, scan tools, sensor simulators, wiring schematics, graphing volt-ohm meters, low-ampere current probes, technical hotlines, electronic databases, probability failure charts and - well, you get the idea.