Decoding OBD2 Message IDs: A Comprehensive Guide to Parameter IDs (PIDs)

Looking for a clear and practical understanding of OBD2?

This guide provides a detailed introduction to the On-Board Diagnostics (OBD2) protocol, including the OBD2 connector, OBD2 Parameter IDs (PIDs), and their connection to the CAN bus.

Note: This is a comprehensive guide designed to help you understand how to request and interpret OBD2 data, explore key use cases for data logging, and gain practical insights.

Discover why this is considered a top resource for learning about OBD2.

You can also watch our OBD2 introductory video above – or download the PDF guide

Article Contents

Author: Martin Falch (Updated January 2025)

PDF icon

Download as PDF

Understanding OBD2: On-Board Diagnostics II

OBD2 is your vehicle’s integrated self-diagnostic system. It’s a standardized protocol that enables the retrieval of diagnostic trouble codes (DTCs) and real-time data through the OBD2 connector. This system is crucial for modern vehicle maintenance and diagnostics.

You’ve likely encountered OBD2 without realizing it. Have you ever seen the malfunction indicator light illuminate on your dashboard?

That light is your car signaling a problem. When you take your vehicle to a mechanic, they use an OBD2 scanner to pinpoint the issue.

To do this, the mechanic connects an OBD2 reader to the OBD2 16-pin connector, usually located near the steering wheel. This tool transmits ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’. These responses can contain valuable information like speed, fuel level, or Diagnostic Trouble Codes (DTCs), significantly speeding up the troubleshooting process.

Image showing a malfunction indicator light (MIL) on a dashboard, illustrating the OBD2 system alerting the driver to a potential vehicle issue.

OBD2 Compatibility: Is Your Car Supported?

In most cases, the answer is yes!

Nearly all modern non-electric vehicles are OBD2 compliant, and the majority operate on the CAN bus protocol. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 support. Some may not be fully compliant. A key indicator of compliance is the vehicle’s year and region of purchase:

Does My Car Have OBD2?
Infographic illustrating OBD2 compliance timelines for vehicles based on region (EU, US) and year of manufacture, helping users determine if their car supports OBD2.

A Brief History of OBD2

OBD2 originated in California. The California Air Resources Board (CARB) mandated OBD in all new vehicles starting from 1991 for emissions monitoring.

The OBD2 standard was developed and recommended by the Society of Automotive Engineers (SAE), which standardized DTCs and the OBD connector across different vehicle manufacturers (SAE J1962).

The OBD2 standard was implemented progressively:

1996: OBD2 becomes mandatory in the USA for cars and light trucks.
2001: Required in the EU for gasoline cars.
2003: Required in the EU for diesel cars as well (EOBD – European On-Board Diagnostics).
2005: OBD2 mandated in the US for medium-duty vehicles.
2008: US vehicles required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 requirement extended to heavy-duty vehicles in the US.

Diagram outlining the historical progression of OBD2 implementation, highlighting key milestones related to emission control and standardization across different vehicle types and regions.

Timeline visualization summarizing the key dates and events in the history of OBD2, providing a quick overview of its evolution and global adoption.

Conceptual image representing the future of OBD3, suggesting trends towards remote diagnostics, emissions testing, cloud connectivity, and IoT integration for enhanced vehicle monitoring.

The Future of OBD2

OBD2 is firmly established, but its future is evolving. Let’s explore some significant trends:

Originally designed for emissions control and testing, legislated OBD2 has an interesting implication: electric vehicles (EVs) are not mandated to support OBD2 in any form. This is evident as most modern EVs do not support standard OBD2 requests. Instead, they often utilize OEM-specific UDS (Unified Diagnostic Services) communication protocols. This generally makes accessing data from EVs challenging, except in cases where decoding methods have been reverse-engineered. For examples, explore our case studies on electric vehicles, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Today, OBD2 implementation varies, facing limitations in data richness and lower-layer protocols. Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging to address these issues. These protocols aim to enhance OBD communication by using the UDS protocol as a base. For more information on these advancements, see our introduction to UDS.

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

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

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

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

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

The OBD2 protocol was initially intended for stationary emissions testing.

However, today, third parties extensively utilize OBD2 to generate real-time vehicle data via OBD2 dongles, CAN loggers, and similar devices. The German automotive industry is seeking to change this landscape (source):

OBD was designed for servicing vehicles in repair shops. ” It was never intended 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 normal driving, with vehicle data being collected and managed centrally by manufacturers. This would give manufacturers control over automotive big data.

Security concerns, such as reducing the risk of car hacking, are cited as reasons for this shift, although many perceive it as a commercially motivated move (source). Whether this trend will materialize remains to be seen, but it could significantly disrupt the market for third-party OBD2 services.

Illustration depicting the trend of electric vehicles potentially limiting or blocking OBD2 data access, highlighting a shift in data accessibility for newer vehicle technologies.

Enhance Your CAN Bus Expertise

Interested in becoming a CAN bus expert?

Access our 12 ‘simple introductions’ in a comprehensive 160+ page PDF guide:

Download Now

CAN Bus – The Ultimate Guide Tutorial PDF

OBD2 Standards: A Layered Approach

On-board diagnostics, or OBD2, is a higher-layer protocol, acting as a language for vehicle communication. CAN (Controller Area Network) is the communication method, similar to a phone line. This makes OBD2 comparable to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

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

These standards can be visualized using the 7-layer OSI model. In the following sections, we’ll focus on the most critical aspects.

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

OSI model diagram comparing OBD2 and CAN bus standards, illustrating how ISO 15765 and ISO 11898 standards align with the 7-layer OSI model for automotive diagnostics.

Detailed pinout diagram of a Type A OBD2 connector, showing the function of each pin in the Data Link Connector (DLC) socket.

The OBD2 Connector: SAE J1962 Standard

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

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

Key points to note:

The connector is typically near the steering wheel, but its exact location can vary and might be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout configuration depends on the communication protocol used.
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 generally found in cars, while Type B is 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 and heavy-duty vehicles often using 250K (with increasing support for 500K).

To visually differentiate between the two, Type B OBD2 connectors have an interrupted groove in the middle. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, whereas a Type A adapter will not fit into a Type B socket.

Diagram comparing OBD2 Connector Type A and Type B, highlighting differences in voltage (12V vs 24V) and physical characteristics for cars, vans, and trucks as per SAE J1962 standards.

Visual representation contrasting OBD2 and CAN bus protocols in the context of ISO 15765 standards, emphasizing their relationship and distinct roles in vehicle communication.

OBD2 and CAN Bus: ISO 15765-4

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, according to 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.
OBD2 adapter cable length must not exceed 5 meters.

OBD2 CAN Identifiers: 11-bit and 29-bit

All OBD2 communication relies on request/response message pairs.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, which is used to query all OBD2-compatible ECUs (Electronic Control Units) to see if they have data to report for the requested parameter (as defined in ISO 15765-4). CAN IDs ranging from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’ requests to specific ECUs, although this is less common.

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

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

For 29-bit identifiers, 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 presented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which the J1939-71 standard marks as ‘Reserved for ISO 15765-2’.

Diagram illustrating the OBD2 protocol request and response frame structure, highlighting the roles of PID (Parameter ID) and data parameters in the communication process.

OBD2 OBD CAN bus Identifiers 7DF 7E8 7E0

Conceptual image distinguishing between OBD2 and proprietary CAN bus protocols, emphasizing the difference in data accessibility and standardization between the two systems.

OBD2 vs. Proprietary CAN Protocols

It’s important to understand that your vehicle’s electronic control units (ECUs) do not depend on OBD2 for their primary functions. Instead, each Original Equipment Manufacturer (OEM) implements its own proprietary CAN protocols for core vehicle operations. These proprietary CAN protocols are often unique to the vehicle brand, model, and year. Generally, this OEM-specific CAN data is undecipherable to external parties unless it is reverse engineered.

If you connect a CAN bus data logger to your car’s OBD2 connector, you might observe OEM-specific CAN data, typically broadcast at a high rate of 1000-2000 frames per second. However, many newer vehicles employ a ‘gateway’ that restricts access to this raw CAN data and only allows OBD2 communication through the OBD2 connector.

In essence, think of OBD2 as an ‘additional’ higher-layer protocol operating alongside the OEM-specific protocol.

Bit-rate and ID Validation

As mentioned, OBD2 can use either of two bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern vehicles most commonly use 500K with 11-bit IDs, but external tools should systematically verify this.

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

Newer versions of ISO 15765-4 consider that vehicles may support OBD communication via OBDonUDS rather than OBDonEDS. While this article mainly 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), it’s important to be aware of these distinctions.

To test for OBDonEDS versus OBDonUDS, a diagnostic tool can send additional request messages, specifically UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.

In practice, OBDonEDS (also 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 illustrating the OBD2 bit-rate and CAN ID validation process as per ISO 15765-4, guiding users through the steps to correctly identify and configure communication parameters.

Diagram showcasing the five lower-layer OBD2 protocols, including CAN (ISO 15765), KWP2000, SAE J1850, and ISO 9141, providing a comparative overview of communication standards.

Five Lower-Layer OBD2 Protocols

While CAN (ISO 15765) is now the dominant lower-layer protocol for OBD2, especially in vehicles manufactured post-2008, it’s beneficial to know the other four protocols used in older vehicles. The pinouts of the OBD2 connector can sometimes indicate which protocol a vehicle might be using.

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

ISO-TP: Transporting OBD2 Messages (ISO 15765-2)

All OBD2 data is transmitted over the CAN bus using a transport protocol called ISO-TP (ISO 15765-2). This protocol allows for the communication of data payloads larger than 8 bytes, which is necessary in OBD2 for operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. For a more detailed explanation, refer to our introduction to UDS.

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

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

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

To better understand OBD2 over CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simple terms, an OBD2 message includes an identifier, data length (PCI field), and data. The data itself is structured into Mode, Parameter ID (PID), and data bytes.

Detailed breakdown of an OBD2 message structure, explaining the components: Mode, Parameter ID (PID), Identifier, and Data Bytes within an OBD-II frame.

Example: OBD2 Request and Response

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

An external tool sends a request message to the vehicle with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds with CAN ID 0x7E8 and 3 payload bytes, including the Vehicle Speed value in the 4th byte, 0x32 (which is 50 in decimal).

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

Next, we will explore OBD2 modes and Parameter IDs (PIDs) in detail.

Example of an OBD2 request-response sequence for vehicle speed, showing CAN IDs (7DF for request, 7E8 for response) and data bytes for Mode and PID.

Detailed example focusing on OBD2 PID 0x0D (Vehicle Speed), illustrating how the PID is used in a request and how the response data byte translates to a physical speed value.

Infographic outlining the 10 OBD2 service modes, detailing their functions such as retrieving current data, freeze frame data, and clearing diagnostic trouble codes (DTCs).

The 10 OBD2 Services (Modes)

There are 10 standardized OBD2 diagnostic services, also known as modes. Mode 0x01 is used to retrieve current real-time data, while other modes are used to display or clear diagnostic trouble codes (DTCs) or show freeze frame data.

Vehicles are not required to support all 10 OBD2 modes, and they may also support additional OEM-specific modes beyond these standardized ones.

In OBD2 messages, the mode is specified in the second byte. In a request, the mode value is included directly (e.g., 0x01). In a response, 0x40 is added to the mode value (e.g., resulting in 0x41).

OBD2 Parameter IDs (PIDs) Explained

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

For example, mode 0x01 contains approximately 200 standardized PIDs that provide real-time data on parameters like speed, RPM, and fuel level. However, a vehicle does not need to support every PID within a mode. In reality, most vehicles only support a subset of these PIDs.

One PID holds a special significance.

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. In response to this PID, the vehicle’s ECU communicates which PIDs from 0x01 to 0x20 it supports. This makes PID 0x00 a fundamental tool for ‘OBD2 compatibility testing’. Furthermore, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to determine support for the remaining mode 0x01 PIDs in blocks of 32 PIDs each.

(Re-used image – already placed above)

OBD2 PID overview tool
Screenshot of an OBD2 PID overview tool, highlighting Service 01 and its functionalities for displaying and interpreting OBD2 Parameter IDs.

Tip: Using an OBD2 PID Overview Tool

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

If you need to look up a mode 0x01 PID, our OBD2 PID overview tool is a valuable resource. It helps you construct OBD2 request frames and dynamically decode OBD2 responses.

OBD2 PID Overview Tool

Practical Guide: Logging and Decoding OBD2 Data

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

The CANedge allows you to configure custom CAN frames for transmission, making it suitable for OBD2 data logging.

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

Diagram illustrating an OBD2 data logger setup, showing the flow of request and response messages (CAN IDs 7DF and 7E8) for PID data logging.

OBD2 bit rate test Screenshot showing bit-rate validation for OBD2 communication, indicating successful CAN frame transmission at a specific bit rate.

OBD2 Supported PIDs Test Screenshot from asammdf software showing OBD2 validation PID test responses, displaying the data received in response to ‘Supported PIDs’ requests.

Review supported PIDs via OBD2 lookup tool

Step #1: Bit-rate, ID, and Supported PIDs Verification

As discussed, ISO 15765-4 outlines how to determine the bit rate and IDs used by a specific vehicle. You can test this using the CANedge as follows (refer to the CANedge Introduction for detailed instructions):

Transmit a CAN frame at 500K and check for successful transmission (if unsuccessful, try 250K).
Use the validated bit rate for all subsequent communication.
Send multiple ‘Supported PIDs’ requests and examine the responses.
Determine whether 11-bit or 29-bit IDs are used based on the response IDs.
Identify supported PIDs based on the response data.

We provide plug-and-play configurations to simplify these tests.

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

As illustrated in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBD request. This is because we use the 0x7DF request ID, which broadcasts the request to all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, there are often numerous responses to this specific PID. For subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. Notably, the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs, suggesting that bus load could be reduced by directing subsequent requests specifically to this ECU using the ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configuring OBD2 PID Requests

After identifying the PIDs supported by your vehicle and the appropriate bit rate and CAN IDs, you can configure your transmit list with the PIDs you’re interested in logging.

Consider these points when configuring your PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses for each request and reduce bus load.
Spacing: Introduce a delay of 300-500 ms between each OBD2 request. Overly frequent requests can overwhelm ECUs and prevent responses.
Battery Drain: Implement triggers to stop transmissions when the vehicle is inactive to prevent unnecessary battery drain by ‘waking up’ ECUs.
Filters: Apply filters to record only OBD2 responses if your vehicle also outputs OEM-specific CAN data, to keep your logs focused and efficient.

Once configured, your device is ready to log raw OBD2 data effectively!

obd2-transmit-list-example-canedge
Example configuration of a CANedge transmit list for OBD2 PID requests, showing how to set up specific PIDs for data logging.

OBD2 data decoded visual plot asammdf CAN bus DBC file
Screenshot from asammdf software displaying a visually plotted and DBC decoded OBD2 data log, showcasing how raw data is transformed into meaningful vehicle parameters.

Step #3: DBC Decoding of Raw OBD2 Data

To analyze and visualize your logged data, you need to decode the raw OBD2 data into ‘physical values’ like km/h or degrees Celsius.

The necessary decoding information is available in ISO 15031-5/SAE J1979 and online 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 slightly more complex than decoding standard CAN signals 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 signals within the payload.

To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID together to uniquely identify each signal. This is a form of multiplexing known as ‘extended multiplexing‘, which can be effectively implemented using DBC files.

CANedge: Your OBD2 Data Logging Solution

The CANedge makes it easy to record OBD2 data directly to an SD card (8-32 GB). Simply connect it to your car or truck to begin logging and then decode the data using free software/APIs and our OBD2 DBC file.

OBD2 Logger Introduction
Explore CANedge

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

All OBD2 communication is based on the ISO-TP transport protocol (ISO 15765-2). While many examples involve single-frame communication, multi-frame communication is essential for larger data sets. This section provides examples of multi-frame OBD2 communication.

Multi-frame OBD2 communication requires flow control frames. As explained in our UDS introduction, this can be managed by sending a static flow control frame, for example, 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.

OBD2-multi-frame-request-message-vehicle-identification-number
Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN), illustrating the structure of a request that exceeds a single CAN frame payload.

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

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more. (See our UDS introduction for more details). To retrieve the VIN from a vehicle using OBD2 requests, use mode 0x09 and PID 0x02:

VIN Vehicle Identification Number OBD2 Example multi-frame

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

The vehicle responds with a First Frame, including the PCI, 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 subsequent 17 bytes contain the VIN, which can be converted from HEX to ASCII as described in our UDS introduction.

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

External diagnostic tools can request up to six mode 0x01 OBD2 PIDs in a single request frame. The ECU will respond with data for all supported PIDs (omitting unsupported PIDs from the response), possibly across multiple frames as per ISO-TP.

This method enhances data collection frequency and efficiency. However, the signal encoding becomes specific to the request method, complicating the use of generic OBD2 DBC files for decoding. We generally advise against this method in practice. Below is an example trace of such a request:

Requesting multiple PIDs in one request

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

Decoding such responses using generic DBC files is challenging. Therefore, we advise against this approach for practical data logging unless using tools specifically designed for it. This scenario represents extended multiplexing, but with multiple instances within the payload. Your DBC file would need to account for the payload position of each PID, making it difficult to generalize across vehicles with varying supported PIDs. Handling this becomes very complex, especially with multiple multi-PID requests, as uniquely identifying messages from each other becomes problematic.

Workarounds could involve custom scripts and recording transmit messages to link responses to requests. However, such methods are difficult to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval

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 target ECU(s) will respond with the number of DTCs stored (including 0 if none are stored), 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 typically structured into two parts, as per 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 shown visually. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.

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

Example of OBD2 DTC (Diagnostic Trouble Code) decoding, showing the structure of a DTC code and its interpretation based on ISO standards.

OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response Example

OBD2 Data Logging: Use Case Examples

OBD2 data from cars and light trucks has numerous applications:

Vehicle Data Logging

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

Explore OBD2 Loggers

Real-Time Vehicle Diagnostics

OBD2 interfaces enable real-time streaming of human-readable OBD2 data, useful for diagnosing vehicle issues and performance monitoring.

Discover OBD2 Streaming Interfaces

Predictive Maintenance

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

Learn about Predictive Maintenance Solutions

Vehicle Black Box Recording

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

Explore CAN Bus Black Box Loggers

Do you have an OBD2 data logging use case in mind? Contact us for a free consultation!

For more educational content, explore our guides section or download our comprehensive ‘Ultimate Guide’ PDF.

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy Now
Contact Us

Recommended Resources

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANedge2 – Dual CAN Bus Telematics Dongle
CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN