OBD2 Protocol PDF: Your Comprehensive Guide to On-Board Diagnostics

Looking for a straightforward and practical understanding of the OBD2 protocol?

You’ve come to the right place. This guide provides an in-depth introduction to the On-Board Diagnostics (OBD2) protocol, covering everything from the OBD2 connector and OBD2 parameter IDs (PIDs) to its crucial link with the CAN bus system.

This isn’t just a theoretical overview; it’s a hands-on introduction designed to equip you with the knowledge to request and decode OBD2 data effectively. We’ll explore key logging applications and share practical tips to get you started.

Discover why this article is becoming recognized as a leading resource for understanding OBD2. And for those who prefer offline access, while this article provides comprehensive information, keep an eye out for potential resources to further enhance your learning journey, perhaps even in a downloadable Obd2 Protocol Pdf format in the future.

What Exactly is OBD2?

OBD2, or On-Board Diagnostics version 2, is essentially your vehicle’s internal health monitoring system. It’s a standardized protocol that has revolutionized automotive diagnostics, allowing mechanics and enthusiasts alike to access a wealth of information about a vehicle’s performance and health. Through the OBD2 connector, you can retrieve diagnostic trouble codes (DTCs) and access real-time data, making troubleshooting and vehicle monitoring more efficient than ever before.

Chances are, you’ve already indirectly interacted with OBD2. Ever seen the check engine light illuminate on your dashboard? That’s your car signaling an issue, and OBD2 is the system that stores and communicates these problems. When you take your car to a mechanic, they use an OBD2 scanner to understand what’s wrong.

The process is simple yet powerful. The mechanic connects the OBD2 reader to the 16-pin OBD2 connector, typically located near the steering wheel. This tool sends ‘OBD2 requests’ to the car’s computer, and the car responds with ‘OBD2 responses’. These responses can include vital data such as speed, fuel level, and those all-important Diagnostic Trouble Codes (DTCs). This streamlined communication makes diagnosing car problems faster and more accurate.

Is My Vehicle OBD2 Compatible?

The simple answer: Almost certainly, yes!

For most modern, non-electric vehicles, OBD2 support is standard, and many operate on the CAN bus network. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t guarantee full OBD2 compliance. As scantool.net explains, just having the connector isn’t enough. A key indicator of compliance is the vehicle’s purchase location and year:

This image, titled “OBD2 Compliance by Region and Year,” shows a table indicating OBD2 compliance requirements based on region (EU, US) and vehicle type (cars/light trucks, gasoline cars, diesel cars, medium duty vehicles, heavy duty vehicles) and year of purchase.

A Look at OBD2 History

The origins of OBD2 trace back to California, driven by the California Air Resources Board (CARB). Recognizing the need for better emission control, CARB mandated OBD in all new vehicles starting from 1991.

The OBD2 standard, as we know it today, was largely shaped by recommendations from the Society of Automotive Engineers (SAE). They standardized DTCs and the OBD connector across different manufacturers with the SAE J1962 standard, promoting consistency and ease of use in vehicle diagnostics.

The adoption of the OBD2 standard was a gradual process, expanding across vehicle types and regions over time:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: The European Union mandated OBD2 for gasoline cars.
2003: The EU extended the requirement to diesel cars as well (known as EOBD in Europe).
2005: OBD2 was required in the US for medium-duty vehicles.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: Finally, OBD2 became mandatory for heavy-duty vehicles in the US.

This image, titled “OBD2 History for Emission Control and Data Access,” illustrates the timeline of OBD2 development, linking it to emission control and its role in accessing car data via the CAN bus.

This image, titled “OBD2 History Timeline Overview,” provides a visual timeline summarizing the key milestones in the history of On-Board Diagnostics.

This image, titled “OBD2 Future Trends: OBD3, Remote Diagnostics, and IoT,” depicts the future evolution of OBD systems towards OBD3 with features like remote diagnostics, emissions testing, cloud connectivity, and IoT integration.

The Future Trajectory of OBD2

OBD2 isn’t going away, but its form and function are evolving. Let’s explore some key trends shaping its future:

Originally, legislated OBD2 was primarily for emissions monitoring and testing. Interestingly, this means electric vehicles (EVs) aren’t obligated to support OBD2 in its traditional form. In fact, most modern EVs largely bypass standard OBD2 requests, opting instead for OEM-specific UDS communication. This makes accessing data from EVs challenging, except when decoding rules have been reverse-engineered. However, there are successful examples of reverse engineering and data access for EVs, as highlighted in case studies for electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Today, OBD2 implementations vary, and it has limitations in data richness and lower-layer protocols. To address these, modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging. These aim to improve OBD communication by using the UDS protocol as a foundation. For deeper insights, see our intro to UDS.

In our increasingly connected world, manual OBD2 emission checks seem outdated. They’re time-consuming and costly. The proposed solution? OBD3 – integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder (similar to those used for bridge tolls) to every car. This would allow the car’s vehicle identification number (VIN) and DTCs to be wirelessly transmitted to a central server for automated checks. Many devices already facilitate CAN or OBD2 data transfer via WiFi/cellular, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger. While this offers convenience and cost savings, it also raises political and privacy concerns due to potential surveillance.

The original intent of OBD2 was for stationary emission controls. However, third parties now widely use OBD2 for real-time data generation via OBD2 dongles, CAN loggers, and more. Interestingly, the German car industry is considering restricting this access. As Christoph Grote, SVP Electronics at BMW, stated in 2017:

“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“

The proposal is to potentially disable OBD2 functionality during driving, centralizing data collection with manufacturers. This would give manufacturers control over the burgeoning ‘automotive big data’. Arguments for this shift often cite security benefits, like reducing the risk of car hacking, though many perceive it as a commercially motivated move, as Navixy discusses. Whether this trend gains momentum remains to be seen, but it could significantly disrupt the market for third-party OBD2 services.

This image, titled “OBD2 Future: Electric Vehicles and Data Access Restrictions,” symbolizes the potential future where electric vehicles might restrict access to data through the OBD2 connector.

Get Our ‘Ultimate CAN Guide’

Eager to become a CAN bus expert?

Our ‘Ultimate CAN Guide’ consolidates 12 ‘simple intros’ into a comprehensive 160+ page PDF:

Download now

This image promotes the “CAN Bus – The Ultimate Guide Tutorial PDF,” visually representing the comprehensive guide available for download.

Understanding OBD2 Standards

On-board diagnostics, OBD2, operates as a higher-layer protocol – think of it like a language. CAN (Controller Area Network) bus, on the other hand, is the communication method, similar to a telephone line. This places OBD2 in the same category as other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

Specifically, OBD2 standards define the OBD2 connector, the lower-layer communication protocols used, OBD2 parameter IDs (PIDs), and much more.

These standards can be mapped to the 7-layer OSI model, a conceptual framework for understanding network communication. In the following sections, we’ll focus on the most critical standards.

Looking at the OSI model overview, you’ll notice that both SAE and ISO standards cover multiple layers. This reflects the standards development for OBD in the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, for instance, SAE J1979 is almost equivalent to ISO 15031-5, and SAE J1962 is comparable to ISO 15031-3.

This image, titled “OBD2 vs CAN Bus in OSI Model,” visually represents the 7-layer OSI model, highlighting how OBD2 and CAN bus protocols, including ISO 15765 and ISO 11898, fit within this framework.

This image, titled “OBD Connector Pinout Socket Female Type A DLC,” shows a detailed pinout diagram of a Type A OBD2 connector socket, also known as a Data Link Connector (DLC).

The OBD2 Connector [SAE J1962]

The 16-pin OBD2 connector is your gateway to accessing vehicle data, standardized by SAE J1962 / ISO 15031-3.

The illustration above shows a Type A OBD2 pin connector (sometimes called a Data Link Connector, or DLC).

Key points about the OBD2 connector:

It’s usually located near the steering wheel, but can sometimes be hidden from plain sight.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout is protocol-dependent, meaning different pins are used for different communication protocols.
CAN bus is the most prevalent lower-layer protocol, so pins 6 (CAN-H) and 14 (CAN-L) are typically connected.

OBD2 Connector Types: A vs. B

In practice, you might encounter both Type A and Type B OBD2 connectors. Type A is generally found in cars, while Type B is more common in medium and heavy-duty vehicles.

As illustrated, both types have similar OBD2 pinouts but differ in power supply output: 12V for Type A and 24V for Type B. Baud rates can also vary, with cars typically using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing).

Visually distinguishing them is easy: Type B OBD2 connectors have an interrupted groove in the middle. This means a Type B OBD2 adapter cable will fit both Type A and B sockets, while a Type A adapter will only fit Type A sockets.

This image, titled “OBD2 Connector Types A vs B (SAE J1962),” compares Type A and Type B OBD2 connectors, highlighting differences in voltage (12V vs 24V) and typical vehicle applications (car vs van/truck).

This image, titled “OBD2 vs CAN bus ISO15765,” visually distinguishes between OBD2 as a protocol and CAN bus (ISO15765) as the underlying communication network.

OBD2 and CAN Bus [ISO 15765-4]

Since 2008, CAN bus became the mandated lower-layer protocol for OBD2 in all US cars, as per ISO 15765.

ISO 15765-4, also known as Diagnostics over CAN (DoCAN), is a set of specifications applied to the CAN standard (ISO 11898).

It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:

CAN bus bit-rate must be either 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.
The OBD2 adapter cable is limited to a maximum length of 5 meters.

OBD2 CAN Identifiers (11-bit, 29-bit)

All OBD2 communication revolves around request/response message pairs.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs (Electronic Control Units) to see if they have data for the requested parameter (defined in ISO 15765-4). In contrast, CAN IDs 0x7E0-0x7E7 are for ‘Physical Addressing’ requests directed to specific ECUs (less common).

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

Some vehicles, particularly vans and light/medium/heavy-duty vehicles, may use extended 29-bit CAN identifiers for OBD2 communication instead of 11-bit IDs.

Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses in 29-bit CAN ID systems are typically found in the range 0x18DAF100 to 0x18DAF1FF (commonly 18DAF110 and 18DAF11E). The response ID is sometimes presented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which the J1939-71 standard marks as ‘Reserved for ISO 15765-2’.

This image, titled “OBD2 Protocol Request and Response Frames,” illustrates the structure of OBD2 communication frames, showing request and response message flows with PIDs and data parameters.

This image, titled “OBD2 CAN bus Identifiers Overview,” presents a table summarizing common CAN bus identifiers used in OBD2 communication, including 7DF, 7E8, and 7E0.

This image, titled “OBD2 vs Proprietary CAN bus Data,” compares OBD2 protocol data with OEM-specific CAN bus data, highlighting the differences in accessibility and standardization.

OBD2 vs. Proprietary CAN Protocols

It’s crucial to understand that your car’s electronic control units (ECUs) operate primarily using OEM-specific CAN protocols, not OBD2. Each Original Equipment Manufacturer (OEM) develops their own proprietary CAN protocols for core vehicle functions. These protocols are often unique to the vehicle brand, model, and year. Unless you are the OEM, interpreting this data is usually impossible without reverse engineering.

Connecting a CAN bus data logger to your car’s OBD2 port might capture OEM-specific CAN data, typically broadcast at a high rate of 1000-2000 frames per second. However, many newer vehicles have a ‘gateway’ that blocks access to this OEM CAN data via the OBD2 port, only allowing OBD2 communication.

In essence, think of OBD2 as a supplementary, higher-layer protocol that runs alongside the OEM-specific protocol.

Bit-rate and ID Validation

As mentioned, OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern cars commonly use 500K and 11-bit IDs, but diagnostic tools should systematically verify this.

ISO 15765-4 provides guidelines for an initialization sequence to determine the correct combination, illustrated in the flowchart below. This method relies on the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit-rate transmission causes CAN error frames.

Newer ISO 15765-4 versions acknowledge that vehicles might support OBD communication via OBDonUDS rather than OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service, as per ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service, as per ISO 14229, ISO 27145-3/SAE J1979-2).

To distinguish between OBDonEDS and OBDonUDS, diagnostic tools can send additional UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.

In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars, while WWH-OBD is mainly used in EU trucks and buses.

This image, titled “OBD2 Bit-rate and CAN ID Validation Flowchart (ISO 15765-4),” outlines the systematic process for validating the correct bit-rate and CAN ID configuration for OBD2 communication as defined by ISO 15765-4.

This image, titled “OBD2 Standards: Five Lower-Layer Protocols,” illustrates the five primary lower-layer protocols used for OBD2 communication, including CAN (ISO 15765), KWP2000, SAE J1850 (VPW & PWM), and ISO 9141.

Five Lower-Layer OBD2 Protocols

While CAN is now the dominant lower-layer protocol for OBD2 (ISO 15765), especially in vehicles manufactured post-2008, understanding the other four protocols is helpful when working with older cars. The pinouts of the OBD2 connector can sometimes indicate which protocol a vehicle uses.

The five lower-layer OBD2 protocols are:

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now the most common protocol.
ISO 14230-4 (KWP2000): Keyword Protocol 2000, frequently used in 2003+ vehicles, particularly in Asia.
ISO 9141-2: Used in European, Chrysler, and Asian vehicles from around 2000-2004.
SAE J1850 (VPW – Variable Pulse Width Modulation): Primarily used in older General Motors (GM) vehicles.
SAE J1850 (PWM – Pulse Width Modulation): Mainly used in older Ford vehicles.

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

All OBD2 data transmitted over CAN bus utilizes a transport protocol known as ISO-TP (ISO 15765-2). This protocol enables the transmission of data payloads exceeding the 8-byte limit of a standard CAN frame. This is essential in OBD2 for tasks like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), where ISO 15765-2 handles segmentation, flow control, and reassembly of larger messages. For a more detailed explanation, refer to our intro to UDS.

However, much of the time, OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF). Here, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-related communication.

This image, titled “ISO 15765-2 ISO-TP OBD2 Frame Types,” illustrates the different frame types defined in ISO-TP for OBD2 communication, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

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

To better grasp OBD2 over CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. Simply put, an OBD2 message consists of an identifier, a data length indicator (PCI field), and the actual data. The data is further broken down into Mode, parameter ID (PID), and data bytes.

This image, titled “OBD2 Message Structure Breakdown,” dissects the structure of an OBD2 message, explaining the role of Mode, PID (Parameter ID), and Data Bytes within the frame.

Example: OBD2 Request/Response

Before diving into the components of an OBD2 message, let’s look at a practical request/response example for ‘Vehicle Speed’.

In this scenario, an external diagnostic tool sends a request to the car 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 Vehicle Speed value in the 4th byte, 0x32 (which is 50 in decimal).

By consulting the decoding rules for OBD2 PID 0x0D, we can determine that the physical value represents a speed of 50 km/h.

Next, we’ll delve into OBD2 modes and PIDs in more detail.

This image, titled “OBD2 Request (7DF) and Response (7E8) Example,” shows a CAN bus trace example of an OBD2 request for vehicle speed (CAN ID 7DF) and the corresponding response (CAN ID 7E8).

This image, titled “OBD2 PID 0D Example: Vehicle Speed,” details the specific example of OBD2 PID 0D, which is used to request and retrieve vehicle speed data.

This image, titled “OBD2 Services (Modes): 10 Diagnostic Services,” outlines the 10 standardized OBD2 diagnostic services or modes, including modes for current data, freeze frame data, and clearing DTCs.

The 10 OBD2 Services (aka Modes)

There are ten standardized OBD2 diagnostic services, often referred to as modes. Mode 0x01 is used for accessing current, real-time data, while other modes are designed to handle Diagnostic Trouble Codes (DTCs) – displaying, clearing, and showing freeze frame data related to them.

Vehicles are not required to support all 10 OBD2 modes, and manufacturers can also implement modes beyond these standardized ones (known as OEM-specific OBD2 modes).

Within OBD2 messages, the mode is indicated in the second byte. In a request message, the mode is directly included (e.g., 0x01). In a response, 0x40 is added to the requested mode (e.g., a response to mode 0x01 will start with 0x41).

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, there are Parameter IDs (PIDs).

For example, mode 0x01 contains approximately 200 standardized PIDs providing real-time data on parameters like speed, RPM, and fuel level. However, a vehicle doesn’t have to support every PID within a mode. In practice, most vehicles only support a subset of the available PIDs.

One PID stands out as particularly important: mode 0x01 PID 0x00. If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID, the vehicle ECU communicates its support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Furthermore, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to determine support for subsequent ranges of mode 0x01 PIDs.

This image, previously used, titled “OBD2 Protocol Request and Response Frames,” again illustrates the structure of OBD2 communication frames, emphasizing the role of PIDs in requests and responses.

This image, titled “OBD2 PID Overview Tool (Service 01),” showcases an OBD2 PID overview tool focused on Service 01, likely displaying supported PIDs and their descriptions.

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs. This scaling data is essential for converting the raw data bytes into meaningful physical values (as explained in our CAN bus intro).

If you need to quickly look up a mode 0x01 PID, our OBD2 PID overview tool is a valuable resource. It helps you construct OBD2 request frames and dynamically decode OBD2 responses.

OBD2 PID overview tool

How to Log and Decode OBD2 Data

Let’s walk through a practical example of logging OBD2 data using the CANedge CAN bus data logger.

The CANedge is configurable to transmit custom CAN frames, making it ideal for OBD2 logging.

Once configured, you can easily connect the CANedge to your vehicle using our OBD2-DB9 adapter cable.

This image, titled “OBD2 PID Data Logger Request (7DF) and Response (7E8),” illustrates the process of using an OBD2 data logger to send PID requests and receive responses, highlighting CAN IDs 7DF and 7E8.

You can send a CAN frame at e.g. 500K, then check if it is successfully sent

This image, titled “OBD2 Bit Rate Test Validation,” shows a screenshot of software validating the CAN bit rate for OBD2 communication, confirming successful frame transmission at 500K.

The responses to ‘Supported PIDs’ can be reviewed in asammdf

This image, titled “OBD2 Supported PIDs Test Responses in asammdf,” displays a screenshot from asammdf software showing responses to ‘Supported PIDs’ requests, allowing users to review and analyze the responses.

This image, titled “Review Supported PIDs via OBD2 Lookup Tool,” demonstrates using an OBD2 PID lookup tool to decode and interpret the ‘Supported PIDs’ results obtained from a vehicle.

#1: Test Bit-rate, IDs & Supported PIDs

As previously discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a specific vehicle. You can use the CANedge to test this, as described below (refer to the CANedge Intro for detailed instructions):

Test Bit-rate: Send a CAN frame at 500K and verify successful transmission (if unsuccessful, try 250K).
Set Bit-rate: Use the identified bit-rate for all subsequent communication.
Request Supported PIDs: Send multiple ‘Supported PIDs’ requests and examine the responses.
Determine CAN ID Type: Based on the response IDs, determine whether the vehicle uses 11-bit or 29-bit CAN IDs.
Identify Supported PIDs: Analyze the response data to identify which PIDs are supported by the vehicle.

We provide ready-to-use configuration files to simplify these tests.

Most non-EV vehicles manufactured in 2008 or later support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

As seen in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBD request. This occurs because we use the 0x7DF request ID, which broadcasts the request to all ECUs, prompting all OBD2/OBDonEDS-compliant ECUs to respond to service 0x01 PID 0x00. This often results in numerous responses, particularly for this PID. As you proceed with subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. Notice that the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs. Therefore, to reduce bus load, you could direct future requests specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

#2: Configure OBD2 PID Requests

Once you’ve identified the OBD2 PIDs your vehicle supports, along with the correct bit-rate and CAN IDs, you can configure your transmit list to request the PIDs you’re interested in logging.

Consider these points when configuring your PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid receiving multiple responses for each request.
Request Spacing: Introduce a delay of 300-500 ms between each OBD2 request. Overly frequent requests may overwhelm the ECUs and cause them to stop responding.
Battery Conservation: Implement triggers to halt transmissions when the vehicle is inactive. This prevents unnecessary battery drain by ‘waking up’ ECUs when the vehicle is off.
Data Filtering: Apply filters to record only OBD2 responses, especially if your vehicle also transmits OEM-specific CAN data, to keep your logs focused.

With these configurations in place, your CANedge is ready to efficiently log raw OBD2 data!

An example list of CANedge OBD2 PID requests

This image, titled “CANedge OBD2 PID Request Transmit List Example,” shows an example configuration of a transmit list in CANedge software, set up to request specific OBD2 PIDs.

asammdf lets you DBC decode and visualize OBD2 data

This image, titled “OBD2 Data Decoded and Visualized in asammdf,” showcases a visual plot of decoded OBD2 data in asammdf software, demonstrating how DBC files can be used for data interpretation and visualization.

#3: DBC Decode Raw OBD2 Data

To effectively analyze and visualize your logged OBD2 data, you need to decode the raw data into ‘physical values’ (like km/h or °C).

The necessary decoding information is detailed in ISO 15031-5/SAE J1979 and is also available on platforms like Wikipedia. For convenience, we offer a free OBD2 DBC file that simplifies DBC decoding of raw OBD2 data in most CAN bus software tools.

Decoding OBD2 data is slightly more complex than standard CAN signal decoding. This is because various OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone isn’t enough to uniquely identify the signals within the payload.

To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID in combination to identify the signal. This form of multiplexing is known as ‘extended multiplexing‘ and can be implemented using DBC files.

CANedge: OBD2 Data Logger

The CANedge makes OBD2 data logging straightforward. It records data directly to an 8-32 GB SD card. Simply connect it to your vehicle (car or truck) to begin logging and use free software/APIs and our OBD2 DBC for data decoding and analysis.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples [ISO-TP]

OBD2 communication, as per ISO 15765-2, always uses the ISO-TP transport protocol. While many examples discussed earlier involve single-frame communication, let’s examine multi-frame communication scenarios.

Multi-frame OBD2 communication requires flow control frames (see our UDS intro). In practice, a static flow control frame can be transmitted approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.

Analyzing multi-frame OBD2 responses necessitates CAN software/API tools that support ISO-TP, such as the CANedge MF4 decoders.

This image, titled “OBD2 Multi-Frame Request Message for VIN,” shows an example of a multi-frame request message used to retrieve the Vehicle Identification Number (VIN) via OBD2.

Example 1: OBD2 Vehicle Identification Number (VIN)

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more (detailed in our UDS intro). To retrieve the VIN using OBD2, you use mode 0x09 and PID 0x02:

This image, titled “VIN (Vehicle Identification Number) OBD2 Multi-Frame Example,” illustrates a multi-frame communication sequence for retrieving the VIN using OBD2, showing both request and response frames.

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

The vehicle responds with a First Frame containing the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is the byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case (see ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes constitute the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction.

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

OBD2 allows diagnostic tools to request up to six mode 0x01 OBD2 PIDs in a single request frame. The ECU should respond with data for all supported PIDs (omitting unsupported ones from the response), possibly using multiple frames as defined by ISO-TP.

This feature enables efficient and higher-frequency data collection, but it also means the signal encoding is specific to the request method. This makes using generic OBD2 DBC files challenging for such applications. We generally advise against using this method in practice. Below is an example trace illustrating this process:

This image, titled “Multi-PID Request Example in OBD2 (ISO-TP Trace),” shows a CAN bus trace example of requesting multiple PIDs (Parameter IDs) in a single OBD2 request using ISO-TP multi-frame communication.

The multi-frame response is similar to the VIN example, but the payload includes the requested PIDs along with their corresponding data. In the example, the PIDs are ordered similarly to the request order, which is common but not strictly mandated by ISO 15031-5.

Decoding this response via generic DBC files is very complex, making this approach impractical for general data logging unless you use a tool specifically designed for it. You’re essentially dealing with extended multiplexing, compounded by multiple instances within the payload. Your DBC file would need to account for the specific payload position of each PID, making it hard to generalize across different vehicles with varying PID support. Furthermore, managing this becomes extremely difficult if you send multiple multi-PID requests, as it becomes challenging to uniquely identify messages.

Workarounds are possible, such as using custom scripts and recording transmit messages from your testing tool. The script could then interpret response messages based on the associated request message. However, such approaches are difficult to scale and manage efficiently.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

You can use OBD2 to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes’. No PID is needed in the request. The targeted ECU(s) will respond with the number of DTCs they have stored (possibly zero), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than two DTCs are stored.

The 2-byte DTC value is typically divided into two parts, according to ISO 15031-5/ISO 15031-6. The first two bits define the ‘category’, and the remaining 14 bits define a 4-digit code (displayed in hexadecimal), as illustrated below. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.

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

This image, titled “OBD2 DTC Decoding and DBC Interpretation Example,” explains how to decode and interpret Diagnostic Trouble Codes (DTCs) from OBD2 data using DBC files.

This image, titled “OBD2 DTC Request and Response CAN Bus Trace Example,” provides a CAN bus trace example of requesting Diagnostic Trouble Codes (DTCs) and the corresponding multi-frame response containing DTC data.

OBD2 Data Logging – Use Case Examples

OBD2 data from cars and light trucks has a wide range of applications:

This image promotes OBD2 data loggers for vehicle diagnostics, showing an OBD2 data logger connected to a car.

Logging data from cars

OBD2 data logging in cars can be used for purposes like reducing fuel consumption, improving driving habits, testing prototype components, and insurance telematics.

obd2 logger

This image promotes OBD2 real-time streaming for diagnostics, showing an OBD2 interface streaming data via USB.

Real-time car diagnostics

OBD2 interfaces enable real-time streaming of human-readable OBD2 data, which is invaluable for diagnosing vehicle issues on the fly.

obd2 streaming

This image promotes OBD2 data loggers for predictive maintenance, illustrating cloud-connected OBD2 loggers for vehicle health monitoring.

Predictive maintenance

Cars and light trucks equipped with IoT OBD2 loggers can be monitored remotely in the cloud for predictive maintenance, helping to anticipate and prevent breakdowns.

predictive maintenance

This image promotes CAN bus data loggers as vehicle ‘black boxes’, useful for insurance and warranty purposes.

Vehicle blackbox logger

An OBD2 logger can function as a ‘black box’ for vehicles or equipment, providing crucial data for incident analysis, dispute resolution, and in-depth diagnostics.

can bus blackbox

Do you have a specific OBD2 data logging application in mind? Reach out for a free consultation!

For further reading and more in-depth introductions, explore our guides section, or download the comprehensive ‘Ultimate Guide’ PDF.

Ready to start logging or streaming OBD2 data?

Get your OBD2 data logger today!

Buy now
Contact us

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN