Does My Car Support OBD2? Understanding On-Board Diagnostics

Do you know if your car supports OBD2? If you’re a car owner, understanding OBD2 (On-Board Diagnostics version 2) is crucial for modern vehicle maintenance and diagnostics. This comprehensive guide will introduce you to the OBD2 protocol, its importance, and how it can Support Obd2 tools for better car care.

In this article, we’ll explore the OBD2 connector, OBD2 Parameter IDs (PIDs), and its connection to the CAN bus system. We aim to provide a practical understanding of OBD2, covering how to request and interpret OBD2 data, key use cases for data logging, and valuable tips for utilizing this powerful system.

Why is this becoming a leading OBD2 resource? Because we focus on providing clear, actionable information to help you understand and leverage support OBD2 capabilities in your vehicle.

You can also watch our OBD2 introductory video above – or download our comprehensive PDF guide on CAN bus.

Article Contents:

Author: Martin Falch (Updated January 2025)

Download as PDF

What Exactly is OBD2?

OBD2 is essentially your car’s internal health monitoring system. It’s a standardized protocol integrated into most modern vehicles that enables the extraction of diagnostic trouble codes (DTCs) and real-time vehicle data through the OBD2 connector.

You’ve likely already interacted with OBD2 without realizing it. Remember the check engine light, officially known as the malfunction indicator light, illuminating 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.

The mechanic connects the OBD2 scanner to the OBD2 16-pin connector, typically located under the dashboard near the steering wheel. This tool sends ‘OBD2 requests’ to the car’s computer, and the car responds with ‘OBD2 responses’. These responses can include vital information like speed, fuel levels, and Diagnostic Trouble Codes (DTCs), which are crucial for faster and more accurate troubleshooting.

Understanding OBD2: The malfunction indicator light (MIL), commonly known as the check engine light, signals potential issues accessible through OBD2 diagnostic tools.

Does My Vehicle Offer OBD2 Support?

The simple answer is: Almost certainly!

The vast majority of newer gasoline and diesel cars are OBD2 compliant, and most operate using the CAN bus communication protocol. However, with older vehicles, even if you find a 16-pin OBD2 connector, it doesn’t automatically mean it supports OBD2. Some may use the connector but not adhere to the OBD2 protocol. To confirm OBD2 compliance, consider the vehicle’s origin and year of purchase:

OBD2 Compliance Guide: This chart indicates general OBD2 adoption timelines based on region and vehicle type, helping determine if your car likely supports OBD2.

A Brief History of OBD2

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

The Society of Automotive Engineers (SAE) played a key role in standardizing OBD2, defining DTCs and the universal OBD connector (SAE J1962), ensuring compatibility across different vehicle manufacturers.

The OBD2 standard was implemented globally in phases:

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

Evolution of OBD2: This graphic illustrates the historical progression of OBD2 implementation, driven primarily by emission control standards.

OBD2 Timeline: A visual timeline summarizing key milestones in the development and mandatory adoption of OBD2 across different regions and vehicle types.

The Future of OBD: OBD3 and beyond envisions remote diagnostics and integration with cloud and IoT technologies for enhanced vehicle monitoring and emissions testing.

The Future Trajectory of OBD2

OBD2 is firmly established, but its evolution is ongoing. Let’s examine some key trends shaping its future:

Initially designed for emissions control and testing, regulatory OBD2 requirements don’t necessarily extend to electric vehicles. Consequently, most modern EVs do not natively support OBD2 in its traditional form. Instead, they often employ OEM-specific UDS communication protocols. This makes accessing data from EVs challenging unless decoding methods are reverse-engineered. However, progress is being made, as seen in case studies for electric vehicles like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Recognizing the limitations of current OBD2 implementations in terms of data richness and underlying protocols, advancements like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging. These aim to modernize OBD communication by utilizing the UDS protocol as a foundation. For a deeper dive, explore our introduction to UDS.

In our increasingly connected world, manual OBD2 testing for emissions seems inefficient. The proposed solution? OBD3 – integrating telematics into all vehicles.

OBD3 envisions equipping vehicles with a small radio transponder, similar to those used for toll collection. This would allow for wireless transmission of the car’s vehicle identification number (VIN) and DTCs to a central server for automated checks.

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

While offering cost savings and convenience, OBD3 raises political and privacy concerns due to potential surveillance implications.

Originally intended for stationary emissions testing, OBD2 is now widely used by third parties to access real-time vehicle data via OBD2 dongles, CAN loggers, and similar devices. However, the German automotive industry is considering restricting this access:

“OBD has been designed to service cars in repair shops. In no way has it been intended to allow third parties to build a form of data-driven economy on the access through this interface“

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal involves disabling OBD2 functionality during normal driving, centralizing data collection with manufacturers. This move aims to give manufacturers control over ‘automotive big data’.

Security concerns, such as reducing the risk of car hacking, are cited as justification, though many perceive this as a commercially motivated strategy (https://www.navixy.com/blog/obd-trackers-what-future-awaits/). The future impact of this trend on the OBD2 aftermarket and third-party services remains uncertain.

EV OBD2 Access: Electric vehicles often deviate from standard OBD2, potentially limiting data access and requiring alternative diagnostic approaches.

Enhance Your CAN Bus Expertise with Our Guide

Ready to become proficient in CAN bus technology?

Our ‘Ultimate CAN Guide’ compiles 12 easy-to-understand introductions into a comprehensive 160+ page PDF:

Download Now

Decoding OBD2 Standards

On-board diagnostics, specifically OBD2, is a higher-layer protocol – think of it as a language. CAN (Controller Area Network) bus is the communication method, analogous to a telephone line. OBD2 is similar in concept to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

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

These standards can be viewed through the lens of the 7-layer OSI model. The following sections highlight the most critical standards.

Notice in the OSI model overview that both SAE and ISO standards cover multiple layers. This reflects the standards defined for OBD in the US (SAE) and Europe (ISO). Many of these standards are technically very similar, such as SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3.

OBD2 and CAN Bus in OSI Model: This diagram maps OBD2 and CAN bus standards to the 7-layer OSI model, highlighting the layered communication architecture.

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector provides easy access to your vehicle’s data and is standardized under SAE J1962 / ISO 15031-3.

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

Key points about the OBD2 connector:

It’s usually located near the steering wheel but may be somewhat hidden under the dashboard.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout configuration varies depending on the communication protocol used.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are commonly connected.

OBD2 Connector Types: A vs. B

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

While both types have similar pinouts, they differ in power supply outputs (12V for Type A and 24V for Type B) and often in baud rates. Cars typically use 500K baud, whereas heavy-duty vehicles often use 250K (with newer systems also supporting 500K).

Type B connectors have a distinguishing interrupted groove in the middle, making them physically different. A Type B OBD2 adapter cable is usually compatible with both Type A and B sockets, but a Type A connector will not fit into a Type B socket.

OBD2 Connector Types: A comparison of Type A and Type B OBD2 connectors, highlighting differences in pin configurations, voltage, and common vehicle applications.

OBD2 Integration with CAN Bus: ISO 15765-4

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

ISO 15765-4, also known as Diagnostics over CAN (DoCAN), is a set of specifications 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 rates 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 be a maximum of 5 meters in length.

OBD2 CAN Identifiers: 11-bit and 29-bit

OBD2 communication relies on request and response message exchanges.

In most cars, 11-bit CAN IDs are used for OBD2. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs to check if they have data for the requested parameter (as defined in ISO 15765-4). CAN IDs ranging from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’ requests directed to specific ECUs, although this is less common.

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

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

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

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

OBD2 Request-Response Framework: Illustrates the fundamental request-response message flow in OBD2 communication, involving a diagnostic tool and vehicle ECUs.

OBD2 CAN ID Table: An overview of common CAN identifiers used in OBD2 communication, including functional and physical addressing IDs for requests and responses.

OBD2 vs. Proprietary CAN: This diagram contrasts OBD2 data with OEM-specific CAN bus data, highlighting that OBD2 is a standardized subset for diagnostics.

OBD2 vs. OEM Proprietary CAN Protocols

It’s important to understand that your vehicle’s Electronic Control Units (ECUs) operate using OEM-specific CAN protocols, independent of OBD2. Vehicle manufacturers develop proprietary CAN protocols tailored to their specific vehicle brands, models, and years. This OEM-specific CAN data is generally inaccessible to third parties unless it is reverse engineered.

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

In essence, OBD2 is an additional, higher-level protocol that operates alongside the OEM-specific protocol.

Bit-rate and ID Validation

OBD2 can utilize two bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern cars 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 specific mandatory OBD2 request (refer to the OBD2 PID section for details) and that incorrect bit rates will cause CAN error frames.

Newer versions of ISO 15765-4 consider that vehicles may support OBD2 communication via OBDonUDS instead of OBDonEDS. 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 protocols, a diagnostic tool can send additional UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS ECUs must 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.

OBD2 Bit-rate Validation Flowchart: A systematic process for validating the correct bit-rate and CAN ID settings for OBD2 communication, as per ISO 15765-4 guidelines.

Five OBD2 Protocols: An overview of the five primary lower-layer protocols used for OBD2 communication, including CAN (ISO 15765) and legacy protocols.

Five Lower-Layer OBD2 Protocols

While CAN (ISO 15765) is now the dominant lower-layer protocol for OBD2 in most vehicles, especially post-2008, older cars might use one of the other four protocols. The connector pinouts can sometimes indicate which protocol is in use:

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and the most common protocol today.
ISO 14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, particularly in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian vehicles from 2000-2004.
SAE J1850 (VPW): Primarily used in older General Motors (GM) vehicles.
SAE J1850 (PWM): Mainly used in older Ford vehicles.

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

All OBD2 data exchange over CAN bus uses a transport protocol called ISO-TP (ISO 15765-2). This protocol allows for transmitting data payloads larger than 8 bytes, which is necessary for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. 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 specifies the use of ‘Single Frame’ (SF) messages. Here, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-related communication.

ISO-TP Frame Types for OBD2: This visual breaks down the different types of frames used in ISO-TP (ISO 15765-2) for OBD2 communication, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

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

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

OBD2 Message Structure: A detailed breakdown of the structure within an OBD2 message frame, showing the arrangement of Mode, PID, and data bytes.

OBD2 Request/Response Example

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

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

By consulting the decoding rules for OBD2 PID 0x0D, we find that the physical value corresponds to 50 km/h.

Let’s now delve into OBD2 modes and PIDs in more detail.

OBD2 Request-Response Example (Vehicle Speed): Illustrates a specific OBD2 request for vehicle speed (PID 0x0D) and the corresponding response, showing CAN IDs and data payloads.

OBD2 PID 0x0D (Vehicle Speed): Explains the specifics of PID 0x0D, which is used to request and receive vehicle speed data in OBD2 systems.

OBD2 Service Modes: A summary of the 10 standardized OBD2 service modes (or modes), outlining their functions, from retrieving current data to managing DTCs.

The 10 OBD2 Services (Modes)

OBD2 defines 10 diagnostic services, also referred to as modes. Mode 0x01 is used to access real-time data, while others are used for retrieving and clearing diagnostic trouble codes (DTCs) or accessing freeze frame data.

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

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

OBD2 Parameter IDs (PIDs)

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

For example, mode 0x01 includes approximately 200 standardized PIDs providing real-time data on parameters like speed, RPM, and fuel level. However, a vehicle doesn’t have to support all OBD2 PIDs within a given mode. In practice, most vehicles only support a subset.

One PID stands out as particularly important.

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

OBD2 PID Request-Response: Reiterates the request-response mechanism in OBD2, emphasizing the role of PIDs in specifying the requested parameter data.

OBD2 PID Overview Tool: A screenshot of an OBD2 PID overview tool, likely showcasing its interface for browsing and selecting PIDs within service mode 0x01.

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 decoding the raw data into meaningful physical values (as explained in our CAN bus introduction).

If you need to quickly look up a mode 0x01 PID, 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

Logging and Decoding OBD2 Data: A Practical Guide

This section provides a practical walkthrough on how to log OBD2 data using the CANedge CAN bus data logger.

The CANedge allows you to configure custom CAN frames for transmission, enabling its use for OBD2 data logging.

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

OBD2 Data Logging Setup: Illustrates a typical OBD2 data logging setup, featuring a CANedge data logger connected to a vehicle’s OBD2 port, ready to capture PID data.

Reviewing responses to ‘Supported PIDs’ in asammdf.

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

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

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

We provide ready-to-use configurations to simplify these initial tests.

Most non-EV cars manufactured in 2008 or later 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 when using the 0x7DF request ID, which polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are typical. As you proceed with subsequent ‘Supported PIDs’ requests, fewer ECUs may respond. Notice that the ECM ECU (0x7E8) appears to support all PIDs supported by other ECUs in this example. This means you could potentially reduce bus load by directing subsequent requests specifically to the ECM 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 with the PIDs you want to log.

Consider these points when configuring PID requests:

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

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

CANedge OBD2 Transmit List Example: An example configuration showing a list of OBD2 PID requests set up for transmission by a CANedge data logger.

OBD2 Data Visualization in asammdf: A screenshot from asammdf software, showing DBC-decoded and visually plotted OBD2 data captured by a CANedge logger.

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 physical values (e.g., km/h or °C).

Decoding information is available in ISO 15031-5/SAE J1979 and 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 somewhat 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 identify the signals within the payload.

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

CANedge: Your OBD2 Data Logging Solution

The CANedge makes OBD2 data logging straightforward. It records data to an 8-32 GB SD card. Simply connect it to your vehicle and start logging. Decode the data using free software/APIs and our OBD2 DBC.

OBD2 logger intro CANedge

Multi-Frame OBD2 Examples: ISO-TP in Action

All OBD2 communication relies on the ISO-TP transport protocol (ISO 15765-2). While earlier examples focused on single-frame communication, this section illustrates multi-frame scenarios.

Multi-frame OBD2 communication involves flow control frames (see 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/API tools with ISO-TP support, such as the CANedge MF4 decoders.

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

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more (see our UDS introduction). To retrieve the VIN using OBD2 requests, 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 byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case (see ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes constitute the VIN, which can be converted from HEX to ASCII as described in our UDS introduction.

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

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

This feature allows for more efficient data collection at higher frequencies, but the signal encoding becomes specific to your request method, making generic OBD2 DBC files less useful. We generally advise against this method in practice. Below is an example trace:

The multi-frame response is similar to the VIN example, but the payload includes both the requested PIDs and their corresponding data. Note that the PIDs in the example are ordered as requested, which is common but not strictly mandated by ISO 15031-5.

Decoding these responses using generic DBC files is challenging. Therefore, we don’t recommend this approach for practical data logging unless you’re using a tool specifically designed for multi-PID requests. It involves complex extended multiplexing, where your DBC file would need to account for the specific payload position of each PID, making it difficult to generalize across vehicles with varying PID support. Handling multiple multi-PID requests further complicates DBC management.

Workarounds might involve custom scripts and recording request messages to interpret responses based on the request context. However, such approaches are generally difficult to scale.

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 target ECU(s) will respond with the number of stored DTCs (possibly 0 if none are stored), 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, 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 shown. 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: Explains how Diagnostic Trouble Codes (DTCs) are structured within OBD2 data, including category bits and the 4-digit hexadecimal code.

OBD2 DTC Request-Response Example: A CAN bus trace example showing the request and multi-frame response for Diagnostic Trouble Codes (DTCs) in OBD2.

OBD2 Data Logging: Real-World Use Cases

OBD2 data from cars and light trucks has numerous applications:

Car Data Logging

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

OBD2 logger

Real-time Vehicle Diagnostics

OBD2 interfaces enable real-time streaming of vehicle data in a human-readable format, valuable for diagnosing vehicle issues on the fly.

OBD2 streaming

Predictive Maintenance

IoT-enabled OBD2 loggers can monitor car and light truck data in the cloud to predict potential breakdowns and facilitate proactive maintenance.

Predictive maintenance

Vehicle Black Box Logging

An OBD2 logger can act as a ‘black box’ for vehicles or equipment, providing crucial data for dispute resolution or in-depth diagnostics.

CAN bus blackbox

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

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

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy now Contact us