OBD2 Pinout: Your Comprehensive Guide to Understanding the 16-Pin Connector

Demystifying the OBD2 Connector Pinout for Automotive Diagnostics and Data Access

Are you diving into the world of vehicle diagnostics or data logging and need to understand the OBD2 connector pinout? You’ve come to the right place. This guide provides a detailed yet practical introduction to the On-Board Diagnostics (OBD2) system, focusing specifically on the OBD2 pinout, its functions, and its critical role in accessing vehicle data.

Whether you’re a seasoned mechanic, a car enthusiast, or a developer working on automotive applications, grasping the OBD2 pinout is essential. This article will break down the 16-pin OBD2 connector, explain the function of each pin, and clarify how it relates to communication protocols like CAN bus.

This is your go-to resource for understanding the OBD2 pinout, empowering you to effectively use OBD2 scanners, data loggers, and other tools.

You can also watch our OBD2 intro video or get the PDF guide for offline access.

Understanding the Basics of OBD2 and its Connector

OBD2, or On-Board Diagnostics II, is a standardized system in vehicles that monitors and reports on various aspects of the vehicle’s performance and health. At the heart of this system is the OBD2 connector, a 16-pin interface that provides access to this wealth of diagnostic information. The OBD2 pinout is the specific arrangement and function of each of these 16 pins.

You’re likely already familiar with OBD2 in some way. Have you ever seen the check engine light illuminate on your dashboard?

This light is a signal from your car’s OBD2 system indicating a detected issue. When you take your vehicle to a repair shop, a mechanic uses an OBD2 scanner to diagnose the problem.

This process involves connecting the OBD2 scanner to the 16-pin OBD2 connector, typically located under the dashboard near the steering column. The scanner sends requests through specific pins in the OBD2 pinout, and the car responds with data, including speed, engine temperature, fuel level, and Diagnostic Trouble Codes (DTCs). Understanding the OBD2 pinout enables efficient and accurate troubleshooting.

Understanding the OBD2 system and its malfunction indicator light (MIL) for vehicle diagnostics.

OBD2 Compatibility: Does Your Car Have It?

The question of OBD2 compatibility is usually straightforward for modern vehicles.

The short answer: Almost certainly, yes!

Nearly all non-electric vehicles manufactured in recent decades support OBD2, and most of these utilize the CAN bus communication protocol. However, it’s important to note that the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 compliance, especially in older vehicles. Some older cars may have the physical connector but not fully implement the OBD2 protocol. To confirm OBD2 compliance, consider the vehicle’s origin and year of manufacture:

Timeline of OBD2 implementation in vehicles across different regions.

A Brief History of OBD2 and the Standardized Connector

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

The OBD2 standard itself was developed and recommended by the Society of Automotive Engineers (SAE), leading to the standardization of DTCs and, crucially, the OBD2 connector pinout across different vehicle manufacturers through SAE J1962. This standardization of the OBD2 pinout was a key step in making vehicle diagnostics more accessible and universal.

The OBD2 standard was progressively implemented worldwide:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: Required in the EU for gasoline cars.
2003: Required in the EU for diesel cars as well (EOBD).
2005: OBD2 was mandated in the US for medium-duty vehicles.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 was finally required in US heavy-duty vehicles.

Visual representation of OBD2 history and its relation to emission control.

Timeline illustrating the evolution of OBD2 standards and implementation.

Conceptual illustration of OBD3 and the future trends in vehicle diagnostics.

The Future of OBD2: Trends and Challenges

While OBD2 remains a vital part of vehicle diagnostics, its future is evolving.

Initially designed for emissions testing, legislated OBD2 is not explicitly required for electric vehicles. Consequently, many modern EVs do not support standard OBD2 requests, often opting for OEM-specific UDS communication. This shift can pose challenges for accessing data from EVs unless reverse engineering efforts uncover the decoding rules, as seen in case studies for brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

To address limitations in data richness and lower-layer protocols, modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These protocols aim to improve OBD communication by using the UDS protocol as a base. For more information on these protocols, refer to our introduction to UDS.

The increasing connectivity of modern cars is also influencing the future of OBD. Traditional manual emission checks are becoming less efficient. OBD3 proposes integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder to vehicles, enabling the transmission of the vehicle identification number (VIN) and DTCs via WiFi to a central server for automated checks. Devices like the CANedge2 WiFi CAN logger and CANedge3 3G/4G CAN logger already facilitate data transfer via WiFi/cellular.

While this offers convenience and cost savings, it raises privacy concerns.

Originally intended for stationary emission controls, OBD2 is now widely used by third parties for real-time data generation via OBD2 dongles, CAN loggers etc. However, the German car industry is considering restricting this access, aiming to centralize data collection and potentially limit third-party access to vehicle data obtained through the OBD2 port.

This proposal, driven by security concerns (like mitigating car hacking risks), is viewed by some as a commercial strategy to control automotive big data. Whether this trend gains traction remains to be seen, but it could significantly impact the market for third-party OBD2 services.

Illustration of electric vehicles and potential limitations in OBD2 data access.

Get Our ‘Ultimate CAN Guide’

Want to become a CAN bus expert and understand how it relates to OBD2?

Download our comprehensive 160+ page PDF guide, featuring 12 ‘simple intros’ to CAN bus and related technologies:

Download now

OBD2 Standards and the Connector Pinout

On-board diagnostics, OBD2, is a higher-layer protocol – a language for vehicle communication. CAN (Controller Area Network) bus is the communication method – the physical medium. OBD2 is comparable to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

OBD2 standards define several aspects, most importantly, the OBD2 connector pinout, lower-layer communication protocols, and OBD2 Parameter IDs (PIDs). Understanding the OBD2 pinout is crucial for physical interfacing and data access.

These standards can be visualized within a 7-layer OSI model. Notably, both SAE (Society of Automotive Engineers) and ISO (International Organization for Standardization) standards cover multiple layers, reflecting OBD standards defined in the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, for example, SAE J1979 vs. ISO 15031-5 and SAE J1962 vs. ISO 15031-3.

OSI model illustrating the relationship between OBD2 and CAN bus standards.

Detailed diagram of the OBD2 connector pinout, Type A.

The OBD2 Connector Pinout in Detail [SAE J1962 / ISO 15031-3]

The 16-pin OBD2 connector, standardized under SAE J1962 and ISO 15031-3, provides a standardized physical interface for accessing vehicle data. The OBD2 pinout diagram above illustrates a typical Type A connector, also known as a Data Link Connector (DLC).

Key points regarding the OBD2 pinout:

The connector is usually located near the steering wheel, but its exact location can be hidden or vary by vehicle model.
Pin 16 of the OBD2 pinout always provides battery voltage, even when the ignition is off, supplying power to OBD2 devices.
The functions assigned to other pins in the OBD2 pinout depend on the communication protocols used by the vehicle.
CAN bus, the most prevalent lower-layer protocol, typically uses Pin 6 (CAN-High) and Pin 14 (CAN-Low) in the OBD2 pinout.

OBD2 Connector Types: Type A vs. Type B Pinout

You may encounter both Type A and Type B OBD2 connectors. Type A is standard in most cars and light vehicles, while Type B is more common in medium and heavy-duty vehicles. The primary difference lies in their OBD2 pinout configuration related to power supply.

While both types share a similar OBD2 pinout for data communication, they differ in power output: Type A typically provides 12V, whereas Type B supplies 24V. Baud rates can also differ, with cars often using 500K and heavy-duty vehicles commonly using 250K (though 500K support is increasing).

Visually distinguishing them, the Type B OBD2 pinout features an interrupted groove in the center of the connector. This physical difference means a Type B OBD2 adapter cable is generally compatible with both Type A and Type B sockets, but a Type A adapter will not fit into a Type B socket.

Comparison of OBD2 Connector Type A and Type B, highlighting pinout and power differences.

Diagram illustrating the relationship between OBD2, CAN bus, and ISO 15765 standards.

OBD2 and CAN Bus Communication [ISO 15765-4]

Since 2008, CAN bus has been the mandated lower-layer protocol for OBD2 in all US vehicles, as per ISO 15765. This standard significantly impacts the OBD2 pinout functionality of pins 6 and 14.

ISO 15765-4 (Diagnostics over CAN or DoCAN) specifies how CAN bus is used for OBD2, focusing on the physical, data link, and network layers. It dictates specific parameters for CAN communication within the OBD2 pinout context:

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

OBD2 CAN Identifiers: 11-bit and 29-bit Addressing

OBD2 communication over CAN bus relies on request and response messages. The OBD2 pinout, particularly pins 6 and 14, facilitates this communication using specific CAN identifiers.

In most cars, 11-bit CAN IDs are used for OBD2. ‘Functional Addressing’ uses CAN ID 0x7DF, which broadcasts a request to all OBD2-compliant ECUs, asking if they have data for the requested parameter (defined in ISO 15765-4). ‘Physical Addressing’ requests, less common, use CAN IDs 0x7E0-0x7E7 to target specific ECUs.

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

Some vehicles, particularly vans and medium/heavy-duty vehicles, may utilize extended 29-bit CAN identifiers for OBD2 communication. This alternative addressing scheme also affects the interpretation of data transmitted via the OBD2 pinout.

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

Responses in 29-bit CAN typically use IDs from 0x18DAF100 to 0x18DAF1FF (often 18DAF110 and 18DAF11E). These response IDs can also be represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is reserved for ISO 15765-2 in the J1939-71 standard.

Diagram illustrating OBD2 request and response frames and PID data parameters.

Comparison of OBD2 and proprietary CAN bus protocols in vehicles.

OBD2 vs. Proprietary CAN Protocols: Understanding the Difference

It’s important to understand that vehicle ECUs rely on OEM-specific proprietary CAN protocols for their internal operations, not OBD2. These proprietary protocols are unique to each vehicle manufacturer, model, and year. Interpreting this proprietary data is generally not possible without OEM documentation or reverse engineering efforts. The OBD2 pinout, while providing a physical access point, primarily exposes OBD2 data, not necessarily the full scope of proprietary vehicle network data.

Connecting a CAN bus data logger to the OBD2 connector might capture OEM-specific CAN data, often broadcast at high rates (1000-2000 frames/second). However, many newer vehicles employ a ‘gateway’ that restricts OBD2 connector access to OBD2 communication only, blocking access to the underlying proprietary CAN data. Therefore, while the OBD2 pinout is physically connected to the vehicle’s CAN bus network, the data accessible through it is often limited to OBD2-standardized information.

Think of OBD2 as an ‘additional’ higher-layer protocol that operates alongside the OEM-specific protocol. The OBD2 pinout serves as the access point for this standardized diagnostic layer.

Bit-rate and ID Validation for OBD2 Communication

OBD2 over CAN can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern cars commonly use 500K and 11-bit IDs. Diagnostic tools must systematically determine the correct combination to establish communication via the OBD2 pinout.

ISO 15765-4 recommends an initialization sequence to identify the correct bit-rate and CAN ID configuration. This method relies on the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request and detects CAN error frames caused by incorrect bit-rate settings.

Newer versions of ISO 15765-4 consider vehicles that may support OBD communication via OBDonUDS (OBD on Unified Diagnostic Services) instead of OBDonEDS (OBD on Emission Diagnostic Service). This article primarily focuses on OBD2/OBDonEDS, which is prevalent in most non-EV cars today, while WWH-OBD/OBDonUDS is mainly used in EU trucks and buses.

To test for OBDonEDS versus OBDonUDS, tools may send 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. This protocol detection is crucial for ensuring correct communication through the OBD2 pinout.

Flowchart illustrating the OBD2 bit-rate and CAN ID validation process as per ISO 15765-4.

Diagram representing the five lower-layer OBD2 protocols.

Five Lower-Layer OBD2 Protocols and Pinout Considerations

While CAN (ISO 15765) is dominant today, older vehicles (pre-2008) may use one of four other lower-layer protocols for OBD2. Understanding these and their potential OBD2 pinout implications is helpful for working with older vehicles. The OBD2 pinout itself is standardized, but the communication on certain pins might differ depending on the protocol.

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now the most common protocol. Pins 6 & 14 are key for CAN communication in the OBD2 pinout.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ cars, especially in Asia.
ISO 9141-2: Used in EU, Chrysler & Asian cars around 2000-2004.
SAE J1850 (VPW – Variable Pulse Width Modulation): Primarily used in older GM vehicles.
SAE J1850 (PWM – Pulse Width Modulation): Primarily used in older Ford vehicles.

ISO-TP for OBD2 Message Transport [ISO 15765-2]

OBD2 data is transmitted over CAN bus using ISO-TP (ISO 15765-2), a transport protocol enabling payloads larger than 8 bytes. This 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, see our introduction to UDS. ISO-TP operates over the CAN physical layer accessed through the OBD2 pinout.

For smaller OBD2 data payloads that fit within a single CAN frame, ISO 15765-2 specifies ‘Single Frame’ (SF) usage. Here, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2 communication.

Illustration of ISO-TP frame types used in OBD2 communication.

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

To better understand OBD2 communication over CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. An OBD2 message generally 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. All of this data is transmitted and received via the OBD2 pinout.

Breakdown of the OBD2 message structure, showing Mode, PID, and data bytes.

Example: OBD2 Request and Response Sequence

Consider a request for ‘Vehicle Speed’ as an example. This demonstrates how data is exchanged through the OBD2 pinout.

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 a message via CAN ID 0x7E8 and a 3-byte payload. The vehicle speed value is in the 4th byte, 0x32 (50 in decimal).

Using OBD2 PID decoding rules for PID 0x0D, we determine that 0x32 corresponds to a physical value of 50 km/h.

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

Example of an OBD2 request and response sequence for vehicle speed.

Detailed example of OBD2 PID 0x0D (Vehicle Speed) request and response.

Overview of the 10 OBD2 service modes and their diagnostic functions.

The 10 Standard OBD2 Services (Modes)

There are 10 standardized OBD2 diagnostic services, often referred to as modes. Mode 0x01 provides current real-time data, while other modes are used for accessing and clearing Diagnostic Trouble Codes (DTCs) or retrieving freeze frame data. These services are accessed via specific commands transmitted through the OBD2 pinout.

Vehicles are not required to support all 10 OBD2 modes and may also implement OEM-specific modes beyond these standards.

In OBD2 messages, the mode is located 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., resulting in 0x41).

OBD2 Parameter IDs (PIDs) and Data Access

Each OBD2 mode contains Parameter IDs (PIDs). Mode 0x01, for example, includes approximately 200 standardized PIDs providing real-time data such as speed, RPM, and fuel level. However, vehicles are not obligated to support all PIDs within a mode, and in practice, most vehicles support only a subset of the available PIDs. Accessing these PIDs involves sending specific requests through the OBD2 pinout.

One PID stands out: Mode 0x01 PID 0x00. If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID, the ECU indicates whether it supports PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, and so on, up to 0xC0, can be used to determine support for the remaining mode 0x01 PIDs.

(Repeated image for context – Diagram illustrating OBD2 request and response frames and PID data parameters.)

Screenshot of the OBD2 PID overview tool, aiding in PID lookup and request construction.

Tip: Using an OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 detail the scaling information necessary to decode standard OBD2 PIDs into physical values (as explained in our CAN bus introduction).

For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is invaluable. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses, simplifying the process of accessing and interpreting data via the OBD2 pinout.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 Data

This section provides a hands-on example of logging OBD2 data using the CANedge CAN bus data logger. The CANedge’s configurable CAN frame transmission capability makes it suitable for OBD2 logging. Connecting the CANedge to your vehicle is straightforward with our OBD2-DB9 adapter cable, linking directly to the OBD2 pinout.

Diagram illustrating OBD2 data logging with a CANedge data logger.

Example of bit-rate validation test for OBD2 communication.
Screenshot from asammdf software showing OBD2 supported PIDs test responses.

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

As discussed, ISO 15765-4 outlines how to identify the correct bit-rate and IDs for a specific vehicle. You can use the CANedge to perform these tests (refer to the CANedge Intro for setup details):

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

We provide ready-to-use configurations to streamline these tests. Most post-2008 non-EV vehicles support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

The asammdf GUI screenshot illustrates typical responses to ‘Supported PIDs’ requests. Using the 0x7DF request ID (functional addressing) often results in multiple responses as all ECUs are polled. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are common. Subsequent ‘Supported PIDs’ requests typically yield fewer responses as fewer ECUs support those PIDs. Notably, the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs in the system. For efficiency, switching to ‘Physical Addressing’ CAN ID 0x7E0 for ECU-specific requests can reduce bus load.

Step #2: Configuring OBD2 PID Requests for Data Logging

Once you’ve identified the supported OBD2 PIDs, bit-rate, and CAN IDs for your vehicle, the next step is to configure your data logger to request the PIDs of interest.

Consider these points when configuring your OBD2 PID requests:

CAN IDs: Use ‘Physical Addressing’ request IDs (e.g., 0x7E0) to target specific ECUs and minimize redundant responses.
Request Spacing: Implement a 300-500 ms delay between OBD2 requests to prevent overwhelming ECUs and ensure reliable responses.
Battery Management: Utilize triggers to halt transmissions when the vehicle is inactive to prevent battery drain by ‘waking up’ ECUs unnecessarily.
Data Filtering: Apply filters to record only OBD2 responses, especially if your vehicle also broadcasts OEM-specific CAN data, to keep logs focused and manageable.

With these configurations in place, your data logger is set to efficiently record raw OBD2 data transmitted through the OBD2 pinout.

Example transmit list for CANedge OBD2 PID requests.

Visualization of decoded OBD2 data in asammdf using a DBC file.

Step #3: DBC Decoding of Raw OBD2 Data

To analyze and visualize the logged OBD2 data, you need to decode the raw data into ‘physical values’ (e.g., km/h, °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 more intricate than standard CAN signal decoding. Different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone isn’t sufficient to identify the signals within the payload.

The solution involves using both the CAN ID, OBD2 mode, and OBD2 PID to uniquely identify each signal. This technique, known as ‘extended multiplexing‘, is supported in formats like DBC files. Using a properly configured DBC file is essential for correctly interpreting data obtained through the OBD2 pinout.

CANedge: Your OBD2 Data Logger Solution

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

OBD2 logger intro
CANedge

OBD2 Multi-Frame Communication Examples [ISO-TP]

While many OBD2 interactions are single-frame, some, like VIN or DTC requests, require multi-frame communication using ISO-TP (ISO 15765-2). Multi-frame communication involves flow control frames (see our UDS introduction). Proper handling of multi-frame messages is essential when working with advanced OBD2 functionalities via the OBD2 pinout.

CANedge configuration examples often include transmitting a static flow control frame approximately 50 ms after the initial request frame to manage multi-frame responses. Analyzing multi-frame OBD2 responses requires CAN software/API tools with ISO-TP support, such as CANedge MF4 decoders.

Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN).

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

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and various automotive applications (see our UDS introduction for details). To retrieve the VIN using OBD2, mode 0x09 and PID 0x02 are used:

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

The vehicle responds with a First Frame containing PCI, 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 (refer to ISO 15031-5 / SAE J1979). The subsequent 17 bytes constitute the VIN, which can be converted from HEX to ASCII as discussed in our UDS introduction. This entire exchange happens through the OBD2 pinout.

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

OBD2 allows requesting up to 6 mode 0x01 PIDs in a single request frame. The ECU should respond with data for supported PIDs (omitting unsupported ones), potentially using multi-frame responses via ISO-TP if necessary. This capability can improve data collection efficiency when accessed through the OBD2 pinout.

While powerful for data acquisition speed, this method complicates signal encoding, making generic OBD2 DBC files less effective. We generally advise against this approach for typical use cases. 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. The PIDs in the example are ordered similarly to the request order, which is common but not strictly mandated by ISO 15031-5.

Decoding these responses using generic DBC files is challenging. We do not recommend this method for practical data logging unless you are using tools specifically designed to support it. This approach represents a form of extended multiplexing but with multiple instances within a single payload, making it difficult to generalize DBC files across vehicles with varying PID support. Managing multiple such multi-PID requests further complicates DBC file handling, making it hard to uniquely identify messages.

Custom scripts and recording request messages alongside responses can offer workarounds, allowing interpretation based on request-response pairings. However, these methods are difficult to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval

OBD2 mode 0x03 (‘Show stored Diagnostic Trouble Codes’) is used to request emissions-related DTCs. The request does not include a PID. Responding ECUs will report the number of stored DTCs (possibly zero if none are present), with each DTC occupying 2 data bytes. Multi-frame responses are required if more than 2 DTCs are stored. DTC retrieval is a key diagnostic function accessed via the OBD2 pinout.

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

The example below shows a response from an ECU with 6 stored DTCs.

Example of OBD2 DTC decoding and interpretation.

Real-World Applications of OBD2 Data Logging

OBD2 data from cars and light trucks has numerous practical applications:

Vehicle Data Logging

OBD2 data logging in cars is useful for fuel efficiency analysis, driving behavior improvement, prototype testing, and insurance telematics.

obd2 logger

Real-time Vehicle Diagnostics

OBD2 interfaces enable real-time streaming of human-readable diagnostic data for immediate issue identification and troubleshooting.

obd2 streaming

Predictive Maintenance

Cloud-connected IoT OBD2 loggers allow for remote vehicle monitoring to predict potential breakdowns and facilitate proactive maintenance.

predictive maintenance

Vehicle Black Box Recording

An OBD2 logger can function as a ‘black box’ for vehicles, recording data for accident analysis, dispute resolution, and in-depth diagnostics.

can bus blackbox

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

Explore our guides section for more introductions to CAN bus and related technologies, or download our ‘Ultimate Guide’ PDF for a comprehensive resource.

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy now
Contact us

Recommended Resources

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[