Decoding Your Car's Health: What Can an OBD2 Scanner Tell You?

Ever wondered what your car is really trying to tell you when that check engine light comes on? Modern vehicles are complex machines, but thankfully, there’s a standardized system designed to help you understand what’s going on under the hood: OBD2.

This guide provides a practical introduction to On-Board Diagnostics version 2 (OBD2), explaining everything from the OBD2 connector and Parameter IDs (PIDs) to its connection with the Controller Area Network (CAN) bus. We’ll break down what information OBD2 can reveal about your vehicle, how to access it, and why understanding OBD2 is increasingly valuable for car owners and enthusiasts alike.

Whether you’re a seasoned mechanic or just curious about your car’s inner workings, understanding what OBD2 can tell you is the first step towards better vehicle maintenance and diagnostics. Let’s dive in and unlock the secrets hidden within your car’s data.

Unveiling the Power of OBD2: What Information is Accessible?

OBD2 is essentially your car’s built-in health monitor. It’s a standardized system that allows you to access a wealth of diagnostic information and real-time data directly from your vehicle. Think of it as a universal translator for your car’s computer. But what exactly can OBD2 tell you?

One of the most common encounters with OBD2 is when the malfunction indicator light (MIL), often called the “check engine light,” illuminates on your dashboard. This light is a signal from your car’s computer indicating that it has detected a problem. When this happens, an OBD2 scanner becomes your key to understanding the issue.

Mechanics use OBD2 scanners, which connect to the OBD2 16-pin connector typically located under the dashboard near the steering wheel. These scanners send “OBD2 requests” to the car’s computer, and the car responds with “OBD2 responses.” These responses contain valuable data, including:

Diagnostic Trouble Codes (DTCs): These codes are like error messages from your car, pinpointing specific problems within the engine, transmission, emissions system, and more. OBD2 can tell you exactly what these codes are, helping to diagnose issues efficiently.
Real-time Data: OBD2 provides access to a stream of live data from your car’s sensors and systems. This includes parameters like engine speed (RPM), vehicle speed, coolant temperature, oxygen sensor readings, fuel trim, and much more. OBD2 can tell you how your engine is performing in real-time.

Alt text: Illustration showing OBD2 scanner connected to a car’s OBD2 port, diagnosing malfunction indicator light (MIL) issue.

Is My Car OBD2 Compliant? Determining Compatibility

The good news is that if you own a relatively recent car, it almost certainly supports OBD2. In fact, for most non-electric cars manufactured in recent decades, OBD2 compatibility is standard, and many also utilize the CAN bus communication protocol.

However, it’s important to note that simply having a 16-pin OBD2 connector doesn’t guarantee full OBD2 compliance, especially in older vehicles. To determine if your car is OBD2 compliant, consider these factors:

Year and Market of Purchase: OBD2 implementation was phased in over time based on regulations in different regions.
- USA: OBD2 became mandatory for cars and light trucks in 1996.
- Europe: OBD2 (EOBD) was required for gasoline cars in 2001 and diesel cars in 2003.

This timeline provides a general guideline. If your car was purchased new in or after these years in these regions, it’s highly likely to be OBD2 compliant.

Alt text: Infographic illustrating OBD2 compliance timeline for US and EU vehicles based on purchase year and vehicle type.

A Look Back: The History of OBD2 and its Evolution

The story of OBD2 begins in California. The California Air Resources Board (CARB), driven by the need for stricter emission controls, mandated the implementation of On-Board Diagnostics in all new cars sold in California starting from 1991. This initial OBD system laid the groundwork for the standardized OBD2 we know today.

The Society of Automotive Engineers (SAE) played a crucial role in developing the OBD2 standard, focusing on standardized DTCs and a universal OBD connector across different manufacturers (defined by SAE J1962). This standardization was key to making vehicle diagnostics more accessible and efficient.

The OBD2 standard was gradually rolled out globally:

1996: OBD2 becomes mandatory in the USA for all cars and light trucks.
2001: The European Union mandates OBD2 for gasoline-powered cars (EOBD).
2003: EOBD is extended to include diesel cars in the EU.
2005: OBD2 is required in the US for medium-duty vehicles.
2008: US vehicles are required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication. This standardized the communication protocol.
2010: OBD2 becomes mandatory for heavy-duty vehicles in the US.

Alt text: Diagram illustrating OBD2 history and its connection to emission control and vehicle data via CAN bus.

Alt text: Timeline infographic summarizing the historical milestones in the development and implementation of OBD2 standards.

Alt text: Graphic depicting the future of OBD3 with remote diagnostics, emissions testing, cloud connectivity, and IoT integration.

The Future of OBD: Trends and Potential Shifts

While OBD2 remains the dominant standard for vehicle diagnostics, the automotive landscape is evolving, and so is OBD. Here are some key trends shaping the future of OBD:

Electric Vehicles (EVs) and OBD: Interestingly, legislative OBD2 requirements were primarily driven by emissions control. As a result, electric vehicles, which have no tailpipe emissions, are not strictly required to support OBD2 in the traditional sense. In practice, many modern EVs do not fully support standard OBD2 requests. Instead, they often use manufacturer-specific protocols like UDS (Unified Diagnostic Services). This can make accessing data from EVs more challenging, often requiring reverse engineering of OEM-specific communication rules.
Advanced OBD Protocols: Recognizing the limitations of current OBD2 in terms of data richness and communication protocols, newer alternatives are emerging. WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are designed to enhance OBD communication by utilizing the more robust UDS protocol as a foundation.
OBD3 and Telematics: The concept of OBD3 envisions a future where vehicles are equipped with telematics capabilities for remote diagnostics and emissions monitoring. This could involve integrating radio transponders into vehicles to automatically transmit Vehicle Identification Numbers (VINs) and DTCs to a central server for analysis. While technically feasible and potentially cost-saving for emissions testing, OBD3 raises privacy concerns related to vehicle surveillance and data collection.
OEM Control Over Vehicle Data: There’s a growing debate about who should control access to vehicle data. Some automotive manufacturers are advocating for limiting third-party access to OBD2 data, citing security concerns and the potential for a “data-driven economy” built on OEM data without their direct involvement. Proposals to “turn off” OBD2 functionality during normal driving and centralize data collection within manufacturer servers could significantly impact the aftermarket OBD2 service and device industry.

Alt text: Conceptual image showing an OBD2 connector being removed from an electric vehicle, symbolizing restricted data access in EVs.

Unlock the Full Picture: Dive Deeper with our ‘Ultimate CAN Guide’

Want to become a true CAN bus and OBD2 expert?

Our comprehensive ‘Ultimate CAN Guide’ consolidates 12 insightful introductions into a 160+ page PDF resource.

Download now

Understanding OBD2 Standards: A Layered Approach

OBD2 operates as a higher-layer protocol, much like a language used for communication. In contrast, CAN bus is the communication method, the “phone line” if you will. This is similar to other CAN-based higher-layer protocols like J1939 (used in heavy-duty vehicles), CANopen (for industrial automation), and NMEA 2000 (for marine electronics).

OBD2 standards define various aspects, including:

OBD2 Connector: The physical interface for accessing vehicle data.
Lower-layer Protocols: The communication methods used to transmit data (e.g., CAN bus).
OBD2 Parameter IDs (PIDs): Codes used to request specific data parameters.

These standards can be visualized using the 7-layer OSI model, a conceptual framework for network communication. Notably, both SAE (Society of Automotive Engineers, US standards) and ISO (International Organization for Standardization, international standards) contribute to OBD2 specifications, often with technically equivalent standards (e.g., SAE J1979 vs. ISO 15031-5 for diagnostic services, SAE J1962 vs. ISO 15031-3 for the connector).

Alt text: OSI model diagram comparing OBD2 and CAN bus standards, highlighting ISO 15765 and ISO 11898 layers.

Alt text: OBD2 connector pinout diagram, Type A female socket, detailing pin assignments for Data Link Connector (DLC).

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

The 16-pin OBD2 connector, formally specified in SAE J1962 / ISO 15031-3, is your physical access point to your car’s diagnostic data. This standardized connector simplifies the process of retrieving information from your vehicle.

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

Location: Usually located near the steering wheel, though its exact placement can vary and may sometimes be hidden behind a panel.
Pin 16: Provides battery power, often even when the ignition is off, allowing scanners to operate.
Pinout Variation: The specific pinout configuration can differ depending on the communication protocol used by the vehicle.
CAN Bus Connection: In vehicles using CAN bus (the most common protocol), pins 6 (CAN-High) and 14 (CAN-Low) are used for communication.

OBD2 Connector Types: A vs. B

In practice, you might encounter two main types of OBD2 connectors: Type A and Type B. Type A is predominantly used in cars and light-duty vehicles, while Type B is more common in medium and heavy-duty vehicles.

While both types share a similar pinout for data communication, they differ in their power supply outputs: Type A typically provides 12V, while Type B provides 24V. Baud rates can also vary, with cars commonly using 500 Kbps and heavy-duty vehicles often using 250 Kbps (though 500 Kbps support is increasing in heavier vehicles).

Visually distinguishing between Type A and Type B connectors is possible by noting that Type B connectors have an interrupted groove in the center. This physical difference means that a Type B OBD2 adapter cable is generally compatible with both Type A and Type B sockets, whereas a Type A adapter will not fit into a Type B socket.

Alt text: Diagram comparing OBD2 Connector Type A and Type B, highlighting differences in groove, voltage (12V/24V), and vehicle application (car/truck).

Alt text: Graphic illustrating the relationship between OBD2 and CAN bus, emphasizing ISO 15765 as the standard for OBD2 over CAN.

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

Since 2008, CAN bus (Controller Area Network) has become the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as defined by ISO 15765.

ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies a set of constraints and guidelines for implementing OBD2 communication over CAN bus (ISO 11898). It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers. Key specifications include:

CAN Bit-rate: Must be either 250 Kbps or 500 Kbps.
CAN IDs: Supports both 11-bit (standard) and 29-bit (extended) CAN identifiers.
Specific CAN IDs for OBD: Defines reserved CAN IDs for OBD2 requests and responses.
Data Frame Length: Diagnostic CAN frames must have a data length of 8 bytes.
Adapter Cable Length: OBD2 adapter cables are limited to a maximum length of 5 meters.

OBD2 CAN Identifiers: 11-bit and 29-bit

OBD2 communication relies on a request-response messaging system.

In most passenger cars, 11-bit CAN IDs are used for OBD2. The “Functional Addressing” ID, 0x7DF, is a broadcast request asking all OBD2-compatible Electronic Control Units (ECUs) if they have data 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 (ECM – Engine Control Module), followed by 0x7E9 (TCM – Transmission Control Module).

Some vehicles, particularly vans and light, medium, and heavy-duty trucks, may use 29-bit extended CAN identifiers for OBD2 communication instead of 11-bit IDs.

In 29-bit CAN, the “Functional Addressing” ID is 0x18DB33F1.

Responses in 29-bit CAN typically use IDs ranging from 0x18DAF100 to 0x18DAF1FF, with common response IDs being 0x18DAF110 and 0x18DAF11E. These 29-bit response IDs are sometimes represented in the ‘J1939 PGN’ (Parameter Group Number) format, specifically PGN 0xDA00 (55808), which is designated as “Reserved for ISO 15765-2” in the J1939-71 standard.

Alt text: Diagram illustrating OBD2 protocol request and response frames, showing PID data and parameters exchange.

Alt text: Comparison graphic highlighting the difference between OBD2 and proprietary OEM-specific CAN bus protocols in vehicles.

OBD2 vs. Proprietary CAN Protocols: What’s the Difference?

It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) do not rely on OBD2 for their primary functions. Instead, each Original Equipment Manufacturer (OEM) implements its own proprietary CAN protocols for internal vehicle communication. These proprietary protocols are often specific to the vehicle brand, model, and year. This OEM-specific CAN data is generally not publicly documented and requires reverse engineering to interpret.

When you connect a CAN bus data logger to your car’s OBD2 port, you might observe this OEM-specific CAN data, typically transmitted at high rates (1000-2000 frames per second). However, in many newer vehicles, a ‘gateway’ module filters and restricts access to this proprietary CAN data through the OBD2 port, allowing only OBD2 communication.

In essence, think of OBD2 as an “add-on” higher-layer protocol that operates alongside the OEM’s primary, proprietary CAN protocol.

Bit-rate and ID Validation: Ensuring Proper Communication

As mentioned, OBD2 over CAN can utilize two bit-rates (250 Kbps, 500 Kbps) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern cars commonly use 500 Kbps and 11-bit IDs, but diagnostic tools should systematically verify the correct combination for each vehicle.

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

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

To distinguish between OBDonEDS and OBDonUDS, diagnostic tools 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 (often referred to as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars today, while WWH-OBD is primarily used in EU trucks and buses.

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

Alt text: Diagram showing the five lower-layer OBD2 protocols: CAN (ISO 15765), KWP2000, SAE J1850 VPW, SAE J1850 PWM, and ISO 9141.

Five Lower-Layer OBD2 Protocols: Beyond CAN

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

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

ISO-TP: Transporting OBD2 Messages Beyond 8 Bytes [ISO 15765-2]

OBD2 communication over CAN bus utilizes a transport protocol called ISO-TP (ISO 15765-2). This protocol is essential because it enables the transmission of data payloads larger than the 8-byte limit of a standard CAN frame. This is necessary for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often require more than 8 bytes of data.

ISO-TP handles segmentation (breaking large messages into smaller CAN frames), flow control (managing data transmission rate), and reassembly (putting fragmented messages back together). For a more detailed explanation of ISO-TP, refer to our introduction to UDS (Unified Diagnostic Services).

However, many OBD2 data requests and responses fit 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 – Protocol Control Information) indicates the payload length (excluding padding), leaving 7 bytes available for OBD2-related communication.

Alt text: Diagram illustrating ISO 15765-2 ISO-TP frame types used in OBD2 communication, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

Decoding the OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]

To understand what OBD2 can tell you, it’s helpful to examine the structure of a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message comprises:

Identifier (CAN ID): Identifies the message source and destination.
Data Length (PCI Field): Specifies the length of the data payload.
Data Payload: Contains the actual OBD2 information, structured as:
- Mode (Service): Indicates the type of diagnostic service being requested or responded to.
- Parameter ID (PID): Identifies the specific data parameter being requested or reported.
- Data Bytes: Contain the actual data values for the requested parameter.

Alt text: Breakdown of an OBD2 message structure, explaining the components: CAN ID, PCI field, Mode, PID, and Data Bytes.

Example: OBD2 Request and Response in Action

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

Request: An external diagnostic tool sends a request message to the car using CAN ID 0x7DF. The payload contains two bytes:
- Mode: 0x01 (Show current data)
- PID: 0x0D (Vehicle Speed)
Response: The car’s ECU responds using CAN ID 0x7E8. The response payload contains three bytes:
- Mode (Response): 0x41 (0x01 + 0x40, indicating a response to mode 0x01)
- Data Byte 1 (Vehicle Speed): 0x32 (which is 50 in decimal).

By consulting the OBD2 PID documentation for PID 0x0D, we find that the value 0x32 represents a vehicle speed of 50 km/h. This example demonstrates how OBD2 can tell you the current speed of the vehicle.

Alt text: Example of OBD2 request (CAN ID 7DF) and response (CAN ID 7E8) messages for vehicle speed (PID 0D).

Alt text: Detailed example of OBD2 PID 0D (Vehicle Speed), showing request and response data and decoding of the speed value.

Alt text: Chart listing the 10 OBD2 service modes (diagnostic services), including current data, freeze frame data, and DTC clearing.

The 10 OBD2 Services (Modes): Requesting Different Types of Information

OBD2 defines 10 diagnostic services, also referred to as modes. Each mode provides access to different categories of diagnostic information:

