OBD2 Guide: Your Comprehensive Guide to On-Board Diagnostics

Looking for a detailed yet easy-to-understand guide on OBD2?

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

Note: This is designed to be a comprehensive guide, offering you advanced insights into requesting and interpreting OBD2 data, crucial logging applications, and expert tips.

Discover why this is considered the ultimate OBD2 resource below.

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

What is OBD2?
Does My Car Use OBD2?
The History of OBD2
The Future of OBD2
OBD2 Standards Explained
Understanding the OBD2 Connector (SAE J1962)
OBD2 and CAN Bus Integration (ISO 15765-4)
Decoding OBD2 Messages with ISO-TP (ISO 15765-2)
The OBD2 Diagnostic Message (SAE J1979, ISO 15031-5)
Practical Guide: Logging and Decoding OBD2 Data
OBD2 Multi-Frame Communication Examples (ISO-TP)
Key OBD2 Data Logging Applications

Author: Martin Falch (Updated January 2025)

Download as PDF

1. What is OBD2?

OBD2, or On-Board Diagnostics version 2, is essentially your car’s built-in health monitoring system. It’s a standardized protocol that allows you to access vital information about your vehicle’s performance and diagnose potential problems. Through the OBD2 system, you can retrieve diagnostic trouble codes (DTCs) and access real-time data using an OBD2 scanner connected to your car’s OBD2 port.

You’ve likely already encountered OBD2 in action, perhaps without realizing it:

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

That light is your car signaling an issue detected by the OBD2 system. When you take your car to a mechanic, they use an OBD2 scanner, also known as a scan tool, to pinpoint the problem.

The mechanic connects the OBD2 reader to the 16-pin OBD2 connector, usually located beneath the steering wheel column. This tool transmits ‘OBD2 requests’ to the vehicle’s computer, and the car responds with ‘OBD2 responses’. These responses can include a wealth of data such as vehicle speed, fuel level, and most importantly, Diagnostic Trouble Codes (DTCs). This data stream empowers mechanics to diagnose malfunctions more efficiently and effectively.

2. Does My Car Use OBD2?

The short answer: Almost certainly, yes!

The vast majority of modern gasoline and diesel cars, excluding fully electric vehicles, are equipped with OBD2 systems, often operating on the CAN bus network. However, it’s important to note that in older vehicles, even if a 16-pin connector resembling an OBD2 port is present, it might not actually support the OBD2 protocol.

To definitively determine OBD2 compliance, consider the vehicle’s region of sale and manufacturing date:

3. The History of OBD2

The origins of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated the inclusion of OBD systems in all new vehicles starting from 1991 for emissions monitoring.

The OBD2 standard as we know it today was developed and recommended by the Society of Automotive Engineers (SAE). It standardized Diagnostic Trouble Codes (DTCs) and the physical OBD connector across all vehicle manufacturers through the SAE J1962 standard.

The global adoption of the OBD2 standard occurred in phases:

1996: OBD2 became mandatory in the USA for all cars and light trucks.
2001: The European Union mandated OBD2 for gasoline cars.
2003: The EU extended the mandate to include diesel cars (known as EOBD – European On-Board Diagnostics).
2005: OBD2 compliance was required in the US for medium-duty vehicles.
2008: US vehicle manufacturers were required to implement ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 became mandatory in the US for heavy-duty vehicles.

4. The Future of OBD2

OBD2 is firmly established in automotive diagnostics, but its future evolution is already taking shape.

Here are some key trends shaping the future of OBD:

Initially, regulatory OBD2 was conceived primarily for emissions control and testing. Consequently, electric vehicles are not obligated to support OBD2 in its traditional 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 shift largely restricts access to EV data unless decoding methods are reverse-engineered, as highlighted in our electric car case studies for brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

The current OBD2 implementation faces limitations in data richness and underlying communication protocols. To address these, advanced alternatives have emerged, notably 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 protocols, refer to our introduction to UDS.

In our increasingly connected world, traditional OBD2 testing methods are becoming less efficient. Manual emission checks are time-consuming and costly.

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

OBD3 envisions adding a small radio transponder (similar to those used for toll collection) to every car. This transponder would enable the vehicle to wirelessly transmit its Vehicle Identification Number (VIN) and DTCs via WiFi to a central server for automated monitoring.

Many devices today already support CAN or OBD2 data transfer over WiFi/cellular networks. Examples include the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.

While offering cost savings and convenience, OBD3 raises political challenges related to data privacy and surveillance.

The OBD2 protocol was originally designed for stationary emissions testing in repair shops.

However, today, OBD2 is extensively utilized by third-party services to generate real-time vehicle data via OBD2 dongles, CAN loggers and similar devices. The German car industry is considering restricting this access:

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

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal involves potentially disabling OBD2 functionality during driving and instead centralizing data collection within manufacturer-controlled servers. This would give manufacturers control over the burgeoning field of ‘automotive big data’.

Security concerns, such as mitigating the risk of car hacking, are cited as justification, though many perceive this as a commercially motivated strategy. Whether this trend gains traction remains to be seen, but it could significantly reshape the market for third-party OBD2 services.

Enhance Your CAN Bus Expertise

Aspiring to become a CAN bus expert?

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

Download Now

5. OBD2 Standards Explained

On-board diagnostics, OBD2, operates as a higher-layer protocol, akin to a language, while CAN functions as the communication medium, similar to a telephone line. This analogy positions OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

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

These standards can be visualized using the 7-layer OSI model. The following sections will delve into the most critical aspects of these standards.

Within the OSI model framework, you’ll notice that both SAE and ISO standards cover several layers. This reflects the development of OBD standards in the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, for instance, SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3.

6. Understanding the OBD2 Connector (SAE J1962)

The 16-pin OBD2 connector provides a standardized and easy interface to access your vehicle’s data. Its specifications are detailed in the SAE J1962 / ISO 15031-3 standard.

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

Key points regarding the OBD2 connector:

It’s typically located near the steering wheel, though its exact location can be somewhat hidden depending on the vehicle model.
Pin 16 provides battery power, often remaining live even when the ignition is off.
The specific OBD2 pinout configuration varies depending on the communication protocol used by the vehicle.
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 standard in most passenger cars, while Type B is more common in medium and heavy-duty vehicles.

As shown in the illustration, both types share a similar pinout structure, but they differ in their power supply outputs: Type A typically provides 12V, while Type B provides 24V. The communication baud rate may also differ, with cars generally using 500K and heavy-duty vehicles often using 250K (though 500K support is becoming more common in newer heavy-duty vehicles).

A key physical difference is that the Type B OBD2 connector has a central interrupted groove. This design allows a Type B OBD2 adapter cable to be compatible with both Type A and Type B sockets, while a Type A adapter will only fit into a Type A socket.

7. OBD2 and CAN Bus Integration (ISO 15765-4)

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

ISO 15765-4, also known as Diagnostics over CAN (DoCAN), outlines specific constraints applied to the CAN standard (ISO 11898) for OBD2 implementation.

Specifically, it standardizes the CAN interface for diagnostic equipment, focusing on the physical layer, data link layer, and network layer:

The 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)

All OBD2 communication is structured around request and response messages.

In most passenger vehicles, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is used to broadcast a request to all OBD2-compatible ECUs, asking if they have data to report on the requested parameter (defined in ISO 15765-4). Conversely, CAN IDs ranging from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’ requests, targeting specific ECUs (though this is less common).

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

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

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

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

OBD2 vs. Proprietary CAN Protocols

It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) operate independently of OBD2 for their core functions. Each Original Equipment Manufacturer (OEM) implements their own proprietary CAN protocols for internal vehicle communication. These OEM CAN protocols are often unique to the vehicle brand, model, and year. Generally, this OEM-specific data remains undecipherable to external parties unless it can be reverse engineered.

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

In essence, think of OBD2 as a supplementary higher-layer protocol that operates alongside the OEM-specific communication network.

Bit-rate and ID Validation

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

ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination, illustrated in the flowchart below. 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 incorrect bit rates will cause CAN error frames during data transmission.

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

To differentiate between OBDonEDS and OBDonUDS protocols, a diagnostic tool can send additional UDS requests. Specifically, sending 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 mainly used in EU trucks and buses.

Five Lower-Layer OBD2 Protocols

While CAN bus is the dominant lower-layer protocol for OBD2 today (ISO 15765), especially in vehicles manufactured post-2008, older vehicles may utilize other protocols. If working with older cars (pre-2008), understanding these alternative protocols is beneficial. The OBD2 connector pinout itself can sometimes indicate the protocol in use.

The five lower-layer OBD2 protocols include:

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and currently the most widely used protocol.
ISO14230-4 (KWP2000): Keyword Protocol 2000, frequently used in 2003+ vehicles, particularly in Asia.
ISO 9141-2: Used in European, Chrysler, and Asian vehicles manufactured around 2000-2004.
SAE J1850 (VPW): Predominantly used in older General Motors (GM) vehicles.
SAE J1850 (PWM): Primarily found in older Ford vehicles.

8. Decoding OBD2 Messages with ISO-TP (ISO 15765-2)

All OBD2 data communication over CAN bus relies on the ISO-TP (ISO 15765-2) transport protocol. ISO-TP allows for the transmission of data payloads exceeding the standard 8-byte CAN frame limit. This is essential in OBD2 for transmitting larger data sets, such as Vehicle Identification Numbers (VINs) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles data segmentation, flow control, and reassembly for these multi-frame messages. For a deeper dive into ISO-TP, refer to our introduction to UDS.

However, many OBD2 data transmissions fit within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF) format. The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes available for OBD2-specific data.

9. The OBD2 Diagnostic Message (SAE J1979, ISO 15031-5)

To fully grasp OBD2 communication over CAN, let’s examine the structure of a raw ‘Single Frame’ OBD2 CAN message. In simple terms, an OBD2 message consists of a CAN identifier, a data length indicator (PCI field), and the data payload. The data payload is further structured into Mode, Parameter ID (PID), and data bytes.

Example: OBD2 Request and Response

Before diving into the details of each part of the OBD2 message, let’s consider a practical example: requesting and receiving vehicle speed data.

In this scenario, an external diagnostic tool sends a request message to the vehicle using CAN ID 0x7DF. This request contains two payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds using CAN ID 0x7E8 with a 3-byte payload. The vehicle speed value is encoded in the 4th byte of the CAN data, which is 0x32 (decimal 50).

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

In the following sections, we will explore OBD2 modes and PIDs in more detail.

The 10 OBD2 Services (Modes)

The OBD2 standard defines 10 diagnostic services, also referred to as modes. Mode 0x01 is used to retrieve current real-time data, while other modes facilitate accessing and clearing Diagnostic Trouble Codes (DTCs) or retrieving freeze frame data.

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

Within 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 requested mode value (e.g., a response to mode 0x01 will have a mode byte of 0x41).

OBD2 Parameter IDs (PIDs)

Each OBD2 mode contains a set of 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 need to support all PIDs within a given mode. In practice, most vehicles only support a subset of the available PIDs.

One PID holds special significance:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. In response to this PID, the ECU reports which PIDs from the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental tool for ‘OBD2 compatibility testing’. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for the remaining mode 0x01 PIDs in ranges 0x21-0x40, 0x41-0x60, etc.

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 contain detailed scaling information for standard OBD2 PIDs. This information is crucial for converting the raw data bytes into meaningful physical values, as explained in our CAN bus introduction.

If you need to quickly look up mode 0x01 PIDs, our OBD2 PID overview tool is a valuable resource. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID Overview Tool

10. 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’s flexible configuration allows users to define custom CAN frames for transmission, making it ideal for OBD2 logging.

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

Test successful CAN frame transmission at 500K baud rate.
Review responses to ‘Supported PIDs’ requests using asammdf software.

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

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

Test Bit Rate: Send a CAN frame at 500K baud rate and check for successful transmission (if unsuccessful, try 250K).
Confirm Bit Rate: Use the validated bit rate for all subsequent communication.
Request Supported PIDs: Send multiple ‘Supported PIDs’ requests (Mode 0x01, PID 0x00 and subsequent PIDs to cover all ranges).
Analyze Response IDs: Determine if the vehicle uses 11-bit or 29-bit CAN IDs based on the response IDs received.
Identify Supported PIDs: Analyze the response data to determine the specific PIDs supported by the vehicle.

We provide ready-to-use configuration files to simplify these initial 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 illustrated in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBD request. This occurs because we use the functional address request ID (0x7DF), which polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses are often received for this PID in particular. As you progress to subsequent ‘Supported PIDs’ requests, fewer ECUs will typically respond. Note that the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs. Therefore, to reduce busload, you can optimize communication by directing subsequent requests specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configure OBD2 PID Requests

Once you have identified the PIDs supported by your vehicle and the correct bit rate and CAN IDs, you can configure your transmit list to request the specific PIDs you are interested in logging.

Consider these factors when configuring your PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0 for ECM) to avoid receiving redundant responses from multiple ECUs.
Request Spacing: Introduce a delay of 300-500 ms between each OBD2 request. Excessively frequent requests can overwhelm ECUs and lead to dropped responses.
Minimize Battery Drain: Implement triggers to stop PID requests when the vehicle is inactive. This prevents unnecessary ECU wake-up and battery drain, especially during prolonged logging sessions.
Filtering: Configure filters to record only OBD2 responses. This is particularly useful if your vehicle also broadcasts OEM-specific CAN data, allowing you to isolate and focus on OBD2 data.

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

Example CANedge configuration for OBD2 PID requests.

Visualize DBC decoded OBD2 data and plot trends using asammdf software.

Step #3: DBC Decode Raw OBD2 Data

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

The necessary decoding formulas and scaling factors are defined in ISO 15031-5/SAE J1979 and are also available on resources like Wikipedia. For convenience, we provide a free OBD2 DBC file. This DBC file simplifies the DBC decoding process for raw OBD2 data in most CAN bus analysis software tools.

Decoding OBD2 data is slightly more complex than decoding standard CAN signals. This is because multiple OBD2 PIDs can be 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, decoding must consider the CAN ID, the OBD2 mode, and the OBD2 PID to correctly identify each signal. This technique is known as ‘extended multiplexing‘ and can be effectively implemented using DBC files.

CANedge: Your OBD2 Data Logger

The CANedge provides a streamlined solution for recording OBD2 data directly to a removable 8-32 GB SD card. Simply connect it to your vehicle (car, truck, etc.) to begin logging. Decode and analyze your data using free software and APIs and our readily available OBD2 DBC file.

OBD2 Logger Introduction
Explore CANedge Data Logger

11. OBD2 Multi-Frame Communication Examples (ISO-TP)

All OBD2 data exchange utilizes the ISO-TP (transport protocol) as per ISO 15765-2. While most examples so far have focused on single-frame communication, this section provides examples of multi-frame communication scenarios.

Multi-frame OBD2 communication necessitates flow control frames (see our UDS introduction for details). 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 or API tools with ISO-TP support, such as the CANedge MF4 decoders.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval

The Vehicle Identification Number (VIN) is often essential for telematics, diagnostics, and various vehicle-related applications (refer to our UDS introduction for more information). To retrieve the VIN from a vehicle using OBD2 requests, you use mode 0x09 and PID 0x02:

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

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

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

This feature enhances data collection efficiency and frequency. However, it also makes signal decoding more complex as the signal encoding becomes specific to the request method. This approach complicates the use of generic OBD2 DBC files. Therefore, we generally advise against using multi-PID requests in practice. The trace example below illustrates a multi-PID request scenario:

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

Decoding such responses using generic DBC files is challenging. Therefore, we do not recommend multi-PID requests for practical data logging unless you are using a tool with specific built-in support for this method. Effectively, you are dealing with a complex case of extended multiplexing with multiple instances within a single payload. Furthermore, creating a DBC file to handle this becomes extremely difficult due to the payload position dependency of each PID and the variability in supported PIDs across different vehicles. Generalizing such a DBC across multiple vehicle types becomes nearly impossible.

While custom scripts and recording transmit messages from your test tool could potentially work around these challenges, enabling interpretation of response messages in conjunction with request messages, such approaches are generally difficult to scale and manage effectively.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval

OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’, allows you to request emissions-related Diagnostic Trouble Codes (DTCs). No PID is included in the request. The targeted ECU(s) will respond with the number of DTCs stored (which could be 0 if no DTCs are present), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored.

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

The example below illustrates a request to an ECU reporting 6 stored DTCs.

12. Key OBD2 Data Logging Applications

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

Vehicle Data Logging from Cars

OBD2 data logging in passenger cars can be used for various purposes, including fuel efficiency optimization, driver behavior analysis, prototype component testing, and insurance telematics.

Explore OBD2 Loggers

Real-Time Vehicle Diagnostics

OBD2 interfaces enable real-time streaming of vehicle data in a human-readable format, facilitating efficient vehicle diagnostics and troubleshooting.

Learn about OBD2 Streaming

Predictive Maintenance Applications

Cars and light trucks equipped with IoT OBD2 loggers can be remotely monitored via cloud platforms for predictive maintenance, enabling proactive breakdown prevention and optimized vehicle uptime.

Discover Predictive Maintenance Solutions

Vehicle Black Box Recording

An OBD2 logger can serve as a ‘black box’ for vehicles or equipment, providing crucial data for incident reconstruction, dispute resolution, and detailed diagnostics in case of accidents or malfunctions.

Explore CAN Bus Black Box Loggers

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

For more in-depth introductions, explore our guides section or download the comprehensive ‘Ultimate Guide’ PDF.

Ready to start logging or streaming OBD2 data?

Get your OBD2 data logger today!

Buy Now
Contact Us for Assistance

Recommended Resources

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN