OBD2 CAN Bus: Your Comprehensive Guide to On-Board Diagnostics

Looking for a detailed yet accessible guide to OBD2 and its connection to CAN bus?

This comprehensive article delves into the On-Board Diagnostic (OBD2) protocol, with a specific focus on its implementation over the CAN bus. We’ll explore the OBD2 connector, OBD2 Parameter IDs (PIDs), and how they interact with the CAN bus network in modern vehicles.

This is more than just an introduction; it’s a deep dive designed to equip you with practical knowledge. You’ll learn how to request and interpret OBD2 data transmitted over the CAN bus, understand key use cases for data logging, and gain valuable tips for working with Obd2 Can Bus systems.

Discover why this guide is rapidly becoming the go-to resource for understanding OBD2 CAN bus.

You can also enhance your learning with our introductory OBD2 video or download our detailed PDF guide on CAN bus for offline access.

Article Contents:

Author: Martin Falch (Updated January 2025)

Download as PDF

Understanding OBD2: The Basics of On-Board Diagnostics

OBD2, or On-Board Diagnostics version 2, is an essential system integrated into modern vehicles. It acts as the vehicle’s self-diagnostic center, standardized to allow access to crucial information like diagnostic trouble codes (DTCs) and real-time operational data via a universal OBD2 connector. The OBD2 protocol frequently utilizes the robust CAN bus for communication, making “OBD2 CAN bus” a fundamental concept in automotive diagnostics.

Have you ever noticed the check engine light illuminate on your dashboard? This is often the first indication that your car’s OBD2 system has detected a problem. When you take your vehicle to a mechanic, they use an OBD2 scanner to pinpoint the issue. This scanner connects to the OBD2 16-pin connector, typically located near the steering wheel.

The OBD2 scanner transmits ‘OBD2 requests’ through the CAN bus to the vehicle’s electronic control units (ECUs). In response, the car sends back ‘OBD2 responses,’ which can include vital data such as speed, fuel level, and Diagnostic Trouble Codes (DTCs). This communication over the OBD2 CAN bus allows for efficient troubleshooting and repair.

![alt text: OBD2 system displaying malfunction indicator light (MIL) and a mechanic using a scan tool to diagnose a vehicle.]

OBD2 Compatibility: Does Your Car Support It?

The question of OBD2 support is common, and the answer is generally: Yes, most likely!

Virtually all contemporary non-electric vehicles are equipped with OBD2 systems, and a significant majority 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 guarantee OBD2 compliance, especially in older models. Some vehicles may have the connector but not fully implement the OBD2 protocol. To confirm OBD2 compatibility, consider the vehicle’s origin and year of manufacture:

![alt text: Infographic showing OBD2 compliance by region and year for vehicles in EU and US, highlighting CAN bus adoption.]

A Look at OBD2 History and Evolution

The inception of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated OBD systems in all new vehicles from 1991 onwards for enhanced emission control.

The OBD2 standard was further developed and recommended by the Society of Automotive Engineers (SAE), leading to standardized DTCs and a uniform OBD connector across different vehicle manufacturers, formalized in SAE J1962.

From its Californian roots, the OBD2 standard progressively expanded:

1996: OBD2 became mandatory in the USA for all cars and light trucks.
2001: The European Union adopted OBD2 requirements for gasoline cars.
2003: OBD2 compliance extended to diesel cars in the EU under the European On-Board Diagnostics (EOBD) regulation.
2005: OBD2 mandate in the US broadened to include medium-duty vehicles.
2008: A pivotal year where US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication, solidifying “OBD2 CAN bus” as the standard.
2010: OBD2 requirements were finalized in the US for heavy-duty vehicles.

![alt text: Timeline infographic illustrating the history of OBD2 development for emission control and exhaust standards, including EOBD2 and EOBDII.]

![alt text: Visual timeline summarizing the historical milestones of OBD2 and on-board diagnostics development and adoption.]

![alt text: Graphic depicting the future trends of OBD2 towards OBD3, remote diagnostics, emissions testing, cloud connectivity, and IoT integration.]

The Future of OBD2: Trends and Innovations

OBD2 is firmly established in automotive technology, but its evolution continues. However, the form it will take in the future is subject to change.

Here are key trends shaping the future of OBD2 and “OBD2 CAN bus”:

Initially designed for emissions monitoring and testing, legislated OBD2 systems face new challenges with electric vehicles. Notably, electric vehicles are not obliged to support OBD2 in its traditional form. This is reflected in the fact that most modern EVs do not support standard OBD2 requests. Instead, they often use OEM-specific UDS communication protocols. This shift can complicate data access from EVs, requiring reverse engineering to decode data – as seen in our case studies for electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Current OBD2 implementations have limitations in data richness and the underlying communication protocols. In response, advanced alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are being developed. These aim to improve OBD communication by utilizing the UDS protocol as a foundation. For a deeper understanding, explore our introduction to UDS.

In an era of connected vehicles, traditional OBD2 testing methods can seem inefficient. Manual emission control checks are time-consuming and costly. The proposed solution is OBD3 – integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder to every car, similar to those used for bridge tolls. This would enable vehicles to wirelessly transmit their vehicle identification number (VIN) and DTCs via WiFi to a central server for automated checks.

Many current devices already facilitate CAN or OBD2 data transfer over WiFi/cellular networks, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger. While this offers convenience and cost savings, it also raises political and privacy concerns related to surveillance.

The original OBD2 protocol was designed for stationary emission inspections. Today, however, OBD2 is widely used by third parties to generate real-time vehicle data via OBD2 dongles, CAN loggers and other devices. However, the German automotive industry is seeking to change this landscape, as highlighted in a report by eenewsautomotive.com:

OBD was created for car servicing in repair shops, not to enable a data-driven economy for third parties based on access through this interface.”
– Christoph Grote, SVP Electronics, BMW (2017)

The proposal suggests deactivating OBD2 functionality during vehicle operation, instead centralizing data collection on manufacturer servers. This would essentially give manufacturers control over ‘automotive big data’ and CAN bus telematics at scale.

Arguments for this shift include enhanced security, such as reducing the risk of car hacking. However, critics view it as a commercial strategy, as discussed in a Navixy blog post. Whether this trend will prevail remains to be seen, but it could significantly impact the market for third-party OBD2 services.

![alt text: Illustration depicting the removal of the OBD2 connector from an electric vehicle, symbolizing restricted data access in EVs.]

Enhance Your CAN Bus Expertise

Ready to become proficient in CAN bus technology?

Access our comprehensive ‘Ultimate CAN Guide,’ which compiles 12 ‘simple introductions’ into a 160+ page PDF:

Download now

![alt text: Cover image of the “CAN Bus – The Ultimate Guide Tutorial PDF,” a comprehensive resource for learning about CAN bus.]

OBD2 Standards: A Deeper Dive

On-board diagnostics OBD2 operates as a higher-layer protocol, akin to a language, while CAN functions as the communication method, similar to a telephone line. This places OBD2 alongside other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

Specifically, OBD2 standards define the OBD2 connector specifications, lower-layer protocols, OBD2 Parameter IDs (PIDs), and other critical aspects for “OBD2 CAN bus” communication.

These standards can be structured using the 7-layer OSI model. The following sections will concentrate on the most crucial standards.

Examining the OSI model, you’ll notice that both SAE and ISO standards cover multiple layers. This generally reflects the standardization of OBD in the USA (SAE) and Europe (ISO). Many of these standards are technically very similar; for instance, SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3, are almost equivalent.

![alt text: OSI 7-layer model diagram comparing OBD2 and CAN bus protocols, highlighting ISO 15765 and ISO 11898 standards.]

![alt text: Detailed pinout diagram of an OBD2 connector socket, female Type A DLC (Data Link Connector).]

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector is the gateway to accessing your vehicle’s data, precisely defined by the SAE J1962 / ISO 15031-3 standard. This connector is critical for establishing “OBD2 CAN bus” communication.

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

Key points about the OBD2 connector:

It’s typically located near the steering wheel, but its exact position may be concealed.
Pin 16 provides battery power, often even when the ignition is switched off.
The OBD2 pinout configuration varies based on the communication protocol used.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are usually connected for “OBD2 CAN bus” systems.

OBD2 Connector Types: A vs. B

In practice, you may encounter both Type A and Type B OBD2 connectors. Type A is commonly found in cars, while Type B is more typical 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 can also vary, with cars generally using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing).

Visually distinguishing between Type A and Type B OBD2 sockets is aided by the interrupted groove in the middle of the Type B connector. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and B sockets, whereas a Type A adapter will not fit into a Type B socket.

![alt text: Diagram contrasting OBD2 Connector Type A and Type B as per SAE J1962, highlighting differences for cars, vans, and trucks with 12V and 24V systems.]

