Chevrolet OBD2 Trouble Codes: Your Guide to Understanding and Decoding

Are you experiencing issues with your Chevrolet and the check engine light is on? Understanding OBD2 trouble codes is the first step to diagnosing and resolving car problems. This guide provides a practical introduction to OBD2 (On-Board Diagnostics II) specifically for Chevrolet vehicles, helping you understand the codes, connector, and how to use them for effective vehicle maintenance.

This is your go-to resource for decoding Chevrolet OBD2 data, key logging applications, and practical tips to get you started. Let’s dive in and make deciphering those codes easier than ever.

You can also watch our OBD2 intro video above – or get the PDF

What is OBD2 and Why It Matters for Your Chevrolet?

OBD2 is essentially your Chevrolet’s built-in health monitoring system. It’s a standardized protocol that allows you to retrieve diagnostic trouble codes (DTCs) and access real-time vehicle data through the OBD2 connector. Think of it as your car’s way of communicating when something isn’t quite right.

You’ve likely already encountered OBD2 in action:

Ever seen the malfunction indicator light—commonly known as the check engine light—illuminate on your Chevrolet’s dashboard?

That’s your Chevrolet signaling a potential problem. When you take your vehicle to a mechanic, they use an OBD2 scanner to pinpoint the issue.

This process involves connecting an OBD2 reader to the OBD2 16-pin connector, usually located near the steering wheel. The scanner sends ‘OBD2 requests’ to your Chevrolet, and the car responds with ‘OBD2 responses’. These responses can include vital information like speed, fuel level, and, importantly, Diagnostic Trouble Codes (DTCs). This data significantly speeds up the troubleshooting process, getting you back on the road faster.

Will OBD2 Work on My Chevrolet?

The answer is almost certainly yes!

Nearly all modern gasoline and diesel Chevrolets are OBD2 compliant and operate on the CAN bus system. However, for older Chevrolet models, even if a 16-pin OBD2 connector is present, it might not fully support the OBD2 protocol. Compliance is often determined by the vehicle’s manufacturing date and original market.

To check your Chevrolet’s OBD2 compatibility, consider these guidelines based on where and when your car was initially purchased:

A Brief History of OBD2 and its Impact on Chevrolet

OBD2’s story begins in California, driven by the California Air Resources Board (CARB). In 1991, CARB mandated OBD for all new vehicles sold in California to monitor and control emissions. This initiative quickly evolved into the standardized OBD2 we know today.

The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBD2, defining DTCs and the universal OBD connector, documented under SAE J1962. This standardization ensured that diagnostic tools could be used across different vehicle manufacturers, including Chevrolet.

The OBD2 standard was progressively implemented across the automotive industry:

1996: OBD2 became mandatory in the USA for all cars and light trucks, including Chevrolet models sold in the US market.
2001: Required in the EU for gasoline cars.
2003: Required in the EU for diesel cars as well (EOBD).
2005: OBD2 was required in the US for medium-duty vehicles.
2008: US vehicles were mandated to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 became mandatory for heavy-duty vehicles in the US.

The Future of OBD2: What’s Next for Chevrolet Diagnostics?

OBD2 is here for the long haul, but it’s evolving. Here are some key trends shaping its future:

While legislated OBD2 was initially focused on emissions, electric vehicles (EVs) aren’t always required to support it. Interestingly, many modern EVs, including some electric Chevrolet models, don’t fully support standard OBD2 requests. Instead, they often use OEM-specific UDS communication. This can make accessing data from EVs challenging unless decoding methods are reverse-engineered. However, for traditional gasoline and diesel Chevrolets, OBD2 remains the primary diagnostic interface.

To address limitations in data richness and lower-layer protocols in traditional OBD2, newer standards like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These aim to improve OBD communication using the UDS protocol.

In our increasingly connected world, manual OBD2 checks seem outdated. The concept of OBD3 is gaining traction, envisioning telematics integrated into all vehicles.

OBD3 proposes adding a small radio transponder to cars, enabling wireless transmission of the vehicle identification number (VIN) and DTCs to a central server for automated checks.

Devices like the CANedge2 WiFi CAN logger and CANedge3 3G/4G CAN logger already facilitate data transfer via WiFi/cellular, paving the way for OBD3. While convenient and cost-saving, OBD3 raises privacy concerns.

Originally designed for emission checks, OBD2 is now widely used by third parties for real-time data access via OBD2 dongles and CAN loggers. However, the automotive industry is considering changes to limit third-party access:

“OBD has been designed to service cars in repair shops. In no way has it been intended to allow third parties to build a form of data-driven economy on the access through this interface”
– Christoph Grote, SVP Electronics, BMW (2017)

Proposals include disabling OBD2 functionality during driving and centralizing data collection with manufacturers. This could impact third-party OBD2 service providers and shift control towards manufacturers, raising questions about data access and the future of independent diagnostics.

