When the original On-Board Diagnostic (OBD) system was being designed, the groups responsible could not possibly have predicted the future changes to automotive technology, involving today’s extensive computerized engine components, body, chassis, entertainment, comfort and emission controls.
The On-Board Diagnostic system that we take for granted now, was being developed back in the late 60s. The system was rudimentary, and there was no standardization back then, but slowly over time, OBD was regulated and standardized. California’s air pollution concerns were a huge driver in this standardization, and in 1991, OBD1 was born. OBD has morphed several times since, and the OBD-II format we use today became mandatory for all vehicles manufactured in the USA in 1996.
OBD-ll created the standardized Diagnostic Trouble Codes (DTC) that we are familiar with. It prescribed the dimension of the familiar 16-pin diagnostic connector and its circuit types, circuit location and signal protocols. OBD-ll even forced the implementation of Controller Area Network or CAN on all US manufactured vehicles in 2008.
The average vehicle today has a vast number of systems, sub-systems, controls, components, and features that may eventually fail and need to be diagnosed. Hooking up a scan tool and retrieving the Diagnostic Troubles Codes is typically the first diagnostic step that many techs perform.
But what exactly is a DTC that we retrieve?
The simple answer is that a DTC is the result of a failed test. Most of the control modules on a vehicle today will monitor and test many things from the circuits attached to it, the inputs that report to it and outputs and devices that it is responsible for.
This monitoring/testing of devices, systems and circuits allows the module to verify the integrity of those devices, systems and circuits to maintain their proper desired operation.
These tests that the module performs can include but are not limited to testing specific circuits for opens or high resistance, short to voltage, short to ground or signal performance. The list of tests a module can perform is long, and these are just a few examples.
If the results of a test performed by the module detect an abnormality, it may set a DTC or it may wait and perform more testing before setting a DTC. What the module does after it sees the failed test will vary with the manufacturer and the system that the DTC or failed test is being set in.
The original OBD-II DTC design designated that each DTC would consist of a string of five characters, and all generic DTCs are defined by the standards set out by OBD-II and European On-Board Diagnostics (EOBD-ll) regulations.
The regulations for a DTC code string are as follows:
Each DTC code will contain one letter, displayed as the first character of the DTC to indicate which of the four main vehicle diagnostic areas the failure is occurring in. These letters are:
P – Powertrain (engine and transmission)
B – Body (includes air conditioning and airbag)
C – Chassis (includes ABS)
U – Network Communication (wiring bus)
The second character in the sequence indicates if the DTC is generic or manufacturer specific. Note: This second character will have different meanings for each of the four main diagnostic areas.
The third character in the sequence can be a number or a letter, but if the DTC concerns the engine, transmission or hybrid controls and starts the DTC sequence with a “P,” the third character will point to the area of concern that is causing the fault, but this only applies to “P” codes.
1 – Fuel and Air Metering
2 – Fuel and Air Injector Circuit
3 – Ignition or Misfire
4 – Auxiliary Emission Controls
5 – Vehicle Speed and Idle Controls
6 – Computer and Output Controls
7 – Transmission
8 – Transmission
9 – SAE Reserved
0 – SAE Reserved
A, B or C – Hybrid Propulsion
The fourth and fifth characters in the DTC code sequence will represent the specific description of the failed component or system. These characters are numbered numerically and are shown as “00,” “01,” etc.
As an example, a code P0131 is a HO2S Circuit Low Voltage Bank 1 Sensor 1 for a 2015 3.6 V6 GM engine in a Chevrolet Impala.
We can see by the characters in the DTC sequence that the first character is a “P” for powertrain code. The second character is a “0” signifying a generic code. The third character is a “1” showing the system involved is the fuel and air injector circuit.
The fourth and fifth characters “31” show that the issue involves HO2S located on bank 1 in the sensor 1 position. The DTC describes the issue and the test that the HO2S has failed: The sensor circuit has low voltage.
When using this OBD-II specific DTC character sequence, there are more than 5,000 DTCs (both generic and manufacturer-specific) that can be used to indicate a failure in one of the four vehicle diagnostic areas.
But manufacturers have realized that this constrained amount of diagnostic DTCs means diagnostic restrictions and may limit the ability to fully diagnose the numerous systems that are on most of the vehicles being built today.
GM has started to use an enhanced method to aid in diagnostics by using a symptom “byte.” The symptom byte is a sequence of two hexadecimal numbers at the end of the DTC. Currently, the symptom byte is being used heavily in the body, chassis, and communication group of DTC codes. But they are often shown when scanning for powertrain codes, especially when they are non-generic and manufacturer specific.
These two extra characters provide more information to the technician and the engineers that developed the systems at the factory. But the extra information that these two characters provide is not the only reason GM started to do this: It cuts the cost of developing huge diagnostic trouble trees, increases the number of DTCs that are available and reduces the number of unique DTCs needed.
Like other manufacturers, GM uses a DTC to determine the failure or issue of a component, wiring, signal or system. And using the enhanced information that a symptom byte provides, helps narrow down the type of fault. It also will start to allow remote diagnostics or over-the-air diagnostics in the future.
When using the enhanced symptom byte, a code C028A:02 Park Brake Motor Circuit is retrieved on a 2015 Impala.
We can see that we are looking at “C” chassis code that is “0” generic, but there is no other information provided by the code description. The code just tells us Park Brake Motor Circuit.
But the two extra digits (symptom byte) after the five-character code further explain the issue with the park brake motor circuit. In this case, the “02” signifies a short-to-ground issue.
GM uses nine symptom bytes categories and fault designations.
GM’s service information (SI) contains a symptom byte list.
But it can also be found at most of our diagnostic information services such as Motor/Alldata and Mitchell. Using the search bar for symptom byte list when diagnosing a GM vehicle, the symptom byte list will describe and define what each symptom byte means and a definition.
The nine categories are:
(00-0F) General Electrical Failures
(10-1F) Additional General Electrical Failures
(20-2F) Frequency Modulation and Pulse Width Modulation Failures
(30-3F) Electronic Control Unit Internal Failures
(40-4F) Electronic Control Unit Programming Failures
(50-5F) Algorithm-Based Failures
(60-6F) Mechanical Failures
(70-7F) Bus Signal or Message Failures
The characters in the brackets before the description show the range of characters that are used in each category. Many techs will already be familiar with seeing these numbers and letters after the familiar five-character DTC is displayed and may have wondered what they mean.
As an example, symptom byte 02 has the description of “short to ground,” and its definition is “This subtype is used for failures where the Electronic Control Unit measures ground (battery negative) potential for greater than a specified time period or when some other value is expected.”
The Parking Brake Control Module (PBCM) on the 2015 Impala has an internal park brake motor and circuit. To verify the proper operation of the internal park brake motor, the PBCM will test this circuit and if the PBCM detects a short to ground on this circuit during the test, the test will fail and the code C028A:02 will set. This failed test will also disable the parking brake and a message and/or a warning indicator may be displayed.
Here is another example of a symptom byte code and how it enhances the diagnostics of a generic DTC. A code B0955 is a generic body code for the Parking Assist Front Sensor Left Middle Circuit on a 2016 GMC Sierra pickup.
GM wants to use the code B0955 to represent all the failures that the Parking Assist Front Sensor Left Middle Circuit can have. They are doing this to simplify the diagnostics and limit the number of DTCs on this vehicle. This can be accomplished by using the symptom byte.
If the code B0955:04 is retrieved, we can see from the code format that it’s a body code, it’s generic and for the parking assist front sensor left middle circuit. But now the symptom byte is telling us that the circuit is open or has high resistance. We now have a simplified diagnostic starting point and will look at the parking assist front sensor left middle circuit trying to diagnose how and why the circuit is open or has high resistance.
By using the symptom byte, GM uses the same B0955 five-character code to represent five different codes.
OBD-ll trouble codes and their format were established to help aid the technician in repairing a failed system. This has worked, but it has limitations.
GM wanted to expand the available diagnostic code base without using a dedicated code for every failure, and the symptom byte allows this.
Many manufacturers are using some form of enhanced DTCs, and some are using a form of symptom byte to expand the diagnostic capabilities.
GM has been very forthcoming in sharing the description of their symptom bytes, but it is very difficult to find any information from other manufacturers.