OBD2 Connector: Your Comprehensive Guide to Vehicle Diagnostics

Demystifying the Obd2 Connector: A Practical Guide for Automotive Diagnostics

Understanding your vehicle’s health is becoming increasingly crucial, and the On-Board Diagnostics II (OBD2) system is at the heart of this process. This guide provides a detailed and practical introduction to the OBD2 connector, a critical interface for accessing your car’s self-diagnostic data. We will explore its function, types, pinouts, and its vital role in modern automotive repair and data acquisition.

Whether you’re a seasoned mechanic or a car owner wanting to understand your vehicle better, this guide will equip you with the knowledge to confidently navigate the world of OBD2 connectors.

You can also watch our OBD2 intro video above – or get the PDF

Understanding the OBD2 System and its Connector

OBD2 is essentially your car’s internal doctor, a standardized system designed for self-diagnostics and reporting. It’s a protocol that allows you to retrieve diagnostic trouble codes (DTCs) and real-time vehicle data through a specific port: the OBD2 connector.

You’ve likely encountered OBD2 in action without even realizing it. That check engine light, or malfunction indicator light (MIL), on your dashboard? That’s your car’s way of communicating an issue detected by the OBD2 system. When you take your car to a repair shop, the mechanic uses an OBD2 scanner to pinpoint the problem.

This process starts with connecting the OBD2 scanner to the 16-pin OBD2 connector, usually located within easy reach near the steering wheel. The scanner sends ‘OBD2 requests’ via the connector, and the car responds with ‘OBD2 responses’. These responses contain valuable information like speed, fuel level, and those all-important Diagnostic Trouble Codes (DTCs). This streamlined communication through the OBD2 connector makes troubleshooting vehicle problems faster and more efficient.

Understanding OBD2: On-Board Diagnostics and the Malfunction Indicator Light (MIL) are key components of vehicle self-diagnostic systems.

OBD2 Connector Compatibility: Does Your Car Have One?

The good news is, if you own a relatively recent non-electric vehicle, the answer is almost certainly yes!

OBD2 has become a standard feature in modern vehicles, especially those using CAN bus communication. However, for older cars, the presence of a 16-pin connector doesn’t automatically guarantee OBD2 compliance. Some older vehicles might have the physical connector but not fully support the OBD2 protocol. A helpful indicator is to check the vehicle’s year of manufacture and where it was originally sold:

Does My Car Have OBD2?
OBD2 Compliance Guide: Check this guide to determine if your car is OBD2 compliant based on its region and year of manufacture.

A Brief History of the OBD2 Connector and Protocol

The origins of OBD2 trace back to California, driven by the California Air Resources Board (CARB). In their pursuit of stricter emission controls, CARB mandated OBD systems in all new cars sold in California starting from 1991.

The Society of Automotive Engineers (SAE) played a crucial role in standardizing the protocol, leading to the OBD2 standard. This standardization included Diagnostic Trouble Codes (DTCs) and, importantly for our focus, the OBD connector, ensuring uniformity across different vehicle manufacturers (SAE J1962).

The adoption of OBD2 was a phased process:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: The European Union mandated OBD2 for gasoline cars.
2003: The EU extended the mandate to diesel cars (EOBD).
2005: OBD2 was required 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 became mandatory for heavy-duty vehicles in the US.

OBD2 Historical Timeline: From emission control origins to standardized data access via the OBD2 connector.

OBD2 Evolution: A timeline illustrating the key milestones in the development and implementation of On-Board Diagnostics.

The Future of OBD: Envisioning OBD3 with remote diagnostics, emissions testing, cloud connectivity, and IoT integration.

The Future Landscape of OBD2 and Vehicle Diagnostics

OBD2 is firmly established, but its future is evolving. Here are some key trends to consider:

Initially designed for emissions control, legislated OBD2 doesn’t inherently apply to electric vehicles. Consequently, most modern EVs do not support standard OBD2 requests. Instead, they often employ OEM-specific UDS communication, making data retrieval challenging without specialized reverse engineering efforts. However, progress is being made in understanding EV data – see case studies for electric cars including Tesla, Hyundai/Kia, Nissan and VW/Skoda EVs.

Limitations in OBD2’s data richness and underlying protocols have spurred the development of enhanced alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). These aim to improve OBD communication by utilizing the UDS protocol. For a deeper dive, explore our intro to UDS.

In our increasingly connected world, manual OBD2 testing for emissions feels outdated. The proposed solution? OBD3: Integrating telematics into vehicles.

OBD3 envisions adding a small radio transponder to vehicles, similar to those used for toll collection. This would enable the car’s vehicle identification number (VIN) and DTCs to be wirelessly transmitted to a central server for automated checks.

Many current devices, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger, already facilitate data transfer via WiFi or cellular networks. While convenient and cost-saving, OBD3 raises privacy concerns related to surveillance.

Originally intended for stationary emission checks, OBD2 is now widely used by third parties for real-time data acquisition via OBD2 dongles, CAN loggers. However, the German automotive industry is considering changes that could impact this:

“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 potentially disabling OBD2 functionality during driving, centralizing data collection with manufacturers. This would give manufacturers control over ‘automotive big data’ and is argued as a security measure to mitigate car hacking risks. However, many view this as a commercially motivated move that could disrupt the third-party OBD2 services market (https://www.navixy.com/blog/obd-trackers-what-future-awaits/). The future of OBD2 and third-party access remains uncertain.

OBD2 in Electric Vehicles: The trend of electric vehicles potentially limiting or blocking access to data via the OBD2 connector.

Enhance Your CAN Bus Expertise

Ready to become a CAN bus expert?

Our comprehensive ‘Ultimate CAN Guide’ compiles 12 ‘simple intros’ into a 160+ page PDF:

Download now

CAN Bus – The Ultimate Guide Tutorial PDF

OBD2 Standards and the Connector

On-board diagnostics OBD2 is a higher-layer protocol, like a language, built upon communication methods like CAN bus (the phone line). This places OBD2 alongside other CAN-based protocols like J1939, CANopen, and NMEA 2000.

OBD2 standards define specifications for the OBD2 connector, lower-layer protocols, OBD2 parameter IDs (PIDs), and more. These standards can be viewed within the 7-layer OSI model. Notably, both SAE and ISO standards cover multiple layers, reflecting US (SAE) and EU (ISO) OBD definitions. Many standards are technically similar, such as SAE J1979 vs. ISO 15031-5 and SAE J1962 vs. ISO 15031-3.

OBD2 and CAN Bus in the OSI Model: Illustrating the layered architecture with ISO and SAE standards for communication.

OBD2 Connector Pinout (Type A): Detailed pinout diagram of a standard Type A OBD2 female connector (Data Link Connector – DLC).

Delving into the OBD2 Connector [SAE J1962 / ISO 15031-3]

The 16-pin OBD2 connector, formally specified in SAE J1962 / ISO 15031-3, is your gateway to accessing vehicle data. The illustration above shows a typical Type A OBD2 connector, also known as a Data Link Connector (DLC).

Key features of the OBD2 connector:

Location: Typically located near the steering wheel, but its exact position can be hidden or vary depending on the vehicle.
Pin 16: Provides battery power, often even when the ignition is off, allowing for continuous monitoring in some cases.
Pinout Variability: The specific OBD2 pinout configuration depends on the communication protocol used by the vehicle.
CAN Bus Integration: CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are commonly connected in the OBD2 connector for data transmission.

OBD2 Connector Types: Type A vs. Type B

You might encounter two main types of OBD2 connectors: Type A and Type B. Type A is standard in most cars and light vehicles, while Type B is more common in medium and heavy-duty vehicles.

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

Visually, the Type B OBD2 connector has a key distinguishing feature: an interrupted groove in the center. This physical difference means a Type B OBD2 adapter cable is generally compatible with both Type A and Type B sockets, whereas a Type A adapter will not fit into a Type B socket. Understanding these connector types is crucial for selecting the correct OBD2 adapter and ensuring proper connection.

OBD2 Connector Types A and B: Illustrating the differences in pin configuration, voltage, and application between Type A (cars, vans) and Type B (trucks) OBD2 connectors.

OBD2 and CAN Bus Relationship: Visual representation of how OBD2 protocol operates over the CAN bus physical layer according to ISO 15765 standards.

OBD2 Communication and CAN Bus [ISO 15765-4]

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

ISO 15765-4, also known as Diagnostics over CAN (DoCAN), is a specific implementation of the CAN standard (ISO 11898) for diagnostics. It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers.

Key specifications of ISO 15765-4 for OBD2 communication via the connector:

CAN Bit-rate: Must be either 250K or 500K.
CAN IDs: Can be 11-bit or 29-bit.
Standardized CAN IDs: Specific CAN IDs are reserved for OBD requests and responses.
Data Frame Length: Diagnostic CAN frames must have a data length of 8 bytes.
Adapter Cable Length Limit: The OBD2 adapter cable should not exceed 5 meters.

OBD2 CAN Identifiers (11-bit, 29-bit)

OBD2 communication is based on a request-response model.

In most cars, 11-bit CAN IDs are used for OBD2. The ‘Functional Addressing’ ID, 0x7DF, is used to broadcast requests to all OBD2-compatible ECUs, asking if they have data for the requested parameter (defined in ISO 15765-4). ‘Physical Addressing’ requests, using CAN IDs 0x7E0-0x7E7, can target specific ECUs but are less common.

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

In some vehicles, particularly vans and medium to heavy-duty vehicles, OBD2 communication might utilize extended 29-bit CAN identifiers instead of 11-bit IDs.

The ‘Functional Addressing’ CAN ID in this case is 0x18DB33F1.

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

OBD2 Request and Response Frames: Illustrating the structure of OBD2 communication frames including Mode, PID, and data parameters.

OBD2 OBD CAN bus Identifiers 7DF 7E8 7E0

OBD2 vs. Proprietary CAN Bus: Comparing standardized OBD2 data access with OEM-specific, proprietary CAN bus data protocols.

OBD2 vs. Proprietary CAN Protocols: What You See Through the Connector

It’s important to understand that your vehicle’s internal electronic control units (ECUs) operate using proprietary CAN protocols defined by the manufacturer (OEM), not OBD2. These OEM-specific protocols are crucial for the core functionality of the vehicle and are often unique to the brand, model, and year. Without OEM documentation or reverse engineering, this data is typically inaccessible to external parties.

When you connect a CAN bus data logger to the OBD2 connector, you might observe OEM-specific CAN data, often broadcast at high rates (1000-2000 frames/second). However, many newer vehicles employ a ‘gateway’ system that restricts access to this raw CAN data through the OBD2 connector, only allowing standardized OBD2 communication.

Think of OBD2 as a separate, standardized ‘overlay’ protocol that runs alongside the OEM’s proprietary communication system. It’s specifically designed for diagnostics and emissions-related data access through the OBD2 connector.

Bit-rate and ID Validation for Reliable OBD2 Connector Communication

As mentioned, OBD2 can use 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 diagnostic tools should systematically verify this.

ISO 15765-4 outlines a systematic initialization sequence to determine the correct combination, illustrated in the flowchart below. This method relies on the fact that OBD2-compliant vehicles must respond to a mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit-rates will cause CAN error frames.

Newer ISO 15765-4 versions account for OBD communication via OBDonUDS (OBD on Unified Diagnostic Service) in addition to OBDonEDS (OBD on Emission Diagnostic Service). This article primarily focuses on OBD2/OBDonEDS (ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (ISO 14229, ISO 27145-3/SAE J1979-2).

To differentiate between OBDonEDS and OBDonUDS, diagnostic tools can send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should respond to this DID.

In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars, while WWH-OBD is primarily used in EU trucks and buses.

OBD2 Bit-rate and CAN ID Validation Flowchart: A systematic process for validating the correct bit-rate and CAN ID configuration for reliable OBD2 communication.

OBD2 Lower-Layer Protocols: Visual comparison of the five primary lower-layer protocols used for OBD2, including CAN (ISO 15765), KWP2000, ISO9141, and SAE J1850 (VPW/PWM).

Five Lower-Layer OBD2 Protocols: Beyond CAN

While CAN (ISO 15765) is the dominant lower-layer protocol for OBD2 today, especially in vehicles manufactured after 2008, older vehicles might use other protocols. Understanding these alternatives and their corresponding OBD2 connector pinouts can be helpful when working with older cars:

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

ISO-TP: Transporting OBD2 Messages Beyond 8 Bytes [ISO 15765-2]

All OBD2 data transmission over CAN bus relies on ISO-TP (ISO 15765-2), a transport protocol that enables sending data payloads larger than the 8-byte CAN frame limit. This is crucial for OBD2 operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often require more than 8 bytes. ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. For more details, refer to our intro to UDS.

However, much 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-specific communication.

ISO-TP Frame Types for OBD2: Diagram illustrating the different frame types defined in ISO 15765-2 for transporting OBD2 messages, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

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

To understand OBD2 communication on CAN bus, let’s examine the structure of a ‘Single Frame’ OBD2 CAN message. In simplified terms, it consists of a CAN identifier, a data length indicator (PCI field), and the data payload. The payload itself is further structured into Mode, parameter ID (PID), and data bytes.

OBD2 Message Structure: Breakdown of a raw OBD2 message frame, highlighting the Mode, Parameter ID (PID), and data bytes.

OBD2 Request/Response Example: Vehicle Speed

Consider this example of requesting and receiving vehicle speed data:

A diagnostic tool sends a request message to the car via the OBD2 connector with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds with CAN ID 0x7E8 and 3 payload bytes, including the speed value in the 4th byte, 0x32 (decimal 50).

By consulting OBD2 PID documentation for PID 0x0D, we find the decoding rule for vehicle speed. In this case, 0x32 translates to a physical value of 50 km/h.

Let’s now delve deeper into OBD2 modes and PIDs.

OBD2 Request and Response Example (Vehicle Speed): Illustrative trace of an OBD2 request (ID 0x7DF) for vehicle speed and the corresponding response (ID 0x7E8) containing the speed data.

OBD2 PID 0D (Vehicle Speed): Detailed explanation of OBD2 PID 0x0D, which is used to request and obtain vehicle speed data.

OBD2 Service Modes: Overview of the 10 standardized OBD2 service modes (modes 0x01 to 0x0A) and their diagnostic functions, including current data, freeze frame, and DTC clearing.

The 10 OBD2 Diagnostic Services (Modes)

OBD2 defines 10 diagnostic services, often called ‘modes’. Mode 0x01 provides access to current, real-time data, while other modes are used for retrieving and clearing diagnostic trouble codes (DTCs), accessing freeze frame data, and more.

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

In OBD2 messages, the mode is indicated in the second byte of the data payload. In a request, the mode is included directly (e.g., 0x01). In the response, 0x40 is added to the requested mode (e.g., 0x41 for a response to mode 0x01).

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the specific data being requested or provided.

For example, mode 0x01 contains approximately 200 standardized PIDs for real-time data such as speed, RPM, and fuel level. However, vehicles don’t necessarily support all PIDs within a given mode. In reality, most vehicles support only a subset of the available PIDs.

One PID holds special significance:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the vehicle ECU indicates its support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to determine support for subsequent PID ranges within mode 0x01.

OBD2 Request and Response Frames: Re-emphasizing the structure of OBD2 communication with Mode, PID, and data parameters.

OBD2 PID overview tool
OBD2 PID Overview Tool: Screenshot of an OBD2 PID overview tool, designed to help users explore and understand OBD2 Parameter IDs.

Practical Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 detail the scaling information needed to convert raw OBD2 data into physical values. Our free OBD2 PID overview tool simplifies this process. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

Hands-on: Logging and Decoding OBD2 Data

Let’s walk through a practical example of logging OBD2 data using the CANedge CAN bus data logger.

The CANedge allows you to configure custom CAN frames for transmission, making it ideal for OBD2 data logging. Connecting it to your vehicle is straightforward using our OBD2-DB9 adapter cable.

OBD2 Data Logger Setup: Diagram showing an OBD2 data logger connected to a vehicle’s OBD2 connector for requesting and receiving PID data.

OBD2 bit rate test
OBD2 Bit-rate Validation Test: Screenshot illustrating a successful bit-rate validation test for OBD2 communication.

OBD2 Supported PIDs Test
OBD2 Supported PIDs Validation: Screenshot from asammdf software showing responses to ‘Supported PIDs’ requests, used for validating OBD2 PID support.

Review supported PIDs via OBD2 lookup tool

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

As discussed earlier, ISO 15765-4 provides a method to determine the correct bit-rate and CAN IDs for a specific vehicle. You can use the CANedge to perform these tests (see the CANedge Intro for detailed instructions):

Bit-rate Test: Send a CAN frame at 500K and check for successful transmission. If unsuccessful, try 250K.
Bit-rate Confirmation: Use the identified bit-rate for all subsequent communication.
Supported PIDs Request: Send multiple ‘Supported PIDs’ requests and analyze the responses.
CAN ID Type Determination: Based on the response IDs, determine whether the vehicle uses 11-bit or 29-bit CAN IDs.
PID Support Identification: Analyze the response data to identify the specific PIDs supported by the vehicle.

We provide pre-configured settings to simplify these initial tests.

Most post-2008 non-electric vehicles typically 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 when using the 0x7DF request ID, as it polls all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, many responses to this PID are often observed. Subsequent ‘Supported PIDs’ requests typically receive fewer responses as fewer ECUs support those PID ranges. Note that the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, allowing for reduced bus load by targeting requests specifically to the ECM using ‘Physical Addressing’ CAN ID 0x7E0 for subsequent communication.

Step #2: Configure OBD2 PID Requests for Data Logging

Once you’ve identified the supported OBD2 PIDs, bit-rate, and CAN IDs for your vehicle, you can configure your data logger to request the PIDs you’re interested in.

Consider these points when configuring your PID requests:

CAN Addressing: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid receiving multiple responses to each request, especially after identifying the ECM as a comprehensive data source.
Request Spacing: Introduce a delay of 300-500 ms between each OBD2 request. Overly rapid requests can overwhelm ECUs and lead to non-responsiveness.
Battery Management: Implement triggers to stop transmitting requests when the vehicle is inactive to prevent unnecessary battery drain by ‘waking up’ ECUs.
Data Filtering: Apply filters to record only OBD2 responses if your vehicle also broadcasts OEM-specific CAN data, reducing data storage and processing needs.

With these configurations in place, your data logger is ready to record raw OBD2 data from your vehicle’s OBD2 connector!

obd2-transmit-list-example-canedge
Example CANedge OBD2 Transmit List: A sample configuration showing a list of OBD2 PID requests set up in a CANedge data logger.

OBD2 data decoded visual plot asammdf CAN bus DBC file
OBD2 Data Visualization in asammdf: Screenshot from asammdf software showing decoded and visualized OBD2 data, leveraging a DBC file for interpretation.

Step #3: DBC Decoding of Raw OBD2 Data for Analysis

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

Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. We provide a free OBD2 DBC file to simplify DBC decoding in most CAN bus software tools.

Decoding OBD2 data is slightly more complex than standard CAN signal decoding. This is because multiple OBD2 PIDs can be transmitted using the same CAN ID (e.g., 0x7E8). The CAN ID alone isn’t sufficient to identify the signals within the payload.

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

CANedge: Your Dedicated OBD2 Data Logger

The CANedge offers an easy way to record OBD2 data directly to an SD card (8-32 GB). Simply connect it to your vehicle’s OBD2 connector and start logging. Analyze the data using free software/APIs and our OBD2 DBC.

OBD2 logger intro
CANedge product page

OBD2 Multi-Frame Examples [ISO-TP]

OBD2 communication, as per ISO 15765-2, utilizes ISO-TP (transport protocol) for all data exchange. While many examples are single-frame, multi-frame communication is essential for larger data sets.

Multi-frame OBD2 communication necessitates flow control frames (see our UDS intro). A common approach is to send a static flow control frame approximately 50 ms after the initial request, 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.

OBD2-multi-frame-request-message-vehicle-identification-number
OBD2 Multi-Frame Request Example: Requesting the Vehicle Identification Number (VIN) using a multi-frame OBD2 request message.

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

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and vehicle identification (see our intro to UDS for more information). To retrieve the VIN via OBD2, use mode 0x09 and PID 0x02:

VIN Vehicle Identification Number OBD2 Example multi-frame

The diagnostic 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, total 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 for details). The subsequent 17 bytes constitute the VIN, convertible from HEX to ASCII as discussed in our UDS introduction.

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

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.

This efficient method allows for higher-frequency data collection. However, the signal encoding becomes specific to the request method, making generic OBD2 DBC files less useful. We generally advise against this method in practice. Here’s an example trace:

Requesting multiple PIDs in one request

The multi-frame response is similar to the VIN example but includes the requested PIDs alongside their data. The PIDs are often ordered as requested, which is typical but not strictly enforced 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 using tools with specific built-in support. It involves extended multiplexing, requiring your DBC file to account for PID payload positions, making generalization across vehicles with varying PID support difficult. Handling multiple multi-PID requests further complicates DBC manipulation, making it hard to uniquely identify messages.

Workarounds could involve custom scripts that interpret responses based on request messages, but these are complex to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval

OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’, allows you to request emissions-related DTCs. No PID is included in the request. The target ECU(s) respond with the number of stored DTCs (possibly zero if none) and the DTCs themselves, each occupying 2 data bytes. Multi-frame responses are necessary if more than 2 DTCs are present.

The 2-byte DTC value is typically 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. 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: Illustrating the structure and interpretation of OBD2 Diagnostic Trouble Codes (DTCs) within a DBC file.

OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response Example

Real-World Applications of OBD2 Data Logging

OBD2 data from cars and light trucks has diverse applications:

Car Data Logging

OBD2 data logging in cars can be leveraged for fuel efficiency optimization, driving behavior improvement, prototype testing, and insurance telematics.

OBD2 logger product link

Real-time Vehicle Diagnostics

OBD2 interfaces enable real-time streaming of human-readable diagnostic data, aiding in immediate vehicle issue diagnosis.

OBD2 streaming interface link

Predictive Maintenance

IoT-enabled OBD2 loggers allow for cloud-based vehicle monitoring, facilitating predictive maintenance to prevent breakdowns.

Predictive maintenance solutions link

Vehicle Black Box Recording

OBD2 loggers can serve as ‘black boxes’ for vehicles or equipment, providing crucial data for dispute resolution and diagnostics.

CAN bus black box logger link

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 ‘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 – Dual CAN Bus Telematics Dongle
CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN