OBD2 Protocol PDF: Your In-Depth Guide to On-Board Diagnostics [2025]

Looking for a comprehensive understanding of the OBD2 protocol?

This guide provides an in-depth exploration of the On-Board Diagnostic (OBD2) protocol, complete with details on the OBD2 connector, OBD2 Parameter IDs (PIDs), and its connection to the CAN bus.

Note: This is a detailed guide designed to enhance your understanding of OBD2. You’ll learn how to interpret OBD2 data requests and responses, explore key applications, and gain valuable practical insights.

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

You can also refer to our introductory OBD2 video above – or download our comprehensive CAN bus guide in PDF format.

Article Contents

Author: Martin Falch (Updated January 2025)

Download as PDF

Decoding OBD2: An Overview

OBD2, or On-Board Diagnostics version 2, serves as your vehicle’s integrated self-diagnostic system. It’s a standardized protocol that enables the retrieval of diagnostic trouble codes (DTCs) and real-time operational data through the OBD2 connector. For those seeking detailed specifications, an Obd2 Protocol Pdf document is an invaluable resource, often available from automotive standards organizations.

You’ve likely encountered OBD2 in everyday driving:

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

This light is your vehicle signaling a potential issue. Automotive technicians utilize OBD2 scanners to pinpoint these problems.

They connect an OBD2 reader to the 16-pin OBD2 connector, typically located near the steering column. This tool transmits ‘OBD2 requests’ to the vehicle, which then responds with ‘OBD2 responses’ containing data such as speed, fuel level, and Diagnostic Trouble Codes (DTCs). This streamlined communication significantly speeds up troubleshooting and repair processes.

Alt text: Illustration of an OBD2 scanner diagnosing a car with the Malfunction Indicator Light (MIL) on, highlighting on-board diagnostics.

OBD2 Compatibility: Is Your Car Equipped?

The short answer: Most likely!

The vast majority of modern gasoline and diesel vehicles support OBD2, and many utilize the CAN bus for communication. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t guarantee OBD2 compliance. Some may still lack full OBD2 functionality. To confirm compatibility, consider the vehicle’s origin and year of purchase:

Alt text: Chart illustrating OBD2 compliance by region and year, detailing US, EU, and CAN requirements for vehicle diagnostics.

A Look at OBD2 History

OBD2’s roots are in California, where the California Air Resources Board (CARB) mandated OBD for all new vehicles from 1991 onwards to monitor and control emissions.

The Society of Automotive Engineers (SAE) further developed and standardized OBD2, defining DTCs and the universal OBD connector (SAE J1962). Detailed specifications are often found in an obd2 protocol pdf.

The OBD2 standard’s implementation unfolded gradually:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: The EU adopted OBD2 requirements for gasoline vehicles.
2003: The EU extended OBD2 compliance to diesel vehicles (EOBD).
2005: OBD2 was required in the US for medium-duty vehicles.
2008: US vehicles were mandated to use ISO 15765-4 (CAN) as the foundation for OBD2.
2010: OBD2 compliance was finally extended to heavy-duty vehicles in the US.

Alt text: Graphic timeline representing OBD2 history, focusing on emission control, exhaust standards, and the evolution to EOBD2 and EOBDII.

Alt text: Timeline overview of OBD2 history, highlighting key milestones and advancements in on-board diagnostics.

Alt text: Conceptual image of OBD3 future trends, including remote diagnostics, emissions testing, cloud connectivity, and IoT integration.

The Future Trajectory of OBD2

OBD2 remains relevant, but its future form is evolving.

Key trends to consider:

Originally conceived for emissions monitoring and testing, regulatory OBD2 requirements don’t extend to electric vehicles. Consequently, most modern EVs don’t support standard OBD2 requests. Instead, they often utilize OEM-specific UDS communication, making data retrieval challenging without OEM-specific tools or reverse-engineered protocols. However, progress is being made in reverse engineering, as shown in case studies for electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Current OBD2 implementations vary in data richness and lower-layer protocols, prompting the development of advanced alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). These aim to enhance OBD communication efficiency and capabilities by utilizing the UDS protocol as a foundation. For a deeper dive, consult resources such as an obd2 protocol pdf or our introduction to UDS.

In today’s interconnected automotive landscape, traditional OBD2 testing methods can seem inefficient. Manual emissions checks are time-consuming and costly.

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

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

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

While offering cost savings and convenience, OBD3 raises political and privacy concerns related to increased vehicle surveillance.

The OBD2 protocol was initially designed for stationary emissions testing.

However, today, third parties extensively utilize OBD2 for real-time data generation through OBD2 dongles, CAN loggers, and similar devices. This trend is facing pushback from the German car industry, as reported by eenewsautomotive.com:

“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 industry proposal suggests disabling OBD2 functionality during normal driving and centralizing data collection through manufacturer-controlled servers. This would give manufacturers control over ‘automotive big data’ and is argued to enhance security by mitigating car hacking risks. However, many view this as a commercially motivated move, potentially disrupting the market for third-party OBD2 services, as discussed by navixy.com. The future impact of this proposal on the OBD2 landscape remains to be seen.

Alt text: Visual concept depicting the future of OBD2 in electric vehicles, showing a removed OBD2 connector symbolizing blocked data access.

Enhance Your CAN Bus Knowledge

Eager to become a CAN bus expert?

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

Download now

OBD2 Standards: A Layered Approach

On-board diagnostics, OBD2, operates as a higher-layer protocol, similar to a language, while CAN serves as the communication method, akin to a phone line. This places OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000. Detailed specifications for these standards are often found in protocol documentation, such as an obd2 protocol pdf.

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

These standards can be viewed within a 7-layer OSI model framework. The following sections will highlight the most critical aspects.

In the OSI model overview, you’ll notice overlap between SAE and ISO standards. This reflects OBD standards developed in the USA (SAE) and EU (ISO). Many standards are technically equivalent, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.

Alt text: Diagram illustrating the OBD2 and CAN bus relationship within the 7-layer OSI model, highlighting ISO 15765 and ISO 11898 standards.

[

](https://www.csselectronics.com/cdn/shop/files/obd2-connector-pinout-socket.svg?v=1633690039)
Alt text: Pinout diagram of an OBD connector, socket female type A DLC, detailing pin assignments for automotive diagnostics.

The OBD2 Connector [SAE J1962]

The 16-pin OBD2 connector facilitates easy access to vehicle data and is standardized under SAE J1962 / ISO 15031-3. For detailed pinout specifications, an obd2 protocol pdf is a valuable reference.

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

Key points to note:

The connector is typically located near the steering wheel, but its exact position may vary and 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

You may 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.

Both types share 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 (though 500K support is increasing).

Visually, a Type B OBD2 connector has an interrupted groove in the middle, distinguishing it from Type A. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and B sockets, while a Type A adapter will not fit a Type B socket.

Alt text: Comparison of OBD2 Connector Type A and Type B, highlighting differences in SAE J1962 standards, 12V vs 24V power, and car vs van/truck applications.

Alt text: Diagram contrasting OBD2 and CAN bus, emphasizing the ISO 15765 standard and their roles in vehicle communication systems.

OBD2 and CAN Bus Integration [ISO 15765-4]

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US-sold vehicles, as per ISO 15765. For precise details, refer to the obd2 protocol pdf documentation for ISO 15765-4.

ISO 15765-4 (Diagnostic communication over Controller Area Network – DoCAN) specifies constraints applied to the CAN standard (ISO 11898) to standardize 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 must not exceed 5 meters in length.

OBD2 CAN Identifiers (11-bit, 29-bit)

OBD2 communication relies on 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 for data on a requested parameter (per ISO 15765-4). CAN IDs 0x7E0-0x7E7 are used for ‘Physical Addressing’ requests to specific ECUs, though less commonly.

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

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

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

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

Alt text: Diagram of OBD2 protocol request and response frames, detailing PID data parameters for on-board diagnostics.

Alt text: Conceptual image contrasting OBD2 and proprietary CAN bus systems, illustrating the difference in data accessibility.

OBD2 vs. Proprietary CAN Protocols

Vehicle Electronic Control Units (ECUs) operate using OEM-specific proprietary CAN protocols, independent of OBD2. These protocols are unique to each vehicle brand, model, and year. Interpreting this proprietary data is generally not possible without OEM tools or reverse engineering efforts.

Connecting a CAN bus data logger to the OBD2 connector may capture OEM-specific CAN data, often broadcast at 1000-2000 frames per second. However, many newer vehicles use a ‘gateway’ to block access to this data via the OBD2 port, allowing only OBD2 communication.

In essence, OBD2 functions as a parallel, ‘extra’ higher-layer protocol alongside the OEM-specific protocol.

Bit-rate and ID Validation

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 with 11-bit IDs. External diagnostic tools should systematically validate these parameters.

ISO 15765-4 provides a recommended initialization sequence to determine the correct combination. This method relies on the fact that OBD2-compliant vehicles must respond to a mandatory OBD2 request (see OBD2 PID section) and that incorrect bit-rates will cause CAN error frames.

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

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

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

Alt text: Flowchart illustrating OBD2 bit-rate and CAN ID validation process according to ISO 15765-4, for diagnostic tool initialization.

Alt text: Graphic representation of five lower-layer OBD2 protocols: CAN (ISO 15765), KWP2000, SAE J1850, ISO 9141, highlighting standard evolution.

Five Lower-Layer OBD2 Protocols

While CAN (ISO 15765) is now the dominant lower-layer protocol for OBD2, especially in vehicles post-2008, older vehicles may use other protocols. Understanding these is useful when working with legacy systems. Detailed protocol specifications can be found in an obd2 protocol pdf. The five primary lower-layer protocols include:

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and widely used today.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, particularly in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian vehicles around 2000-2004.
SAE J1850 (VPW): Predominantly used in older GM vehicles.
SAE J1850 (PWM): Mainly used in older Ford vehicles.

ISO-TP for OBD2 Message Transport [ISO 15765-2]

All OBD2 data exchange over CAN bus utilizes the ISO-TP (ISO 15765-2) transport protocol. This protocol enables the transmission of data payloads exceeding the 8-byte CAN frame limit, crucial for OBD2 operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 provides mechanisms for segmentation, flow control, and reassembly of larger messages. Further details are available in our UDS protocol introduction and in the official obd2 protocol pdf documentation.

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

Alt text: Diagram illustrating ISO 15765-2 ISO-TP OBD2 frame types, including single frame, first frame, consecutive frame, and flow control frame.

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

To better understand OBD2 communication over CAN, let’s examine 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 itself. The data section is further structured into Mode, Parameter ID (PID), and data bytes. For detailed specifications, consult the obd2 protocol pdf documentation.

Alt text: Breakdown of OBD2 message structure, explaining raw mode, PID, ID, and data bytes in an OBD-II frame.

Example: OBD2 Request and Response

Consider this example of requesting and receiving ‘Vehicle Speed’ data.

A diagnostic tool sends a request message to the vehicle with CAN ID 0x7DF and a 2-byte payload: Mode 0x01 and PID 0x0D. The vehicle responds with CAN ID 0x7E8 and a 3-byte payload, including the vehicle speed value in the 4th byte, 0x32 (decimal 50).

Looking up the OBD2 PID 0x0D decoding rules reveals that the physical value is 50 km/h.

The following sections detail OBD2 modes and PIDs.

Alt text: Example of OBD2 request (7DF) and response (7E8) for vehicle speed, illustrating data exchange.

Alt text: OBD2 PID example showing Vehicle Speed with PID 0D, detailing data interpretation and units.

Alt text: Overview of OBD2 services modes, including current data, freeze frame, and clear DTC, highlighting diagnostic service functionalities.

The 10 OBD2 Services (Modes)

OBD2 defines 10 diagnostic services, also known as modes. Mode 0x01 provides real-time data, while others are used for displaying and clearing diagnostic trouble codes (DTCs) or accessing freeze frame data. Refer to an obd2 protocol pdf for a complete list and detailed descriptions of all modes.

Vehicles are not required to support all 10 OBD2 modes and may also implement OEM-specific modes beyond the standard set.

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

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the data being requested or provided.

For example, Mode 0x01 contains approximately 200 standardized PIDs for real-time data such as speed, RPM, and fuel level. However, vehicles typically support only a subset of these PIDs within each mode. An obd2 protocol pdf provides comprehensive listings of standardized PIDs.

One PID holds special significance:

If an emissions-related ECU supports any OBD2 services, it must support Mode 0x01 PID 0x00. Responding to PID 0x00, 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 Mode 0x01 PIDs.

Alt text: Diagram again illustrating OBD2 protocol request and response frames, emphasizing PID data parameters and their role in diagnostics.

Alt text: Screenshot of an OBD2 PID overview tool, highlighting service 01 and its functionalities in parameter identification.

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5, often available in an obd2 protocol pdf, detail scaling information for standard OBD2 PIDs. This information is essential for decoding raw data into physical values, as explained in our CAN bus introduction.

For quick PID lookups within Mode 0x01, our OBD2 PID overview tool is invaluable. It aids in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

Practical Guide to Logging and Decoding OBD2 Data

This section provides a hands-on example of logging OBD2 data using the CANedge CAN bus data logger.

The CANedge allows configuration of custom CAN frame transmissions, making it suitable for OBD2 data logging.

Once configured, connect the CANedge to your vehicle using our OBD2-DB9 adapter cable.

Alt text: Diagram of an OBD2 PID data logger requesting data using 7DF and receiving responses via 7E8, illustrating data logging setup.

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

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

Alt text: Image of reviewing supported PIDs via an OBD2 lookup tool, demonstrating the process of decoding PID results.

#1: Bit-rate, ID, and Supported PID Validation

As discussed, ISO 15765-4 details how to determine the bit-rate and IDs used by a vehicle. Use the CANedge to perform these tests (see the CANedge Intro for detailed instructions):

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

We offer plug-and-play configurations to facilitate these tests.

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

As seen in the asammdf GUI screenshot, multiple responses to a single OBD request are common due to the use of the 0x7DF request ID, which polls all ECUs. Because all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are typical. Subsequent ‘Supported PIDs’ requests will elicit fewer responses as fewer ECUs support those PIDs. Notably, the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs, suggesting that busload could be reduced by directing subsequent communication to the ECM ECU specifically using the ‘Physical Addressing’ CAN ID 0x7E0.

#2: Configuring OBD2 PID Requests

Once you’ve identified the supported OBD2 PIDs, bit-rate, and CAN IDs for your vehicle, configure your transmit list with the desired PIDs.

Consider these factors:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses per request.
Spacing: Introduce 300-500 ms intervals between OBD2 requests to avoid overwhelming ECUs.
Battery Drain: Implement triggers to halt transmissions when the vehicle is inactive to prevent ECU ‘wake-up’ and battery drain.
Filters: Apply filters to record only OBD2 responses if OEM-specific CAN data is also present.

With these configurations, your device is set to log raw OBD2 data.

Alt text: Example of an OBD2 transmit list configured for CANedge, showing PID requests for data logging.

Alt text: Visual plot of decoded OBD2 data in asammdf, utilizing a CAN bus DBC file for data interpretation and visualization.

#3: DBC Decoding of Raw OBD2 Data

For data analysis and visualization, decode the raw OBD2 data into ‘physical values’ (e.g., km/h, °C).

Decoding information is available in ISO 15031-5/SAE J1979, and often summarized online (e.g., Wikipedia). For convenience, we provide a free OBD2 DBC file to facilitate DBC decoding of raw OBD2 data in most CAN bus software tools.

Decoding OBD2 data is more complex than standard CAN signal decoding. Since different OBD2 PIDs can be transmitted using the same CAN ID (e.g., 0x7E8), the CAN ID alone isn’t sufficient to identify the signals within the payload.

To address this, use the CAN ID, OBD2 mode, and OBD2 PID to uniquely identify each signal. This multiplexing technique, known as ‘extended multiplexing‘, can be implemented using DBC files.

CANedge: Your OBD2 Data Logger

The CANedge simplifies OBD2 data recording to an 8-32 GB SD card. Simply connect it to a vehicle to start logging and decode the data using free software/APIs and our OBD2 DBC file.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples [ISO-TP]

OBD2 communication always uses ISO-TP (ISO 15765-2). While previous examples showed single-frame communication, this section presents multi-frame scenarios. For detailed protocol specifications, consult an obd2 protocol pdf document.

Multi-frame OBD2 communication requires flow control frames. A static flow control frame can be transmitted approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example. For more details on flow control, refer to our UDS introduction.

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

Alt text: Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN), showing the structure for extended data requests.

Example 1: OBD2 Vehicle Identification Number (VIN)

The Vehicle Identification Number (VIN) is crucial for telematics and diagnostics. To retrieve the VIN via OBD2 requests, use mode 0x09 and PID 0x02:

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

The vehicle responds with a First Frame containing 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), in this case, 1. The subsequent 17 bytes constitute the VIN, which can be converted from HEX to ASCII as detailed in our UDS introduction.

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

Diagnostic tools can request up to six Mode 0x01 OBD2 PIDs in a single request frame. The ECU responds with data for supported PIDs (omitting unsupported PIDs in the response), potentially using multiple frames via ISO-TP if necessary.

This method allows for more efficient data collection but complicates signal encoding, making generic OBD2 DBC files less effective. We generally advise against this approach. Below is an example trace:

The multi-frame response is similar to the VIN example, but includes the requested PIDs and their corresponding data. In practice, PIDs are often ordered as requested (though not strictly mandated by ISO 15031-5).

Decoding these responses using generic DBC files is challenging. We advise against this method for practical data logging unless using tools specifically designed for multi-PID requests. This scenario represents extended multiplexing, where the DBC file needs to account for the payload position of each PID, making it difficult to generalize across vehicles with varying PID support. Handling multiple multi-PID requests further complicates DBC management.

A custom script, combined with recording transmit messages, could potentially interpret responses by correlating them with requests. However, such methods are complex to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’, is used to request emissions-related DTCs. No PID is included in the request. Responding ECUs report the number of stored DTCs (potentially zero), with each DTC occupying 2 data bytes. Multi-frame responses are required when more than two DTCs are stored.

The 2-byte DTC value is structured 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 illustrated. 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.

Alt text: DBC interpretation example for OBD2 DTC Diagnostic Trouble Codes, showing decoding process and category breakdown.

OBD2 Data Logging: Use Case Applications

OBD2 data from cars and light trucks has diverse applications:

Alt text: Image depicting an OBD2 data logger in a car, symbolizing on-board diagnostics and data collection.

Car Data Logging

OBD2 data logging in cars can be used for fuel efficiency improvement, driving behavior analysis, prototype testing, and insurance applications.

obd2 logger

Alt text: Illustration of OBD2 real-time streaming diagnostics via USB, showing data flow and connectivity for live analysis.

Real-Time Car Diagnostics

OBD2 interfaces facilitate real-time streaming of human-readable OBD2 data for vehicle diagnostics and issue identification.

obd2 streaming

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

Predictive Maintenance

Cloud-connected IoT OBD2 loggers enable predictive maintenance for cars and light trucks, helping to anticipate and prevent breakdowns.

predictive maintenance

Alt text: Visual of a black box CAN logger for vehicles, used for insurance, warranty, and event data recording.

Vehicle Black Box Logger

An OBD2 logger can function as a vehicle ‘black box’ for event recording, dispute resolution, and detailed diagnostics.

can bus blackbox

Do you have an OBD2 data logging application? Contact us for expert consultation!

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

Need to log or stream OBD2 data?

Get your OBD2 data logger now!

Buy now
Contact us