Get Our ‘Ultimate CAN Guide’

Want to master CAN bus technology?

Download our comprehensive 160+ page PDF guide featuring 12 simple introductions:

Download now

Understanding OBD2 Standards for Chevrolet Vehicles

On-board diagnostics, or OBD2, is a higher-layer protocol—a language for vehicle communication. CAN bus is the communication method, like a phone line. OBD2 is similar to other CAN-based protocols like J1939, CANopen, and NMEA 2000.

OBD2 standards define the connector, lower-layer protocols, OBD2 parameter IDs (PIDs), and more. These standards are structured in a 7-layer OSI model. Importantly, standards are set by both SAE (primarily for the US market) and ISO (for the EU and international markets). Many standards are technically equivalent, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.

The OBD2 Connector: Accessing Your Chevrolet’s Data [SAE J1962]

The 16-pin OBD2 connector is your gateway to accessing vehicle data. Standardized under SAE J1962 / ISO 15031-3, it simplifies diagnostics.

The illustration shows a typical Type A OBD2 pin connector, also known as the Data Link Connector (DLC).

Key points about the OBD2 connector:

It’s generally located near your Chevrolet’s steering wheel, though it might be slightly hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout varies based on the communication protocol used.
CAN bus is the most common lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are usually active.

OBD2 Connector Types: A vs. B

You may encounter Type A and Type B OBD2 connectors. Type A is standard in cars like Chevrolets, while Type B is common in medium and heavy-duty vehicles.

While both types have similar pinouts, Type B provides a 24V power supply (Type A is 12V). Baud rates can also differ, with cars typically at 500K and heavy-duty vehicles often at 250K (though 500K support is increasing).

Type B connectors have a distinguishing interrupted groove in the middle. A Type B OBD2 adapter cable will fit both Type A and B sockets, but a Type A adapter will not fit a Type B socket.

OBD2 and CAN Bus: The Communication Backbone of Your Chevrolet [ISO 15765-4]

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in US vehicles, including Chevrolets, as per ISO 15765.

ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies how OBD2 operates on the CAN bus. It sets rules for the physical, data link, and network layers:

CAN bus bit-rate must be 250K or 500K.
CAN IDs can be 11-bit or 29-bit.
Specific CAN IDs are designated for OBD requests and responses.
Diagnostic CAN frame data length is fixed at 8 bytes.
OBD2 adapter cables must not exceed 5 meters in length.

OBD2 CAN Identifiers: 11-bit and 29-bit

OBD2 communication is based on request/response message pairs.

Most Chevrolets use 11-bit CAN IDs for OBD2. The ‘Functional Addressing’ ID 0x7DF is used to query all OBD2-compliant ECUs for data on a requested parameter (ISO 15765-4). ‘Physical Addressing’ requests to specific ECUs can be made using CAN IDs 0x7E0-0x7E7, though this is less common.

ECUs respond with 11-bit IDs in the range 0x7E8-0x7EF. The most frequent response ID is 0x7E8 (from the Engine Control Module, ECM), and to a lesser extent 0x7E9 (from the Transmission Control Module, TCM).

Some vehicles, like certain Chevrolet vans and trucks, may use 29-bit CAN identifiers for OBD2. Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1. Responses use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). This response ID is sometimes represented as the J1939 PGN 0xDA00 (55808), which is reserved for ISO 15765-2 in the J1939-71 standard.

OBD2 vs. Chevrolet Proprietary CAN Protocols

It’s crucial to understand that your Chevrolet’s ECUs don’t rely on OBD2 for their primary functions. Chevrolet, like other Original Equipment Manufacturers (OEMs), uses proprietary CAN protocols for core vehicle operations. These protocols are specific to the Chevrolet brand, model, and year. Generally, this OEM-specific CAN data is undecipherable without specialized knowledge or reverse engineering.

Connecting a CAN bus data logger to your Chevrolet’s OBD2 port might reveal OEM-specific CAN data, often broadcast at high rates (1000-2000 frames/second). However, newer Chevrolets may have a ‘gateway’ that blocks access to this data, limiting the OBD2 port to OBD2 communication only.

In essence, OBD2 is an additional higher-layer protocol running alongside Chevrolet’s proprietary protocol.

Bit-rate and ID Validation for Chevrolet OBD2

OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), creating four possible combinations. Modern Chevrolets commonly use 500K and 11-bit IDs. Diagnostic tools should systematically validate these settings.

ISO 15765-4 provides a sequence for auto-detecting the correct combination. This process leverages the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request. Incorrect bit-rate transmission will result in CAN error frames.

Newer ISO 15765-4 versions consider OBDonUDS alongside OBDonEDS. This article primarily discusses OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979) versus WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).

Tools can test for OBDonEDS vs. OBDonUDS by sending UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). OBDonUDS-compatible vehicles should respond to this DID.

OBDonEDS (aka OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars today, while WWH-OBD is mainly used in EU trucks and buses.

Five Lower-Layer OBD2 Protocols

While CAN is dominant for OBD2 today (ISO 15765), older Chevrolets (pre-2008) might use one of four other lower-layer protocols. Pinouts can help identify the protocol in older models.

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used today.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ cars, especially in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian cars in 2000-04.
SAE J1850 (VPW): Mostly in older GM vehicles.
SAE J1850 (PWM): Mostly in older Ford vehicles.

ISO-TP: Transporting OBD2 Messages [ISO 15765-2]

OBD2 data is transmitted over CAN bus using ISO-TP (ISO 15765-2), a transport protocol that allows for messages larger than 8 bytes. This is essential for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. For more details, refer to our UDS introduction.

However, many OBD2 data requests and responses fit within a single CAN frame. In these cases, ISO 15765-2 uses ‘Single Frame’ (SF) format. The first data byte (PCI field) indicates the payload length, leaving 7 bytes for OBD2 communication.

Decoding the OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]

To understand OBD2 on CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. Simplified, an OBD2 message includes an identifier, data length (PCI field), and data. The data section is structured into Mode, parameter ID (PID), and data bytes.

OBD2 Request/Response Example

Consider this example for requesting and receiving ‘Vehicle Speed’:

An external tool sends a request to the Chevrolet with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds with CAN ID 0x7E8 and 3 payload bytes, including the speed value in the 4th byte, 0x32 (decimal 50).

Using OBD2 PID 0x0D decoding rules, we find that 0x32 corresponds to 50 km/h.

Next, we’ll explore OBD2 modes and PIDs in detail.

The 10 OBD2 Services (Modes)

There are 10 standardized OBD2 diagnostic services, also known as modes. Mode 0x01 provides real-time data, while others are used for Diagnostic Trouble Codes (DTCs), freeze frame data, and more.

Vehicles aren’t required to support all OBD2 modes, and they may also implement OEM-specific modes beyond these 10.

In OBD2 messages, the mode is the 2nd byte. In requests, the mode is directly included (e.g., 0x01). In responses, 0x40 is added to the mode value (e.g., 0x41 for a response to mode 0x01).

OBD2 Parameter IDs (PIDs)

Each OBD2 mode contains Parameter IDs (PIDs).

For instance, mode 0x01 includes approximately 200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, a vehicle may not support all PIDs within a mode; most support only a subset.

One PID stands out:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the ECU indicates support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental test for OBD2 compatibility. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to check support for subsequent PID ranges within mode 0x01.

Tip: OBD2 PID Overview Tool

SAE J1979 and ISO 15031-5 appendices detail scaling information for standard OBD2 PIDs, enabling conversion of raw data to physical values.

Our OBD2 PID overview tool is useful for looking up mode 0x01 PIDs. It helps construct OBD2 request frames and dynamically decode responses.

OBD2 PID overview tool

How to Log and Decode Chevrolet OBD2 Data

This section provides a practical guide to logging OBD2 data from your Chevrolet using the CANedge CAN bus data logger.

The CANedge allows custom CAN frame transmission, making it ideal for OBD2 logging.

Connect the CANedge to your Chevrolet using our OBD2-DB9 adapter cable to begin.

Test CAN frame transmission at 500K to verify successful communication.

Review ‘Supported PIDs’ responses using asammdf.

#1: Verify Bit-rate, IDs, and Supported PIDs

ISO 15765-4 outlines how to determine the correct bit-rate and IDs for a specific vehicle. Use the CANedge to perform these tests:

Send a CAN frame at 500K; if successful, proceed. If not, try 250K.
Use the verified bit-rate for all subsequent communication.
Send multiple ‘Supported PIDs’ requests and analyze the responses.
Determine 11-bit or 29-bit IDs based on response IDs.
Identify supported PIDs based on response data.

We provide plug-and-play configurations for these tests.

Most post-2008 non-EV vehicles, including Chevrolets, support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common when using the 0x7DF request ID, which polls all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, many responses to this PID are typical. Fewer ECUs respond to subsequent ‘Supported PIDs’ requests. The ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, potentially reducing bus load by directing requests specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

#2: Configure OBD2 PID Requests

Once you know your Chevrolet’s supported OBD2 PIDs, bit-rate, and CAN IDs, configure your transmit list with the PIDs you want to log.

Consider these factors:

CAN IDs: Use ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses per request.
Spacing: Add 300-500 ms intervals between OBD2 requests to prevent ECU overload.
Battery Drain: Implement triggers to stop transmission when the vehicle is off to prevent battery drain.
Filters: Filter to record only OBD2 responses if OEM-specific CAN data is also present.

With these configurations, your device is ready to log raw OBD2 data.

Example CANedge OBD2 PID request list.

asammdf allows DBC decoding and visualization of OBD2 data.

#3: DBC Decode Raw OBD2 Data

To analyze and visualize logged data, decode the raw OBD2 data into physical values.

Decoding information is in ISO 15031-5/SAE J1979 and online resources like Wikipedia. Use our free OBD2 DBC file to simplify DBC decoding in CAN bus software tools.

Decoding OBD2 data is more complex than standard CAN signals because different OBD2 PIDs use the same CAN ID (e.g., 0x7E8). The CAN ID alone isn’t enough to identify the payload signals.

You must use the CAN ID, OBD2 mode, and OBD2 PID to identify signals—a form of multiplexing called extended multiplexing. This can be managed using DBC files.

CANedge: Your OBD2 Data Logger

The CANedge simplifies OBD2 data recording to an 8-32 GB SD card. Connect it to your Chevrolet to start logging and decode data using free software/APIs and our OBD2 DBC file.

OBD2 logger intro

CANedge

OBD2 Multi-Frame Examples [ISO-TP]

OBD2 data communication uses ISO-TP (ISO 15765-2). While many examples are single-frame, multi-frame communication is used for larger data sets.

Multi-frame OBD2 requires flow control frames. A static flow control frame transmitted ~50 ms after the initial request works effectively with CANedge.

Multi-frame OBD2 responses need CAN software/API tools supporting ISO-TP, like CANedge MF4 decoders.

Example 1: Retrieving the Chevrolet Vehicle Identification Number (VIN) via OBD2

The Vehicle Identification Number (VIN) is vital for telematics and diagnostics. Retrieve your Chevrolet’s VIN using OBD2 mode 0x09 and PID 0x02:

The tool sends a Single Frame request with PCI field (0x02), service ID (0x09), and PID (0x02).

The vehicle responds with a First Frame containing PCI, length (0x014 = 20 bytes), mode (0x49), and PID (0x02). Byte 0x01 after the PID is the Number Of Data Items (NODI), which is 1 in this case. The subsequent 17 bytes are the VIN, which can be converted from HEX to ASCII.

Example 2: OBD2 Multi-PID Request (6x PIDs)

External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU responds with data for supported PIDs, using multi-frame responses via ISO-TP if needed.

This method enhances data collection efficiency but complicates signal encoding, making generic OBD2 DBC files less useful. It’s generally not recommended for practical use. Here’s an example trace:

The multi-frame response is similar to the VIN example, but includes requested PIDs and their data. PIDs are often ordered as requested.

Decoding this response with DBC files is challenging. This approach is not recommended for data logging unless your tool specifically supports it. It involves extended multiplexing with payload position dependencies, making DBC generalization across vehicles difficult. Handling multiple multi-PID requests via DBC becomes nearly impossible.

Workarounds might involve custom scripts and recording transmit messages to interpret responses based on requests. However, these methods are hard to scale.

Example 3: Chevrolet OBD2 Diagnostic Trouble Codes (DTCs)

Use OBD2 mode 0x03 (‘Show stored Diagnostic Trouble Codes’) to request emissions-related DTCs. No PID is needed in the request. ECUs respond with the number of stored DTCs (possibly zero) and DTC data, with each DTC using 2 bytes. Multi-frame responses are necessary if more than 2 DTCs are stored.

The 2-byte DTC value is categorized and includes a 4-digit code (hexadecimal), as per ISO 15031-5/ISO 15031-6. Decode DTCs using OBD2 DTC lookup tools like repairpal.com.

The example below shows a request to an ECU with 6 stored DTCs.

OBD2 Data Logging Use Cases for Chevrolet Vehicles

OBD2 data from Chevrolets and light trucks has numerous applications:

Logging Data from Chevrolet Cars

Use OBD2 data to reduce fuel costs, improve driving habits, test prototype parts, and optimize insurance premiums.

obd2 logger

Real-time Chevrolet Diagnostics

Stream human-readable OBD2 data in real-time for diagnosing vehicle issues and performance monitoring.

obd2 streaming

Predictive Maintenance for Chevrolet Fleets

Monitor Chevrolet cars and trucks via IoT OBD2 loggers to predict and prevent breakdowns, reducing downtime and maintenance costs.

predictive maintenance

Chevrolet Vehicle Black Box Logger

Use an OBD2 logger as a ‘black box’ for Chevrolet vehicles, providing crucial data for incident analysis, warranty claims, and diagnostics.

can bus blackbox

Do you have an OBD2 data logging use case? Contact us for expert advice!

Explore our guides section for more introductions or download our ‘Ultimate Guide’ PDF.

Need to log or stream OBD2 data from your Chevrolet?

Get your OBD2 data logger today!

Buy now

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[