OBD2 Explained: A Practical Guide for Beginners [2025 Update]

Looking for a straightforward, hands-on introduction to OBD2?

This guide offers a practical overview of the On-Board Diagnostic (OBD2) protocol, covering the OBD2 connector, OBD2 Parameter IDs (PIDs), and its connection to the Controller Area Network (CAN) bus.

Note: This is designed as a practical primer, equipping you with the knowledge to request and interpret OBD2 data, understand key logging applications, and gain valuable practical insights.

Discover why this guide has become a leading resource for understanding OBD2.

You can also watch our introductory OBD2 video tutorial above – or download the PDF version.

Article Contents

Author: Martin Falch (Updated January 2025)

PDF icon

Download this guide as a PDF

Demystifying OBD2: On-Board Diagnostics Explained

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

You’ve likely encountered OBD2 in action already. Ever seen the malfunction indicator light illuminate on your dashboard?

That’s your car signaling a potential issue. When you take your vehicle to a mechanic, they utilize an OBD2 scanner to pinpoint the problem.

To do this, the mechanic connects the OBD2 reader to the 16-pin OBD2 connector, usually located near the steering wheel. This tool sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’ containing information like speed, fuel level, or Diagnostic Trouble Codes (DTCs). This process significantly accelerates troubleshooting and repair.

Understanding OBD2: The Malfunction Indicator Light (MIL) and Diagnostic Scan Tool in action.

OBD2 Compatibility: Does Your Car Support It?

In most cases: Yes, probably!

The vast majority of modern non-electric vehicles are OBD2 compliant, and many utilize the CAN bus protocol. For older vehicles, even if a 16-pin OBD2 connector is present, it might not actually support OBD2. A key indicator of OBD2 compliance is the vehicle’s original point of sale and manufacturing date:

Does My Car Have OBD2?
OBD2 Compliance Guide: Check your vehicle’s origin and manufacturing date to determine OBD2 support.

A Look Back: The History of OBD2

OBD2’s story begins in California, where the California Air Resources Board (CARB) mandated OBD in all new vehicles starting in 1991 for emissions monitoring.

The Society of Automotive Engineers (SAE) further refined this by recommending the OBD2 standard, standardizing DTCs and the OBD connector across different vehicle manufacturers (SAE J1962).

The OBD2 standard was implemented gradually across the globe:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: Required in the EU for gasoline-powered cars.
2003: Extended to diesel cars in the EU (EOBD).
2005: OBD2 requirement expanded to medium-duty vehicles in the US.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2.
2010: OBD2 mandate extended to heavy-duty vehicles in the US.

OBD2 History: From Emission Control Origins to Global Adoption.

OBD2 Timeline: Key Milestones in the Evolution of On-Board Diagnostics.

The Future of OBD: OBD3, Remote Diagnostics, and the Internet of Things (IoT).

The Trajectory of OBD2: Future Trends

OBD2 is firmly established, but its evolution continues. Here are crucial trends shaping its future:

Originally conceived for emissions control and testing, legislated OBD2 doesn’t inherently apply to electric vehicles. Consequently, most modern EVs do not support standard OBD2 requests. Instead, they often employ OEM-specific UDS communication protocols. This typically makes data decoding challenging unless reverse engineering efforts reveal the decoding rules. However, there are successful examples of reverse engineering and accessing data from EVs, as shown in our case studies for electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Today, OBD2 implementations vary, facing limitations in data richness and lower-layer protocols. Modern alternatives like WWH-OBD (World-Wide Harmonized OBD) and OBDonUDS (OBD on UDS) address these issues. They aim to optimize OBD communication by utilizing the UDS protocol as a foundation. For deeper insights into these protocols, explore our introduction to UDS.

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

The solution on the horizon? OBD3 – integrating telematics into all vehicles.

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

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 challenges related to surveillance and data privacy.

Originally designed for stationary emission controls, OBD2 is now widely used by third parties for real-time data generation through OBD2 dongles, CAN loggers and similar tools. However, the German automotive industry is seeking to restrict this access:

“OBD has been designed to service cars 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 involves deactivating OBD2 functionality during driving, centralizing data collection with manufacturers. This would place OEMs in control of ‘automotive big data’.

Arguments for this shift often cite security concerns, such as mitigating the risk of car hacking. However, many perceive it as a commercially motivated strategy. The future of this proposal remains uncertain, but it could significantly disrupt the market for third-party OBD2 services.

OBD2 in Electric Vehicles: Potential Shifts Towards Restricted Data Access.

Enhance Your CAN Bus Expertise

Ready to become a CAN bus expert?

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

Download the Ultimate CAN Bus Guide Now

CAN Bus – The Ultimate Guide Tutorial PDF

Understanding OBD2 Standards

On-board diagnostics, OBD2, is a higher-layer protocol – think of it like a language. CAN bus, on the other hand, is a communication method – similar to a phone line. This positions OBD2 alongside other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

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

These standards can be structured within a 7-layer OSI model. The following sections will focus on the most critical aspects.

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

OBD2 and CAN Bus in the OSI Model: Layered Communication Standards.

OBD2 Connector Pinout: Type A Socket (Female) – Data Link Connector (DLC).

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector provides straightforward access to your vehicle’s data and is detailed in the SAE J1962 / ISO 15031-3 standards.

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

Key points to note:

The connector is usually near the steering wheel, but its exact location can vary and may be hidden.
Pin 16 supplies battery power, often even when the ignition is off.
The OBD2 pinout configuration depends on the communication protocol in use.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically connected.

OBD2 Connector Types: A vs. B

In practice, you may encounter both Type A and Type B OBD2 connectors. Type A is commonly found in cars, while Type B is more frequent in medium and heavy-duty vehicles.

As the illustration shows, 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 differ, with cars often using 500K, while heavy-duty vehicles typically use 250K (though 500K support is increasing).

Visually distinguishing them, the Type B OBD2 connector has a break in the center groove. 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.

OBD2 Connector Types A and B: Distinctions in Power and Application (Cars vs. Trucks).

OBD2 and CAN Bus: Interrelation and ISO 15765 Standards.

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, as per ISO 15765.

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies 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 must not exceed 5 meters in length.

OBD2 CAN Identifiers: 11-bit and 29-bit

All OBD2 communication uses request/response message exchanges.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID here is 0x7DF, which broadcasts a request to all OBD2-compatible ECUs to report data on the requested parameter (as per ISO 15765-4). CAN IDs ranging from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’ requests aimed at specific ECUs (less common).

ECUs can respond with 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 certain vehicles (e.g., vans and light/medium/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 is also sometimes represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which the J1939-71 standard marks as ‘Reserved for ISO 15765-2’.

OBD2 Protocol Request and Response Frames: Data Flow in OBD2 Communication.

OBD2 OBD CAN bus Identifiers 7DF 7E8 7E0

OBD2 vs. Proprietary CAN Bus Protocols: Coexistence within Vehicle Networks.

OBD2 vs. Proprietary CAN Protocols: A Dual System

It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) operate using OEM-specific CAN protocols, independently of OBD2. Each Original Equipment Manufacturer (OEM) develops proprietary CAN protocols tailored to their specific vehicle brands, models, and production years. Interpreting this OEM-specific data is generally not possible without OEM tools or reverse engineering expertise (reverse engineering techniques).

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

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

Bit-rate and ID Validation: Ensuring Correct Communication

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

ISO 15765-4 provides 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 mandatory OBD2 request (see the OBD2 PID section for details) and that incorrect bit rate transmission 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 primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979), WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2) exists as an alternative.

To test for OBDonEDS versus OBDonUDS protocol, diagnostic tools can send 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.

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

OBD2 Bit-rate and CAN ID Validation Flowchart: ISO 15765-4 Initialization Process.

OBD2 Lower-Layer Protocols: CAN (ISO 15765) and Legacy Protocols (KWP2000, SAE J1850, ISO9141).

Five Lower-Layer OBD2 Protocols: Beyond CAN

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

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and widely used in most modern vehicles.
ISO 14230-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): Primarily found in older GM vehicles.
SAE J1850 (PWM): Mostly used in older Ford vehicles.

ISO-TP: Transporting OBD2 Messages Beyond 8 Bytes (ISO 15765-2)

OBD2 data communication over CAN bus relies on ISO-TP (ISO 15765-2), a transport protocol. ISO-TP enables the transmission of data payloads exceeding the 8-byte CAN frame limit, essential for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). It manages data segmentation, flow control, and reassembly. For more details, refer to our introduction to UDS.

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

ISO-TP Frame Types for OBD2 Communication: Single Frame, First Frame, Consecutive Frame, Flow Control Frame.

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

To understand OBD2 over CAN in detail, let’s examine a raw ‘Single Frame’ OBD2 CAN message. Simplified, an OBD2 message consists of a CAN identifier, a data length indicator (PCI field), and the actual data. The data itself is structured into Mode, Parameter ID (PID), and data bytes.

OBD2 Message Structure: Mode, Parameter ID (PID), and Data Bytes Explained.

OBD2 Request/Response Example: Vehicle Speed

Consider this request-response sequence for retrieving ‘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 car responds using CAN ID 0x7E8 with 3 payload bytes, including the Vehicle Speed value in the 4th byte, 0x32 (decimal 50).

Referring to the OBD2 PID 0x0D decoding specifications, we determine that the physical value is 50 km/h.

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

OBD2 Request and Response Example: Retrieving Vehicle Speed (PID 0x0D).

OBD2 PID 0x0D: Vehicle Speed Parameter – Request and Response Breakdown.

OBD2 Services (Modes): 10 Standardized Diagnostic Services for Data Access and Control.

The 10 OBD2 Services (Modes): Accessing Diagnostic Functionality

OBD2 defines 10 diagnostic services, or modes. Mode 0x01 provides access to current, real-time data, while others are used to manage diagnostic trouble codes (DTCs) or retrieve freeze-frame data.

Vehicles are not required to support all 10 OBD2 modes and may also implement OEM-specific modes outside of these standardized ones.

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

OBD2 Parameter IDs (PIDs): Requesting Specific Data Points

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

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

One PID stands out as particularly important.

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID, the vehicle ECU indicates its support for PIDs 0x01-0x20. This makes PID 0x00 a crucial ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.

OBD2 Request-Response with PIDs: Parameter IDs for Specific Data Requests.

OBD2 PID overview tool
OBD2 PID Overview Tool: Service 01 – Accessing Real-Time Data Parameters.

Practical Tool: OBD2 PID Overview

The appendices of SAE J1979 and ISO 15031-5 detail scaling information for standard OBD2 PIDs, enabling you to convert raw data into physical values (as explained 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.

Access the OBD2 PID Overview Tool

Hands-on Guide: Logging and Decoding OBD2 Data

This section provides a practical 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 logging.

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

OBD2 Data Logger Setup: CANedge and OBD2-DB9 Adapter for Data Acquisition.

OBD2 bit rate test
Bit-rate Validation: Testing CAN Frame Transmission at 500K with CANedge.

OBD2 Supported PIDs Test
Supported PIDs Test Results: Reviewing OBD2 Responses in asammdf Software.

Review supported PIDs via OBD2 lookup tool

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

As discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a specific vehicle. You can use the CANedge to perform these tests (see the CANedge Introduction for setup details):

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

We provide ready-to-use configuration files to streamline these tests.

Most non-EV vehicles manufactured after 2008 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, multiple responses to a single OBD request are common. This is because the 0x7DF request ID polls all ECUs for responses. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are often seen. For subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. Notice that the ECM ECU (0x7E8) supports all PIDs supported by other ECUs in this example. Reducing bus load can be achieved by directing subsequent communication specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configuring OBD2 PID Requests for Logging

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

Consider these points when configuring your logging:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses per request.
Request Spacing: Introduce a delay of 300-500 ms between OBD2 requests to prevent ECU overload and ensure reliable responses.
Power Management: Implement triggers to halt transmissions when the vehicle is inactive to prevent battery drain by waking up ECUs unnecessarily.
Data Filtering: Apply filters to record only OBD2 responses if your vehicle also broadcasts OEM-specific CAN data, reducing data storage and processing overhead.

With these configurations, your CANedge device is ready to log raw OBD2 data efficiently.

obd2-transmit-list-example-canedge
Example CANedge OBD2 PID Request List Configuration.

OBD2 data decoded visual plot asammdf CAN bus DBC file
OBD2 Data Visualization in asammdf: DBC Decoding and Plotting of Logged Data.

Step #3: DBC Decoding of Raw OBD2 Data for Analysis

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

Decoding specifications are found in ISO 15031-5/SAE J1979 and online resources like Wikipedia. We provide a free OBD2 DBC file to simplify DBC decoding 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 is not sufficient to identify the signals within the payload.

Therefore, decoding requires using the CAN ID, OBD2 mode, and OBD2 PID together to identify the signal. This form of multiplexing, known as ‘extended multiplexing‘, can be implemented using DBC files.

CANedge: Your OBD2 Data Logging Solution

The CANedge offers a streamlined solution for recording OBD2 data directly to an 8-32GB SD card. Simply connect it to your vehicle and begin logging. Analyze the data using free software and APIs and our OBD2 DBC file.

Explore OBD2 Logger Options
Learn More About CANedge

Multi-Frame OBD2 Examples: ISO-TP in Action

All OBD2 communication utilizes ISO-TP (transport protocol) as defined in ISO 15765-2. While most examples so far have been single-frame, this section explores multi-frame communication scenarios.

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

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

OBD2-multi-frame-request-message-vehicle-identification-number
OBD2 Multi-Frame Request Example: Vehicle Identification Number (VIN) Retrieval.

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

The Vehicle Identification Number (VIN) is essential for telematics, diagnostics, and more (see our UDS introduction for further details). To retrieve the VIN using OBD2, use mode 0x09 and PID 0x02:

VIN Vehicle Identification Number OBD2 Example multi-frame

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

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

External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU should respond with data for supported PIDs (omitting unsupported ones), potentially spanning multiple frames as per ISO-TP.

This efficient method allows for higher-frequency data collection. However, the signal encoding becomes specific to the request method, complicating the use of generic OBD2 DBC files. We generally advise against this method for practical applications. Here’s an example trace of such a multi-PID request:

Requesting multiple PIDs in one request

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

Decoding this response using generic DBC files is challenging. We advise against this approach for practical data logging unless specialized tools with built-in support are used. This scenario represents extended multiplexing, complicated by multiple instances within the payload. DBC files would need to account for the specific payload position of each PID, making generalization across vehicles with varying PID support difficult. Managing multiple such multi-PID requests further complicates DBC handling.

Workarounds might involve custom scripts that interpret responses based on request messages. However, such methods are generally not scalable.

Example 3: Diagnostic Trouble Codes (DTCs) Retrieval via OBD2

OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’, allows retrieval of emissions-related DTCs. The request frame does not include a PID. Responding ECUs indicate the number of stored DTCs (possibly zero), with each DTC occupying 2 data bytes. Multi-frame responses are needed when more than 2 DTCs are stored.

The 2-byte DTC value is structured as per ISO 15031-5/ISO 15031-6. The first 2 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 6 stored DTCs.

OBD2 DTC Decoding: Interpreting Diagnostic Trouble Code Bytes.

OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response Example

OBD2 Data Logging: Real-World Applications

OBD2 data from cars and light trucks has diverse applications:

Vehicle Data Logging

OBD2 data logging in cars can optimize fuel efficiency, improve driving habits, test prototype components, and inform insurance models.

Explore OBD2 Data Loggers

Real-time Vehicle Diagnostics

OBD2 interfaces enable real-time streaming of human-readable diagnostic data, aiding in immediate vehicle troubleshooting.

Discover OBD2 Streaming Interfaces

Predictive Maintenance Solutions

IoT-connected OBD2 loggers facilitate remote vehicle monitoring for predictive maintenance, preventing breakdowns.

Learn about Predictive Maintenance Applications

Vehicle Black Box Recorders

OBD2 loggers can function as ‘black boxes’ in vehicles or equipment, providing crucial data for incident analysis or diagnostics.

Explore Vehicle Black Box Loggers

Have an OBD2 data logging application in mind? Contact us for a free consultation!

Contact Our Team

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

Ready to Log or Stream OBD2 Data?

Get Your OBD2 Data Logger Today!

Purchase Now Contact Us for Support