Mode 0x01: Show current data: Provides real-time sensor data and vehicle parameters. This is how OBD2 can tell you things like engine temperature, speed, RPM, and sensor readings.
Mode 0x02: Show freeze frame data: Displays data captured when a DTC was set, providing a snapshot of conditions at the time of a fault.
Mode 0x03: Show stored Diagnostic Trouble Codes (DTCs): Retrieves currently active DTCs that are causing the check engine light to be on. OBD2 can tell you what specific problems your car has detected.
Mode 0x04: Clear Diagnostic Trouble Codes and stored values: Resets the check engine light and clears stored DTCs and freeze frame data.
Mode 0x05: Test oxygen sensor monitoring results: Provides results from oxygen sensor tests.
Mode 0x06: Test non-continuous monitoring system results: Shows results for tests that run intermittently.
Mode 0x07: Request control of on-board system or component: Used for activating specific system tests (less commonly used in basic OBD2 scanning).
Mode 0x08: Request control of on-board system, test or component: Similar to mode 0x07.
Mode 0x09: Request vehicle information: Retrieves vehicle-specific information like VIN and calibration IDs. OBD2 can tell you your car’s VIN and other identifying details.
Mode 0x0A: Request permanent Diagnostic Trouble Codes: Retrieves DTCs that cannot be cleared by normal means.

Important Note: Vehicles are not required to support all 10 OBD2 modes, and manufacturers may also implement OEM-specific modes beyond these standardized ones.

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

OBD2 Parameter IDs (PIDs): Requesting Specific Data Points

Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the exact data parameter you want to access.

For example, within mode 0x01 (Show current data), there are hundreds of standardized PIDs that provide real-time information on various vehicle parameters, such as vehicle speed, engine RPM, intake manifold pressure, coolant temperature, and fuel level. However, vehicles are not required to support all PIDs within a given mode, and in practice, most vehicles only support a subset of the standardized PIDs.

One PID stands out as particularly important: PID 0x00 in mode 0x01. If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. When you request PID 0x00, the vehicle’s ECU responds by indicating which PIDs within the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental tool for testing OBD2 compatibility and discovering supported PIDs. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for subsequent ranges of mode 0x01 PIDs.

Alt text: Diagram illustrating OBD2 request and response frames, emphasizing PID data and parameter exchange for specific information retrieval.

Alt text: Screenshot of an OBD2 PID overview tool, showing service 01 PIDs and their descriptions for easy lookup.

Tip: Leveraging an OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 contain detailed scaling and decoding information for standard OBD2 PIDs. This information is crucial for converting the raw data bytes received from OBD2 responses into meaningful physical values.

To simplify the process of working with mode 0x01 PIDs, we offer a free OBD2 PID overview tool. This tool helps you construct OBD2 request frames and dynamically decode OBD2 responses, making it easier to understand what OBD2 can tell you about your vehicle’s real-time data.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 Data

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

To get started, connect the CANedge to your vehicle’s OBD2 port using an OBD2-DB9 adapter cable.

Alt text: Diagram showing an OBD2 PID data logger making a request (7DF) and receiving a response (7E8) for data logging.

Alt text: Screenshot showing bit-rate validation during OBD2 testing, confirming successful CAN frame transmission.

You can send a CAN frame at e.g. 500K, then check if it is successfully sent

Alt text: Screenshot from asammdf software showing OBD2 validation PID test responses, displaying supported PIDs from the vehicle.

The responses to ‘Supported PIDs’ can be reviewed in asammdf

‘Supported PIDs’ results can be decoded via our OBD2 PID lookup tool

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

As discussed earlier, ISO 15765-4 outlines a process to determine the correct bit-rate and CAN IDs for OBD2 communication with a specific vehicle. You can use the CANedge to perform these validation steps:

Bit-rate Test: Send a CAN frame at 500 Kbps and check for successful transmission. If unsuccessful, try 250 Kbps.
Bit-rate Selection: Use the validated bit-rate for all subsequent communication.
Supported PIDs Discovery: Send multiple ‘Supported PIDs’ requests (mode 0x01 PID 0x00, PID 0x20, etc.) and analyze the responses.
CAN ID Type Determination: Based on the response CAN IDs (e.g., 11-bit 0x7E8 or 29-bit 0x18DAF110), determine whether the vehicle uses 11-bit or 29-bit CAN IDs for OBD2.
Supported PID Identification: Analyze the response data to identify the specific PIDs supported by your vehicle.

We provide pre-configured CANedge configurations to streamline these tests. Most non-EV cars manufactured after 2008 typically support 40-80 PIDs using a 500 Kbps bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

As illustrated in the asammdf GUI screenshot, you may observe multiple responses to a single OBD2 request, especially when using the functional addressing ID 0x7DF. This is because the 0x7DF request polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, you’ll often see multiple responses to this PID in particular. As you request subsequent ‘Supported PIDs’ (e.g., 0x20, 0x40), fewer ECUs may respond. Notice that in the example, the ECM ECU (0x7E8) supports all the PIDs supported by other ECUs. Therefore, to reduce bus load, you can optimize communication by directing subsequent requests specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configure OBD2 PID Requests for Data Logging

Once you’ve identified the supported OBD2 PIDs, bit-rate, and CAN IDs for your vehicle, you can configure your data logger to request the specific PIDs you want to log.

Consider these factors when configuring your PID requests:

CAN ID Optimization: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to target specific ECUs and avoid redundant responses.
Request Spacing: Introduce a delay of 300-500 milliseconds between consecutive OBD2 requests. Sending requests too rapidly (spamming) can overwhelm ECUs and cause them to stop responding.
Battery Drain Management: Implement triggers to stop transmitting OBD2 requests when the vehicle is inactive (e.g., ignition off) to prevent unnecessary ECU wake-up and battery drain.
Data Filtering: Apply filters to record only OBD2 responses if your vehicle also transmits OEM-specific CAN data that you don’t need to log.

With these configurations in place, your data logger is ready to capture raw OBD2 data!

Alt text: Example of a CANedge OBD2 PID request transmit list configuration, showing PIDs and request parameters.

Alt text: asammdf software visualization of decoded OBD2 data plotted over time, using a DBC file for CAN bus signal interpretation.

Step #3: DBC Decode Raw OBD2 Data for Analysis

To analyze and visualize your logged OBD2 data, you need to convert the raw data bytes into human-readable ‘physical values’ (e.g., km/h, °C, RPM). This process is called DBC decoding.

The necessary decoding information is defined in ISO 15031-5/SAE J1979 and is also available in resources like Wikipedia. To simplify decoding, we provide a free OBD2 DBC file. This DBC file can be used with most CAN bus software tools to automatically decode raw OBD2 data.

Decoding OBD2 data is slightly more complex than decoding standard CAN signals. This is because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is not sufficient to identify the signal within the payload.

To correctly decode OBD2 data, you need to consider the CAN ID, OBD2 mode, and OBD2 PID together. This is a form of multiplexing known as ‘extended multiplexing‘, which can be implemented in DBC files.

CANedge: Your Dedicated OBD2 Data Logger

The CANedge provides a simple and efficient solution for logging OBD2 data directly to an 8-32 GB SD card. Just connect it to your car or truck’s OBD2 port to start recording. You can then use our free software and APIs along with our OBD2 DBC file to decode and analyze your data.

OBD2 logger intro CANedge

Multi-Frame OBD2 Communication Examples [ISO-TP]

Most of the OBD2 examples we’ve discussed so far involve single-frame communication. However, some OBD2 requests and responses require multi-frame communication using the ISO-TP transport protocol (ISO 15765-2).

Multi-frame OBD2 communication necessitates the use of flow control frames (see our UDS intro for details). In practice, you can often implement flow control by transmitting a static flow control frame approximately 50 milliseconds after the initial request frame, as demonstrated in the CANedge configuration example.

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

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

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

The Vehicle Identification Number (VIN) is a crucial piece of vehicle information used in telematics, diagnostics, and other applications. You can retrieve the VIN using OBD2 mode 0x09 and PID 0x02:

Request: The diagnostic tool sends a Single Frame request with:
- PCI Field: 0x02 (Single Frame, 2 bytes payload)
- Service ID (Mode): 0x09 (Request Vehicle Information)
- PID: 0x02 (Vehicle Identification Number)
Response: The vehicle responds with a multi-frame response:
- First Frame:
  - PCI: Indicates First Frame
  - Length: 0x014 (20 bytes total response length)
  - Mode (Response): 0x49 (0x09 + 0x40)
  - PID: 0x02
  - NODI: 0x01 (Number Of Data Items – 1 in this case)
  - VIN Data (Bytes 1-17): The 17-byte VIN encoded in HEX.

The VIN data bytes can then be converted from HEX to ASCII characters to obtain the human-readable VIN.

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

OBD2 allows diagnostic tools to request 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) in a multi-frame response if necessary.

This multi-PID request feature can increase data acquisition efficiency, but it also introduces complexity in data decoding, making generic OBD2 DBC files less suitable. We generally do not recommend this approach for practical data logging due to the decoding challenges.

The multi-frame response structure is similar to the VIN example, but the payload includes the requested PIDs themselves, followed by the data values for each PID. The PIDs in the response are typically ordered to match the request order, but this is not strictly mandated by the ISO 15031-5 standard.

Decoding multi-PID responses using generic DBC files is very difficult and not recommended for practical data logging unless you are using specialized tools with built-in support for this method. The data encoding becomes highly specific to the request method, making it challenging to generalize decoding across different vehicles or requests.

Example 3: Diagnostic Trouble Codes (DTCs) – Understanding Vehicle Faults

OBD2 mode 0x03 (“Show stored Diagnostic Trouble Codes”) is used to retrieve emissions-related DTCs. No PID is included in the request. The ECU(s) will respond with the number of stored DTCs (which could be zero if no DTCs are active) and the DTC codes themselves, with each DTC occupying 2 data bytes. Multi-frame responses are required if more than 2 DTCs are stored.

The 2-byte DTC value is structured according to ISO 15031-5/ISO 15031-6. The first two bits define the DTC category (e.g., Powertrain, Chassis, Body, Network), while the remaining 14 bits represent a 4-digit code (displayed in hexadecimal). Decoded DTC values can be looked up in online OBD2 DTC lookup tools like repairpal.com to understand the specific fault indicated.

Alt text: Diagram explaining OBD2 DTC (Diagnostic Trouble Code) decoding and interpretation using a DBC file example.

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

Real-World Applications: OBD2 Data Logging Use Cases

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

Alt text: Graphic depicting an OBD2 data logger connected to a car, symbolizing on-board diagnostics and data collection.

Vehicle Data Logging and Analysis

OBD2 data logging can provide valuable insights for:

Fuel Efficiency Optimization: Analyze driving patterns and engine parameters to identify areas for fuel consumption reduction.
Driver Behavior Improvement: Monitor driving habits to promote safer and more efficient driving styles.
Prototype Testing and Validation: Collect real-world vehicle data for testing and validating new automotive components or software.
Insurance Telematics: Gather driving data for usage-based insurance programs and risk assessment.

obd2 logger

Alt text: Illustration of OBD2 real-time streaming diagnostics via USB connection, showcasing live vehicle data analysis.

Real-time Vehicle Diagnostics and Monitoring

OBD2 interfaces enable real-time streaming of vehicle data for:

Live Diagnostics: Monitor vehicle parameters in real-time to diagnose issues and troubleshoot problems on the go.
Performance Monitoring: Track engine performance metrics for tuning, optimization, and performance analysis.
Custom Dashboards: Create personalized dashboards displaying real-time vehicle data for driver information and feedback.

obd2 streaming

Alt text: Graphic representing OBD2 data logger for predictive maintenance and telematics, highlighting IoT integration for remote monitoring.

Predictive Maintenance and Fleet Management

Predictive Maintenance: Cloud-connected OBD2 loggers can enable predictive maintenance by monitoring vehicle health and predicting potential breakdowns before they occur.
Fleet Management: Track vehicle location, usage, and health for optimized fleet operations and maintenance scheduling.

predictive maintenance

Alt text: Image of a black box CAN bus data logger, symbolizing vehicle event recording for insurance and warranty purposes.

Vehicle Black Box and Event Recording

Black Box Functionality: OBD2 loggers can act as ‘black boxes’ for vehicles, recording data in the event of accidents or incidents for analysis and dispute resolution.
Warranty and Liability: Provide objective vehicle data for warranty claims and liability assessments.

can bus blackbox

Do you have an OBD2 data logging use case in mind? We’re here to help! Reach out for a free consultation.

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

Ready to leverage OBD2 data?

Get your OBD2 data logger today!

Buy now Contact us

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[

Decoding Your Car’s Health: What Can an OBD2 Scanner Tell You?

In this article