Unlock Full OBD2 Functions: A Comprehensive Guide to Vehicle Diagnostics

Need a deep dive into OBD2 and its extensive capabilities?

This comprehensive guide explores the On-Board Diagnostics 2 (OBD2) protocol, covering everything from the OBD2 connector and Parameter IDs (PIDs) to its crucial link with the CAN bus.

Dive in for a detailed understanding of how to access and utilize Full Obd2 Functions for advanced vehicle diagnostics, data logging, and performance analysis. Discover why this guide is considered the ultimate resource for mastering OBD2 technology.

You can also watch our OBD2 overview video above – or download the PDF guide for offline access.

Understanding the Power of OBD2: What is it?

OBD2 is your car’s sophisticated, built-in diagnostic system. It’s a standardized protocol designed to provide comprehensive access to vehicle health data. Through the OBD2 connector, you can tap into a wealth of information, from retrieving diagnostic trouble codes (DTCs) to monitoring real-time parameters. It’s the key to unlocking full OBD2 functions.

You’ve likely encountered OBD2 in action without even realizing it. The check engine light on your dashboard? That’s OBD2 signaling a potential issue. When you visit a mechanic, their primary tool for diagnosing problems is an OBD2 scanner.

Mechanics connect an OBD2 reader to the OBD2 16-pin connector, typically located near the steering wheel. This tool sends ‘OBD2 requests’ to the vehicle’s computer, and the car responds with ‘OBD2 responses’. These responses contain crucial data such as speed, fuel level, and Diagnostic Trouble Codes (DTCs), enabling efficient and accurate troubleshooting. This interaction is at the heart of accessing full OBD2 functions.

Image showing a malfunction indicator light (MIL) or check engine light on a car dashboard, highlighting the visual cue for OBD2 system alerts.

OBD2 Compatibility: Is Your Car Equipped?

The answer is, for most modern vehicles, almost certainly yes!

Nearly all gasoline and diesel cars manufactured in recent decades support OBD2, and many utilize the CAN bus communication protocol. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t guarantee full OBD2 compliance. Some older connectors might not support the complete OBD2 protocol suite. A key indicator of OBD2 compliance is the vehicle’s manufacturing origin and year:

Infographic illustrating OBD2 compliance timelines for vehicles based on region (EU, US) and vehicle type, helping users determine if their car supports OBD2.

A Look Back: The History of OBD2

The origins of OBD2 can be traced back to California, driven by the California Air Resources Board (CARB). Recognizing the need for enhanced emission control, CARB mandated OBD systems in all new cars starting from 1991.

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

The OBD2 standard was progressively implemented across the automotive industry:

1996: OBD2 became mandatory in the USA for all cars and light trucks.
2001: The European Union mandated OBD2 for gasoline cars.
2003: OBD2 requirements expanded in the EU to include diesel cars (known as EOBD).
2005: OBD2 compliance was extended in the US to medium-duty vehicles.
2008: US regulations required vehicles to adopt ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 became mandatory in the US for heavy-duty vehicles, completing its widespread adoption.

Diagram illustrating the historical progression of OBD2 development, emphasizing its roots in emission control and expansion to broader vehicle diagnostics.

Timeline visualization summarizing key milestones in OBD2 history, from its inception to widespread adoption across vehicle categories and regions.

Conceptual image representing the future of OBD, hinting at OBD3 with elements like cloud connectivity, remote diagnostics, and IoT integration for enhanced vehicle monitoring.

The Future Trajectory of OBD2

OBD2 is firmly established as a cornerstone of vehicle diagnostics, but its evolution continues. However, its future form is subject to change.

Initially designed for emission control and testing, legislated OBD2 requirements don’t inherently extend to electric vehicles. Consequently, most modern EVs do not support standard OBD2 requests. Instead, they often utilize OEM-specific UDS communication protocols. This shift makes accessing data from EVs challenging without OEM-specific tools or reverse-engineered solutions. However, initiatives are emerging to bridge this gap, as seen in case studies for electric cars including brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Current OBD2 implementations face limitations in data richness and reliance on older lower-layer protocols. To address these, modern alternatives like WWH-OBD (World-Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging. These protocols aim to modernize OBD communication by building upon the UDS protocol, offering enhanced capabilities. Learn more about these advancements in our introduction to UDS.

In our increasingly connected world, traditional OBD2 testing methods can seem outdated. Manual emission checks are time-intensive and costly.

The proposed solution? OBD3 – integrating telematics into every vehicle.

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

Many devices today 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 offering convenience and cost savings, OBD3 raises political and privacy concerns related to surveillance.

The original OBD2 protocol was designed for in-garage emission testing.

However, today, third-party applications extensively utilize OBD2 for real-time data acquisition through OBD2 dongles, CAN loggers and similar devices. Interestingly, the German car industry is seeking to restrict this third-party access:

OBD was intended for car servicing in repair shops. It was never designed to allow third parties to build a data-driven economy based on access through this interface.“

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal suggests disabling OBD2 functionality during driving, centralizing data collection within manufacturer-controlled servers. This would give manufacturers control over ‘automotive big data’.

Arguments for this shift cite security concerns, such as mitigating the risk of car hacking), although many perceive it as a commercially motivated move. The future of OBD2 and third-party data access remains uncertain, potentially disrupting the market for OBD2-based services.

Illustration depicting the potential future trend of electric vehicles limiting OBD2 data access, symbolized by a removed OBD2 connector in an EV context.

Enhance Your Knowledge: The ‘Ultimate CAN Guide’

Ready to become a CAN bus expert and fully understand OBD2 within this framework?

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

Download now

Decoding OBD2 Standards

On-board diagnostics, OBD2, operates as a higher-layer protocol – essentially, a language for vehicle communication. CAN (Controller Area Network) serves as the communication method, similar to a phone line. This places OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

OBD2 standards meticulously define the OBD2 connector, lower-layer protocols, OBD2 Parameter IDs (PIDs), and numerous other specifications essential for accessing full OBD2 functions.

These standards can be organized using the 7-layer OSI model. The following sections will concentrate on the most critical aspects of these standards.

In the OSI model overview, you’ll notice that both SAE and ISO standards cover multiple layers. This reflects the standardization efforts for OBD in the US (SAE) and Europe (ISO). Many of these standards are technically very similar, for instance, SAE J1979 and ISO 15031-5, as well as SAE J1962 and ISO 15031-3.

Diagram illustrating the relationship between OBD2 and CAN bus within the 7-layer OSI model, showing the relevant ISO and SAE standards for each layer.

Detailed pinout diagram of a Type A OBD2 connector socket, labeled with pin numbers and descriptions for understanding connector wiring and functionalities.

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector serves as your gateway to accessing vehicle data, standardized under SAE J1962 / ISO 15031-3.

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

Key points to note about the OBD2 connector:

It’s usually located near the steering wheel, but sometimes may be hidden behind a panel.
Pin 16 provides battery power, often remaining active even when the ignition is off.
The OBD2 pinout configuration varies depending 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 commonly connected.

OBD2 Connector Types: A vs. B

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

As shown in the illustration, both types have 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 typically using 500K, while heavy-duty vehicles often use 250K (with increasing support for 500K in newer models).

Visually distinguishing them, the Type B OBD2 connector has an interrupted groove in the middle. 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.

Diagram comparing Type A and Type B OBD2 connectors, highlighting differences in physical appearance, voltage (12V vs 24V), and typical vehicle applications (car vs. truck).

Visual representation contrasting OBD2 and CAN bus, emphasizing ISO 15765 as the standard bridging the two for vehicle diagnostics and communication.

OBD2 and CAN Bus Integration: ISO 15765-4

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as mandated by ISO 15765.

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

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

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

OBD2 CAN Identifiers: 11-bit and 29-bit

All OBD2 communication relies on a request/response message exchange.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, which broadcasts a request to all OBD2-compatible ECUs, asking if they have data for the requested parameter (per ISO 15765-4). In contrast, CAN IDs 0x7E0-0x7E7 facilitate ‘Physical Addressing’ requests to specific ECUs (less commonly used).

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 medium/heavy-duty vehicles, may utilize extended 29-bit CAN identifiers for OBD2 communication instead of 11-bit IDs.

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

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

Diagram illustrating the OBD2 request-response communication flow, showcasing the structure of request and response frames with parameters and PIDs.

Conceptual graphic differentiating OBD2 CAN bus data from proprietary OEM-specific CAN bus data, highlighting that OBD2 is a standardized subset within the broader vehicle CAN network.

OBD2 vs. Proprietary CAN Protocols

It’s crucial to understand that your vehicle’s electronic control units (ECUs) operate independently of OBD2 for their core functions. Original Equipment Manufacturers (OEMs) implement their own proprietary CAN protocols for internal vehicle communication. These proprietary CAN protocols are often unique to the vehicle brand, model, and year. Unless you are the OEM, interpreting this proprietary data is typically not possible without reverse engineering efforts.

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

In essence, think of OBD2 as an ‘additional’ higher-layer protocol that operates alongside the OEM-specific protocol. It provides a standardized interface for diagnostics without interfering with the vehicle’s core communication network.

Bit-rate and ID Validation for Reliable OBD2 Access

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

ISO 15765-4 outlines a systematic initialization sequence to determine the correct combination, illustrated in the flowchart below. This method leverages the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit-rates will cause CAN error frames.

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

To distinguish between OBDonEDS and OBDonUDS protocols, diagnostic tools may send additional request messages, specifically UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS must have ECUs that respond to this DID.

In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-electric vehicles today, while WWH-OBD is primarily used in EU trucks and buses.

Flowchart depicting the systematic process for OBD2 bit-rate and CAN ID validation as per ISO 15765-4, guiding diagnostic tools in establishing correct communication parameters.

Diagram illustrating the five lower-layer OBD2 protocols (CAN, KWP2000, SAE J1850 VPW/PWM, ISO9141), highlighting CAN (ISO 15765) as the dominant modern standard.

Five Lower-Layer OBD2 Protocols: A Historical Perspective

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

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and now the most widely used OBD2 protocol.
ISO 14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, particularly in Asia.
ISO 9141-2: Used in European, Chrysler, and Asian vehicles manufactured between 2000-2004.
SAE J1850 (VPW – Variable Pulse Width Modulation): Predominantly 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)

All OBD2 data communication over CAN bus relies on the ISO-TP (ISO 15765-2) transport protocol. This protocol enables the transmission of data payloads exceeding the 8-byte CAN frame limit. This capability is essential in OBD2 for operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often require larger data packets. ISO 15765-2 manages data segmentation, flow control, and reassembly. For a more in-depth understanding, refer to our introduction to UDS.

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

Diagram illustrating different ISO-TP frame types used in OBD2 communication, including Single Frame (SF), First Frame (FF), Consecutive Frame (CF), and Flow Control (FC) for managing data transport.

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

To effectively utilize full OBD2 functions, understanding the structure of an OBD2 message on CAN is crucial. Consider a simplified ‘Single Frame’ OBD2 CAN message. It consists of a CAN identifier, a data length indicator (PCI field), and the data payload. The data payload is further structured into Mode, Parameter ID (PID), and data bytes.

Breakdown of an OBD2 message structure, dissecting it into CAN ID, PCI field (data length), Mode, PID, and data bytes to clarify message composition.

Example: OBD2 Request and Response in Action

Let’s examine a practical example of an OBD2 request and response for retrieving ‘Vehicle Speed’.

An external diagnostic tool sends a request message to the car with CAN ID 0x7DF and a 2-byte payload: Mode 0x01 and PID 0x0D. The car responds with a message via CAN ID 0x7E8 and a 3-byte payload. This response includes the ‘Vehicle Speed’ value in the 4th byte, which is 0x32 (decimal 50).

Referring to the OBD2 PID decoding specifications for PID 0x0D, we can determine that the physical value represents a vehicle speed of 50 km/h.

Next, we will delve deeper into OBD2 modes and PIDs, which are fundamental to accessing full OBD2 functions.

Example of an OBD2 request-response sequence for vehicle speed, showing the request frame (CAN ID 7DF) with Mode 01 and PID 0D, and the response frame (CAN ID 7E8) containing the speed value.

Detailed example focusing on OBD2 PID 0D (Vehicle Speed), illustrating the PID value, data bytes, and the conversion process to obtain the physical speed value.

Infographic summarizing the 10 OBD2 service modes (modes 01-0A), listing their functions such as showing current data, freeze frame data, clearing DTCs, and on-board monitoring tests.

The 10 Essential OBD2 Services (Modes)

OBD2 defines 10 diagnostic services, also known as modes, each designed for specific diagnostic tasks. Mode 0x01 provides access to real-time data, while other modes are used for retrieving and clearing diagnostic trouble codes (DTCs), accessing freeze frame data, and conducting on-board system tests. These modes are the foundation for utilizing full OBD2 functions.

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

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

OBD2 Parameter IDs (PIDs): Accessing Specific Data Points

Within each OBD2 mode, Parameter IDs (PIDs) are used to specify particular data points or diagnostic information you want to access.

For example, mode 0x01 encompasses approximately 200 standardized PIDs providing real-time data on parameters like speed, RPM, engine temperature, and fuel level. However, vehicles are not obligated to support all standardized PIDs within a mode. In practice, most vehicles support only a subset of the available PIDs. Understanding supported PIDs is crucial to effectively use full OBD2 functions.

One PID holds special significance: mode 0x01 PID 0x00. If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID, the ECU indicates its support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for subsequent ranges of mode 0x01 PIDs.

(Re-used image, already described above)

Screenshot of an OBD2 PID overview tool, showcasing its interface for service 01, likely demonstrating how to look up and interpret PID data for diagnostics.

Practical Resource: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 detail the scaling and conversion formulas for standard OBD2 PIDs, essential for decoding raw data into meaningful physical values, as we discussed in our CAN bus introduction.

For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is invaluable. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses, simplifying the process of accessing full OBD2 functions.

OBD2 PID overview tool

Step-by-Step Guide: Logging and Decoding OBD2 Data

This section provides a practical demonstration of logging OBD2 data using the CANedge CAN bus data logger. The CANedge’s configurable CAN frame transmission capability makes it ideal for OBD2 data logging.

Connecting the CANedge to your vehicle is straightforward using our OBD2-DB9 adapter cable.

Diagram illustrating the setup for OBD2 data logging using a CANedge logger, showing the connection to the OBD2 port and the flow of request (7DF) and response (7E8) messages.

Example image showing bit-rate validation for OBD2 communication, likely depicting a successful CAN frame transmission at 500K.

Screenshot from asammdf software showing OBD2 validation PID test responses, indicating successful communication and data retrieval.

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

As discussed earlier, ISO 15765-4 details how to determine the correct bit-rate and CAN IDs for a specific vehicle. You can use the CANedge to perform these tests as outlined below (refer to the CANedge Intro for detailed instructions):

Transmit a CAN frame at 500K and verify successful transmission (if unsuccessful, try 250K).
Use the identified bit-rate for all subsequent communication.
Send multiple ‘Supported PIDs’ requests (mode 0x01 PID 0x00) and analyze the responses.
Determine 11-bit or 29-bit CAN ID usage based on response IDs.
Identify supported PIDs from the response data to understand full OBD2 functions available.

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

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

As shown in the asammdf GUI screenshot, receiving multiple responses to a single OBD request is common when using the 0x7DF request ID, as it polls all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are typical. For subsequent ‘Supported PIDs’ requests, the number of responding ECUs generally decreases. Notice that the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs. To reduce busload, you can direct requests specifically to the ECM by using the ‘Physical Addressing’ CAN ID 0x7E0 for subsequent communication.

Step #2: Configure OBD2 PID Requests for Targeted Data Logging

Once you’ve identified the supported OBD2 PIDs for your vehicle, along with the correct bit-rate and CAN IDs, you can configure your transmit list with the specific PIDs you wish to log. This step is crucial for leveraging full OBD2 functions for data analysis.

Consider these points when configuring your OBD2 PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize redundant responses and focus on specific ECU data.
Spacing: Implement a delay of 300-500 ms between each OBD2 request to prevent overwhelming ECUs and ensure reliable responses.
Battery Drain: Utilize triggers to halt transmission when the vehicle is inactive, preventing unnecessary ECU wake-up and battery drain during extended logging sessions.
Filters: Apply filters to record only OBD2 responses, particularly if your vehicle also broadcasts OEM-specific CAN data, streamlining your data logs.

After configuration, your CANedge is ready to log raw OBD2 data efficiently.

Example configuration of a CANedge transmit list, showing OBD2 PID requests for specific parameters, likely including CAN IDs, PIDs, and transmission intervals.

Screenshot from asammdf software displaying visually plotted, DBC-decoded OBD2 data, showcasing parameters like speed and RPM from a CAN bus log file.

