What Can OBD2 Tell You? Unlocking Your Car's Secrets

Want to understand what your car is really telling you?

This guide provides a practical introduction to the On-Board Diagnostics 2 (OBD2) protocol, covering everything from the OBD2 connector and Parameter IDs (PIDs) to its connection with the Controller Area Network (CAN) bus.

Note: This is designed as a practical introduction, so you’ll discover how to request and interpret OBD2 data, explore key logging applications, and gain valuable practical insights.

Discover why this is becoming the go-to OBD2 tutorial for enthusiasts and professionals alike.

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

Article Contents

Author: Martin Falch (Updated January 2025)

Download as PDF

Decoding OBD2: Your Car’s Diagnostic System

OBD2 is essentially your vehicle’s built-in health monitor. It’s a standardized system that allows access to crucial information like Diagnostic Trouble Codes (DTCs) and real-time operational data directly from your car’s computer via the OBD2 port.

You’ve likely already encountered OBD2 in action:

Ever seen the check engine light illuminate on your dashboard?

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

Mechanics connect the OBD2 reader to the OBD2 16-pin connector, typically located under the dashboard near the steering wheel. This tool sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’. These responses can contain a wealth of information, including speed, fuel level, and Diagnostic Trouble Codes (DTCs), enabling faster and more accurate troubleshooting.

Understanding OBD2: On-Board Diagnostics and the Malfunction Indicator Light (MIL), commonly known as the check engine light.

Is My Vehicle OBD2 Compliant?

In most cases, yes!

The vast majority of modern gasoline and diesel vehicles, excluding fully electric cars, are equipped with OBD2 and often utilize the CAN bus communication protocol. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 compliance. Some may have the connector but not fully support the OBD2 protocol. A reliable way to check compliance is to consider where and when your car was originally purchased as new:

OBD2 Compliance Guide: Check if your car is OBD2 compliant based on purchase location and year for US, EU, and Canada.

A Look at OBD2 History

The origins of OBD2 trace back to California, where the California Air Resources Board (CARB) mandated OBD systems in all new vehicles starting from 1991 for emissions monitoring purposes.

The OBD2 standard, aiming for greater uniformity, was developed based on recommendations from the Society of Automotive Engineers (SAE). This standardization included Diagnostic Trouble Codes (DTCs) and the physical OBD connector itself, as defined in SAE J1962, ensuring consistency across different vehicle manufacturers.

The implementation of OBD2 was phased in progressively:

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

OBD2 Historical Timeline: Evolution of On-Board Diagnostics for emission control and exhaust monitoring, including EOBD2 and EOBDII standards.

OBD2 History Timeline Overview: A visual timeline illustrating the historical progression of On-Board Diagnostics.

OBD2 Future Trends: Envisioning OBD3 with remote diagnostics, emissions testing, cloud connectivity, and IoT integration.

The Future of OBD2

OBD2 is firmly established, but its evolution continues. Let’s examine some key trends shaping its future:

Initially, OBD2 was primarily designed for emissions control and testing mandated by legislation. Consequently, electric vehicles (EVs) are not compelled to support OBD2 in any form. In practice, most modern EVs indeed lack support for standard OBD2 requests. Instead, they predominantly use OEM-specific UDS (Unified Diagnostic Services) communication protocols. This shift generally complicates data retrieval from EVs, except in cases where reverse engineering efforts have decoded the proprietary protocols. For examples, explore our case studies on electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Today, OBD2 implementations vary, and it faces limitations in data richness and underlying communication protocols. To address these, modern alternatives like WWH-OBD (World-Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. Both aim to enhance and streamline OBD communication by utilizing the UDS protocol as a foundation. For a deeper understanding of these protocols, refer to our introduction to UDS.

In our increasingly connected world, traditional OBD2 testing methods can appear cumbersome. Manual emission control checks are time-consuming and costly.

The solution on the horizon? OBD3 – integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder, similar to those used for electronic toll collection, to every car. This would enable vehicles to transmit their Vehicle Identification Number (VIN) and DTCs wirelessly via WiFi to a central server for automated checks.

Many devices already facilitate CAN or OBD2 data transfer via WiFi or cellular networks, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.

While offering cost savings and convenience, OBD3 also raises political challenges related to surveillance and data privacy.

The OBD2 protocol was originally conceived for stationary emission control tests.

However, today, third-party entities widely utilize OBD2 to generate real-time vehicle data through OBD2 dongles, CAN loggers and similar devices. Interestingly, the German car industry is seeking to restrict this 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)

The proposal suggests disabling OBD2 functionality while driving, centralizing data collection within manufacturer-controlled servers. This would essentially give manufacturers control over the burgeoning field of ‘automotive big data’.

Arguments center around security concerns, such as mitigating the risk of car hacking. However, many perceive this move as commercially motivated. Whether this trend gains traction remains to be seen, but it has the potential to significantly disrupt the market for third-party OBD2 services.

OBD2 Future Challenges: Electric Vehicles increasingly restricting data access through the OBD2 connector.

Get Our Comprehensive CAN Bus Guide

Ready to become a CAN bus expert?

Access our 12 ‘simple introductions’ in one comprehensive 160+ page PDF:

Download Now

OBD2 Standards: Defining the Framework

On-Board Diagnostics 2 (OBD2) is a higher-layer protocol, functioning like a language, while CAN acts as the communication method, akin to a telephone line. This positions OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

Specifically, OBD2 standards delineate the OBD2 connector specifications, lower-layer protocols, OBD2 Parameter IDs (PIDs), and other critical aspects of the system.

These standards can be visualized within a 7-layer OSI model framework. The following sections will focus on the most pertinent standards.

Observing the OSI model overview, it’s noticeable that both SAE and ISO standards cover multiple layers. This reflects the development of OBD standards in both the USA (SAE) and the EU (ISO). Many standards are technically very similar, for example, SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3.

OBD2 and CAN Bus within the OSI Model: Illustrating the 7-layer OSI model with ISO 15765 and ISO 11898 standards for OBD2 and CAN Bus.

OBD2 Connector Pinout: Detailed view of a Type A OBD2 connector socket (female), also known as Data Link Connector (DLC).

The OBD2 Connector [SAE J1962]: Your Access Port

The 16-pin OBD2 connector provides straightforward access to your vehicle’s data and is specified in the SAE J1962 / ISO 15031-3 standard.

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

Key features of the OBD2 connector:

It’s generally 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, allowing for scanner operation without the car running.
The OBD2 pinout configuration varies depending on the communication protocol used.
CAN bus, the most prevalent lower-layer protocol, typically utilizes pins 6 (CAN-High) and 14 (CAN-Low).

OBD2 Connector Types: A vs. B

In practical applications, you might encounter both Type A and Type B OBD2 connectors. Type A is commonly found in passenger cars, while Type B is more prevalent in medium and heavy-duty vehicles.

As illustrated, both types share similar OBD2 pinouts but differ in their power supply outputs (12V for Type A and 24V for Type B). Baud rates may also vary, with cars typically using 500 kbps, while heavy-duty vehicles often use 250 kbps (with increasing support for 500 kbps in newer models).

A distinguishing visual cue is that the Type B OBD2 connector features an interrupted groove in the center. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, whereas a Type A connector will not fit into a Type B socket.

OBD2 Connector Types A and B: Comparing SAE J1962 Type A and Type B connectors for cars, vans, and trucks, highlighting 12V and 24V differences.

OBD2 vs CAN bus ISO15765: Contrasting OBD2 protocol with CAN bus physical layer as defined by ISO 15765.

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

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as mandated by ISO 15765.

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies a set of constraints applied to the CAN standard (ISO 11898).

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

CAN bus bit-rate must be either 250 kbps or 500 kbps.
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 must have a maximum length of 5 meters.

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

All OBD2 communication operates on a request-response principle.

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

ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most common response ID is 0x7E8 (from the ECM, Engine Control Module), followed by 0x7E9 (from the TCM, Transmission Control Module).

In some vehicle types, particularly vans and light, medium, and heavy-duty vehicles, OBD2 communication may utilize extended 29-bit CAN identifiers instead of 11-bit CAN identifiers.

In these cases, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses from the vehicle will use CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). This response ID is sometimes represented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated as ‘Reserved for ISO 15765-2’ in the J1939-71 standard.

OBD2 Protocol Request and Response Frames: Illustrating the structure of OBD2 communication frames for requesting and responding to PID data parameters.

OBD2 vs Proprietary CAN bus: Contrasting OBD2 standardized data access with OEM-specific proprietary CAN bus data.

OBD2 vs. Proprietary CAN Protocols: Two Worlds of Data

It’s important to understand that your vehicle’s Electronic Control Units (ECUs) do not rely on OBD2 for their core functions. Instead, each Original Equipment Manufacturer (OEM) implements their own proprietary CAN protocols for internal communication and control. These proprietary CAN protocols are often unique to the vehicle brand, model, and year. Unless you are the OEM, interpreting this proprietary data is generally not possible without significant effort, such as reverse engineering.

When you connect a CAN bus data logger to your vehicle’s OBD2 connector, you might observe the OEM-specific CAN data, typically broadcast at high rates of 1000-2000 frames per second. However, in many newer vehicles, a ‘gateway’ module restricts access to this raw CAN data, allowing only OBD2 communication through the OBD2 port.

In essence, think of OBD2 as an ‘extra’ higher-layer protocol that operates parallel to the OEM-specific protocol. It’s a standardized layer specifically for diagnostics and emissions-related data.

Bit-rate and ID Validation: Ensuring Correct Communication

As mentioned, OBD2 can use one of two bit rates (250 kbps, 500 kbps) and either 11-bit or 29-bit CAN IDs. This results in four potential combinations. In modern cars, 500 kbps and 11-bit IDs are the most common, but external diagnostic tools should systematically verify this.

ISO 15765-4 provides recommendations for a systematic initialization sequence to determine the correct combination, illustrated in the flowchart below. This method leverages the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section for details) and that using an incorrect bit rate will generate CAN error frames.

Newer versions of ISO 15765-4 acknowledge that vehicles may support OBD communication via OBDonUDS (OBD on Unified Diagnostic Services) rather than OBDonEDS (OBD on Emission Diagnostic Services). This article primarily focuses on OBD2/OBDonEDS (as defined by ISO 15031-5/SAE J1979) in contrast to WWH-OBD/OBDonUDS (as defined by ISO 14229, ISO 27145-3/SAE J1979-2).

To differentiate between OBDonEDS and OBDonUDS protocols, a diagnostic tool might send additional request messages, specifically 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 vehicles today, while WWH-OBD is mainly used in EU trucks and buses.

OBD2 Bit-rate and CAN ID Validation Flowchart: Illustrating the ISO 15765-4 validation process for determining correct bit-rate and CAN ID.

OBD2 Standards and Protocols: Overview of the five key lower-layer protocols used in OBD2, including CAN (ISO 15765), KWP2000, SAE J1850, and ISO 9141.

Five Lower-Layer OBD2 Protocols: A Historical Perspective

While CAN bus is the dominant lower-layer protocol for OBD2 today, as per ISO 15765, particularly in vehicles manufactured after 2008, it’s helpful to be aware of the four other protocols previously used, especially when working with older vehicles. The pinout configuration of the OBD2 connector can sometimes provide clues about the protocol in use.

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

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

All OBD2 data is transmitted over the CAN bus using a transport protocol called ISO-TP (ISO 15765-2). This protocol enables the transmission of data payloads exceeding the 8-byte limit of a standard CAN frame. This capability is essential in OBD2 for operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often require more than 8 bytes of data. ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. For detailed information, refer to our introduction to UDS.

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

ISO 15765-2 ISO-TP OBD2 Frame Types: Diagram illustrating different frame types in ISO-TP for OBD2 communication.

The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]: Anatomy of a Request

To better understand OBD2 communication over CAN, let’s examine the structure of a raw ‘Single Frame’ OBD2 CAN message. In simple terms, an OBD2 message consists of a CAN identifier, a data length indicator (PCI field), and the actual data payload. The data payload is further broken down into a Mode byte, a Parameter ID (PID), and data bytes.

OBD2 PIDs Message Structure: Breakdown of an OBD2 message structure, explaining Mode, Parameter ID (PID), ID, and data bytes.

Example: OBD2 Request and Response for Vehicle Speed

Let’s illustrate with a practical example: requesting and receiving vehicle speed data.

In this scenario, an external diagnostic tool sends a request message to the vehicle with CAN ID 0x7DF. The payload contains two bytes: Mode 0x01 and PID 0x0D. The vehicle responds with a message on CAN ID 0x7E8. The response payload contains three bytes, with the vehicle speed value encoded in the fourth byte as 0x32 (which is 50 in decimal).

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

We will now delve into the details of OBD2 modes and PIDs.

OBD2 Request and Response Example: Illustrating an OBD2 request with ID 7DF and response with 7E8 for vehicle speed.

OBD2 PID Example – Vehicle Speed 0D: Detailed example of OBD2 Parameter ID 0D representing vehicle speed.

OBD2 Services and Modes: Overview of the 10 OBD2 service modes, including current data, freeze frame, and DTC clearing.

The 10 OBD2 Services (Modes): Accessing Different Data Types

OBD2 defines 10 diagnostic services, also referred to as modes. Mode 0x01 is used to retrieve current real-time data parameters, while other modes are designed to access and clear Diagnostic Trouble Codes (DTCs), retrieve freeze frame data (snapshots of data when a DTC was set), and perform other diagnostic functions.

It’s important to note that vehicles are not required to support all 10 OBD2 modes. Furthermore, manufacturers may implement additional modes beyond the 10 standardized modes for OEM-specific diagnostics.

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

OBD2 Parameter IDs (PIDs): Requesting Specific Data Points

Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the particular data point being requested.

For instance, mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on parameters such as vehicle speed, engine RPM, and fuel level. However, a vehicle is not obligated to support all defined PIDs within a given mode. In practice, most vehicles support only a subset of the available PIDs.

One PID holds special significance:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the ECU communicates which PIDs from the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to determine support for subsequent ranges of mode 0x01 PIDs (0x21-0x40, 0x41-0x60, etc.).

OBD2 Protocol Request and Response Frames: Diagram illustrating OBD2 request and response frames for PID data parameters.

OBD2 PID Overview Tool: Screenshot of an OBD2 PID overview tool for service 01, used for exploring supported PIDs.

Tip: Utilizing an OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 contain detailed scaling information for standard OBD2 PIDs, enabling you to convert the raw data bytes into meaningful physical values (as explained in our CAN bus introduction).

For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is a valuable resource. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 Data

This section provides a hands-on example of how to log OBD2 data using the CANedge CAN bus data logger.

The CANedge’s configurable CAN frame transmission feature makes it ideal for OBD2 logging.

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

OBD2 PID Data Logger Request: Diagram showing an OBD2 data logger requesting PID data using CAN IDs 7df and 7e8.

OBD2 Bit Rate Test Validation: Example of validating bit rate in OBD2 communication.

OBD2 Supported PIDs Test Responses: Reviewing responses to ‘Supported PIDs’ test in asammdf.

Step #1: Validate Bit-rate, CAN IDs, and Supported PIDs

As previously discussed, ISO 15765-4 outlines a procedure to identify the bit rate and CAN IDs used by a specific vehicle. You can use the CANedge to perform these tests as follows (refer to the CANedge Intro for detailed instructions):

Bit-rate Test: Send a CAN frame at 500 kbps and check for successful transmission. If unsuccessful, try 250 kbps.
Bit-rate Confirmation: Use the identified bit-rate for all subsequent communication.
Supported PIDs Discovery: Send multiple ‘Supported PIDs’ requests and analyze the responses.
CAN ID Determination: Based on the response IDs, determine whether the vehicle uses 11-bit or 29-bit CAN IDs for OBD2 communication.
PID Support Analysis: Analyze the response data to identify the PIDs supported by the vehicle.

We provide pre-configured settings to streamline these tests.

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

As shown in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBD request, particularly when using the 0x7DF request ID, which broadcasts the request to all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are often observed. As you progress to subsequent ‘Supported PIDs’ requests, fewer ECUs are likely to respond. Notice that the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs. Optimizing communication efficiency can be achieved by directing subsequent requests specifically to the ECM ECU using ‘Physical Addressing’ with CAN ID 0x7E0.

Step #2: Configure OBD2 PID Requests for Data Logging

Once you’ve identified the OBD2 PIDs supported by your vehicle and the correct bit rate and CAN IDs to use, you can configure your CANedge to request the specific PIDs you want to log.

Consider these factors when configuring your CANedge:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize redundant responses.
Request Spacing: Introduce a delay of 300-500 ms between consecutive OBD2 requests to prevent overwhelming the ECUs, which may cause them to stop responding.
Power Management: Implement triggers to halt transmission when the vehicle is inactive to prevent battery drain and unintended ECU wake-ups.
Data Filtering: Configure filters to record only OBD2 responses, especially if your vehicle also transmits OEM-specific CAN data, to reduce data storage and processing needs.

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

CANedge OBD2 PID Request Example: An example configuration list of OBD2 PID requests for CANedge.

OBD2 Data Visualization in asammdf: Decoded and visualized OBD2 data plot in asammdf using a CAN bus DBC file.

Step #3: DBC Decode Raw OBD2 Data for Analysis

To effectively analyze and visualize your logged OBD2 data, you need to decode the raw data bytes into human-readable ‘physical values,’ such as km/h or °C.

The necessary decoding information is specified in ISO 15031-5/SAE J1979 and is also available on resources 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 somewhat more complex than standard CAN signal decoding because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is insufficient to uniquely identify the signals within the payload.

To address this, you must consider the CAN ID, OBD2 mode, and OBD2 PID together to identify the signal correctly. This multiplexing technique is known as ‘extended multiplexing,’ which can be implemented using DBC files.

CANedge: Your Dedicated OBD2 Data Logger

The CANedge provides a straightforward solution for recording OBD2 data directly to a removable 8-32 GB SD card. Simply connect it to your vehicle’s OBD2 port to begin logging. Data can be decoded using free software and APIs and our OBD2 DBC file.

OBD2 logger intro
CANedge Product Details

OBD2 Multi-Frame Examples [ISO-TP]: Handling Larger Data

OBD2 communication, governed by ISO-TP (ISO 15765-2), utilizes multi-frame messaging when data exceeds the single-frame limit. While earlier examples focused on single-frame exchanges, this section illustrates multi-frame communication scenarios.

Multi-frame OBD2 communication necessitates flow control frames (refer to our UDS introduction). 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.

Furthermore, processing multi-frame OBD2 responses requires CAN software and API tools that support ISO-TP, such as the CANedge MF4 decoders.

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

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and various other applications (see our UDS introduction for more context). To retrieve the VIN using OBD2 requests, you use mode 0x09 and PID 0x02:

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

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

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

External diagnostic tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU will respond with data for the supported PIDs (omitting data for unsupported PIDs), potentially using multi-frame responses as needed per ISO-TP.

This feature enhances data collection efficiency, but it also means that signal encoding becomes specific to the request method. This can make using generic OBD2 DBC files challenging for such cases. We generally advise against using this method in practice unless specifically required. Below is an example trace of such a multi-PID request and response:

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

Decoding this response via generic DBC files is complex and often impractical. Therefore, we do not recommend this approach for general data logging unless you’re using tools specifically designed for multi-PID requests. This scenario presents a form of extended multiplexing, complicated by multiple instances throughout the payload. Your DBC file would need to account for the specific payload position of each PID, making it difficult to generalize across vehicles with varying PID support. Handling this complexity solely through DBC manipulations becomes nearly impossible if you send multiple such multi-PID requests, as you lose a clear method to differentiate messages from each other.

Workarounds could involve custom scripts and recording both request and response messages. The script could then interpret responses based on the preceding request, but such methods are challenging to scale.

Example 3: Diagnostic Trouble Codes (DTCs) via OBD2

You can use OBD2 to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes.’ No PID is included in the request. The targeted ECU(s) will respond with the number of DTCs currently stored (which may be zero if no DTCs are present), with each DTC occupying 2 data bytes. Multi-frame responses are necessary if more than 2 DTCs are stored.

The 2-byte DTC value is structured into two parts, as defined by ISO 15031-5/ISO 15031-6. The first 2 bits categorize the DTC (e.g., Powertrain, Body, Chassis, Network), and the remaining 14 bits form a 4-digit code (displayed in hexadecimal), as shown in the visual. Decoded DTC values can be looked up using online OBD2 DTC lookup tools like repairpal.com.

The example below illustrates a request to an ECU that has 6 DTCs stored.

OBD2 DTC Decoding Example: Interpretation example of OBD2 Diagnostic Trouble Codes (DTC) using DBC.

OBD2 Data Logging: Real-World Use Cases

OBD2 data from cars and light trucks has diverse applications:

Vehicle Data Logging

OBD2 data logging in cars can be used for various purposes, including fuel efficiency improvement, driving behavior analysis, prototype testing, and insurance telematics.

OBD2 Logger Solutions

Real-Time Vehicle Diagnostics

OBD2 interfaces facilitate real-time streaming of vehicle data for live diagnostics, enabling mechanics and enthusiasts to quickly identify and troubleshoot vehicle issues.

OBD2 Real-Time Streaming Tools

Predictive Maintenance

Cloud-connected IoT OBD2 loggers enable remote vehicle monitoring for predictive maintenance, helping to anticipate and prevent breakdowns, particularly useful for fleet management.

Predictive Maintenance Solutions

Vehicle Black Box Recording

An OBD2 logger can function as a ‘black box’ for vehicles or equipment, recording critical data for incident analysis, warranty validation, and diagnostic purposes.

CAN Bus Black Box Loggers

Do you have an OBD2 data logging application in mind? Contact us for a free consultation!

Explore our guides section for more introductory articles or download our comprehensive ‘Ultimate Guide’ PDF.

Ready to start logging or streaming OBD2 data?

Get your OBD2 data logger today!

Buy Now
Contact Us

Recommended Resources

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN

What Can OBD2 Tell You? Unlocking Your Car’s Secrets