![alt text: Graphic comparing OBD2 and CAN bus, emphasizing their relationship under the ISO 15765 standard.]

OBD2 and CAN Bus: ISO 15765-4 in Detail

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as per ISO 15765. This standard is central to “OBD2 CAN bus” functionality.

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

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

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

OBD2 CAN Identifiers: 11-bit and 29-bit

All OBD2 communication over CAN bus is structured around request/response message pairs.

In most cars, 11-bit CAN IDs are utilized for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, used to query all OBD2-compatible ECUs for data on a requested parameter (as defined in ISO 15765-4). Conversely, CAN IDs in the range 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests to specific ECUs, though this is less frequently used.

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

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

For 29-bit identifiers, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

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

![alt text: Diagram illustrating OBD2 protocol request and response frames, showing PID data and parameters flow.]

![alt text: Table overview of OBD2 CAN bus identifiers, including 7DF, 7E8, and 7E0, used for requests and responses.]

![alt text: Comparison graphic of OBD2 vs proprietary CAN bus protocols, highlighting differences in data access and standardization.]

OBD2 vs. Proprietary CAN Protocols: Understanding the Difference

It is crucial to understand that your vehicle’s electronic control units (ECUs) do not rely on OBD2 for their core operations. Original Equipment Manufacturers (OEMs) implement their own proprietary CAN protocols for vehicle control and internal communication. These proprietary CAN protocols are often unique to the vehicle brand, model, and year. Without OEM documentation, interpreting this proprietary CAN data is usually impossible unless you undertake reverse engineering.

When you connect a CAN bus data logger to your vehicle’s OBD2 connector, you might observe 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 proprietary CAN data through the OBD2 port, allowing only standardized OBD2 communication.

In essence, think of OBD2 as a supplementary, higher-level protocol that operates alongside the OEM-specific protocol. OBD2 over CAN bus provides a standardized interface for diagnostics and emissions-related data, separate from the vehicle’s internal control network.

Bit-rate and ID Validation in OBD2 CAN Bus

As previously mentioned, OBD2 CAN bus can operate at two bit-rates (250K, 500K) and utilize two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern vehicles most commonly use 500K bit-rate with 11-bit IDs. Therefore, external diagnostic tools should systematically validate these parameters.

ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination. This method relies on the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (detailed in the OBD2 PID section) and leverages the fact that transmitting data at an incorrect bit-rate will cause CAN error frames.

More recent versions of ISO 15765-4 account for vehicles that might support OBD communication via OBDonUDS rather than the traditional OBDonEDS. While 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 differentiate between OBDonEDS and OBDonUDS protocols, a diagnostic tool can 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 predominantly used in non-electric vehicles today, whereas WWH-OBD is mainly used in EU trucks and buses.

![alt text: Flowchart illustrating the OBD2 bit-rate and CAN ID validation process according to ISO 15765-4, for establishing OBD2 CAN bus communication.]

![alt text: Graphic showing the five lower-layer OBD2 protocols: CAN (ISO 15765), KWP2000, SAE J1850, and ISO 9141.]

Five Lower-Layer OBD2 Protocols: Beyond CAN Bus

While CAN bus is the dominant lower-layer protocol for OBD2 today under ISO 15765, especially in vehicles post-2008, it’s important to be aware of the other four protocols used in older vehicles. Examining the OBD2 connector pinouts can help determine which protocol might be in use in older cars.

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and currently the most common protocol for “OBD2 CAN bus” systems.
ISO 14230-4 (KWP2000): Keyword Protocol 2000 was prevalent in 2003+ vehicles, particularly in Asia.
ISO 9141-2: Used in European, Chrysler, and Asian vehicles from 2000-2004.
SAE J1850 (VPW): Primarily used in older General Motors (GM) vehicles.
SAE J1850 (PWM): Mainly used in older Ford vehicles.

ISO-TP: Transporting OBD2 Messages Over CAN Bus (ISO 15765-2)

All OBD2 data, when transmitted over CAN bus, utilizes a transport protocol known as ISO-TP (ISO 15765-2). This protocol is essential for enabling communication of data payloads exceeding the 8-byte limit of a standard CAN frame. ISO-TP is crucial in OBD2 for operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), where data often exceeds 8 bytes. It provides mechanisms for segmentation, flow control, and reassembly of larger messages. For a more detailed explanation, refer to our introduction to UDS.

However, much of the time, OBD2 data fits within a single CAN frame. In these instances, 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 available for OBD2-related communication.

![alt text: Diagram illustrating ISO 15765-2 ISO-TP OBD2 frame types, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.]

The OBD2 Diagnostic Message Structure: SAE J1979, ISO 15031-5

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

![alt text: Breakdown of an OBD2 message structure, explaining the raw frame components including Mode, PID, ID, and data bytes.]

Example: OBD2 Request and Response Sequence

Before diving into the specifics of each part of an OBD2 message, consider this practical example of a request and response for the parameter ‘Vehicle Speed’.

In this scenario, an external diagnostic tool sends a request message to the vehicle with CAN ID 0x7DF and a 2-byte payload: Mode 0x01 and PID 0x0D. The vehicle responds using CAN ID 0x7E8 with a 3-byte payload, which includes the Vehicle Speed value in the 4th byte, 0x32 (50 in decimal).

By consulting the decoding rules for OBD2 PID 0x0D, we determine that the physical value is 50 km/h.

Next, we will explore OBD2 modes and PIDs in more detail.

![alt text: Example of an OBD2 request (7DF) and response (7E8) sequence for vehicle speed, showing data flow.]

![alt text: Detailed example of OBD2 PID 0D for Vehicle Speed, explaining the data encoding and physical value interpretation.]

![alt text: Diagram outlining the 10 OBD2 service modes (diagnostic services), including current data, freeze frame, and clear DTCs.]

The 10 Standard OBD2 Services (Modes)

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

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 ones, known as OEM-specific OBD2 modes.

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

OBD2 Parameter IDs (PIDs): Accessing Specific Data

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

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

One PID holds particular significance:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the vehicle’s ECU communicates its support for PIDs 0x01-0x20. This makes PID 0x00 a valuable tool for a basic ‘OBD2 compatibility test’. Additionally, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs in ranges of 32 PIDs each.

![alt text: Reiteration of the OBD2 protocol request and response frames diagram, emphasizing PID data and parameters in communication.]

![alt text: Screenshot of an OBD2 PID overview tool, showing service 01 parameters and data for on-board diagnostics.]

Tip: Using an OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 provide essential scaling information for standard OBD2 PIDs. This information is crucial for decoding raw OBD2 data into meaningful physical values, as discussed in our CAN bus introduction.

For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is an invaluable resource. It aids 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 practical demonstration of how to log OBD2 data using the CANedge CAN bus data logger.

The CANedge allows configuration of custom CAN frames for transmission, making it suitable for applications such as OBD2 data logging.

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

![alt text: Diagram showing an OBD2 PID data logger setup, with request (7DF) and response (7E8) message flow.]

You can send a CAN frame at e.g. 500K, then check if it is successfully sent
![alt text: Screenshot showing a bit rate validation test for OBD2 CAN bus at 500K, confirming successful transmission.]

The responses to ‘Supported PIDs’ can be reviewed in asammdf
![alt text: Screenshot of asammdf software displaying OBD2 supported PIDs test responses for review and analysis.]

![alt text: Image demonstrating how to review and decode ‘Supported PIDs’ results using an OBD2 PID lookup tool.]

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

As previously discussed, ISO 15765-4 outlines how to determine the correct bit-rate and IDs for a specific vehicle’s OBD2 CAN bus system. You can perform these tests using the CANedge as described below (refer to the CANedge Intro for detailed instructions):

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

We offer plug-and-play configuration files to streamline these tests.

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

As illustrated in the asammdf GUI screenshot, it is common to receive multiple responses to a single OBD request, especially when using 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 common. As you progress to subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. Notably, the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs in the system. This suggests that bus load can be reduced by directing subsequent communication specifically to the ECM using ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configuring OBD2 PID Requests

Once you have identified the supported OBD2 PIDs for your vehicle, along with the correct bit-rate and CAN IDs, you can proceed to configure your transmit list with the PIDs of interest.

Consider these factors when setting up your OBD2 PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses to each request, focusing communication on specific ECUs.
Request Spacing: Introduce a delay of 300-500 ms between each OBD2 request to prevent overwhelming the ECUs, which may cause them to stop responding.
Battery Management: Implement triggers to halt transmission when the vehicle is inactive to prevent unnecessary battery drain by ‘waking up’ ECUs.
Data Filtering: Apply filters to record only OBD2 responses if your vehicle also outputs OEM-specific CAN data, streamlining data collection to relevant OBD2 information.

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

An example list of CANedge OBD2 PID requests
![alt text: Example CANedge transmit list configured for OBD2 PID requests, showing setup for data logging.]

asammdf lets you DBC decode and visualize OBD2 data
![alt text: Screenshot from asammdf software showing OBD2 data decoded and visualized as a plot using a CAN bus DBC file.]

Step #3: DBC Decoding of Raw OBD2 Data

Finally, to effectively analyze and visualize your logged data, you need to decode the raw OBD2 data into ‘physical values’ such as km/h or °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 somewhat more complex than standard CAN signal decoding. This complexity arises 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, it’s necessary to use the CAN ID, OBD2 mode, and OBD2 PID in combination to identify each signal. This method is known as ‘extended multiplexing‘ and can be implemented in formats like DBC files, enabling accurate interpretation of OBD2 data.

CANedge: Your OBD2 Data Logging Solution

The CANedge simplifies the process of recording OBD2 data directly to an SD card (8-32 GB). Simply connect it to your vehicle (car/truck) to start logging. Data can then be decoded using free software/APIs and our OBD2 DBC file.

OBD2 logger intro
CANedge

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

All OBD2 data transmission, especially when payloads exceed the standard CAN frame size, utilizes ISO-TP (transport protocol) as per ISO 15765-2. While many examples discussed have been single-frame communication, this section illustrates multi-frame communication scenarios.

Multi-frame OBD2 communication necessitates flow control frames (refer to our UDS introduction). In practice, this can be managed by transmitting a static flow control frame approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.

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

![alt text: Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN) retrieval.]

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

The Vehicle Identification Number (VIN) is crucial for various applications, including telematics and diagnostics (detailed in our UDS introduction). To retrieve the VIN from a vehicle using OBD2 requests, you would use mode 0x09 and PID 0x02:

![alt text: Example of VIN Vehicle Identification Number retrieval using OBD2 multi-frame communication.]

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

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

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

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

This feature enhances data collection efficiency and frequency, but it also means that signal encoding is specific to your request method. This specificity can complicate the use of generic OBD2 DBC files. Therefore, this method is generally not recommended for standard OBD2 data logging. Below is an example trace of such communication:

![alt text: Trace example of requesting multiple PIDs in a single OBD2 request, showing multi-frame ISO-TP communication.]

The multi-frame response structure is similar to the VIN example but includes the requested PIDs along with their corresponding data. In practice, the PIDs in the response are typically ordered as requested (though not strictly mandated by ISO 15031-5).

Decoding these responses using generic DBC files is challenging. It is generally not recommended for practical data logging unless you are using a tool specifically designed to support this multi-PID request method. This approach introduces a form of extended multiplexing, complicated by the need to account for the specific payload position of each PID in your DBC file. This complexity increases when sending multiple multi-PID requests, as uniquely identifying messages becomes difficult.

Workarounds could involve custom scripts and recording transmit messages from your testing tool. The script could then interpret response messages in conjunction with the request messages. However, such methods are generally complex to scale.

Example 3: Retrieving OBD2 Diagnostic Trouble Codes (DTCs)

You can retrieve emissions-related Diagnostic Trouble Codes (DTCs) using OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’. No PID is included in the request. The target ECU(s) will respond with the number of stored DTCs (including zero if none are stored), with each DTC occupying 2 data bytes. Multi-frame responses are required when more than two DTCs are stored.

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

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

![alt text: Example of OBD2 DTC (Diagnostic Trouble Code) DBC interpretation and decoding process.]

![alt text: Example of OBD2 Diagnostic Trouble Codes (DTCs) CAN bus request and response trace frames.]

OBD2 Data Logging: Real-World Use Cases

OBD2 data logging from cars and light trucks has numerous applications across various industries:

Vehicle Data Logging

OBD2 data from passenger vehicles can be leveraged for fuel efficiency analysis, driving behavior improvement, prototype component testing, and insurance telematics.

obd2 logger

Real-time Vehicle Diagnostics

OBD2 interfaces facilitate real-time streaming of vehicle data in a human-readable format, ideal for diagnosing vehicle issues on the go.

obd2 streaming

Predictive Maintenance

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

predictive maintenance

Vehicle Black Box Recording

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

can bus blackbox

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 the ‘Ultimate Guide’ PDF for comprehensive CAN bus knowledge.

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy now
Contact us