OBD2 Explained: Your Comprehensive Guide to On-Board Diagnostics [2025]

Looking for a straightforward and practical understanding of Obd2?

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

This is a hands-on introduction, designed to teach you how to request and interpret OBD2 data, explore key use cases for data logging, and offer practical tips.

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

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

Understanding OBD2: What Is It?

OBD2, or On-Board Diagnostics version 2, is essentially your vehicle’s internal health monitoring system. It’s a standardized protocol that enables access to diagnostic trouble codes (DTCs) and real-time vehicle data through the OBD2 port.

You’ve likely encountered OBD2 in action without even realizing it.

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

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

Mechanics connect an OBD2 reader to the OBD2 16-pin connector, typically found under the dashboard near the steering column. This tool sends ‘OBD2 requests’ to the car’s computer, and the car responds with ‘OBD2 responses’. These responses can contain critical information like speed, fuel level, and Diagnostic Trouble Codes (DTCs), which significantly speeds up the troubleshooting process.

Understanding OBD2: On-Board Diagnostics and the Malfunction Indicator Light (MIL)

OBD2 Compatibility: Does Your Car Have It?

The short answer is: Almost certainly!

Nearly all modern gasoline and diesel cars, with the exception of electric vehicles in some aspects, are equipped with OBD2 and predominantly operate on the CAN bus protocol. If you own an older vehicle, it’s important to note that even if a 16-pin OBD2 connector is present, it might not actually support the OBD2 protocol. A reliable way to confirm OBD2 compliance is by checking where and when your car was originally purchased:

OBD2 Compliance Guide: Check if Your Car is OBD2 Compatible Based on Purchase Location and Year

A Look at OBD2 History

The origin of OBD2 can be traced back to California. The California Air Resources Board (CARB) mandated the inclusion of OBD systems in all new vehicles starting from 1991 for the purpose of emission control.

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

From its Californian roots, the OBD2 standard was progressively implemented worldwide:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: Required in the European Union for gasoline cars.
2003: Extended in the EU to include diesel cars under the European On-Board Diagnostics (EOBD) regulation.
2005: OBD2 requirement in the US expanded to medium-duty vehicles.
2008: US vehicles were required to adopt ISO 15765-4 (CAN) as the communication basis for OBD2.
2010: OBD2 mandate finally extended to heavy-duty vehicles in the US.

OBD2 History: From Emission Control to Modern Vehicle Data Acquisition via CAN bus

OBD2 History Timeline: A Visual Overview of On-Board Diagnostics Evolution

The Future of OBD: OBD3, Remote Diagnostics, and Cloud-Based Emission Testing

The Future Trajectory of OBD2

OBD2 is firmly established in the automotive industry, but its future form is evolving.

Here are some key trends shaping the future of OBD systems:

Initially designed for emissions monitoring and testing, legislated OBD2 systems are not explicitly required for electric vehicles. Consequently, most modern EVs do not fully support standard OBD2 requests. Instead, they often utilize OEM-specific UDS communication protocols. This shift can make data retrieval from EVs challenging, except in cases where decoding methods have been reverse-engineered. Examples include our case studies for electric cars covering Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Recognizing the limitations of current OBD2 implementations in terms of data richness and protocol efficiency, newer alternatives have emerged. These include WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). Both aim to modernize OBD communication by building upon the UDS protocol. For a deeper understanding of these advancements, refer to our introduction to UDS.

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

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

OBD3 envisions adding a small radio transponder to every car, similar to those used for electronic toll collection. This technology would allow for the automatic transmission of the car’s vehicle identification number (VIN) and DTCs via WiFi to a central server for streamlined monitoring.

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

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

The original OBD2 protocol was conceived for stationary emission testing.

However, today, OBD2 is extensively used by third parties to generate real-time vehicle data through OBD2 dongles, CAN loggers and similar devices. The German automotive industry is seeking to change this landscape:

“OBD was intended for servicing cars in repair shops. It was never meant to allow third parties to build a data-driven economy on the access provided by this interface.”

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal involves deactivating OBD2 functionality while the vehicle is in motion, centralizing data collection through manufacturer-controlled servers. This would effectively place automotive manufacturers at the helm of the burgeoning ‘automotive big data’ sector.

The rationale is often centered around security, aiming to mitigate the risk of car hacking. However, many view this as a commercially motivated maneuver. Whether this trend will solidify remains to be seen, but it has the potential to significantly disrupt the market for third-party OBD2 services.

OBD2 Future: Will Electric Vehicles Limit Access to Diagnostic Data?

Enhance Your CAN Bus Expertise

Ready to become proficient in CAN bus technology?

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

Download now

Decoding OBD2 Standards

On-board diagnostics, specifically OBD2, operates as a higher-layer protocol – akin to a language in communication systems. CAN (Controller Area Network) functions as the communication method, comparable to a telephone line. This positions OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

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

These standards can be categorized using the 7-layer OSI model. In the following sections, we will focus on the most crucial aspects.

In the OSI model framework, it’s notable that both SAE and ISO standards cover multiple layers. This reflects the standardization efforts for OBD systems 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.

OBD2 and CAN Bus in the OSI Model: ISO 15765 and ISO 11898 Standards

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

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 typical Type A OBD2 pin connector, also known as a Data Link Connector (DLC).

Key points about the OBD2 connector:

It’s generally located near the steering wheel, although it can sometimes be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout configuration depends on the vehicle’s communication protocol.
CAN bus is the most prevalent lower-layer protocol, which means pins 6 (CAN-H) and 14 (CAN-L) are commonly used for communication.

OBD2 Connector Types: A vs. B

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

As illustrated, 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).

Visually distinguishing them, the Type B OBD2 connector has a distinctive interrupted groove in the middle. Consequently, a Type B OBD2 adapter cable is versatile and compatible with both Type A and B sockets, whereas a Type A connector will not fit into a Type B socket.

OBD2 Connector Types A and B: Differences in SAE J1962 Standards for Cars, Vans, and Trucks

OBD2 vs CAN Bus: Understanding 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 (DoCAN), specifies a set of constraints and guidelines for using CAN (ISO 11898) in diagnostic applications.

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

CAN bus bit-rates must be either 250K or 500K.
CAN IDs can be 11-bit or 29-bit.
Specific CAN IDs are designated for OBD request and response messages.
Diagnostic CAN frame data length is fixed at 8 bytes.
The OBD2 adapter cable is limited to a maximum length of 5 meters.

OBD2 CAN Identifiers: 11-bit and 29-bit

OBD2 communication is structured around request and response messages.

In most passenger cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, which is used to query all OBD2-compliant ECUs (Electronic Control Units) about their ability to provide data on the requested parameter (as defined in ISO 15765-4). Conversely, CAN IDs from 0x7E0 to 0x7E7 can be utilized for ‘Physical Addressing’ requests to specific ECUs, although this is less frequently used.

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

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

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

Responses from the vehicle are typically seen with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (commonly 18DAF110 and 18DAF11E). The response ID is also sometimes referred to in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is reserved for ISO 15765-2 in the J1939-71 standard.

OBD2 Protocol: Request and Response Frames for PID Data Parameters

OBD2 vs Proprietary CAN bus: Understanding the Differences in Vehicle Data Access

OBD2 vs. Proprietary CAN Protocols

It’s important to understand that your vehicle’s Electronic Control Units (ECUs) operate independently of OBD2 for their primary functions. Each Original Equipment Manufacturer (OEM) implements its own proprietary CAN protocols for vehicle control and communication. These OEM-specific CAN protocols are often unique to the vehicle brand, model, and production year. Without OEM documentation, interpreting this proprietary data is typically not possible unless you engage in reverse engineering.

When you connect a CAN bus data logger to your vehicle’s OBD2 connector, you might observe OEM-specific CAN data being broadcast, typically at a high rate of 1000-2000 frames per second. However, in many newer vehicles, a ‘gateway’ module restricts access to this raw CAN data, allowing only OBD2 communication through the OBD2 port.

In essence, think of OBD2 as a supplementary, higher-layer protocol that runs in parallel with the OEM-specific protocols.

Bit-rate and ID Validation

As previously mentioned, OBD2 can operate at two different bit rates (250K, 500K) and with two CAN ID lengths (11-bit, 29-bit), resulting in four potential protocol combinations. In contemporary vehicles, 500K bit-rate with 11-bit IDs is the most common configuration. Diagnostic tools should systematically verify these parameters.

ISO 15765-4 provides guidelines for performing an initialization sequence to automatically determine the correct communication parameters, illustrated in the flowchart below. This process leverages 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 using an incorrect bit rate will result in CAN error frames.

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

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

In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is predominantly used in non-electric vehicles today, whereas WWH-OBD is mainly found in EU trucks and buses.

OBD2 Bit-rate and CAN ID Validation Flowchart: ISO 15765-4 Compliance

OBD2 Standards: The Five Protocols – CAN (ISO 15765), KWP 2000, SAE J1850, and ISO 9141

Five Lower-Layer OBD2 Protocols

While CAN bus is the dominant lower-layer protocol for OBD2 today, as standardized by ISO 15765, particularly in vehicles manufactured post-2008, it’s beneficial to be aware of the four alternative protocols used in older vehicles. The pinout configurations can often indicate which protocol is in use in your vehicle.

ISO 15765 (CAN bus): Mandated in US vehicles since 2008 and currently the most widely used protocol.
ISO 14230-4 (KWP2000): Keyword Protocol 2000, common in vehicles from 2003 onwards, especially in Asia.
ISO 9141-2: Used in European, Chrysler, and Asian vehicles from 2000-2004.
SAE J1850 (VPW): Predominantly used in older General Motors vehicles.
SAE J1850 (PWM): Primarily found in older Ford vehicles.

ISO-TP: Transporting OBD2 Messages [ISO 15765-2]

All OBD2 data transmission over CAN bus relies on the ISO-TP (ISO 15765-2) transport protocol. This protocol is crucial for enabling the communication of data payloads exceeding the 8-byte limit of standard CAN frames. This capability is essential in OBD2 for tasks such as retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 manages data segmentation, flow control, and reassembly. For a more detailed explanation, please refer to our introduction to UDS.

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

ISO 15765-2 ISO-TP OBD2 Frame Types: Single Frame, First Frame, Consecutive Frame, and Flow Control Frame

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

To better understand OBD2 communication over CAN, let’s examine a basic ‘Single Frame’ OBD2 CAN message. In simple terms, an OBD2 message consists of an identifier, a data length indicator (PCI field), and the actual data. The data section is further divided into Mode, Parameter ID (PID), and data bytes.

OBD2 PIDs: OBD-II Message Structure Breakdown Explained – Mode, PID, and Data Bytes

OBD2 Request/Response Example

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

In this scenario, an external diagnostic tool sends a request message to the vehicle with CAN ID 0x7DF, containing two payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds via CAN ID 0x7E8 with three payload bytes, including the vehicle speed value in the fourth byte, represented as 0x32 (which is 50 in decimal).

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

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

OBD2 Request and Response: Example of 7DF Request and 7E8 Response for Vehicle Speed

OBD2 PID Example: Vehicle Speed Parameter ID 0D

OBD2 Services and Modes: Overview of 10 Diagnostic Services Including Current Data, Freeze Frame, and DTC Clearing

The 10 OBD2 Services (Modes)

There are ten defined OBD2 diagnostic services, commonly referred to as modes. Mode 0x01 is used to retrieve current real-time data, while other modes are designed to access and clear diagnostic trouble codes (DTCs) or to retrieve freeze frame data.

Vehicles are not required to support all OBD2 modes and may also implement additional, OEM-specific modes beyond the ten standardized ones.

In OBD2 messages, the mode is indicated 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 mode value (e.g., resulting in 0x41 for a response to mode 0x01).

OBD2 Parameter IDs (PIDs)

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, it’s important to note that a vehicle is not obligated to support all PIDs within a given mode. In practice, most vehicles support only a subset of the available PIDs.

One PID holds particular significance in OBD2 diagnostics.

Specifically, if an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. When this PID is requested, the vehicle ECU responds with a bitmask indicating which PIDs from 0x01 to 0x20 it supports. This makes PID 0x00 a crucial ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, and so on, up to 0xC0, can be used to determine support for subsequent ranges of mode 0x01 PIDs.

OBD2 Protocol Request and Response Frames: Essential for PID Data Parameter Communication

OBD2 PID Overview Tool: Service 01 for Real-Time Data Parameters

Tip: 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 detailed 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.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 Data

In this section, we’ll walk through 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.

OBD2 PID Data Logger Request: Utilizing 7DF and 7E8 for Data Acquisition

Validating Bit-Rate: Testing Successful CAN Frame Transmission at 500K

Reviewing Supported PIDs: Analyzing Responses in asammdf for OBD Validation

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

As previously 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 as described below (refer to the CANedge Intro for detailed instructions):

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

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

Most non-electric vehicles manufactured in 2008 or later typically 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, 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, many responses are typically received for this PID. As observed, fewer ECUs respond to subsequent ‘Supported PIDs’ requests. Notably, the ECM ECU (0x7E8) in this example supports all PIDs supported by other ECUs, indicating 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

Once you’ve identified the OBD2 PIDs supported by your vehicle and the correct bit-rate and CAN IDs, you can configure your transmit list to request the PIDs of interest.

Consider these points when configuring your requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses per request.
Request Spacing: Implement a delay of 300-500 ms between each OBD2 request to prevent overwhelming the ECUs, which may cause them to stop responding.
Battery Management: Use 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, especially if your vehicle also broadcasts OEM-specific CAN data.

With these configurations in place, your device is set up to effectively log raw OBD2 data.

Example CANedge OBD2 PID Request Transmit List Configuration

Visualizing Decoded OBD2 Data: Plotting with asammdf and CAN bus DBC file

Step #3: DBC Decoding of Raw OBD2 Data

Finally, to analyze and visualize your logged data, you need to decode the raw OBD2 data into meaningful ‘physical values’ such as km/h or °C.

The necessary decoding information is available in ISO 15031-5/SAE J1979 and can also be found on resources like Wikipedia. For convenience, we provide 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 because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is not sufficient to uniquely identify the signals within the payload.

To address this, it’s essential to use the CAN ID, OBD2 mode, and OBD2 PID together to correctly identify each signal. This method of multiplexing is known as ‘extended multiplexing‘, and it can be effectively implemented using DBC files.

CANedge: Your OBD2 Data Logging Solution

The CANedge offers an easy way to record OBD2 data directly to a removable 8-32 GB SD card. Simply connect it to your car or truck to start logging. Data can then be decoded using free software and APIs and our OBD2 DBC file.

OBD2 logger intro
CANedge product details

OBD2 Multi-Frame Examples: ISO-TP in Action

All OBD2 communication utilizes the ISO-TP transport protocol (ISO 15765-2). While many examples are single-frame, multi-frame communication is crucial for larger data sets. This section provides examples of multi-frame OBD2 interactions.

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

Analyzing 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 Example for Vehicle Identification Number (VIN)

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

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

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 containing the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is the byte 0x01, indicating 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 represent the VIN and can be converted from HEX to ASCII using methods discussed in our UDS introduction.

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

External 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 data for unsupported PIDs in the response), using multiple frames if necessary, as per ISO-TP.

This capability enhances data collection efficiency and frequency. However, the signal encoding becomes specific to the request method, which complicates the use of generic OBD2 DBC files. We generally advise against this method for most applications. Below is an example trace of such a multi-PID request:

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

Decoding this response using standard DBC files is challenging, making this approach less practical for general data logging unless you are using tools specifically designed to support it. This scenario represents a complex form of extended multiplexing, compounded by the challenge of payload position variability for each PID across different vehicles.

This complexity can be partially addressed with custom scripts and by recording the transmit messages from your diagnostic tool. The script could then correlate response messages with request messages to interpret the data. However, such methods are difficult to scale and manage across diverse applications.

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 currently stored (which may be zero if no DTCs are present), with each DTC represented by 2 data bytes. Multi-frame responses are necessary 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 DTC ‘category’, and the remaining 14 bits form a 4-digit code (displayed in hexadecimal), as shown in the visual. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.

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

OBD2 DTC Decoding: Diagnostic Trouble Code Interpretation and DBC Example

OBD2 Data Logging: Real-World Use Cases

OBD2 data from cars and light trucks is invaluable in various applications:

Vehicle Data Logging

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

Explore OBD2 Loggers

Real-Time Vehicle Diagnostics

OBD2 interfaces facilitate real-time streaming of vehicle data for immediate diagnostics and troubleshooting.

Discover OBD2 Streaming

Predictive Maintenance

IoT-enabled OBD2 loggers allow for cloud-based vehicle monitoring to predict and prevent potential breakdowns.

Learn about Predictive Maintenance

Vehicle Black Box Recording

An OBD2 logger can function as a vehicle ‘black box’, providing crucial data for incident analysis and diagnostics.

Explore Black Box CAN Loggers

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

For further reading, explore our guides section or download our comprehensive ‘Ultimate Guide’ PDF.

Ready 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
Learn More

CANEDGE2 – PRO CAN IoT LOGGER
Explore CANedge2

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN
Discover CAN Bus Interface