OBD2 Information: Your Comprehensive Guide to On-Board Diagnostics

Want to understand OBD2 in simple terms?

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

Note: This is designed as a practical introduction, so you’ll also learn how to request and decode OBD2 data, explore key logging applications, and gain valuable practical tips.

Discover why this has become a leading OBD2 tutorial.

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

Understanding OBD2: What is It?

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

You’ve likely already encountered OBD2 in action:

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

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

To do this, the mechanic connects an OBD2 reader to the 16-pin OBD2 connector, typically located near the steering wheel. This tool sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’ that can include data like speed, fuel level, or Diagnostic Trouble Codes (DTCs). This process significantly speeds up troubleshooting and repair.

Understanding OBD2: The malfunction indicator light (MIL), commonly known as the check engine light, is a key component of the On-Board Diagnostics system.

OBD2 Compatibility: Does Your Car Have It?

The short answer is: Most likely, yes!

Almost all modern non-electric vehicles are equipped with OBD2, and the majority operate on the CAN bus protocol. For older vehicles, it’s important to note that even if a 16-pin OBD2 connector is present, it might not actually support OBD2. A reliable way to check for OBD2 compliance is to consider where and when your car was originally purchased as new:

Checking OBD2 Compatibility: A visual guide to determine if your car is OBD2 compliant based on region and year of manufacture.

A Brief 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 in all new vehicles starting from 1991 for emissions monitoring purposes.

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

From its Californian inception, the OBD2 standard was progressively implemented:

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 (known as EOBD – European On-Board Diagnostics).
2005: OBD2 became mandatory in the US for medium-duty vehicles.
2008: US regulations required vehicles to utilize ISO 15765-4 (CAN) as the foundation for OBD2.
2010: OBD2 standardization was completed in the US with its requirement for heavy-duty vehicles.

OBD2 History: A visual representation of the evolution of OBD2 in relation to emission control and exhaust standards, including EOBD2 and EOBDII.

OBD2 History Timeline: A concise timeline providing an overview of the historical milestones in the development and implementation of On-Board Diagnostics.

OBD2 Future: Illustrating the future trends of OBD2 towards OBD3, including remote diagnostics, emissions testing, cloud integration, and IoT applications.

The Future of OBD2: Trends and Innovations

OBD2 is set to remain a crucial technology, but its form and function are evolving.

Here are some significant trends shaping the future of OBD2:

Initially, legislated OBD2 was primarily designed for emissions control and testing. Interestingly, this means that electric vehicles (EVs) are not obligated to support OBD2 in any form. This is reflected in the fact that most modern EVs do not support standard OBD2 requests. Instead, they typically use OEM-specific UDS communication protocols. This often makes it challenging to access data from EVs, except when decoding rules have been reverse-engineered. For examples, see our case studies on electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Today, OBD2 implementations vary widely and have limitations, particularly in data richness and lower-layer protocols. To address these issues, modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. Both aim to enhance OBD communication by utilizing the UDS protocol as a foundation. For a deeper understanding of these protocols, refer to our introduction to UDS.

In our increasingly connected world, traditional OBD2 testing methods can appear outdated. Manual emission control checks are not only time-consuming but also costly.

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

OBD3 concept involves adding a small radio transponder (similar to those used for bridge tolls) to all cars. This would allow the car’s vehicle identification number (VIN) and DTCs to be transmitted wirelessly via WiFi to a central server for automated checks.

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

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

The OBD2 protocol was originally intended for stationary emission controls.

However, today OBD2 is extensively used by third parties to generate real-time vehicle data via OBD2 dongles, CAN loggers and more. Interestingly, the German car industry is seeking to change this landscape:

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

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal suggests “disabling” OBD2 functionality during driving and instead centralizing data collection on manufacturer servers. This would effectively place vehicle manufacturers in control of the burgeoning field of ‘automotive big data’.

The rationale often cited is security, aiming to mitigate the risk of car hacking. However, many perceive this as a commercially motivated move. Whether this trend gains traction remains to be seen, but it has the potential to significantly disrupt the market for third-party OBD2 services.

OBD2 Future in Electric Vehicles: Depicting the trend where electric vehicles are increasingly restricting access to data via the OBD2 connector.

Enhance Your CAN Bus Expertise

Want to become a CAN bus expert?

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

Download now

OBD2 Standards: A Deep Dive

On-board diagnostics, OBD2, functions as a higher-layer protocol, similar to a language, while CAN acts as the communication method, analogous to a phone line. This places OBD2 in the same category as other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

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

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

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

OBD2 vs CAN Bus: Illustrating the OBD2 and CAN Bus standards within the 7-Layer OSI Model, highlighting ISO 15765 and ISO 11898.

OBD Connector Pinout: Detailed pinout diagram of a Type A OBD2 connector socket (female), also known as 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 to note:

The connector is usually located near the steering wheel, but its exact location can vary and may be hidden.
Pin 16 is for battery power supply (often active 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 typically connected.

OBD2 Connector Types: A vs. B

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

As shown in the illustration, both types share similar OBD2 pinouts but differ in power supply outputs (12V for Type A and 24V for Type B). Baud rates often differ as well, with cars typically using 500K, while heavy-duty vehicles often use 250K (though 500K support is increasing).

To visually distinguish between the two OBD2 socket types, note that the Type B OBD2 connector has a distinctive interrupted groove in the middle. 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: Comparison of Type A and Type B OBD2 connectors as per SAE J1962 standard, highlighting differences for cars, vans, and trucks.

OBD2 vs CAN bus: A comparative overview of OBD2 and CAN bus protocols, emphasizing ISO15765 standards.

OBD2 and CAN Bus: ISO 15765-4

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

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies a set of constraints applied to the CAN standard (ISO 11898).

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

CAN bus bit-rate must be either 250K or 500K.
CAN IDs can be 11-bit or 29-bit.
Specific CAN IDs are designated for OBD requests and responses.
Diagnostic CAN frame data length is fixed at 8 bytes.
The OBD2 adapter cable must not exceed 5 meters in length.

OBD2 CAN Identifiers: 11-bit and 29-bit

All OBD2 communication is based on request/response message exchanges.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, which is used to query all OBD2-compatible ECUs to check if they have data to report for the requested parameter (as per ISO 15765-4). In contrast, CAN IDs 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests directed to specific ECUs (though less commonly used).

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

In certain vehicles, especially vans and light/medium/heavy-duty vehicles, OBD2 communication may utilize extended 29-bit CAN identifiers instead of 11-bit IDs.

Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

When the vehicle responds, you’ll see responses with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is also sometimes presented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated as ‘Reserved for ISO 15765-2’ in the J1939-71 standard.

OBD2 Protocol: Illustrating the request and response frames in OBD2 protocol for parameter data communication.

OBD2 vs Proprietary CAN bus: Comparing OBD2 with OEM-specific proprietary CAN bus systems in vehicles.

OBD2 vs. Proprietary CAN Protocols: Key Differences

It’s crucial to understand that your vehicle’s electronic control units (ECUs) do not depend on OBD2 for their primary functions. Instead, each Original Equipment Manufacturer (OEM) develops and implements its own proprietary CAN protocols for these purposes. These proprietary CAN protocols are often unique to the vehicle brand, model, and year. Typically, this OEM-specific data is inaccessible unless you can reverse engineer it.

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

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

Bit-rate and ID Validation in OBD2

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. In modern vehicles, the most common configuration is 500K with 11-bit IDs, but external diagnostic 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 transmitting data at an incorrect bit-rate will cause 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), as opposed 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, a diagnostic tool can send additional request messages, specifically UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS must 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-EV cars today, whereas WWH-OBD is mainly found in EU trucks and buses.

OBD2 Validation Flowchart: A flowchart illustrating the process of OBD2 bit-rate and CAN ID validation as per ISO 15765-4.

OBD2 Protocols Overview: A visual representation of the five lower-layer OBD2 protocols including CAN (ISO 15765), KWP 2000, SAE J1850, and ISO 9141.

Five Lower-Layer OBD2 Protocols

While CAN is now the dominant lower-layer protocol for OBD2 in most vehicles as per ISO 15765, understanding the other four protocols is useful, particularly when working with older vehicles (pre-2008). The pinouts can also help identify the protocol used in your vehicle.

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

Transporting OBD2 Messages via ISO-TP: ISO 15765-2

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

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

ISO-TP Frame Types: An illustration of ISO 15765-2 ISO-TP frame types used in OBD2 communication, detailing Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

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

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

OBD2 Message Structure: A breakdown of the OBD2 message structure, explaining Mode, Parameter ID (PID), and Data Bytes within an OBD-II message.

Example: OBD2 Request and Response Cycle

Let’s consider an example of a request and response for the ‘Vehicle Speed’ parameter to illustrate how OBD2 messages work.

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

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

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

OBD2 Request and Response: Example of an OBD2 request with ID 7DF and response with ID 7e8 for the vehicle speed parameter.

OBD2 PID Example: Detailed example of OBD2 PID 0D, representing vehicle speed and its data interpretation.

OBD2 Services and Modes: Overview of OBD2 services and modes including current data, freeze frame, and clearing DTCs.

The 10 OBD2 Services (Modes)

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

Vehicles are not required to support all 10 OBD2 modes, and they may also implement modes beyond these 10 standardized ones (known as OEM-specific OBD2 modes).

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

OBD2 Parameter IDs (PIDs) Explained

Each OBD2 mode contains Parameter IDs (PIDs).

For instance, mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on parameters like speed, RPM, and fuel level. However, a vehicle is not obligated to support all OBD2 PIDs within a given mode. In practice, most vehicles support only a subset of these PIDs.

One PID, in particular, is of special significance.

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. In response to this PID, the vehicle’s ECU communicates its support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental tool for ‘OBD2 compatibility testing’. Furthermore, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.

OBD2 Protocol Frames: Detailing OBD2 protocol request and response frames, emphasizing PID parameters.

OBD2 PID Overview Tool: Interface of an OBD2 PID overview tool, specifically for service 01, aiding in PID selection and understanding.

Practical Tip: Using the OBD2 PID Overview Tool

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

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

OBD2 PID overview tool

Logging and Decoding OBD2 Data: A Practical Guide

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 logging.

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

OBD2 Data Logger Setup: Illustrating the setup for OBD2 PID data logging with request ID 7df and response ID 7e8.

Verifying Bit Rate: Example of sending a CAN frame at 500K to validate successful transmission.

Supported PIDs Test: Reviewing responses to ‘Supported PIDs’ test in asammdf software.

Step #1: Bit-rate, IDs & Supported PIDs Validation

As discussed, ISO 15765-4 outlines how to identify the bit-rate and IDs used by a specific vehicle. You can perform these tests using the CANedge as described below (refer to the CANedge Intro for detailed instructions):

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

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

Most non-EV vehicles manufactured from 2008 onwards 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 polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, there are often numerous responses to this PID. For subsequent ‘Supported PIDs’ requests, the number of responding ECUs gradually decreases. Notice that the ECM ECU (0x7E8) supports all PIDs supported by other ECUs in this example. This suggests that busload can be reduced by specifically requesting responses from only this ECU using the ‘Physical Addressing’ CAN ID 0x7E0 for future communication.

Step #2: Configuring OBD2 PID Requests

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

Consider these points when configuring your requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses per request.
Spacing: Add a delay of 300-500 ms between each OBD2 request to prevent overwhelming the ECUs.
Battery Drain: Use triggers to stop transmissions when the vehicle is inactive to prevent unnecessary battery drain.
Filters: Implement filters to record only OBD2 responses, especially if your vehicle also outputs OEM-specific CAN data.

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

CANedge OBD2 Request List: Example of a CANedge OBD2 PID request transmit list configuration.

OBD2 Data Visualization: OBD2 data decoded and visually plotted in asammdf using a CAN bus DBC file for interpretation.

Step #3: DBC Decoding of Raw OBD2 Data

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

The necessary decoding information is available in ISO 15031-5/SAE J1979 and various online resources like Wikipedia. For convenience, we offer a free OBD2 DBC file that simplifies DBC decoding of raw OBD2 data in most CAN bus software tools.

Decoding OBD2 data is slightly more complex than standard CAN signals because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is not sufficient to uniquely identify the signals within the payload.

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

CANedge: Your OBD2 Data Logger Solution

The CANedge provides an easy way to record OBD2 data onto an 8-32 GB SD card. Simply connect it to your vehicle to start logging and decode the data using free software/APIs and our OBD2 DBC.

OBD2 logger intro CANedge

OBD2 Multi-Frame Examples: ISO-TP in Action

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

Multi-frame OBD2 communication requires flow control frames (see our UDS intro). 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.

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

Example 1: Retrieving OBD2 Vehicle Identification Number (VIN)

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

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, representing the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for further details). The subsequent 17 bytes constitute the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction.

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

External 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 (excluding unsupported ones), potentially using multiple frames as per ISO-TP.

This efficient feature allows for collecting OBD2 data at a higher frequency. However, it also means that signal encoding is specific to your request method, making the use of generic OBD2 DBC files challenging for these scenarios. We generally advise against using this method. Below is an example trace of what this might look like:

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

Decoding this response using DBC files is complex in practice, and therefore, we do not recommend this approach for practical data logging unless you’re using a tool with built-in support for it. Effectively, you’re dealing with extended multiplexing, but with multiple instances throughout the payload. Your DBC file would need to account for the specific payload position of each PID, making it difficult to generalize across vehicles that may have varying supported PIDs. Furthermore, managing this becomes very challenging, if not impossible, via pure DBC manipulations if you send several such multi-PID requests, as you’ll lack a method to uniquely identify these messages from each other.

A workaround could involve a custom script and recording the transmit messages from your testing tool. The script could then interpret the response message in conjunction with the request message. However, such approaches are generally difficult to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval

You can use OBD2 to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes’. No PID is included in this request. The targeted ECU(s) will respond with the number of DTCs they have stored (potentially 0 if none 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 typically divided into two parts, as per ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’, and the remaining 14 bits define 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 with 6 stored DTCs.

OBD2 DTC Decoding: Example of OBD2 DTC (Diagnostic Trouble Code) decoding and DBC interpretation.

OBD2 Data Logging Use Cases: Real-World Applications

OBD2 data from cars and light trucks has diverse applications:

Car Data Logging Applications

OBD2 data logging in cars can be used for various purposes, such as reducing fuel consumption, improving driving habits, testing prototype parts, and insurance telematics.

obd2 logger

Real-Time Car Diagnostics

OBD2 interfaces enable real-time streaming of human-readable OBD2 data, which is invaluable for diagnosing vehicle issues.

obd2 streaming

Predictive Maintenance

Cars and light trucks equipped with IoT OBD2 loggers can be monitored in the cloud to predict and prevent potential breakdowns through predictive maintenance.

predictive maintenance

Vehicle Black Box Logger

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

can bus blackbox

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

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

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy now Contact us

Recommended for You

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[