Understanding OBD2 CAN: Your Car's Diagnostic Network Explained

As a car owner or automotive professional, you’ve likely heard of OBD2. But have you ever wondered how it actually works, especially in relation to the Controller Area Network (CAN bus) within your vehicle? This guide provides a comprehensive yet accessible explanation of Obd2 Can, delving into its workings, standards, and practical applications.

In this article, we’ll explore the critical role of OBD2 CAN in modern vehicle diagnostics and data communication. We’ll break down the complexities into easy-to-understand sections, covering everything from the OBD2 connector and CAN bus integration to data logging and troubleshooting. Whether you’re a seasoned mechanic or a curious car enthusiast, this guide will enhance your understanding of OBD2 CAN and its significance in today’s automotive landscape.

What is OBD2 and its Relation to CAN Bus?

OBD2, or On-Board Diagnostics version 2, is essentially your car’s internal health monitoring system. It’s a standardized protocol that allows access to a wealth of diagnostic information and real-time data from your vehicle. This access is crucial for identifying issues, monitoring performance, and ensuring your car runs efficiently. But how is this data accessed and transmitted? The answer lies in OBD2 CAN.

Think of the malfunction indicator light (MIL), often called the “check engine light,” on your dashboard. When this light illuminates, it’s a signal from your car’s OBD2 system indicating a potential problem. To diagnose this issue, a mechanic uses an OBD2 scanner. This scanner connects to the 16-pin OBD2 connector, usually located near the steering wheel. The key here is that in most modern vehicles, the communication between the scanner and the car’s various electronic control units (ECUs) happens over the CAN bus network using the OBD2 protocol – hence, OBD2 CAN. The scanner sends OBD2 requests via CAN, and the car responds with OBD2 responses, also via CAN, containing data like speed, engine temperature, or Diagnostic Trouble Codes (DTCs). This streamlined communication via OBD2 CAN makes troubleshooting faster and more efficient.

Understanding OBD2: On-Board Diagnostics and the Malfunction Indicator Light (MIL)

Does Your Car Use OBD2 CAN?

The likelihood is very high that your car supports OBD2 CAN, especially if it’s a newer, non-electric vehicle. CAN bus is the dominant communication network in modern cars, and OBD2 often operates on top of it. For older vehicles, even if they have a 16-pin OBD2 connector, it’s not guaranteed to be OBD2 compliant, and even less guaranteed to be OBD2 CAN. Compliance depends on where and when the vehicle was originally purchased:

OBD2 Compliance Guide: Determining if Your Car Supports OBD2 CAN in EU & US Markets

A Brief History of OBD2 and the Rise of OBD2 CAN

OBD2’s origins trace back to California, where the California Air Resources Board (CARB) mandated OBD systems in all new cars from 1991 onwards for emission control. The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBD2, particularly the DTCs and the OBD connector itself (SAE J1962). This standardization paved the way for the widespread adoption of OBD2 CAN.

The OBD2 standard was implemented progressively:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: The EU required OBD2 for gasoline cars.
2003: OBD2 (EOBD) became mandatory for diesel cars in the EU.
2005: OBD2 was required in the US for medium-duty vehicles.
2008: A pivotal year for OBD2 CAN, as US cars were mandated to use ISO 15765-4 (CAN) as the foundation for OBD2 communication. This solidified OBD2 CAN as the primary communication method.
2010: OBD2 became mandatory for heavy-duty vehicles in the US.

This timeline highlights the increasing importance of OBD2 and the eventual dominance of OBD2 CAN as the standard communication protocol for vehicle diagnostics.

OBD2 History: From Emission Control to OBD2 CAN and Data Access

OBD2 History Timeline: Key Milestones in On-Board Diagnostics and OBD2 CAN Evolution

The Future of OBD: OBD3, Remote Diagnostics, and the Continued Relevance of OBD2 CAN

The Future of OBD2: The Enduring Role of OBD2 CAN

While OBD2 is firmly established, its future is evolving, particularly in the context of electric vehicles and increasing data demands. However, OBD2 CAN is likely to remain a relevant communication method for years to come, even as the automotive landscape changes.

Originally designed for emissions control, legislated OBD2 isn’t strictly required for electric vehicles. Interestingly, many modern EVs don’t support standard OBD2 requests, opting instead for OEM-specific UDS communication. This often makes accessing EV data challenging without reverse engineering efforts. However, even with this shift in EVs, OBD2 CAN remains crucial for internal combustion engine vehicles, which still dominate the roads.

Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging to enhance OBD communication. These protocols aim to improve data richness and streamline communication by utilizing the UDS protocol on top of CAN. Despite these advancements, the fundamental principles of OBD2 CAN communication remain relevant.

The concept of OBD3, which envisions adding telematics to vehicles for remote emission checks, further emphasizes the importance of data communication. OBD3 proposes using a radio transponder to transmit VIN and DTCs via WiFi to a central server. This concept builds upon the existing data communication infrastructure often reliant on OBD2 CAN. Devices like the CANedge2 WiFi CAN logger and CANedge3 3G/4G CAN logger already facilitate CAN and OBD2 data transfer over wireless networks, showcasing the existing capabilities built upon OBD2 CAN technology.

However, the increasing use of OBD2 for third-party data access has raised concerns within the automotive industry. Manufacturers are exploring ways to control access to vehicle data, potentially limiting third-party access through the OBD2 interface. Despite these potential changes, the underlying communication layer, often OBD2 CAN, will still be essential for internal vehicle communication and manufacturer-authorized diagnostics.

Even with potential shifts in data access and the rise of electric vehicles, OBD2 CAN remains a cornerstone of automotive diagnostics and data communication for a vast majority of vehicles on the road today and in the foreseeable future.

OBD2 Future Challenges: Electric Vehicles and Data Access Limitations While OBD2 CAN Remains Relevant for ICE Vehicles

Enhance Your OBD2 CAN Expertise with our ‘Ultimate CAN Guide’

Ready to deepen your understanding of CAN bus and OBD2 CAN?

Download our comprehensive 160+ page PDF guide, featuring 12 ‘simple intros’ to CAN bus and related technologies.

Download now

OBD2 Standards and the Role of CAN Bus

OBD2 operates as a higher-layer protocol, essentially a language for diagnostics. CAN bus, on the other hand, is the communication method, the physical network over which this diagnostic language is spoken. This relationship is fundamental to OBD2 CAN. OBD2 is comparable to other higher-layer protocols built on CAN, like J1939, CANopen, and NMEA 2000.

OBD2 standards comprehensively define various aspects, including the OBD2 connector, the lower-layer communication protocols (crucially including CAN bus), and OBD2 Parameter IDs (PIDs), among other things. These standards ensure interoperability and consistent OBD2 CAN communication across different vehicle makes and models.

The OBD2 standards can be visualized within the 7-layer OSI model, illustrating how OBD2 builds upon the foundation of CAN bus. It’s worth noting that both SAE (US standards) and ISO (EU standards) contribute to OBD2 specifications. Many standards are technically equivalent, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3, reflecting the global harmonization efforts in OBD2 CAN and related technologies.

OBD2 and CAN Bus in the OSI Model: Understanding ISO 15765 and ISO 11898 Standards for OBD2 CAN

OBD2 Connector Pinout: SAE J1962 Type A Connector Used in OBD2 CAN Interfaces

The OBD2 Connector: Your Gateway to OBD2 CAN Data [SAE J1962]

The 16-pin OBD2 connector, standardized under SAE J1962 / ISO 15031-3, is the physical interface that enables you to tap into your car’s OBD2 CAN data. It’s your direct access point to the diagnostic network.

The illustration shows a typical Type A OBD2 pin connector, also known as the Data Link Connector (DLC). Key features of this connector in the context of OBD2 CAN include:

Location: Usually near the steering wheel, though sometimes hidden behind a panel.
Pin 16: Provides battery power, often even when the ignition is off, allowing continuous power for OBD2 CAN communication and devices.
Pinout Variations: The OBD2 pinout is not fixed; it depends on the specific communication protocol used.
CAN bus Pins: For OBD2 CAN communication, pins 6 (CAN-High) and 14 (CAN-Low) are crucial as they are typically connected to the CAN bus network.

Understanding the OBD2 connector pinout is essential for correctly interfacing with the OBD2 CAN network in your vehicle.

OBD2 Connector Types: Type A vs. Type B in OBD2 CAN Systems

You might encounter both Type A and Type B OBD2 connectors. Type A is standard in most cars, while Type B is more common in medium and heavy-duty vehicles. Both types can support OBD2 CAN, but there are key differences.

While both types share a similar OBD2 pinout structure, they differ primarily in power supply outputs: 12V for Type A (cars) and 24V for Type B (trucks). Baud rates can also vary; cars typically use 500K, while heavy-duty vehicles often use 250K (though 500K is becoming more common). These variations are important to consider when working with OBD2 CAN across different vehicle types.

Visually, Type B connectors have an interrupted groove in the middle, distinguishing them from Type A. A Type B OBD2 adapter cable is generally compatible with both Type A and Type B sockets, while a Type A adapter will only fit into a Type A socket. This physical compatibility is relevant when selecting tools and adapters for OBD2 CAN applications.

OBD2 Connector Types A and B: Distinctions in SAE J1962 Standards and Implications for OBD2 CAN Connectivity

OBD2 vs CAN Bus: Illustrating the Relationship and ISO 15765 Standards in OBD2 CAN Systems

OBD2 and CAN Bus: Diving Deeper into ISO 15765-4

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US cars, as defined by ISO 15765. This standard is the cornerstone of modern OBD2 CAN communication.

ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies a set of constraints applied to the CAN standard (ISO 11898) for diagnostic purposes. It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers of the OSI model, specifically for OBD2 CAN.

Key specifications of ISO 15765-4 for OBD2 CAN include:

Bit-rate: CAN bus bit-rate must be either 250K or 500K.
CAN IDs: Supports both 11-bit and 29-bit CAN identifiers.
Specific CAN IDs: Defines specific CAN IDs for OBD requests and responses within the OBD2 CAN framework.
Data Length: Diagnostic CAN frames must have a data length of 8 bytes.
Cable Length: The OBD2 adapter cable is limited to a maximum of 5 meters.

These specifications ensure reliable and consistent OBD2 CAN communication for vehicle diagnostics.

OBD2 CAN Identifiers: 11-bit and 29-bit Addressing

All OBD2 CAN communication is based on request/response message pairs.

In most cars, 11-bit CAN IDs are used for OBD2 CAN. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs for data on a requested parameter (as per ISO 15765-4). ‘Physical Addressing’ requests, using CAN IDs 0x7E0-0x7E7, can target specific ECUs, but are less common in typical OBD2 CAN usage.

ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most frequent response ID is 0x7E8 (Engine Control Module, ECM), and to a lesser extent 0x7E9 (Transmission Control Module, TCM). These IDs are fundamental to understanding OBD2 CAN message flow.

In some vehicles, especially vans and medium/heavy-duty vehicles, OBD2 CAN communication might use extended 29-bit CAN identifiers instead of 11-bit IDs.

Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1. Responses use CAN IDs from 0x18DAF100 to 0x18DAF1FF, typically 18DAF110 and 18DAF11E. The response ID is sometimes presented in the J1939 PGN format as 0xDA00 (55808), which in the J1939-71 standard is designated as ‘Reserved for ISO 15765-2’. Understanding these different addressing schemes is crucial for working with OBD2 CAN in diverse vehicle applications.

OBD2 Request and Response Frames: Understanding PID Data Parameters in OBD2 CAN Communication

OBD2 vs Proprietary CAN Bus: Differentiating Standard OBD2 CAN from OEM-Specific CAN Data

OBD2 CAN vs. Proprietary CAN Protocols

It’s crucial to understand that your car’s ECUs primarily function using OEM-specific CAN protocols, not OBD2. OBD2 is an additional protocol layered on top of the existing vehicle communication network, often CAN bus. These OEM protocols are often unique to the vehicle brand, model, and year, and are generally not publicly documented. Unless you can reverse engineer them, this OEM-specific CAN data is typically inaccessible to those outside the manufacturer.

When you connect a CAN bus data logger to your car’s OBD2 connector, you might observe OEM-specific CAN data alongside OBD2 CAN traffic, typically broadcast at high rates (1000-2000 frames/second). However, many newer vehicles employ a ‘gateway’ that restricts access to this OEM CAN data through the OBD2 port, allowing only OBD2 CAN communication.

In essence, think of OBD2 as a parallel, higher-level protocol existing alongside the OEM’s proprietary CAN communication. For diagnostic and emission-related data, OBD2 CAN provides a standardized access point, while the deeper, more comprehensive vehicle control and data remain within the OEM’s proprietary CAN networks.

Bit-rate and ID Validation in OBD2 CAN

As discussed, OBD2 CAN can operate at two bit-rates (250K, 500K) and with two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern cars commonly use 500K and 11-bit IDs, but diagnostic tools should systematically verify these parameters.

ISO 15765-4 recommends a systematic initialization sequence to determine the correct combination. This process leverages the fact that OBD2-compliant vehicles must respond to a mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit-rates will cause CAN error frames. This validation process is vital for establishing reliable OBD2 CAN communication.

Newer versions of ISO 15765-4 account for vehicles supporting OBD communication via OBDonUDS instead of 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 test for OBDonEDS vs. OBDonUDS, diagnostic tools can send 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 (aka 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. Understanding these protocol variations is important for advanced OBD2 CAN diagnostics.

OBD2 Bit-rate and CAN ID Validation Flowchart: Following ISO 15765-4 for Reliable OBD2 CAN Setup

OBD2 Lower-Layer Protocols: CAN (ISO 15765) and Alternatives in OBD2 and OBD2 CAN History

Five Lower-Layer OBD2 Protocols, Including OBD2 CAN

While CAN (ISO 15765) is now the dominant lower-layer protocol for OBD2, especially for OBD2 CAN, older vehicles (pre-2008) may use other protocols. Knowing these alternatives can be helpful when dealing with legacy systems. Pinouts can sometimes indicate the protocol in use.

The five lower-layer protocols used with OBD2 include:

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now the most common protocol for OBD2 CAN.
ISO14230-4 (KWP2000): Keyword Protocol 2000, used in 2003+ cars, particularly in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian cars from 2000-2004.
SAE J1850 (VPW): Mostly found in older GM vehicles.
SAE J1850 (PWM): Predominantly used in older Ford vehicles.

Although CAN is now dominant for OBD2 CAN, understanding these historical protocols provides valuable context, especially when working with older vehicles.

Transporting OBD2 Messages via ISO-TP: Ensuring Reliable OBD2 CAN Data Transfer [ISO 15765-2]

All OBD2 data, including OBD2 CAN communication, is transported using the ISO-TP (ISO 15765-2) transport protocol over CAN. This protocol is essential because it allows for the transmission of data payloads larger than the 8-byte limit of a standard CAN frame. This capability is necessary in OBD2 CAN for transmitting information like the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often exceed 8 bytes. ISO 15765-2 provides mechanisms for segmentation, flow control, and reassembly of these larger messages within the OBD2 CAN framework. For a more in-depth understanding, refer to introductions to UDS (Unified Diagnostic Services).

However, much of the time, OBD2 CAN data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF) format. In a Single Frame, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for the actual OBD2 communication. This efficient use of CAN frames is typical for many OBD2 CAN data requests and responses.

ISO 15765-2 Frame Types: Single Frame, First Frame, Consecutive Frame, and Flow Control in OBD2 CAN Communication

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

To fully grasp OBD2 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 itself is further structured into Mode, Parameter ID (PID), and data bytes. Understanding this structure is key to interpreting OBD2 CAN data.

OBD2 Message Structure Breakdown: Mode, PID, and Data Bytes in OBD2 CAN Frames

Example of OBD2 CAN Request and Response

Before dissecting each part of the OBD2 CAN message, let’s look at a practical example: requesting ‘Vehicle Speed’.

To get the vehicle speed, an external tool sends a request message over OBD2 CAN with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds via OBD2 CAN with CAN ID 0x7E8 and 3 payload bytes. The vehicle speed value is contained in the 4th byte, 0x32 (which is 50 in decimal).

By consulting OBD2 PID documentation for PID 0x0D, we find the decoding rules. In this case, 0x32 translates to a physical value of 50 km/h. This simple example illustrates the request-response mechanism of OBD2 CAN and how PIDs are used to access specific data.

OBD2 CAN Request and Response Example: Requesting Vehicle Speed with CAN IDs 7DF and 7E8

OBD2 PID 0D: Decoding Vehicle Speed Data in OBD2 CAN Communication

OBD2 Services (Modes): Diagnostic Services, Current Data, Freeze Frame, and DTC Clearing in OBD2 CAN

The 10 OBD2 Services (Modes) in OBD2 CAN

There are 10 standardized OBD2 diagnostic services, also known as modes. Mode 0x01 is used to access current real-time data, while other modes are for retrieving and clearing Diagnostic Trouble Codes (DTCs) or accessing freeze frame data. These modes form the foundation of OBD2 CAN diagnostic capabilities.

It’s important to note that vehicles are not required to support all 10 OBD2 modes. They may also support OEM-specific modes beyond the standardized set. In OBD2 CAN messages, the mode is indicated in the second byte. In a request message, the mode is included directly (e.g., 0x01). In a response message, 0x40 is added to the mode value (e.g., 0x41). This mode identification is crucial for interpreting OBD2 CAN messages.

OBD2 Parameter IDs (PIDs) within OBD2 CAN

Within each OBD2 mode, there are Parameter IDs (PIDs). For example, mode 0x01 contains approximately 200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles typically support only a subset of these PIDs. The availability of specific PIDs is vehicle-dependent in OBD2 CAN systems.

One PID is particularly significant for OBD2 CAN compatibility testing: mode 0x01 PID 0x00. If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. When queried with this PID, the ECU responds, indicating its support for PIDs 0x01-0x20. Thus, PID 0x00 is a fundamental tool for verifying OBD2 CAN compatibility. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to check support for subsequent ranges of mode 0x01 PIDs.

OBD2 Request and Response Frames: PID Data Parameters in OBD2 CAN Communication

OBD2 PID Overview Tool: Service 01 and PID Lookup for OBD2 CAN Diagnostics

Tip: OBD2 PID Overview Tool for OBD2 CAN Data

SAE J1979 and ISO 15031-5 appendices contain scaling information for standard OBD2 PIDs, enabling the conversion of raw data to physical values. This decoding process is essential for working with OBD2 CAN data.

For quick lookup of mode 0x01 PIDs, consider using an OBD2 PID overview tool. This tool can assist in constructing OBD2 request frames and dynamically decoding OBD2 CAN responses.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 CAN Data

Let’s walk through a practical example of logging OBD2 CAN data using a CANedge CAN bus data logger. The CANedge is configurable to transmit custom CAN frames, making it suitable for OBD2 CAN logging and data acquisition.

Connecting the CANedge to your vehicle is straightforward using an OBD2-DB9 adapter cable. Once connected, you can configure the device to log and transmit OBD2 CAN data.

OBD2 PID Data Logger: Requesting PIDs with CAN IDs 7DF and 7E8 in OBD2 CAN Logging

Reviewing Supported PIDs in asammdf for OBD2 CAN Data

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

As previously discussed, ISO 15765-4 outlines how to determine the correct bit-rate and CAN IDs for a vehicle’s OBD2 CAN implementation. The CANedge can be used to perform these tests (refer to the CANedge Intro for detailed instructions):

Bit-rate Test: Send a CAN frame at 500K and check for successful transmission. If unsuccessful, try 250K.
Bit-rate Confirmation: Use the identified bit-rate for subsequent OBD2 CAN communication.
Supported PIDs Discovery: Send ‘Supported PIDs’ requests and analyze the responses to identify supported PIDs in OBD2 CAN.
CAN ID Type Determination: Based on response IDs, determine if 11-bit or 29-bit CAN IDs are used for OBD2 CAN.
PID Support Verification: Analyze response data to determine the range of supported PIDs in OBD2 CAN.

Pre-configured settings are available for these tests, simplifying the process. Most post-2008 non-EV cars typically support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol for OBD2 CAN.

As illustrated in the asammdf GUI screenshot, multiple responses to a single OBD request are common due to the use of the 0x7DF request ID, which queries all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are often observed. Subsequent ‘Supported PIDs’ requests typically elicit fewer responses as fewer ECUs support the extended PID ranges. Note that the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, suggesting that bus load could be reduced by directing subsequent requests specifically to the ECM using ‘Physical Addressing’ CAN ID 0x7E0 for optimized OBD2 CAN communication.

Step #2: Configure OBD2 PID Requests for Efficient OBD2 CAN Logging

Once you’ve identified the supported OBD2 PIDs, bit-rate, and CAN IDs for your vehicle’s OBD2 CAN system, the next step is to configure your data logger to request the PIDs of interest.

Consider these factors when configuring your OBD2 CAN data logger:

CAN ID Addressing: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize redundant responses and bus load in OBD2 CAN.
Request Spacing: Introduce a delay of 300-500 ms between OBD2 requests to prevent overwhelming ECUs and ensure reliable responses in OBD2 CAN.
Power Management: Implement triggers to stop data transmission when the vehicle is inactive to conserve battery power and prevent ECU “wake-up” during OBD2 CAN logging.
Data Filtering: Apply filters to record only OBD2 responses if OEM-specific CAN data is also present, focusing your OBD2 CAN data capture.

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

Example CANedge OBD2 PID Request List for Efficient OBD2 CAN Data Acquisition

Visualizing Decoded OBD2 CAN Data in asammdf using a CAN bus DBC file

Step #3: DBC Decode Raw OBD2 CAN Data for Analysis

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

Decoding information is found in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, a free OBD2 DBC file is available, simplifying DBC decoding of raw OBD2 CAN data in most CAN bus software tools.

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

To solve this, you need to use the CAN ID, OBD2 mode, and OBD2 PID together to identify the signal. This multiplexing technique, known as ‘extended multiplexing‘, can be implemented in DBC files for efficient decoding of OBD2 CAN data.

CANedge: Your Reliable OBD2 CAN Data Logger

The CANedge is designed for easy recording of OBD2 CAN data directly to an 8-32 GB SD card. Simply connect it to your car or truck to start logging. Free software and APIs, along with an OBD2 DBC file, are available for data decoding and analysis.

OBD2 logger intro CANedge

OBD2 Multi-Frame Examples in OBD2 CAN: ISO-TP in Action

All OBD2 CAN data communication uses the ISO-TP transport protocol (ISO 15765-2). Most examples so far have focused on single-frame communication. This section provides examples of multi-frame communication in OBD2 CAN.

Multi-frame OBD2 CAN communication requires flow control frames. A common approach is to transmit a static flow control frame approximately 50 ms after the initial request frame. The CANedge configuration example illustrates this technique.

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

OBD2 Multi-Frame Request Message: Vehicle Identification Number (VIN) Request in OBD2 CAN

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

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more. To retrieve the VIN using OBD2 CAN requests, you use mode 0x09 and PID 0x02.

The diagnostic tool initiates the process by sending a Single Frame request with the PCI field (0x02), request service identifier (0x09), and PID (0x02) over OBD2 CAN.

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 byte 0x01, representing 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, which can be converted from HEX to ASCII. This multi-frame exchange is a common example of ISO-TP in OBD2 CAN.

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

Diagnostic tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame over OBD2 CAN. The ECU should respond with data for the supported PIDs, omitting unsupported PIDs, and using multi-frame responses via ISO-TP if necessary.

This feature enhances data collection efficiency, but the signal encoding becomes specific to the request method. This makes using generic OBD2 DBC files challenging for such cases. This method is generally not recommended for practical use. Here’s an example trace:

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

Decoding these multi-PID responses using generic DBC files is complex. It’s generally not recommended for practical data logging unless you’re using tools specifically designed for this purpose. It involves extended multiplexing, where the DBC file must account for the specific payload position of each PID, making it difficult to generalize across vehicles with varying PID support. Handling multiple such multi-PID requests further complicates DBC management, making it challenging to uniquely identify messages.

Workarounds might involve custom scripts and recording request messages to interpret responses based on request-response pairs. However, these approaches are difficult to scale. For most OBD2 CAN data logging applications, simpler, single-PID requests are more practical.

Example 3: Retrieving OBD2 Diagnostic Trouble Codes (DTCs) via OBD2 CAN

You can use OBD2 mode 0x03 (‘Show stored Diagnostic Trouble Codes’) to request emissions-related DTCs via OBD2 CAN. No PID is included in the request. The target ECU(s) respond with the number of stored DTCs (possibly zero) and each DTC is represented by 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored in OBD2 CAN.

The 2-byte DTC value is structured according to ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’, and the remaining 14 bits form a 4-digit hexadecimal code. 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 6 stored DTCs in OBD2 CAN.

OBD2 DTC Decoding Example: DBC Interpretation of Diagnostic Trouble Codes in OBD2 CAN

OBD2 CAN Data Logging: Real-World Use Cases

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

Car Data Logging via OBD2 CAN

OBD2 CAN data logging in cars can be used to optimize fuel efficiency, improve driving habits, test prototype components, and for insurance telematics.

obd2 logger

Real-time Car Diagnostics with OBD2 CAN

OBD2 CAN interfaces enable real-time streaming of human-readable OBD2 data for diagnosing vehicle issues and monitoring performance.

obd2 streaming

Predictive Maintenance using OBD2 CAN Data

Cars and light trucks can be monitored via IoT OBD2 CAN loggers in the cloud for predictive maintenance, anticipating breakdowns and enabling proactive repairs.

predictive maintenance

Vehicle Black Box Recording via OBD2 CAN

An OBD2 CAN logger can serve as a vehicle ‘black box’, recording data for incident analysis, warranty validation, and diagnostic purposes.

can bus blackbox

Do you have an OBD2 CAN data logging application in mind? Contact us for expert guidance and solutions!

Explore our guides section for more introductory resources, or download the ‘Ultimate Guide’ PDF for in-depth knowledge.

Need to log or stream OBD2 CAN data?

Get your OBD2 CAN data logger today!

Buy now Contact us

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[

Understanding OBD2 CAN: Your Car’s Diagnostic Network Explained

In this article