Step #3: DBC Decode Raw OBD2 Data for Analysis

To analyze and visualize your logged OBD2 data, you need to decode the raw data into ‘physical values’ (e.g., km/h, °C). This decoding process is essential to fully utilize full OBD2 functions for practical insights.

Decoding information is found in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, we offer a free OBD2 DBC file to simplify DBC decoding in most CAN bus software tools.

Decoding OBD2 data is more complex than standard CAN signals. Different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). The CAN ID alone is insufficient to uniquely identify the signals within the payload.

To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID to accurately identify each signal. This multiplexing technique, known as ‘extended multiplexing‘, is effectively implemented using DBC files.

CANedge: Your Dedicated OBD2 Data Logger

The CANedge provides a user-friendly solution for recording OBD2 data directly to an 8-32 GB SD card. Simply connect it to your vehicle (car or truck) to begin logging. Decode your data using free software/APIs and our OBD2 DBC.

OBD2 logger intro
CANedge Product Details

Advanced OBD2: Multi-Frame Examples with ISO-TP

OBD2 communication, as per ISO 15765-2, relies on ISO-TP for all data transmission. While many examples illustrate single-frame communication, multi-frame communication is essential for transmitting larger datasets. This section explores multi-frame examples, further demonstrating full OBD2 functions.

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

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

Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN), showing the initial request frame and subsequent flow control for multi-frame data transfer.

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

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and various vehicle-related applications (see our UDS intro for more). To retrieve the VIN using OBD2 requests, you utilize mode 0x09 and PID 0x02:

The diagnostic tool initiates 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, total length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for details). The remaining 17 bytes constitute the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction.

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

OBD2 allows external tools to request data for up to 6 mode 0x01 OBD2 PIDs within a single request frame. The ECU responds with data for the supported PIDs (omitting unsupported PIDs from the response), potentially using multi-frame responses via ISO-TP if needed. This capability expands full OBD2 functions for efficient data acquisition.

This powerful feature enables higher-frequency and more efficient data collection. However, the signal encoding becomes specific to your request method, making generic OBD2 DBC files less effective for such use cases. We generally advise against this method for practical applications unless specifically required. Below is an example trace illustrating this process:

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

Decoding these responses using generic DBC files is challenging. Therefore, we do not recommend this approach for practical data logging unless your tools specifically support it. This scenario represents extended multiplexing with multiple instances within the payload. Generalizing DBC files across vehicles with varying supported PIDs becomes very complex. Furthermore, managing multiple multi-PID requests using pure DBC manipulations becomes very difficult due to the lack of a method to uniquely identify these messages.

Workarounds involve custom scripts and recording transmit messages from your testing tool. The script could then interpret the response message in conjunction with the corresponding request message. However, such approaches are generally difficult to scale and manage for large-scale data logging.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval

You can use OBD2 to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes’. No PID is included in the request. The targeted ECU(s) will respond with the number of stored DTCs (possibly 0 if no DTCs are stored). Each DTC is represented by 2 data bytes, necessitating multi-frame responses when more than 2 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 below. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.

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

Diagram illustrating OBD2 DTC decoding, breaking down the 2-byte DTC value into category bits and a 4-digit hexadecimal code for interpretation and troubleshooting.

Real-World Applications: OBD2 Data Logging Use Cases

OBD2 data from cars and light trucks enables a wide array of applications, leveraging full OBD2 functions for diverse purposes:

Vehicle Data Logging for Cars

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

OBD2 Logger Solutions

Real-time Vehicle Diagnostics

OBD2 interfaces facilitate real-time streaming of vehicle data in a human-readable format, ideal for diagnosing vehicle issues and monitoring performance.

OBD2 Real-time Streaming Interfaces

Predictive Maintenance for Fleets

Cars and light trucks equipped with IoT OBD2 loggers can be remotely monitored in the cloud for predictive maintenance, helping to prevent breakdowns and optimize fleet operations.

Predictive Maintenance Solutions

Vehicle Black Box Recording

An OBD2 logger can serve as a ‘black box’ for vehicles or equipment, providing crucial data for incident analysis, warranty validation, and diagnostic purposes.

CAN Bus Black Box Loggers

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

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

Ready to start logging and streaming OBD2 data?

Get your OBD2 data logger today!

Buy Now
Contact Us for Inquiries

Recommended Resources

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN