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

Looking for a straightforward and practical guide to OBD2 connectors?

This guide provides a comprehensive introduction to the On-Board Diagnostic (OBD2) protocol, focusing on OBD2 connectors, OBD2 Parameter IDs (PIDs), and their connection to the CAN bus system.

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

Discover why this guide is considered the top OBD2 tutorial available.

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

Understanding OBD2 and OBD2 Connectors

OBD2 is essentially your vehicle’s integrated self-diagnostic system. It operates through a standardized protocol that enables the extraction of Diagnostic Trouble Codes (DTCs) and real-time data via the OBD2 connector.

You’ve likely already encountered OBD2 in your car ownership experience.

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

This light is your vehicle signaling that there’s a problem. When you take your car to a mechanic, they use an OBD2 scanner to diagnose the issue.

To perform this diagnosis, the mechanic connects the OBD2 reader to the OBD2 16 pin connector located near the steering wheel. This tool sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’. These responses can contain a wealth of information, such as 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), with a mechanic using a scan tool.

OBD2 Connector Compatibility: Is Your Car Equipped?

In short: Most likely, yes!

Nearly all modern non-electric vehicles are equipped with OBD2 systems, and most operate on the CAN bus network. For older vehicles, it’s important to note that even if a 16-pin OBD2 connector is present, it might not actually support the OBD2 protocol. A key factor in determining OBD2 compliance is the vehicle’s original point of sale and the year it was manufactured:

OBD2 Compliance Guide: A visual guide to check if your car has OBD2 based on region and manufacturing year, for US, EU and CAN.

The History of OBD2 and OBD2 Connectors

The origins 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 emissions monitoring.

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).
2005: OBD2 requirement expanded in the US to medium-duty vehicles.
2008: US vehicles were required to utilize ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 mandate finally included heavy-duty vehicles in the US.

OBD2 History: Timeline illustrating the evolution of OBD2 standards driven by emission control and the integration of CAN bus technology.

OBD2 History Timeline: A visual timeline providing an overview of the historical milestones in the development and implementation of on-board diagnostics.

OBD2 Future Trends: Depicting the future of OBD with OBD3, remote diagnostics, emissions testing, cloud integration, and IoT.

The Future of OBD2 and OBD2 Connectors

OBD2 is expected to remain a crucial part of vehicle diagnostics, but its future form is evolving.

Here are some significant trends to consider:

Originally designed for emissions control and testing, legislated OBD2 has a notable exception: electric vehicles. Electric vehicles aren’t mandated to support OBD2 in any form. This is evident as most modern EVs do not support standard OBD2 requests. Instead, they often use OEM-specific UDS communication protocols. This shift generally makes it challenging to decode data from electric vehicles unless decoding rules have been reverse-engineered. Examples of successful reverse engineering efforts can be found in our case studies for electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

OBD2’s current implementations have limitations, particularly in data richness and lower-layer protocols. To address these, advanced alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. Both aim to improve OBD communication by using the UDS protocol as a base. For a deeper dive into these protocols, refer to our introduction to UDS.

In today’s connected automotive landscape, traditional OBD2 testing methods can be inefficient. Manual emission control checks are time-consuming and costly.

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

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

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

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

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

OBD was intended for car servicing in repair shops, not for third parties to create a data-driven economy via 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 give manufacturers control over ‘automotive big data’ and is argued as a security measure (e.g., to reduce the risk of car hacking). However, many view this as a commercially motivated move. The long-term impact of this proposal on the OBD2 third-party service market remains to be seen.

OBD2 Future in EVs: Illustration showing electric vehicles potentially restricting data access through the OBD2 connector.

Enhance Your CAN Bus Knowledge

Interested in becoming a CAN bus expert?

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

Download now

CAN Bus Ultimate Guide: Cover image of the PDF guide, designed to help users become experts in CAN bus technology.

OBD2 Standards and OBD2 Connectors

On-board diagnostics, or OBD2, operates as a higher-layer protocol – akin to a language. CAN, on the other hand, is the communication method, comparable to a telephone line. This places OBD2 alongside other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

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

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

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

OBD2 vs CAN Bus: OSI Model diagram illustrating the layers of OBD2 and CAN Bus, highlighting ISO 15765 and ISO 11898 standards.

OBD Connector Pinout: Diagram of an OBD connector pinout, socket female Type A DLC (Data Link Connector).

The OBD2 Connector [SAE J1962]

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

The illustration shows a typical Type A OBD2 pin connector (often called the Data Link Connector, or DLC).

Key points about the OBD2 connector:

It’s usually located near the steering wheel but can sometimes be hidden.
Pin 16 provides battery power, often 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 commonly connected.

OBD2 Connector Types: Type A vs. Type B

You might encounter both Type A and Type B OBD2 connectors. Type A is generally used in cars, while Type B is more common in medium and heavy-duty vehicles.

As shown, 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, while heavy-duty vehicles often use 250K (though newer models may support 500K).

To visually distinguish them, Type B OBD2 connectors have an interrupted groove in the middle. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and Type 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, used in cars, vans, and trucks, showing 12V and 24V differences.

OBD2 vs CAN bus ISO15765: Diagram illustrating the relationship between OBD2 and CAN bus within the ISO15765 framework.

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 per 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).

Specifically, 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, 29-bit)

All OBD2 communication involves request and response message exchanges.

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

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

In some vehicles, particularly vans and light, medium, and 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.

Vehicle responses will use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is also sometimes shown in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which in the J1939-71 standard is marked as ‘Reserved for ISO 15765-2’.

OBD2 Protocol Communication: Diagram showing OBD2 protocol request and response frames, highlighting PID data parameters.

OBD2 CAN bus Identifiers: Table overview of OBD CAN bus identifiers including 7DF, 7E8, and 7E0, commonly used for OBD2 communication.

OBD2 vs Proprietary CAN bus data: Illustration contrasting OBD2 and OEM-specific proprietary CAN bus protocols and data.

OBD2 vs. Proprietary CAN Protocols

It’s crucial to understand that your vehicle’s electronic control units (ECUs) operate independently of OBD2. Original Equipment Manufacturers (OEMs) implement their own proprietary CAN protocols for vehicle functions. These protocols are often specific to the vehicle brand, model, and year. Typically, this OEM-specific CAN data is undecipherable without OEM documentation or reverse engineering efforts.

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

In essence, OBD2 can be considered an ‘additional’ higher-layer protocol that operates in parallel with the OEM-specific protocol.

Bit-rate and ID Validation

As mentioned, OBD2 can use one of two bit-rates (250K, 500K) and either 11-bit or 29-bit CAN IDs, resulting in four potential combinations. Modern cars most commonly use 500K with 11-bit IDs. However, external tools should systematically verify these settings.

ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination, as illustrated in the flowchart. 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-rate transmissions will cause CAN error frames.

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

To test for OBDonEDS versus OBDonUDS, a diagnostic tool may send additional UDS requests using 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, while WWH-OBD is mainly found in EU trucks and buses.

OBD2 Bit-rate and CAN ID Validation: Flowchart outlining the process of OBD2 bit-rate and CAN ID validation according to ISO 15765-4.

OBD2 Five Protocols: Diagram illustrating the five lower-layer protocols of OBD2 standards including CAN (ISO 15765), KWP2000, SAE J1850, and ISO9141.

Five Lower-Layer OBD2 Protocols

While CAN bus is now the dominant lower-layer protocol for OBD2 according to ISO 15765, especially in vehicles from 2008 onwards, older cars may use other protocols. It’s helpful to know the other four lower-layer protocols previously used for OBD2, and their pinout configurations, which can help identify the protocol used in older vehicles:

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and now the most common protocol.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, 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 used in older Ford vehicles.

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

All OBD2 data communication over CAN bus uses a transport protocol known as ISO-TP (ISO 15765-2). This protocol facilitates the transmission of data payloads exceeding 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 detailed information, see 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) format. Here, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-related communication.

ISO 15765-2 Frame Types: Diagram illustrating ISO-TP OBD2 frame types according to ISO 15765-2 standards.

The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]

To better understand OBD2 communication on 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 section is further divided into Mode, Parameter ID (PID), and data bytes.

OBD2 Message Structure: Breakdown of an OBD2 message structure, explaining raw mode, PID, ID, and data bytes.

Example: OBD2 Request and Response

Before detailing each part of the OBD2 message, let’s consider a practical example of requesting and receiving the ‘Vehicle Speed’ parameter.

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

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

In the next sections, we will delve into OBD2 modes and PIDs in more detail.

OBD2 Request and Response Example: Illustrating an OBD2 request with ID 7DF and a response with ID 7E8 for vehicle speed.

OBD2 PID Example: Vehicle Speed PID 0D, showing the structure and interpretation of the PID for vehicle speed.

OBD2 Services Modes: Diagram of OBD2’s 10 PID modes for diagnostic services, including current data, freeze frame, and clear DTC.

The 10 OBD2 Services (Modes)

OBD2 includes 10 diagnostic services, commonly 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) or show freeze frame data.

Vehicles are not required to support all 10 standardized OBD2 modes and may also support additional, OEM-specific modes.

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

OBD2 Parameter IDs (PIDs)

Each OBD2 mode contains Parameter IDs (PIDs).

For example, Mode 0x01 includes approximately 200 standardized PIDs that provide real-time data such as speed, RPM, and fuel level. However, vehicles are not required to support every PID within a mode, and most vehicles only support a subset of these PIDs.

One PID is particularly important:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. In response to this PID, the vehicle ECU reports which PIDs from 0x01-0x20 it supports. This makes PID 0x00 a fundamental tool for testing OBD2 compatibility. Additionally, PIDs 0x20, 0x40, and so on up to 0xC0, can be used to determine support for the remaining Mode 0x01 PIDs.

OBD2 Request and Response Frames: Diagram again illustrating OBD2 protocol request and response frames in relation to PID data parameters.

OBD2 PID Overview Tool: Screenshot of an OBD2 PID overview tool, specifically for service 01, used for examining and understanding PIDs.

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 contain scaling information for standard OBD2 PIDs, which allows you to convert raw data into physical values (as explained in our CAN bus introduction).

For quickly looking up 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

How to Log and Decode OBD2 Data

This section provides a practical guide on logging OBD2 data using the CANedge CAN bus data logger.

The CANedge allows configuration of custom CAN frames for transmission, making it suitable for OBD2 logging.

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

OBD2 Data Logger Setup: Illustration showing an OBD2 data logger requesting PID data with IDs 7df and 7e8.

Validating Bit Rate: Screenshot showing bit rate validation for OBD2, ensuring correct communication speed.

Supported PIDs Test Responses: Screenshot from asammdf, reviewing responses to ‘Supported PIDs’ tests.

#1: Test Bit-rate, IDs & Supported PIDs

As discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a specific vehicle. You can test this with the CANedge as follows (see the CANedge Introduction for detailed instructions):

Transmit 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 whether 11-bit or 29-bit IDs are used based on the response IDs.
Identify supported PIDs from the response data.

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

Most non-EV vehicles 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, multiple responses to a single OBD request are common. This is because using the 0x7DF request ID 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 observed, fewer ECUs respond to subsequent ‘Supported PIDs’ requests. Notably, the ECM ECU (0x7E8) supports all PIDs supported by other ECUs in this example, meaning bus load can be reduced by specifically requesting responses only from this ECU using ‘Physical Addressing’ CAN ID 0x7E0 for future communications.

#2: Configure OBD2 PID Requests

After identifying the OBD2 PIDs supported by your vehicle and the appropriate bit-rate and CAN IDs, you can configure your transmit list with the PIDs you want to monitor.

Consider these points when configuring:

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

Once these configurations are set, your device is ready to log raw OBD2 data.

CANedge OBD2 PID Requests: Example list of CANedge OBD2 PID requests configuration for data logging.

OBD2 Data Visualization: OBD2 data visualized as a plot in asammdf, decoded from a CAN bus DBC file.

#3: DBC Decode Raw OBD2 Data

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

Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, we provide a free OBD2 DBC file, simplifying DBC decoding of raw OBD2 data in most CAN bus software tools.

Decoding OBD2 data is 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 insufficient to identify the signals within the payload.

To solve this, you must use the CAN ID, OBD2 mode, and OBD2 PID together to identify the signal. This multiplexing method, known as ‘extended multiplexing’, can be implemented using DBC files.

CANedge: OBD2 Data Logger

The CANedge allows for straightforward recording of OBD2 data to an 8-32 GB SD card. Simply connect it to a vehicle to begin logging and decode the data using free software/APIs and our OBD2 DBC file.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples [ISO-TP]

All OBD2 data communication relies on the ISO-TP transport protocol (ISO 15765-2). While many examples are single-frame communications, multi-frame communication is also important. This section provides examples of multi-frame scenarios.

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

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

OBD2 Multi-Frame Request: Example of an OBD2 multi-frame request message, specifically for Vehicle Identification Number (VIN).

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval

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

VIN Retrieval Example: OBD2 multi-frame example for VIN retrieval, showing request and response message structure.

The tester tool sends a Single Frame request with PCI field (0x02), request service identifier (0x09), and PID (0x02).

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

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

External tools can request up to 6 Mode 0x01 OBD2 PIDs in a single request frame. The ECU responds with data for supported PIDs (excluding unsupported ones in the response), potentially across multiple frames as per ISO-TP.

This efficient feature allows for higher frequency data collection, but the signal encoding becomes specific to your request method. This can complicate the use of generic OBD2 DBC files. We generally advise against this method for most applications. Below is an example trace:

Multi-PID Request Example: Trace example of requesting multiple PIDs in one OBD2 request, showing ISO-TP multi-frame communication.

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 similarly to the request, which is common but not strictly mandated by ISO 15031-5.

Decoding this response via generic DBC files is challenging, making this approach less practical for general data logging unless specialized tools with built-in support are used. This scenario represents extended multiplexing, further complicated by multiple instances within the payload. A DBC file would need to account for the specific payload position of each PID, making it hard to generalize across vehicles with varying PID support. Handling multiple multi-PID requests via pure DBC manipulation becomes very complex.

A workaround could involve custom scripts, also recording transmit messages from your testing tool. The script could then interpret responses based on the corresponding request message. However, such methods are often 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 zero if none are stored), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than two DTCs are stored.

The 2-byte DTC value is typically structured as per ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’, and the remaining 14 bits form a 4-digit hexadecimal code, as 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 decoding and DBC interpretation for Diagnostic Trouble Codes.

OBD2 DTC Request Response: CAN bus trace frames example of OBD2 Diagnostic Trouble Codes request and response.

OBD2 Data Logging – Use Case Examples

OBD2 data from cars and light trucks is valuable for numerous applications:

Logging Data from Cars

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

OBD2 logger

Real-Time Car Diagnostics

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

OBD2 streaming

Predictive Maintenance

Cars and light trucks equipped with IoT OBD2 loggers connected to the cloud can be monitored for predictive maintenance, helping to prevent breakdowns.

Predictive maintenance

Vehicle Black Box Logger

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

CAN bus blackbox

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

For more introductory guides, check out our guides section or download our comprehensive ‘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

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN