In the realm of modern automotive technology, the Obd2 Communication Protocol stands as a critical cornerstone for vehicle diagnostics and data access. This standardized system, known as On-Board Diagnostics II (OBD2), empowers mechanics, car enthusiasts, and even vehicle owners to tap into a wealth of information about a car’s health and performance.
This guide provides an in-depth exploration of the OBD2 protocol, encompassing its connector, communication parameters, and its vital link to the Controller Area Network (CAN bus). Designed as a practical resource, we will delve into requesting and interpreting OBD2 data, highlighting key applications and offering valuable tips for effective utilization.
Learn why this article is becoming the go-to resource for understanding the OBD2 communication protocol.
You can also watch our OBD2 intro video above – or get the PDF
What is OBD2 and its Communication Protocol?
OBD2 is essentially your vehicle’s internal self-diagnostic system. It is defined by a standardized communication protocol that allows for the retrieval of diagnostic trouble codes (DTCs) and real-time operational data through the OBD2 connector.
You’ve likely encountered OBD2 in action without realizing it. The malfunction indicator light on your dashboard, often referred to as the “check engine light,” is a direct output of the OBD2 system. It illuminates when your car detects an issue, signaling the need for attention.
When you take your vehicle to a mechanic, they use an OBD2 scanner to pinpoint the problem. This tool is connected to the OBD2 16-pin connector, typically located near the steering wheel. The OBD2 scanner transmits ‘OBD2 requests’ to the car’s computer system. In response, the car sends back ‘OBD2 responses’, which can include data points like speed, fuel level, and, importantly, Diagnostic Trouble Codes (DTCs). This streamlined communication process drastically speeds up the troubleshooting and repair process.
Image showing a malfunction indicator light (MIL) or check engine light, an OBD2 scanner tool, and the OBD2 connector, illustrating the basic components of an OBD2 diagnostic process.
OBD2 Compatibility: Does Your Car Use This Communication Protocol?
The answer is very likely yes. The vast majority of modern non-electric vehicles are equipped with OBD2 systems, and most of these operate using the CAN bus as their underlying communication network.
However, for older vehicles, the presence of a 16-pin OBD2 connector isn’t a guarantee of OBD2 compliance. Some older cars may have this connector without fully supporting the OBD2 protocol. A key indicator of OBD2 compliance is the vehicle’s year and region of purchase:
Does My Car Have OBD2?
Infographic illustrating OBD2 compliance based on vehicle purchase location (EU/US) and year, highlighting the phased rollout of OBD2 regulations.
A Brief History of the OBD2 Communication Protocol
The origins of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated the inclusion of On-Board Diagnostics (OBD) in all new cars starting in 1991 for emissions monitoring purposes.
The OBD2 communication protocol itself was further refined and standardized by the Society of Automotive Engineers (SAE). They established standardized DTCs and a uniform OBD connector design across different vehicle manufacturers through the SAE J1962 standard.
From its Californian inception, the OBD2 standard gradually expanded its reach:
- 1996: OBD2 became mandatory in the USA for all cars and light trucks.
- 2001: The European Union mandated OBD2 for gasoline cars.
- 2003: The EU extended the mandate to include diesel cars (known as EOBD in Europe).
- 2005: OBD2 compliance was required in the US for medium-duty vehicles.
- 2008: US vehicles were required to utilize ISO 15765-4 (CAN) as the foundation for their OBD2 systems, standardizing the communication protocol.
- 2010: OBD2 became mandatory in the US for heavy-duty vehicles.
Diagram illustrating the historical timeline of OBD2 adoption, emphasizing its origins in emission control and its evolution alongside CAN bus technology.
Timeline graphic summarizing key milestones in OBD2 history, from its inception to its widespread adoption across vehicle types and regions.
Visual representation of the envisioned future of OBD systems with OBD3, highlighting trends like remote diagnostics, cloud connectivity, and IoT integration.
The Future of OBD2 Communication Protocol
While OBD2 remains a vital part of vehicle diagnostics, its future is evolving. Here are some key trends shaping its trajectory:
Originally, legislated OBD2 was primarily intended for emissions control and testing. Interestingly, this means that electric vehicles (EVs) are not obligated to support OBD2 in any form. In practice, very few modern EVs implement standard OBD2 requests. Instead, most EVs utilize OEM-specific UDS (Unified Diagnostic Services) communication protocols. This OEM-specific approach generally makes accessing data from EVs challenging, except in cases where the proprietary protocols have been reverse-engineered. Examples of successful reverse engineering efforts can be seen in case studies for electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.
The current OBD2 implementation has faced limitations, particularly in data richness and the underlying communication protocols. To address these, newer alternatives have emerged, including WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). Both of these aim to modernize and enhance OBD communication by building upon the UDS protocol. For a deeper understanding of these protocols, refer to our introduction to UDS.
In our increasingly connected world, traditional OBD2 testing methods can seem outdated. Manual emission control checks are time-consuming and costly. The proposed solution? OBD3 – integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder to all cars, similar to those used for bridge tolls. This would enable vehicles to wirelessly transmit their vehicle identification number (VIN) and DTCs to a central server via WiFi for automated checks.
Many devices already facilitate the wireless transfer of CAN or OBD2 data, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger. While this approach offers convenience and cost savings, it also raises political concerns related to surveillance and data privacy.
The original OBD2 protocol was designed for stationary emission controls. However, today, it is extensively used by third parties to generate real-time vehicle data through OBD2 dongles, CAN loggers and similar devices. Interestingly, the German car industry is pushing for changes in this landscape:
“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 is to effectively disable OBD2 functionality while driving, centralizing data collection within manufacturer-controlled servers. This would give manufacturers control over the burgeoning ‘automotive big data’. The rationale often cited is security, aiming to mitigate the risk of car hacking. However, many view this as a commercially motivated move to control valuable data access, potentially disrupting the market for third-party OBD2 services. Whether this trend gains traction remains to be seen.
Illustration depicting the trend of electric vehicles potentially limiting access to data through the OBD2 connector, highlighting the shift towards OEM-controlled data access.
Enhance Your CAN Bus Expertise
Do you aspire to become a CAN bus expert?
Access our comprehensive collection of 12 ‘simple intros’ in a single 160+ page PDF:
Download now
CAN Bus – The Ultimate Guide Tutorial PDF
OBD2 Standards and the Communication Protocol
On-board diagnostics, OBD2, operates as a higher-layer protocol – essentially a language for vehicle communication. CAN bus, on the other hand, serves as the communication method, analogous to a phone line. This places OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.
Specifically, the OBD2 standards define the OBD2 connector’s physical specifications, the lower-layer communication protocols used, OBD2 Parameter IDs (PIDs), and other critical aspects of the diagnostic system.
These standards can be visualized within the 7-layer OSI model, a framework for understanding network communication. The following sections will focus on the most crucial standards within this model. You’ll notice that both SAE (primarily US standards) and ISO (international standards, often adopted in the EU) standards cover various layers. In many cases, the SAE and ISO standards are technically very similar, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.
Diagram mapping OBD2 and CAN bus standards onto the 7-layer OSI model, highlighting the layers covered by ISO and SAE standards.
Detailed pinout diagram of a Type A OBD2 connector socket, showing pin assignments and their functions within the OBD2 communication protocol.
The OBD2 Connector [SAE J1962 / ISO 15031-3]
The 16-pin OBD2 connector is your gateway to accessing vehicle data. Its specifications are meticulously defined in the SAE J1962 / ISO 15031-3 standards. The illustration above shows a typical Type A OBD2 pin connector, also known as a Data Link Connector (DLC).
Key points to remember about the OBD2 connector:
- It’s usually located near the steering wheel, but sometimes it can be hidden.
- Pin 16 provides battery power, often even when the ignition is off.
- The specific OBD2 pinout configuration depends on the communication protocol used by the vehicle.
- CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically connected.
OBD2 Connector Types: A vs. B
In practical applications, you might encounter both Type A and Type B OBD2 connectors. Type A connectors are most commonly found in cars, while Type B connectors are prevalent in medium and heavy-duty vehicles.
While both types share similar OBD2 pinouts, they differ in their power supply outputs – Type A provides 12V, while Type B provides 24V. Baud rates can also vary; cars typically use 500K, while heavy-duty vehicles often use 250K (with increasing support for 500K in newer models).
Visually, Type B OBD2 connectors can be identified by an interrupted groove in the middle of the connector face. This physical difference means that a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, but a Type A adapter will not fit into a Type B socket.
Diagram contrasting Type A and Type B OBD2 connectors, highlighting differences in voltage, physical appearance, and typical vehicle applications.
Conceptual diagram illustrating the relationship between OBD2 and CAN bus, emphasizing ISO 15765 as the standard defining OBD2 over CAN communication.
OBD2 and CAN Bus Communication Protocol [ISO 15765-4]
Since 2008, CAN bus has been the mandated lower-layer communication protocol for OBD2 in all vehicles sold in the US, as stipulated by ISO 15765.
ISO 15765-4, also known as Diagnostics over CAN (or DoCAN), outlines a set of specifications applied to the CAN standard (ISO 11898) specifically for OBD2.
It standardizes the CAN interface for diagnostic test equipment, focusing on the physical, data link, and network layers of the OSI model. Key specifications include:
- CAN bus bit-rate must be either 250K or 500K.
- CAN IDs can be 11-bit or 29-bit.
- Specific CAN IDs are designated for OBD requests and responses.
- Diagnostic CAN frame data length is fixed at 8 bytes.
- The OBD2 adapter cable is limited to a maximum length of 5 meters.
OBD2 CAN Identifiers (11-bit, 29-bit)
All OBD2 communication relies on a request/response message exchange.
In most passenger cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is used to broadcast a request to all OBD2-compatible Electronic Control Units (ECUs), asking if they have data to report for the requested parameter (as per ISO 15765-4). ‘Physical Addressing’ requests, using CAN IDs in the range 0x7E0-0x7E7, can be used to target specific ECUs, but are less common.
ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most frequent response ID is 0x7E8 (for the ECM, Engine Control Module), followed by 0x7E9 (for the TCM, Transmission Control Module).
In some vehicle types, particularly vans and light/medium/heavy-duty vehicles, OBD2 communication may utilize extended 29-bit CAN identifiers instead of 11-bit IDs.
For 29-bit CAN, the ‘Functional Addressing’ CAN ID is 0x18DB33F1. Responses, if any, will use CAN IDs in the range 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). This response ID is sometimes represented in ‘J1939 PGN’ format as PGN 0xDA00 (55808), which is designated as ‘Reserved for ISO 15765-2’ in the J1939-71 standard.
Diagram illustrating the request-response message flow in OBD2 communication, showing the roles of request frames, response frames, PIDs, and data parameters.
OBD2 OBD CAN bus Identifiers 7DF 7E8 7E0
Conceptual image contrasting OBD2 communication with proprietary OEM-specific CAN bus protocols, highlighting OBD2 as a standardized diagnostic layer alongside manufacturer-specific data.
OBD2 vs. Proprietary CAN Protocols
It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) operate primarily using OEM-specific proprietary CAN protocols, not OBD2. Each Original Equipment Manufacturer (OEM) develops their own unique CAN protocols tailored to their vehicle brands, models, and years. Unless you are the OEM, deciphering this proprietary CAN data is generally not possible without reverse engineering.
When you connect a CAN bus data logger to your car’s OBD2 connector, you might observe OEM-specific CAN data being broadcast, typically at a high rate of 1000-2000 frames per second. However, in many newer vehicles, a ‘gateway’ module restricts access to this raw CAN data through the OBD2 port, allowing only OBD2 communication.
In essence, think of OBD2 as an ‘additional’ higher-layer protocol operating parallel to the OEM’s primary communication protocol. It’s a standardized diagnostic layer built on top of the vehicle’s core communication network.
Bit-rate and ID Validation in OBD2 Communication Protocol
As mentioned, OBD2 can utilize either 250K or 500K bit-rates and 11-bit or 29-bit CAN IDs. This results in four possible combinations for the communication protocol. Modern cars commonly use 500K and 11-bit IDs, but external tools should systematically verify this.
ISO 15765-4 provides a recommended initialization sequence to automatically determine the correct combination. This process relies on the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section for details) and that using an incorrect bit-rate will generate CAN error frames.
Newer versions of ISO 15765-4 also account for vehicles that might support OBD communication via OBDonUDS (OBD on Unified Diagnostic Services) rather than the more traditional OBDonEDS (OBD on Emission Diagnostic Services). This article primarily focuses on OBD2/OBDonEDS (defined by ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (defined by ISO 14229, ISO 27145-3/SAE J1979-2).
To differentiate between OBDonEDS and OBDonUDS, 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 referred to as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars today, while WWH-OBD is mainly used in EU trucks and buses.
Flowchart illustrating the process of OBD2 bit-rate and CAN ID validation according to ISO 15765-4, guiding diagnostic tools in automatically detecting the correct communication parameters.
Diagram showcasing the five lower-layer protocols historically used for OBD2, including CAN (ISO 15765), KWP2000, SAE J1850 (VPW and PWM), and ISO 9141, highlighting CAN as the dominant modern protocol.
Five Lower-Layer OBD2 Communication Protocols
While CAN (ISO 15765) is now the dominant lower-layer basis for OBD2 in most vehicles, especially those manufactured after 2008, older cars may utilize other protocols. Understanding these historical protocols can be useful when diagnosing older vehicles. The OBD2 connector pinouts can sometimes provide clues as to which protocol might be in use.
The five lower-layer protocols are:
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now the most common globally.
- ISO 14230-4 (KWP2000): Keyword Protocol 2000, frequently used in 2003+ vehicles, particularly 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 GM vehicles.
- SAE J1850 (PWM – Pulse Width Modulation): Primarily used in older Ford vehicles.
Transporting OBD2 Messages via ISO-TP [ISO 15765-2]
All OBD2 data exchange over CAN bus relies on the ISO-TP (ISO 15765-2) transport protocol. This protocol is essential because it enables the transmission of data payloads exceeding the 8-byte limit of a standard CAN frame. This capability is crucial in OBD2 for tasks like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often require more than 8 bytes of data. ISO 15765-2 handles segmentation of larger messages, flow control, and reassembly at the receiving end. For a more detailed explanation of ISO-TP, refer to our introduction to UDS.
However, a significant portion of OBD2 communication involves data that 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 (the PCI field – Protocol Control Information) indicates the payload length (excluding padding), leaving 7 bytes available for OBD2-specific communication.
Diagram illustrating different ISO-TP frame types used in OBD2 communication, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame, explaining their roles in message segmentation and transport.
The OBD2 Diagnostic Message Structure [SAE J1979, ISO 15031-5]
To gain a clearer understanding of OBD2 communication over CAN, let’s examine the structure of 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 actual data payload. The payload itself is further structured into Mode, Parameter ID (PID), and data bytes.
Breakdown of the OBD2 message structure, showing the components of a raw CAN frame used for OBD2 communication, including CAN ID, PCI field, Mode, PID, and data bytes.
Example: OBD2 Request/Response Sequence
Before diving into the specifics of OBD2 message components, let’s consider a practical example: requesting and receiving vehicle speed data.
In this scenario, an external diagnostic tool initiates communication by sending a request message to the vehicle. This request message uses CAN ID 0x7DF and contains a 2-byte payload: Mode 0x01 and PID 0x0D. The vehicle responds with a message using CAN ID 0x7E8 and a 3-byte payload. The vehicle speed value is encoded in the 4th byte of the CAN data payload, which is 0x32 in hexadecimal (equivalent to 50 in decimal).
By consulting the OBD2 PID documentation for PID 0x0D, we can determine that this value represents vehicle speed in km/h. Thus, 0x32 corresponds to a speed of 50 km/h. This example illustrates the fundamental request-response mechanism of the OBD2 communication protocol.
Example of an OBD2 request-response sequence for vehicle speed, showing the request frame (CAN ID 7DF, Mode 0x01, PID 0x0D) and the corresponding response frame (CAN ID 7E8) containing the speed data.
Detailed explanation of OBD2 PID 0x0D (Vehicle Speed), showing the request and response message structure and how the data byte represents speed in km/h.
Infographic listing the 10 standard OBD2 service modes (or modes), including their descriptions and common uses in diagnostics, such as retrieving current data, freeze frame information, and clearing DTCs.
The 10 OBD2 Services (Modes)
The OBD2 standard defines 10 diagnostic services, often referred to as modes. Mode 0x01 is used to request current, real-time data parameters. Other modes are designed for retrieving and clearing Diagnostic Trouble Codes (DTCs), accessing freeze frame data (data captured when a DTC was set), and performing other diagnostic functions.
It’s important to note that vehicles are not required to support all 10 OBD2 modes. Manufacturers may also 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 the corresponding response message, 0x40 is added to the requested mode value (e.g., a response to mode 0x01 will have mode 0x41 in the response).
OBD2 Parameter IDs (PIDs)
Within each OBD2 mode, there are Parameter IDs (PIDs). PIDs are codes that identify specific data parameters that can be requested.
For example, Mode 0x01 (Show current data) includes approximately 200 standardized PIDs that represent real-time data points like vehicle speed, engine RPM, coolant temperature, and fuel level. However, a vehicle does not necessarily support all PIDs defined within a mode. In practice, most vehicles only support a subset of the available PIDs.
One PID holds a special significance: PID 0x00 in Mode 0x01. If an emissions-related ECU supports any OBD2 services at all, it must support Mode 0x01 PID 0x00. When this PID is requested, the vehicle ECU responds with a bitmask indicating which PIDs in the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental tool for testing OBD2 compatibility. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for subsequent ranges of Mode 0x01 PIDs.
(Repeated image for context, already used above)
OBD2 PID overview tool
Screenshot of an OBD2 PID overview tool, showcasing its interface and functionality for looking up and understanding OBD2 PIDs within service mode 0x01.
Practical Tip: OBD2 PID Overview Tool
The appendices of the SAE J1979 and ISO 15031-5 standards provide scaling and conversion information for standard OBD2 PIDs. This information is crucial for converting raw OBD2 data bytes into meaningful physical values (as discussed in our CAN bus introduction).
If you need to quickly look up details for a Mode 0x01 PID, our OBD2 PID overview tool is a valuable resource. This tool assists you in constructing OBD2 request frames and dynamically decoding OBD2 responses, making it easier to work with the OBD2 communication protocol.
OBD2 PID overview tool
How to Log and Decode OBD2 Data: A Practical Guide
This section provides a hands-on example of logging OBD2 data using the CANedge CAN bus data logger. The CANedge’s flexible configuration allows you to define custom CAN frames for transmission, making it suitable for OBD2 data logging.
Once configured, the CANedge can be easily connected to your vehicle’s OBD2 port using our OBD2-DB9 adapter cable.
Diagram illustrating the use of an OBD2 data logger to send OBD2 requests (e.g., CAN ID 7DF) and receive responses (e.g., CAN ID 7E8) for logging PID data.
OBD2 bit rate test
Screenshot showing a bit-rate validation test for OBD2 communication, demonstrating the process of verifying successful CAN frame transmission at a specific bit-rate.
OBD2 Supported PIDs Test
Screenshot from asammdf software showing responses to ‘Supported PIDs’ requests, illustrating how to use diagnostic tools to discover supported OBD2 PIDs in a vehicle.
Review supported PIDs via OBD2 lookup tool
Step #1: Validate Bit-rate, CAN IDs, and Supported PIDs
As previously discussed, ISO 15765-4 outlines a procedure to determine the correct bit-rate and CAN IDs for a specific vehicle’s OBD2 system. You can use the CANedge to perform these validation steps:
- Test Bit-rate: Send a CAN frame at 500K bit-rate and check if it is successfully transmitted (if not, try 250K).
- Use Identified Bit-rate: Use the validated bit-rate for all subsequent OBD2 communication.
- Send ‘Supported PIDs’ Requests: Transmit multiple ‘Supported PIDs’ requests (Mode 0x01, PIDs 0x00, 0x20, 0x40, etc.) and analyze the responses.
- Determine CAN ID Type: Based on the response CAN IDs, identify whether the vehicle uses 11-bit or 29-bit CAN IDs for OBD2 communication.
- Identify Supported PIDs: Analyze the response data to determine the specific PIDs supported by the vehicle.
We provide pre-configured CANedge configurations to streamline these initial tests. Most non-electric vehicles manufactured after 2008 typically support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS communication protocol.
As shown in the asammdf GUI screenshot, you may observe multiple responses to a single OBD request, particularly when using the functional addressing request ID 0x7DF. This is because 0x7DF broadcasts the request to all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, multiple ECUs may respond. For subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. Note that the ECM (Engine Control Module) ECU (0x7E8) often supports all PIDs supported by other ECUs in the vehicle. Therefore, to reduce bus load, you can switch to ‘Physical Addressing’ using CAN ID 0x7E0 for subsequent communication, specifically targeting the ECM for responses.
Step #2: Configure OBD2 PID Requests for Data Logging
Once you have determined the supported OBD2 PIDs, bit-rate, and CAN IDs for your vehicle, you can configure your CANedge to request the specific PIDs you want to log.
Key considerations for configuring OBD2 PID requests:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to target specific ECUs and avoid multiple responses per request.
- Request Spacing: Introduce a delay of 300-500 milliseconds between each OBD2 request. Overly rapid requests can overwhelm ECUs and lead to unreliable responses.
- Battery Drain Management: Implement triggers to stop PID requests when the vehicle is inactive to prevent unnecessary battery drain by “waking up” ECUs.
- Data Filtering: Set up filters to record only OBD2 responses, especially if your vehicle also broadcasts OEM-specific CAN data, to keep your logs focused and efficient.
With these configurations in place, your CANedge is ready to log raw OBD2 data from your vehicle.
obd2-transmit-list-example-canedge
Example of a CANedge transmit list configuration for OBD2 PID requests, showing how to set up periodic requests for specific PIDs for data logging.
OBD2 data decoded visual plot asammdf CAN bus DBC file
Screenshot from asammdf software showing visually plotted and DBC-decoded OBD2 data, demonstrating how raw OBD2 data can be converted into meaningful graphs and charts.
Step #3: DBC Decode Raw OBD2 Data for Analysis
To effectively analyze and visualize your logged OBD2 data, you need to decode the raw data bytes into physical values (e.g., km/h, °C, RPM). This is achieved through DBC decoding.
The necessary decoding information (scaling, units, etc.) is documented in the ISO 15031-5/SAE J1979 standards and is also available on resources like Wikipedia. For convenience, we provide a free OBD2 DBC file that simplifies the process of DBC decoding raw OBD2 data in most CAN bus software tools.
Decoding OBD2 data is slightly more complex than decoding standard CAN signals. This is because multiple OBD2 PIDs are often transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is not sufficient to uniquely identify the signals within the payload.
To address this, decoding must consider not only the CAN ID but also the OBD2 mode and PID to correctly identify each signal. This technique is known as ‘extended multiplexing‘. It can be effectively implemented in DBC files and is supported by tools like asammdf.
CANedge: Your Dedicated OBD2 Data Logger
The CANedge is designed for easy OBD2 data recording. It logs data directly to a removable 8-32 GB SD card. Simply connect it to your vehicle’s OBD2 port to start logging. Data can be decoded and analyzed using free software tools and APIs and our provided OBD2 DBC file.
OBD2 logger intro CANedge product details
OBD2 Multi-Frame Examples [ISO-TP]
As discussed, all OBD2 communication utilizes the ISO-TP transport protocol (ISO 15765-2). While many examples involve single-frame messages, multi-frame communication is necessary for larger data payloads. This section provides examples of multi-frame OBD2 communication scenarios.
Multi-frame OBD2 exchanges require flow control frames (see our UDS introduction for details). In practice, flow control can be managed by transmitting a static flow control frame approximately 50 milliseconds after the initial request frame, as illustrated in the CANedge configuration example below.
Analyzing multi-frame OBD2 responses necessitates CAN software and API tools with ISO-TP support, such as the CANedge MF4 decoders.
OBD2-multi-frame-request-message-vehicle-identification-number
Example of a multi-frame OBD2 request message for Vehicle Identification Number (VIN), illustrating the structure of a request that may require a multi-frame response.
Example 1: Retrieving the OBD2 Vehicle Identification Number (VIN)
The Vehicle Identification Number (VIN) is frequently needed for telematics applications, diagnostics, and various vehicle-related services (see our UDS introduction for more information). To retrieve the VIN using OBD2 requests, you use Mode 0x09 (Vehicle Information) and PID 0x02 (Vehicle Identification Number).
VIN Vehicle Identification Number OBD2 Example multi-frame
The diagnostic tool sends a Single Frame request containing the PCI field (0x02), request service identifier (0x09), and PID (0x02).
The vehicle responds with a First Frame. This frame contains the PCI field, the total length of the multi-frame message (0x014 = 20 bytes), the mode (0x49, i.e., 0x09 + 0x40), and the 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 details). The subsequent 17 bytes contain the VIN itself, which can be converted from hexadecimal to ASCII characters.
Example 2: OBD2 Multi-PID Request (Requesting 6 PIDs)
OBD2 allows diagnostic tools to request data for up to 6 Mode 0x01 PIDs in a single request frame. The ECU will respond with data for the supported PIDs (omitting data for unsupported PIDs) and may use multi-frame responses via ISO-TP if needed.
This multi-PID request feature offers a way to collect OBD2 data more efficiently and at a higher frequency. However, it also introduces complexities. The signal encoding in the response becomes specific to the request method, making the use of generic OBD2 DBC files challenging. We generally advise against using multi-PID requests for routine data logging due to these complexities. Below is an example trace of a multi-PID request and response:
Requesting multiple PIDs in one request
The multi-frame response structure resembles the VIN example, but with the added complexity of including both the requested PIDs and the corresponding data values for each. In practice, the PIDs in the response are often ordered similarly to their order in the request, but this is not strictly mandated by the ISO 15031-5 standard.
Decoding these multi-PID responses using standard DBC files is very challenging. Therefore, we do not recommend this approach for general data logging unless you are using tools specifically designed for multi-PID requests. This approach introduces a complex form of extended multiplexing. Your DBC file would need to account for the specific payload position of each PID, which makes it difficult to create a generalized DBC file applicable across different vehicles with varying PID support. Managing multiple such multi-PID requests further complicates DBC-based decoding.
Workarounds might involve custom scripts that interpret responses in conjunction with the original request messages. However, such approaches are difficult to scale and maintain.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval
OBD2 provides a mechanism to request emissions-related Diagnostic Trouble Codes (DTCs) using Mode 0x03, “Show stored Diagnostic Trouble Codes.” The request for DTCs in Mode 0x03 does not include a PID. The targeted ECU(s) will respond with the number of stored DTCs (which could be zero if no DTCs are active). Each DTC is represented by 2 data bytes. Multi-frame responses are necessary when more than two DTCs are stored, as the response payload may exceed the 7-byte limit of a single CAN frame.
The 2-byte DTC value is structured according to ISO 15031-5/ISO 15031-6. The first 2 bits define the DTC ‘category’, while the remaining 14 bits form a 4-digit code (displayed in hexadecimal). Decoded DTC values can be looked up using online OBD2 DTC lookup tools like repairpal.com.
The example below shows a request to an ECU that has 6 DTCs stored.
Diagram explaining the structure and interpretation of OBD2 Diagnostic Trouble Codes (DTCs), showing the 2-byte DTC format and how to decode the category and code components.
OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response Example
OBD2 Data Logging – Real-World Use Case Examples
OBD2 data from cars and light trucks has a wide range of applications across various industries:
Vehicle Data Logging
OBD2 data logging in cars can be used to optimize fuel efficiency, improve driving habits, validate prototype components, and for insurance telematics.
OBD2 data logger
Real-time Vehicle Diagnostics
OBD2 interfaces enable real-time streaming of human-readable vehicle data, facilitating rapid diagnostics and troubleshooting of vehicle issues.
OBD2 streaming interface
Predictive Maintenance Applications
Cloud-connected IoT OBD2 loggers can continuously monitor vehicle health, enabling predictive maintenance strategies to prevent breakdowns and optimize fleet operations.
Predictive maintenance solutions
Vehicle Black Box Recording
OBD2 loggers can serve as ‘black box’ recorders in vehicles and equipment, providing crucial data for accident reconstruction, warranty claims, and diagnostic analysis.
CAN bus black box logger
Do you have a specific OBD2 data logging application in mind? Contact us for a free consultation!
Contact us
Explore our guides section for more introductory articles, or download our comprehensive ‘Ultimate Guide’ PDF.
Need to log or stream OBD2 data for your project?
Get your OBD2 data logger today!
Buy now Contact us for assistance
Recommended Resources
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANedge2 – Dual CAN Bus Telematics Dongle CANEDGE2 – PRO CAN IoT LOGGER
[
