Understanding OBD2: Your Comprehensive Guide to On-Board Diagnostics

Need a straightforward and comprehensive guide to OBD2?

This guide provides an in-depth introduction to the On-Board Diagnostics 2 (OBD2) protocol, covering everything from the OBD2 connector and OBD2 Parameter IDs (PIDs) to its connection with the CAN bus system.

Note: This is designed to be a comprehensive guide to enhance your understanding of OBD2. You’ll also learn practical aspects such as requesting and decoding OBD2 data, key applications for logging, and actionable tips.

Discover why this guide is becoming a leading resource for mastering OBD2.

You can also watch our introductory OBD2 video above – or download this guide as a PDF

Article Contents

Author: Martin Falch (Updated January 2025)

Download this guide as PDF

What Exactly is OBD2?

OBD2 is essentially your vehicle’s integrated self-diagnostic system. It operates as a standardized protocol that enables the extraction of diagnostic trouble codes (DTCs) and real-time vehicle data through the OBD2 connector.

You’ve likely already encountered OBD2 in action:

Have you ever noticed the check engine light illuminate on your dashboard?

This light is your vehicle signaling that an issue has been detected. When you take your car to a mechanic, they will use an OBD2 scanner to pinpoint the problem.

This process involves connecting an OBD2 reader to the OBD2 16-pin connector, typically located near the steering wheel. The diagnostic tool transmits ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’. These responses can include critical data such as speed, fuel level, and Diagnostic Trouble Codes (DTCs), significantly speeding up the troubleshooting and repair process.

Image showing a dashboard malfunction indicator light (MIL) and an OBD2 scan tool, illustrating the use of OBD2 in diagnosing car issues.

OBD2 Compatibility: Is Your Car Equipped?

In short: Most likely, yes!

The vast majority of modern non-electric vehicles are equipped with OBD2 systems, and many of these operate on the CAN bus network. For older vehicles, it’s important to note that the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 support. Some may feature the connector but not fully adhere to the OBD2 protocol standards. To confirm OBD2 compliance, consider when and where your vehicle was originally purchased:

Infographic showing OBD2 compliance by region and year, indicating timelines for mandatory OBD2 adoption in the US and EU.

A Look at OBD2 History

The origins of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated the inclusion of On-Board Diagnostics in all new vehicles from 1991 onwards, primarily for emission control.

The OBD2 standard was further developed and recommended by the Society of Automotive Engineers (SAE), which played a crucial role in standardizing DTCs and the OBD connector across different vehicle manufacturers (SAE J1962).

From its Californian roots, the OBD2 standard progressively became a global requirement:

1996: OBD2 became mandatory in the USA for 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 was required in the US for medium-duty vehicles.
2008: All cars sold in the US were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 compliance was finally extended to heavy-duty vehicles in the US.

Diagram illustrating the history of OBD2, emphasizing its role in emission control and its evolution alongside automotive data and CAN bus technology.

Timeline infographic summarizing the key milestones in OBD2 history, from its inception to global mandates.

Conceptual image depicting the future of OBD, hinting at OBD3 and its integration with remote diagnostics, emissions testing, cloud technology, and IoT.

The Future of OBD2

OBD2 is firmly established in automotive diagnostics, but its future form is evolving. Here are key trends shaping its path:

Initially designed for emissions control and testing, legislated OBD2 faces a changing landscape, particularly with electric vehicles. Electric vehicles (EVs) are not required to support OBD2 in its traditional form, and in practice, very few modern EVs implement standard OBD2 requests. Instead, many EVs utilize OEM-specific UDS (Unified Diagnostic Services) communication protocols. This shift often makes accessing and decoding data from EVs challenging, except in cases where reverse engineering efforts have revealed the decoding rules. Our case studies on electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs, illustrate these complexities.

Recognizing the limitations of current OBD2 implementations, especially in data richness and lower-layer protocols, modern alternatives are emerging. WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are designed to enhance OBD communication by using the UDS protocol as a foundation. To delve deeper into these advanced protocols, refer to our introduction to UDS.

In an increasingly connected automotive world, traditional OBD2 testing methods appear inefficient. Manual emission control checks are time-consuming and costly.

The proposed solution is OBD3 – integrating telematics into all vehicles.

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

Many current devices, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger, already facilitate CAN or OBD2 data transfer via WiFi/cellular networks.

While this offers cost savings and convenience, it also raises political and privacy concerns related to surveillance.

The original OBD2 protocol was intended for stationary emission controls.

However, today, third-party services extensively utilize OBD2 for real-time data generation through OBD2 dongles, CAN loggers and similar devices. The German car industry is considering changes that could significantly alter 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 involves potentially disabling OBD2 functionality during normal driving, centralizing data collection within manufacturer-controlled servers. This would effectively place automotive manufacturers in control of the burgeoning ‘automotive big data’ ecosystem.

Arguments for this shift often cite security improvements, such as reducing the risk of car hacking. However, many perceive this move as commercially motivated. Whether this trend gains traction remains to be seen, but it has the potential to disrupt the market for third-party OBD2 services significantly.

Icon depicting an OBD2 connector being removed from an electric vehicle, symbolizing the potential shift in data access and diagnostics for EVs.

Enhance Your OBD2 Expertise with Our CAN Bus Guide

Want to become proficient in CAN bus technology?

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

Download Now

Understanding OBD2 Standards

On-board diagnostics, or OBD2, operates as a higher-layer protocol — akin to a language — while CAN bus serves as the communication method — comparable to a phone line. This analogy positions OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

Specifically, OBD2 standards define specifications for the OBD2 connector, lower-layer communication protocols, OBD2 Parameter IDs (PIDs), and more.

These standards can be organized within a 7-layer OSI model framework. The following sections will concentrate on the most critical standards.

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

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

Illustration of an OBD2 connector pinout, specifically a Type A female socket (Data Link Connector DLC), detailing pin assignments.

The OBD2 Connector: SAE J1962 Standard

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

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

Key features of the OBD2 connector include:

Location typically near the steering wheel, though it may be concealed.
Pin 16 provides battery power, often active even when the ignition is off.
Pinout configuration varies based on the communication protocol used.
CAN bus is the most prevalent lower-layer protocol, with pins 6 (CAN-H) and 14 (CAN-L) commonly connected.

OBD2 Connector Types: A vs. B

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.

While both types share similar OBD2 pinouts, they differ in power supply outputs: 12V for Type A and 24V for Type B. Baud rates can also vary, with cars typically using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing).

Visually, a Type B OBD2 connector is distinguished by an interrupted groove in the middle. A Type B OBD2 adapter cable is compatible with both Type A and B sockets, but a Type A connector will not fit into a Type B socket.

Diagram contrasting OBD2 Connector Type A and Type B, highlighting differences in voltage (12V vs 24V) and typical vehicle applications.

Conceptual illustration representing the relationship between OBD2 and CAN bus under the ISO 15765 standard.

OBD2 and CAN Bus: ISO 15765-4 Standard

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

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

Specifically, 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.
OBD2 adapter cable length is limited to 5 meters maximum.

OBD2 CAN Identifiers: 11-bit and 29-bit

OBD2 communication is structured around request/response message exchanges.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, used to query all OBD2-compatible ECUs to report data for the requested parameter (defined in ISO 15765-4). CAN IDs ranging from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’ requests directed to specific ECUs, though this is 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).

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

In these cases, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

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

Diagram illustrating the OBD2 request-response protocol, showing the flow of data parameters and PIDs between a scan tool and vehicle ECUs.

Illustration comparing OBD2 CAN bus data with OEM-specific proprietary CAN bus data, highlighting the differences in standardization and accessibility.

OBD2 vs. Proprietary CAN Protocols

It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) function independently of OBD2. Original Equipment Manufacturers (OEMs) implement their own proprietary CAN protocols for core vehicle operations. These CAN protocols are often specific to the vehicle’s brand, model, and year. Without OEM specifications, interpreting this proprietary data is typically not possible, unless through reverse engineering efforts.

When connecting a CAN bus data logger to your vehicle’s OBD2 connector, you might observe OEM-specific CAN data, typically broadcast at high frequencies (1000-2000 frames/second). However, newer vehicles often employ a ‘gateway’ system that restricts access to this OEM CAN data through the OBD2 port, allowing only standardized OBD2 communication.

In essence, OBD2 functions as a supplementary higher-layer protocol, operating alongside the OEM-specific protocol.

Bit-rate and ID Validation

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

ISO 15765-4 provides guidelines for an initialization sequence to determine the correct protocol combination, as shown in the flowchart. This process relies on the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section for details) and the fact that incorrect bit-rate transmission will cause CAN error frames.

Current versions of ISO 15765-4 consider that vehicles might 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) as opposed to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).

To differentiate between OBDonEDS and OBDonUDS protocols, diagnostic tools may send additional request messages, specifically UDS requests using 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, whereas 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 tool initialization.

Diagram showcasing the five lower-layer protocols used in OBD2, including CAN (ISO 15765), KWP2000, SAE J1850 (VPW & PWM), and ISO 9141, indicating protocol diversity in OBD2 systems.

Five Lower-Layer OBD2 Protocols

While CAN (ISO 15765) is the dominant lower-layer protocol for OBD2 in modern vehicles, older cars (pre-2008) may use one of four other protocols. Understanding these legacy protocols and their pinouts can be helpful when working with older vehicles:

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

ISO-TP for OBD2 Messaging: 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 limit of standard CAN frames. ISO-TP is essential in OBD2 for operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), where data often exceeds 8 bytes. It provides mechanisms for segmentation, flow control, and reassembly of larger messages. For a more detailed explanation, refer to our introduction to UDS.

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

Diagram illustrating different 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 effectively understand OBD2 communication over CAN, let’s examine the structure of a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message comprises an 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, detailing the components of a raw CAN frame including Mode, PID, and data bytes within the payload.

Example: OBD2 Request and Response

Before diving into the specifics of each OBD2 message component, let’s look at a practical example of a request and response for ‘Vehicle Speed’.

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

By consulting the OBD2 PID specifications for PID 0x0D, we can determine that the physical value corresponds to 50 km/h.

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

Example sequence diagram showing an OBD2 request for vehicle speed (PID 0x0D) using CAN ID 0x7DF and the corresponding response from the vehicle using CAN ID 0x7E8.

Detailed view of OBD2 PID 0x0D (Vehicle Speed) example, illustrating the data bytes and their interpretation to derive the physical speed value.

Infographic outlining the 10 standard OBD2 service modes (diagnostic services), including modes for current data, freeze frame data, and DTC management.

The 10 OBD2 Diagnostic Services (Modes)

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

Vehicles are not required to support all 10 OBD2 modes, and manufacturers may implement additional, OEM-specific modes beyond these standard ones.

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

OBD2 Parameter IDs (PIDs)

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

For instance, mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on parameters such as vehicle speed, engine RPM, and fuel level. However, vehicles are not obligated to support every PID within a mode. In practice, most vehicles support only a subset of the available PIDs.

One PID holds special significance in OBD2.

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the vehicle’s ECU indicates which PIDs from 0x01 to 0x20 it supports. This makes PID 0x00 an essential tool for basic ‘OBD2 compatibility testing’. Similarly, PIDs 0x20, 0x40, and so on, up to 0xC0, can be used to determine support for the remaining mode 0x01 PIDs.

(Re-used image) Diagram illustrating the OBD2 request-response protocol, showing the flow of data parameters and PIDs between a scan tool and vehicle ECUs.

Screenshot of an OBD2 PID overview tool, demonstrating its interface for accessing and understanding OBD2 service 01 PIDs.

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 provide scaling and decoding information for standard OBD2 PIDs, which are crucial for converting raw data into meaningful physical values (as described in our CAN bus introduction).

For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is invaluable. This tool assists in constructing OBD2 request frames and dynamically decoding OBD2 responses, streamlining the diagnostic process.

Access the OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 Data

This section provides a step-by-step example of how to log OBD2 data using the CANedge CAN bus data logger.

The CANedge device allows for the configuration of custom CAN frames for transmission, making it ideal for OBD2 data logging.

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

Diagram showing an OBD2 data logger requesting PID data using CAN IDs 7DF and 7E8, illustrating data flow in a logging setup.

Screenshot demonstrating a bit-rate validation test for OBD2 communication, ensuring correct communication parameters are set.

Screenshot from asammdf software showing OBD validation PID test responses, used to identify supported PIDs in a vehicle.

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

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

Bit-rate Test: Send a CAN frame at 500K and verify successful transmission. If unsuccessful, try 250K.
Set Bit-rate: Use the successfully identified bit-rate for all subsequent communication.
Supported PIDs Request: Send multiple ‘Supported PIDs’ requests and analyze the responses.
CAN ID Length Determination: Based on the response IDs, determine if 11-bit or 29-bit CAN IDs are in use.
Supported PID Identification: Analyze the response data to identify which PIDs are supported by the vehicle.

We provide ready-to-use configuration files to facilitate these initial tests.

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

As demonstrated in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBD request when using the functional address request ID 0x7DF. This is because 0x7DF is a broadcast request that polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs are required to support service 0x01 PID 0x00, numerous responses are often received for this PID. Subsequent ‘Supported PIDs’ requests generally elicit fewer responses as fewer ECUs support those specific PIDs. Notably, the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs in the system. Therefore, to reduce bus load, you can direct subsequent requests specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configure OBD2 PID Requests

With the knowledge of supported OBD2 PIDs for your vehicle, along with the correct bit-rate and CAN IDs, you can now configure your transmit list to request the specific PIDs of interest.

Consider these points when setting up your PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses to each request.
Request Spacing: Introduce a delay of 300-500 ms between each OBD2 request to prevent overwhelming the ECUs and ensure reliable responses.
Battery Management: Implement triggers to halt transmissions when the vehicle is inactive, preventing unnecessary ECU wake-up and battery drain.
Data Filtering: Apply filters to record only OBD2 responses if your vehicle also broadcasts OEM-specific CAN data, streamlining data logs.

Once configured with these considerations, your device is ready to efficiently log raw OBD2 data.

Example configuration of a CANedge transmit list for OBD2 PID requests, showing setup parameters for efficient data logging.

Screenshot from asammdf showing OBD2 data visually plotted after DBC decoding, illustrating data analysis and visualization capabilities.

Step #3: DBC Decode Raw OBD2 Data

To effectively analyze and visualize logged OBD2 data, it’s necessary to decode the raw data into ‘physical values,’ such as km/h or degrees Celsius.

The decoding specifications can be found in ISO 15031-5/SAE J1979 and are also available on resources like Wikipedia. For convenience, we offer a free OBD2 DBC file that simplifies DBC decoding of raw OBD2 data in most CAN bus software tools.

Decoding OBD2 data is somewhat more complex than standard CAN signal decoding. This complexity arises because multiple OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is insufficient to uniquely identify the signals within the payload.

To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID in combination to correctly identify each signal. This method is known as ‘extended multiplexing,’ which can be effectively implemented using DBC files.

CANedge: Your OBD2 Data Logging Solution

The CANedge provides an easy way to record OBD2 data directly to an 8-32 GB SD card. Simply connect it to your vehicle to start logging, and then decode the data using free software/APIs and our OBD2 DBC file.

Explore OBD2 logger options
Learn more about CANedge

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

All OBD2 data communication leverages the ISO-TP (transport protocol) as per ISO 15765-2. While many examples discussed previously involve single-frame communication, this section illustrates multi-frame communication scenarios.

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

Furthermore, processing multi-frame OBD2 responses requires CAN software and 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 structure for extended data requests.

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

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and various vehicle-related applications (see our UDS introduction for more information). To retrieve the VIN from a vehicle using OBD2 requests, you use 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, the byte 0x01 represents 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 constitute the VIN, which can be converted from HEX to ASCII format using methods described in our UDS introduction.

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

External diagnostic tools can request up to six mode 0x01 OBD2 PIDs in a single request frame. The ECU is expected to respond with data for all supported PIDs (omitting data for unsupported PIDs), possibly using multiple frames as per ISO-TP if necessary.

This feature enhances data collection efficiency and frequency. However, the signal encoding becomes specific to the request method, which can complicate the use of generic OBD2 DBC files. We generally advise against using this method in practice. Below is an example trace of such a multi-PID request:

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

Decoding such responses using generic DBC files is challenging. Therefore, we do not recommend this approach for practical data logging unless you are using a tool specifically designed to handle multi-PID requests. This scenario effectively involves extended multiplexing, but with multiple instances throughout the payload. Your DBC file would need to account for the specific payload position of each PID, making it difficult to create a universally applicable DBC file across different vehicles with varying PID support. Furthermore, managing multiple such multi-PID requests becomes very complex, as it becomes difficult to uniquely identify messages from each other.

A potential workaround involves using a custom script that interprets response messages in conjunction with their corresponding request messages, especially if you also record the transmit messages from your diagnostic tool. However, such methods are generally complex to scale and manage.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

OBD2 can be used 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 DTCs stored (which may be zero), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than two DTCs are stored.

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

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

Diagram explaining OBD2 DTC decoding, breaking down the 2-byte DTC value into category and code components for interpretation.

Practical Applications of OBD2 Data Logging

OBD2 data from cars and light trucks has diverse applications across various sectors:

Vehicle Data Logging

OBD2 data logging in cars can be used for purposes such as reducing fuel consumption, improving driving habits, testing prototype components, and insurance telematics applications.

Explore OBD2 loggers

Real-Time Vehicle Diagnostics

OBD2 interfaces facilitate real-time streaming of vehicle data in human-readable formats, crucial for diagnosing vehicle issues efficiently.

Discover OBD2 streaming

Predictive Maintenance

Utilizing IoT-enabled OBD2 loggers for cloud-based monitoring of cars and light trucks enables predictive maintenance strategies to anticipate and prevent potential breakdowns.

Learn about predictive maintenance

Vehicle Black Box Recording

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

Explore CAN bus black box solutions

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

For more introductory guides, visit our tutorials section or download the ‘Ultimate Guide’ PDF.

Ready to start logging or streaming OBD2 data?

Get your OBD2 data logger today!

Purchase Now Contact Us

Recommended Resources

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[