OBD2 CAN Protocol: A Deep Dive into On-Board Diagnostics

Need a comprehensive guide to the Obd2 Can Protocol?

This article provides an in-depth exploration of the OBD2 (On-Board Diagnostics) protocol, with a specific focus on its integration with the CAN (Controller Area Network) bus. We will delve into the intricacies of the OBD2 connector, OBD2 parameter IDs (PIDs), and the crucial link between OBD2 and the CAN bus system in modern vehicles.

This is more than just a simple introduction; it’s a detailed guide for anyone seeking to understand how OBD2 communication functions over the CAN protocol. Learn how to request and interpret OBD2 data, explore key applications for data logging, and gain practical insights into working with OBD2 CAN protocol.

Discover why this article is becoming a go-to resource for understanding the OBD2 CAN protocol.

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

Understanding OBD2 and its Connection to CAN Protocol

OBD2 is essentially your car’s internal health monitoring system. It’s a standardized protocol designed to retrieve diagnostic trouble codes (DTCs) and access real-time vehicle data through the OBD2 connector. OBD2’s prevalence means you’ve likely encountered it in some form, even if you weren’t aware of it directly.

Remember the check engine light illuminating on your dashboard? That’s OBD2 at work, signaling a potential issue within your vehicle. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the problem.

This process involves connecting the OBD2 scanner to the 16-pin OBD2 connector, typically located near the steering wheel. The scanner transmits ‘OBD2 requests’ to the car’s computer system. In turn, the car responds with ‘OBD2 responses,’ which can contain valuable information like speed, fuel level, or those critical Diagnostic Trouble Codes (DTCs). This efficient communication significantly speeds up the troubleshooting and repair process.

Alt: OBD2 system displaying malfunction indicator light (MIL) and diagnostic scan tool.

OBD2 Compatibility: Is Your Car Equipped?

The answer is overwhelmingly yes, probably!

The vast majority of modern, non-electric vehicles are equipped with OBD2 systems, and a significant portion of these utilize the CAN bus for communication. However, it’s important to note that the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 compliance, especially in older vehicles. To confirm if your car supports OBD2, consider its origin and year of purchase:

Alt: OBD2 compliance chart by region and vehicle type, highlighting US and EU regulations.

A Brief History of OBD2 and CAN Integration

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

The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBD2, establishing uniform DTCs and the OBD connector itself (SAE J1962) across different vehicle manufacturers.

The OBD2 standard adoption unfolded gradually across the globe:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: The European Union (EU) required OBD2 for gasoline cars.
2003: EU extended the requirement to diesel cars as well (EOBD – European On-Board Diagnostics).
2005: OBD2 became mandatory in the US for medium-duty vehicles.
2008: US regulations mandated the use of ISO 15765-4 (CAN) as the underlying protocol for OBD2 communication. This solidified the OBD2 CAN protocol.
2010: OBD2 was finally required for heavy-duty vehicles in the US.

Alt: OBD2 history infographic highlighting emission control and CAN bus integration.

Alt: Timeline overview of OBD2 history and standardization milestones.

Alt: OBD3 future concept with remote diagnostics, emissions testing, cloud, and IoT.

The Future of OBD2: Trends and Challenges

OBD2 is firmly established, but its evolution is ongoing. Several key trends are shaping its future:

While legislated OBD2 was initially focused on emissions control and testing, this presents a challenge for electric vehicles. Electric vehicles are not obligated to support OBD2 in the traditional sense. Consequently, most modern EVs do not support standard OBD2 requests. Instead, they often utilize OEM-specific UDS (Unified Diagnostic Services) communication protocols. This OEM-specific approach can make data extraction from EVs difficult, except in cases where reverse engineering efforts have uncovered the communication rules. However, initiatives are emerging to bridge this gap, as seen in case studies for electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Recognizing the limitations of current OBD2 implementations regarding data richness and lower-layer protocols, advancements like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These protocols aim to modernize OBD communication by building upon the UDS protocol. For a deeper understanding, refer to our introduction to UDS.

In our increasingly connected world, traditional OBD2 testing methods can seem inefficient. Manual emission control checks are time-consuming and costly. OBD3 proposes a solution: integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder (similar to those used for bridge tolls) to every car. This would enable the car’s vehicle identification number (VIN) and DTCs to be transmitted wirelessly via WiFi to a central server for automated checks. Devices like the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger already facilitate CAN or OBD2 data transfer over WiFi/cellular networks.

While OBD3 offers cost savings and convenience, it also raises political concerns related to surveillance and data privacy.

The original intent of OBD2 was for stationary emission controls. However, third-party applications are now extensively using OBD2 for real-time data generation via OBD2 dongles, CAN loggers and similar devices. However, the German car industry is seeking to restrict this access, as highlighted in a report:

“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 during driving, centralizing data collection with manufacturers. This would give manufacturers control over the valuable ‘automotive big data’. While security concerns, such as mitigating the risk of car hacking, are cited as justification, many view this as a commercially motivated move (source). The future of OBD2 third-party services remains uncertain, and this trend could potentially disrupt the market.

Alt: OBD2 connector removed from electric vehicle, symbolizing restricted data access.

Enhance Your CAN Expertise with Our ‘Ultimate CAN Guide’

Ready to become a CAN bus expert?

Access our comprehensive collection of 12 ‘simple intros’ in a single 160+ page PDF:

Download now

OBD2 Standards and the CAN Bus

On-board diagnostics, OBD2, operates as a higher-layer protocol, like a language spoken over a communication network. CAN bus serves as the communication method, analogous to a telephone line. This framework places OBD2 alongside other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

The OBD2 standards meticulously define aspects like the OBD2 connector, lower-layer protocols, OBD2 parameter IDs (PIDs), and more. These standards can be visualized using the 7-layer OSI model. The following sections will concentrate on the most crucial standards.

Observing the OSI model overview, you’ll notice that both SAE and ISO standards cover multiple layers. This reflects the standards established for OBD in the USA (SAE) and EU (ISO). Notably, several standards are technically very similar, for instance, SAE J1979 and ISO 15031-5, as well as SAE J1962 and ISO 15031-3.

Alt: OSI 7-layer model illustrating OBD2 and CAN bus standards ISO 15765 and ISO 11898.

Alt: OBD2 connector pinout diagram, female Type A Data Link Connector (DLC).

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector is the gateway to accessing your car’s diagnostic data. It’s formally specified in the SAE J1962 / ISO 15031-3 standard.

The illustration provides an example of a Type A OBD2 pin connector, also known as the Data Link Connector (DLC). Key points to remember about the OBD2 connector:

It’s typically located near the steering wheel, although it may be concealed.
Pin 16 provides battery power, often even when the ignition is switched off.
The specific OBD2 pinout configuration depends on the communication protocol used.
CAN bus is the most prevalent lower-layer protocol, which means pins 6 (CAN-H) and 14 (CAN-L) are usually connected.

OBD2 Connector Types: A vs. B

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

As shown in the illustration, both types share similar OBD2 pinouts but differ in power supply outputs: 12V for Type A and 24V for Type B. Baud rates often differ too, with cars typically using 500K, while heavy-duty vehicles often use 250K (with increasing support for 500K).

Type B OBD2 connectors have a distinguishing interrupted groove in the middle, allowing for physical differentiation. A Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, whereas a Type A adapter will not fit into a Type B socket.

Alt: OBD2 Connector Type A vs B comparison, highlighting voltage and vehicle type differences.

Alt: Diagram illustrating the relationship between OBD2 and CAN bus according to ISO 15765.

OBD2 and CAN Bus Protocol: ISO 15765-4 Deep Dive

Since 2008, CAN bus has become the mandated lower-layer protocol for OBD2 in all vehicles sold in the US, as per 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). It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:

The 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 length is limited to 5 meters.

OBD2 CAN Identifiers: 11-bit and 29-bit

All OBD2 communication relies on request/response message exchanges.

In most passenger cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs to check if they have data to report for the requested parameter (as per ISO 15765-4). In contrast, CAN IDs in the range 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests directed to specific ECUs (less commonly used).

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

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

Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1. Vehicle responses will use CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is sometimes represented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which the J1939-71 standard marks as ‘Reserved for ISO 15765-2’.

Alt: OBD2 protocol request and response frame structure with PID and data parameters.

Alt: Comparison of OBD2 standard CAN bus vs. proprietary OEM-specific CAN bus data.

OBD2 vs. Proprietary CAN Protocols: A Key Distinction

It’s crucial to understand that your car’s electronic control units (ECUs) operate independently of OBD2 for their core functions. Original equipment manufacturers (OEMs) implement their own proprietary CAN protocols for vehicle control and internal communication. These proprietary CAN protocols are often specific to the vehicle brand, model, and year. Generally, this OEM-specific data is inaccessible to external parties without reverse engineering (more on reverse engineering).

Connecting a CAN bus data logger to your car’s OBD2 connector might reveal OEM-specific CAN data, typically broadcast at high rates (1000-2000 frames/second). However, in many newer vehicles, a ‘gateway’ system restricts access to this OEM CAN data, allowing only OBD2 communication through the OBD2 connector.

In essence, think of OBD2 as a supplementary higher-layer protocol running alongside the OEM-specific protocol. It’s an added diagnostic layer, not the foundation of the vehicle’s internal communication network.

Bit-rate and ID Validation in OBD2 CAN Protocol

As outlined, OBD2 CAN protocol can operate with two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), creating four potential combinations. Modern cars commonly use 500K with 11-bit IDs. However, external diagnostic tools should systematically verify these parameters.

ISO 15765-4 provides recommendations for a systematic initialization sequence to determine the correct combination. This method leverages the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (refer to the OBD2 PID section for details). Incorrect bit-rate transmission will result in CAN error frames, aiding in bit-rate identification.

Newer versions of ISO 15765-4 acknowledge that vehicles may 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) compared to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).

To differentiate between OBDonEDS and OBDonUDS protocols, diagnostic tools may 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-electric vehicles today, while WWH-OBD is mainly used in EU trucks and buses.

Alt: Flowchart illustrating OBD2 bit-rate and CAN ID validation process according to ISO 15765-4.

Alt: OBD2 standards diagram showing five protocols: CAN (ISO 15765), KWP2000, SAE J1850, ISO 9141.

Five Lower-Layer OBD2 Protocols (Beyond CAN)

While CAN bus (ISO 15765) is dominant for OBD2 today, particularly in vehicles manufactured after 2008, older vehicles might utilize one of four other lower-layer protocols. Understanding these legacy protocols and their pinouts can be helpful when working with older cars.

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, especially in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian cars in the 2000-2004 period.
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: Transporting OBD2 Messages over CAN (ISO 15765-2)

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

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

Alt: ISO 15765-2 ISO-TP OBD2 frame types diagram: Single Frame, First Frame, Consecutive Frame, Flow Control Frame.

Decoding the OBD2 Diagnostic Message (SAE J1979, ISO 15031-5)

To understand OBD2 communication over CAN at a deeper level, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message comprises a CAN identifier, a data length indicator (PCI field), and the data payload. The data payload itself is structured into Mode, parameter ID (PID), and data bytes.

Alt: OBD2 message structure breakdown, explaining Mode, PID, and Data Bytes within a CAN frame.

OBD2 Request/Response Example: Vehicle Speed

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

An external diagnostic tool sends a request message to the car with CAN ID 0x7DF and a 2-byte payload: Mode 0x01 and PID 0x0D. The car responds with a message on CAN ID 0x7E8 and a 3-byte payload. The vehicle speed value is contained in the 4th byte (0x32), which translates to 50 in decimal form.

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

Let’s now explore OBD2 modes and PIDs in more detail.

Alt: OBD2 request/response example with CAN IDs 7DF (request) and 7E8 (response) for vehicle speed.

Alt: OBD2 PID 0D example, illustrating the request and response structure for Vehicle Speed.

Alt: OBD2 services/modes diagram, listing 10 modes including current data, freeze frame, and clear DTCs.

The 10 OBD2 Services (Modes)

OBD2 defines 10 diagnostic services, often referred to as modes. Mode 0x01 is used to retrieve current, real-time data, while other modes are designed for accessing and clearing diagnostic trouble codes (DTCs) or retrieving freeze frame data.

Vehicles are not required to support all 10 OBD2 modes. Furthermore, manufacturers may implement OEM-specific modes beyond the 10 standardized modes.

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) Explained

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

For instance, mode 0x01 contains approximately 200 standardized PIDs providing real-time data on parameters like speed, RPM, and fuel level. However, a vehicle does not necessarily support all PIDs within a given mode. In practice, most vehicles only support a subset of the available PIDs.

One PID holds special significance: 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 indicates its support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental test for OBD2 compatibility. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs in blocks of 32.

Alt: OBD2 protocol request and response frames illustrating PID data parameters.

Alt: Screenshot of an OBD2 PID overview tool for service 01, displaying PID descriptions.

Practical Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 contain scaling information for standard OBD2 PIDs. This information is crucial for converting raw data bytes into meaningful physical values (as discussed in our CAN bus introduction).

For quick PID lookups in mode 0x01, 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

Logging and Decoding OBD2 CAN Data: A Practical Guide

This section demonstrates a practical approach to logging OBD2 data using the CANedge CAN bus data logger.

The CANedge’s configurable CAN frame transmission capability makes it suitable for OBD2 data logging. Connecting the CANedge to your vehicle is straightforward using our OBD2-DB9 adapter cable.

Alt: OBD2 PID data logger setup diagram, showing request and response CAN IDs 7df and 7e8.

Alt: Screenshot showing successful CAN frame transmission at 500K bit rate for OBD2 testing.

Alt: asammdf software screenshot displaying OBD2 supported PIDs test responses.

Step #1: Bit-rate, ID, and Supported PID Validation

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

Bit-rate Test: Transmit a CAN frame at 500K and verify successful transmission. If unsuccessful, try 250K.
Bit-rate Confirmation: Use the identified bit-rate for all subsequent communication.
Supported PIDs Request: Send multiple ‘Supported PIDs’ requests and analyze the responses.
CAN ID Determination: Based on the response IDs, determine whether 11-bit or 29-bit CAN IDs are in use.
Supported PID Identification: Analyze the response data to identify the supported PIDs.

We provide pre-configured settings to simplify these initial tests.

Most non-EV cars manufactured from 2008 onwards support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

The asammdf GUI screenshot illustrates a common scenario where multiple ECUs respond to a single OBD request. This occurs because we use the functional address request ID 0x7DF, which queries all ECUs for responses. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, multiple responses are often received for this PID. As you progress to subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. Notice that the ECM ECU (0x7E8) in this example supports all PIDs supported by other ECUs. Therefore, to reduce bus load, subsequent communication could be directed specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configuring OBD2 PID Requests for Data Logging

Having identified the supported OBD2 PIDs for your vehicle, along with the correct bit-rate and CAN IDs, the next step is to configure your transmit list with the PIDs you wish to log.

Consider these factors when configuring your OBD2 PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize redundant responses from multiple ECUs.
Request Spacing: Introduce a delay of 300-500 ms between each OBD2 request to prevent overwhelming the ECUs and ensure reliable responses.
Battery Drain Management: Implement triggers to halt transmission when the vehicle is inactive, preventing unnecessary ECU wake-up and battery drain.
Data Filtering: Apply filters to record only OBD2 responses if your vehicle also broadcasts OEM-specific CAN data, focusing your logs on the relevant diagnostic information.

Once configured with these considerations, your CANedge device is ready to log raw OBD2 data efficiently!

Alt: Example of a CANedge OBD2 PID request transmit list configuration.

Alt: asammdf software displaying decoded and visualized OBD2 data plot using a CAN bus DBC file.

Step #3: DBC Decoding of Raw OBD2 Data for Analysis

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

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

Decoding OBD2 data is more complex than standard CAN signal decoding. This is 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 use the CAN ID, OBD2 mode, and OBD2 PID together to identify the specific signal. This technique, known as ‘extended multiplexing‘, can be implemented using DBC files to properly interpret and separate the different OBD2 signals within the data stream.

CANedge: Your Dedicated OBD2 Data Logger

The CANedge provides an easy-to-use solution for recording OBD2 data directly to an 8-32 GB SD card. Simply connect it to your car or truck to begin logging. Utilize free software and APIs along with our OBD2 DBC file for data analysis and decoding.

OBD2 logger intro
CANedge product details

OBD2 Multi-Frame Communication Examples (ISO-TP)

While many OBD2 interactions involve single-frame messages, some operations, like retrieving VIN or DTCs, require multi-frame communication using ISO-TP (ISO 15765-2). These examples illustrate multi-frame OBD2 communication.

Multi-frame OBD2 communication necessitates 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 requires CAN software and API tools that support ISO-TP, such as the CANedge MF4 decoders.

Alt: OBD2 multi-frame request message example for Vehicle Identification Number (VIN).

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

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

The diagnostic tool initiates a Single Frame request with 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 (refer to ISO 15031-5 / SAE J1979 for detailed specifications). The subsequent 17 bytes constitute the VIN, which can be converted from HEX to ASCII using methods discussed in our UDS introduction.

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

External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU is expected to respond with data for the supported PIDs (omitting data for unsupported PIDs) potentially across multiple frames using ISO-TP if necessary.

This technique enhances data collection efficiency and frequency. However, the signal encoding becomes specific to the request method, making generic OBD2 DBC files less applicable. We generally advise against this method in practice. Below is an example trace of a multi-PID request and response:

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

Decoding these responses using generic DBC files is challenging. Therefore, we do not recommend this approach for practical data logging unless you are using a tool with specific built-in support for multi-PID requests. Effectively, you would be dealing with a complex case of extended multiplexing. Furthermore, if you send multiple multi-PID requests, it becomes very difficult to uniquely identify the messages from each other using only DBC manipulations.

Workarounds might involve custom scripts and recording the transmit messages from your testing tool. The script could then interpret the response message in conjunction with the corresponding request message. However, such solutions are difficult to scale for broader applications.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval

OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’, is used to request emissions-related DTCs. No PID is included in the request. The targeted ECU(s) respond with the number of stored DTCs (which can be 0 if no DTCs are present). Each DTC is represented by 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored.

The 2-byte DTC value is structured as defined in ISO 15031-5/ISO 15031-6. The first 2 bits indicate the ‘category’, and the remaining 14 bits form a 4-digit hexadecimal code, as shown in the diagram. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.

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

Alt: OBD2 DTC decoding example showing category and code interpretation.

Real-World Applications of OBD2 CAN Data Logging

OBD2 data from cars and light trucks has numerous practical applications:

Alt: OBD2 data logger connected to a car, illustrating on-board diagnostics applications.

Car Data Logging Applications

OBD2 data logging in cars can be utilized to reduce fuel consumption, enhance driving habits, test prototype components, and for insurance-related purposes.

Explore OBD2 loggers

Alt: OBD2 real-time streaming diagnostics via USB interface.

Real-time Car Diagnostics

OBD2 interfaces facilitate real-time streaming of human-readable OBD2 data, enabling efficient vehicle diagnostics and troubleshooting.

Discover OBD2 streaming interfaces

Alt: OBD2 data logger for predictive maintenance and telematics applications.

Predictive Maintenance Applications

Cars and light trucks equipped with IoT OBD2 loggers can be remotely monitored in the cloud to predict potential breakdowns and enable proactive maintenance.

Learn about predictive maintenance with OBD2

Alt: CAN bus data logger as a vehicle black box for insurance and warranty purposes.

Vehicle Black Box Logging

An OBD2 logger can serve as a ‘black box’ for vehicles or equipment, providing valuable data for accident investigations, dispute resolution, and detailed diagnostics.

Explore CAN bus black box loggers

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

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

Ready to log or stream OBD2 data?

Get your OBD2 data logger today!

Purchase OBD2 Data Loggers
Contact us for support

Recommended Resources

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN