OBD2 Connector Identification: Your Guide to Pinouts, Types, and Standards

Need to understand the OBD2 connector?

You’ll learn about:

Identifying the OBD2 connector in your vehicle.
Understanding OBD2 connector pinouts and their functions.
Distinguishing between OBD2 connector Type A and Type B.
The SAE J1962 standard and its importance for OBD2 connectors.
How OBD2 connector identification relates to vehicle diagnostics and data logging.

Let’s dive into the world of OBD2 connector identification and unlock the gateway to your vehicle’s data.

What is the OBD2 Connector?

The OBD2 connector, formally known as the Data Link Connector (DLC), is a standardized 16-pin interface in your vehicle. It’s the gateway to your car’s On-Board Diagnostic system (OBD2), allowing access to diagnostic trouble codes (DTCs) and real-time vehicle data. Mechanics use OBD2 scanners by connecting to this connector to diagnose issues quickly and efficiently.

Think of the malfunction indicator light (MIL) on your dashboard – the “check engine light.” When it illuminates, it signals a problem detected by your car’s self-diagnostic system. The OBD2 connector is the physical point of access for tools to communicate with this system, retrieve error codes, and monitor parameters like speed and fuel level.

Alt text: Malfunction Indicator Light (MIL) on a dashboard, commonly known as the check engine light, indicating an OBD2 system detected issue.

Identifying OBD2 Connector Compatibility

Wondering if your car has an OBD2 connector? The answer is almost certainly yes, especially if it’s a newer, non-electric vehicle. While most modern cars feature a 16-pin OBD2 connector, older vehicles might have one that doesn’t fully support the OBD2 standard. Compliance is often tied to the vehicle’s market and manufacturing date.

As a general guideline for OBD2 connector identification and compatibility:

USA: OBD2 became mandatory for cars and light trucks in 1996.
Europe: OBD2 (EOBD) was required for gasoline cars in 2001 and diesel cars in 2003.

To be certain about OBD2 compliance, especially in older models with a 16-pin connector, consider where and when the vehicle was originally purchased.

Alt text: Chart showing OBD2 compliance timeline for vehicles in the EU and US markets.

A Brief History of OBD2 and Connector Standardization

The OBD2 standard originated in California, driven by the California Air Resources Board (CARB) who mandated OBD in all new cars from 1991 onwards for emission control. The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBD2, defining Diagnostic Trouble Codes (DTCs) and crucially, the OBD connector itself under the SAE J1962 standard. This standardization ensured uniformity across different vehicle manufacturers, simplifying diagnostics.

The OBD2 standard and connector rollout progressed globally:

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

Alt text: Diagram illustrating OBD2 history and its connection to emission control and vehicle data via CAN bus.

Alt text: Timeline infographic outlining the historical progression of OBD2 standardization and implementation.

Alt text: Graphic depicting the future trend of OBD3 with remote diagnostics, emissions testing, cloud connectivity and IoT.

The Future of OBD2 and Data Access

While OBD2 remains relevant, its future is evolving. Originally designed for emissions control, its role is being reshaped by factors like electric vehicles and the increasing demand for vehicle data. Electric vehicles (EVs), interestingly, are not mandated to support OBD2 in the same way as combustion engine cars. Many EVs utilize OEM-specific UDS communication protocols instead, making standardized OBD2 access less common.

Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging to address limitations in data richness and communication protocols. These aim to enhance OBD communication using the UDS protocol as a foundation.

The concept of OBD3 envisions adding telematics to vehicles for remote emissions monitoring. This would involve a radio transponder for transmitting VIN and DTCs wirelessly. While convenient, this raises privacy concerns.

Furthermore, the automotive industry is debating the extent of third-party access to vehicle data via OBD2. Proposals to limit OBD2 functionality during driving and centralize data collection by manufacturers could significantly impact the aftermarket OBD2 service sector.

Alt text: Illustration representing the potential trend of electric vehicles limiting access to data via the OBD2 connector.

Deep Dive into OBD2 Standards

OBD2 operates as a higher-layer protocol, like a language built upon a communication method. In the context of vehicles, CAN bus serves as the communication method (like a phone line). OBD2 is comparable to other CAN-based protocols like J1939, CANopen, and NMEA 2000.

The OBD2 standards comprehensively define various aspects, including the OBD2 connector, lower-layer communication protocols, and OBD2 Parameter IDs (PIDs). These standards can be organized within the 7-layer OSI model, with both SAE and ISO standards contributing to different layers, reflecting US (SAE) and EU (ISO) standardization efforts. Many of these standards are technically very similar, for example SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3, particularly concerning the OBD2 connector identification and specifications.

Alt text: OSI 7-layer model diagram comparing OBD2 and CAN bus standards, highlighting ISO 15765 and ISO 11898.

The OBD2 Connector: SAE J1962 Standard and Pinout

The OBD2 connector, standardized under SAE J1962 / ISO 15031-3, is your physical interface to vehicle data. This 16-pin connector simplifies data access. The illustration below depicts a Type A OBD2 pin connector, also known as a Data Link Connector (DLC).

Key points about OBD2 connector identification and usage:

Location: Typically found near the steering wheel, though it might be concealed.
Pin 16: Provides battery power, often active even when the ignition is off.
Pinout variations: The specific OBD2 pinout configuration depends on the vehicle’s communication protocol.
CAN bus: The most prevalent lower-layer protocol, utilizing pins 6 (CAN-H) and 14 (CAN-L).

Alt text: OBD2 connector pinout diagram, Type A female socket, detailing pin assignments and functions.

OBD2 Connector Types: Type A vs. Type B

In practical applications, you might encounter both Type A and Type B OBD2 connectors. Type A is standard in cars and light vehicles, while Type B is more common in medium and heavy-duty vehicles. The primary difference for OBD2 connector identification lies in their power supply output and physical keying.

Although both types share similar OBD2 pinouts, Type A delivers 12V power, whereas Type B provides 24V. Baud rates can also differ, with cars typically using 500K and heavy-duty vehicles often using 250K (with increasing support for 500K).

Visually, Type B OBD2 connectors have a distinguishing interrupted groove in the center. This mechanical difference ensures that a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, while a Type A adapter will only fit into a Type A socket. This physical distinction is crucial for OBD2 connector identification in different vehicle classes.

Alt text: Comparison diagram of OBD2 Connector Type A and Type B, highlighting differences in voltage (12V vs 24V) and physical keying as per SAE J1962.

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

OBD2 and CAN Bus Communication: ISO 15765-4

Since 2008, CAN bus, as defined by ISO 15765, has been mandatory for OBD2 communication in all US vehicles. ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers.

Key ISO 15765-4 specifications relevant to OBD2 connector identification and communication:

Bit-rate: CAN bus must operate at either 250K or 500K.
CAN IDs: Supports both 11-bit and 29-bit CAN identifiers.
Standard CAN IDs: Specific CAN IDs are designated for OBD requests and responses.
Data Length: Diagnostic CAN frames must have an 8-byte data length.
Cable Length: OBD2 adapter cables are limited to a maximum of 5 meters.

OBD2 CAN Identifiers: 11-bit and 29-bit

OBD2 communication relies on request/response message exchanges. In most cars, 11-bit CAN IDs are used. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs for data on a requested parameter. ‘Physical Addressing’ requests, using CAN IDs 0x7E0-0x7E7 to target specific ECUs, are less common.

ECUs respond with 11-bit IDs in the range 0x7E8-0x7EF. 0x7E8 (ECM, Engine Control Module) and 0x7E9 (TCM, Transmission Control Module) are the most common response IDs.

Some vehicles, particularly vans and medium/heavy-duty vehicles, might utilize extended 29-bit CAN identifiers for OBD2 communication. In this case, the ‘Functional Addressing’ CAN ID is 0x18DB33F1. Responses use CAN IDs from 0x18DAF100 to 0x18DAF1FF, with typical examples being 18DAF110 and 18DAF11E. The response ID is sometimes represented in the J1939 PGN format as PGN 0xDA00 (55808), which is reserved for ISO 15765-2 in the J1939-71 standard.

Alt text: Diagram illustrating the OBD2 protocol request and response frames, highlighting PID and data parameters.

Alt text: Conceptual diagram contrasting OBD2 and proprietary OEM-specific CAN bus data protocols.

OBD2 vs. OEM-Specific CAN Protocols

It’s important to recognize that vehicle Electronic Control Units (ECUs) operate using proprietary CAN protocols developed by the Original Equipment Manufacturer (OEM), independent of OBD2. These protocols are often vehicle brand, model, and year-specific. Understanding this distinction is key for effective OBD2 connector identification and data interpretation. Without OEM documentation or reverse engineering, decoding this proprietary data is generally not possible for third parties.

When you connect a CAN bus data logger to your OBD2 connector, you might observe OEM-specific CAN data alongside OBD2 data. However, in many newer vehicles, a gateway module restricts access to this OEM data, allowing only OBD2 communication through the OBD2 connector.

Think of OBD2 as a parallel, standardized, higher-layer protocol coexisting with the OEM’s proprietary communication network within the vehicle.

Bit-rate and ID Validation for OBD2 Connector Communication

OBD2 over CAN may use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential protocol combinations. Modern cars commonly use 500K and 11-bit IDs. Diagnostic tools should systematically validate these parameters to ensure correct communication.

ISO 15765-4 provides a standardized initialization sequence to determine the correct combination. This process leverages the mandatory support for a specific OBD2 request in compliant vehicles (refer to the OBD2 PID section) and detects CAN error frames caused by incorrect bit-rate settings.

Newer versions of ISO 15765-4 consider OBD communication via OBDonUDS as well as OBDonEDS. While this article primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service), WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service) is relevant for EU trucks and buses.

To differentiate between OBDonEDS and OBDonUDS, tools can send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and 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 mainly used in EU commercial vehicles.

Alt text: Flowchart illustrating the OBD2 bit-rate and CAN ID validation process according to ISO 15765-4.

Alt text: Diagram showing the five lower-layer OBD2 protocols: CAN (ISO 15765), KWP2000, SAE J1850 (VPW & PWM), and ISO 9141.

Five Lower-Layer OBD2 Protocols

While CAN (ISO 15765) is now the dominant lower-layer protocol for OBD2, particularly in vehicles post-2008, older cars may utilize other protocols. Understanding these is helpful, especially when dealing with older vehicles and OBD2 connector identification. Pinout configurations can sometimes indicate the protocol in use.

The five lower-layer OBD2 protocols are:

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

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

All OBD2 communication over CAN bus uses the ISO-TP (ISO 15765-2) transport protocol. This protocol enables the transmission of data payloads exceeding 8 bytes, essential 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 smaller OBD2 data exchanges that fit within a single CAN frame, ISO 15765-2 specifies the use of ‘Single Frame’ (SF) formatting. In SF frames, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-specific data.

Alt text: Diagram illustrating ISO 15765-2 ISO-TP OBD2 frame types, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

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

To understand OBD2 communication at the message level, let’s examine a simplified ‘Single Frame’ OBD2 CAN message. It consists of a CAN identifier, a data length indicator (PCI field), and the data payload. The payload is further structured into Mode, Parameter ID (PID), and data bytes.

Alt text: Breakdown of the OBD2 message structure, explaining Mode, PID, and Data Bytes within a raw OBD2 frame.

OBD2 Request/Response Example: Vehicle Speed

Consider an example of requesting ‘Vehicle Speed’ using OBD2. An external tool sends a request with CAN ID 0x7DF, containing Mode 0x01 and PID 0x0D. The vehicle responds with CAN ID 0x7E8, including the speed value in the 4th byte, 0x32 (decimal 50). By consulting OBD2 PID documentation for PID 0x0D, we can decode 0x32 as 50 km/h.

Alt text: Example of OBD2 request (CAN ID 7DF) and response (CAN ID 7E8) messages for vehicle speed.

Alt text: Detailed example of OBD2 PID 0D for Vehicle Speed, showing request and response data bytes and interpretation.

Alt text: Table outlining the 10 OBD2 service modes (diagnostic services), including current data, freeze frame, and clear DTCs.

The 10 OBD2 Services (Modes)

OBD2 defines 10 diagnostic services, also referred to as modes. Mode 0x01 is used for real-time data, while others are for accessing/clearing DTCs or retrieving freeze frame data. Vehicles are not required to support all 10 OBD2 modes and may implement OEM-specific modes beyond these.

In OBD2 messages, the mode is 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 for a response to mode 0x01).

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the data being requested. Mode 0x01, for instance, includes approximately 200 standardized PIDs for real-time parameters like speed, RPM, and fuel level. However, vehicles typically support only a subset of these PIDs.

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 support for PIDs 0x01-0x20. Thus, PID 0x00 serves as a fundamental OBD2 compatibility test. Similarly, PIDs 0x20, 0x40, and so on, can be used to check support for subsequent PID ranges within mode 0x01.

Alt text: Diagram illustrating OBD2 protocol request and response frames, highlighting PID and data parameters.

Alt text: Screenshot of an OBD2 PID overview tool, showcasing service 01 parameters and data fields.

Tip: OBD2 PID Overview Tool

SAE J1979 and ISO 15031-5 appendices provide scaling information for standard OBD2 PIDs, enabling conversion of raw data into physical values. Our free OBD2 PID overview tool simplifies this process. It aids in constructing OBD2 request frames and dynamically decoding OBD2 responses for mode 0x01 PIDs.

OBD2 PID overview tool

Logging and Decoding OBD2 Data: A Practical Guide

Let’s illustrate how to log OBD2 data using the CANedge CAN bus data logger. The CANedge allows configuration of custom CAN frames for transmission, making it suitable for OBD2 data logging. Connect the CANedge to your vehicle via an OBD2-DB9 adapter cable for easy setup.

Alt text: Diagram depicting an OBD2 PID data logger setup, showing request (7DF) and response (7E8) message flow.

Alt text: Screenshot showing bit-rate validation test for OBD2 communication.

Alt text: Screenshot from asammdf software showing OBD validation PID test responses.

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

ISO 15765-4 outlines how to determine the correct bit-rate and IDs for a vehicle. Use the CANedge to perform these tests:

Attempt CAN frame transmission at 500K; if unsuccessful, try 250K.
Use the validated bit-rate for subsequent communication.
Send ‘Supported PIDs’ requests and analyze responses.
Determine 11-bit or 29-bit IDs based on response IDs.
Identify supported PIDs from response data.

Plug-and-play configurations are available to simplify these tests. Most post-2008 non-EV cars support 40-80 PIDs using 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol. As shown in the asammdf GUI, multiple ECUs may respond to a single OBD request using the 0x7DF ID. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses are common for this PID. By switching to ‘Physical Addressing’ with CAN ID 0x7E0 and targeting the ECM ECU (0x7E8), you can reduce bus load by requesting data specifically from this ECU.

Step #2: Configuring OBD2 PID Requests

Once you’ve identified supported PIDs, bit-rate, and CAN IDs, configure your transmit list with desired PIDs. Consider these factors:

CAN IDs: Use ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses.
Spacing: Introduce 300-500 ms intervals between OBD2 requests to prevent ECU overload.
Battery Drain: Implement triggers to halt transmission when the vehicle is inactive to prevent ECU “wake-up.”
Filters: Apply filters to record only OBD2 responses, especially if OEM-specific CAN data is also present.

With configuration complete, the device is ready to log raw OBD2 data.

Alt text: Example of a CANedge OBD2 PID request transmit list configuration.

Alt text: Visual plot of decoded OBD2 data in asammdf, using a CAN bus DBC file for interpretation.

Step #3: DBC Decoding of Raw OBD2 Data

To analyze and visualize logged data, decode the raw OBD2 data into physical units (e.g., km/h, °C). Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. A free OBD2 DBC file is provided to facilitate DBC decoding in most CAN bus software tools.

Decoding OBD2 data is more intricate than standard CAN signals because different OBD2 PIDs share the same CAN ID (e.g., 0x7E8). The CAN ID alone isn’t enough to identify the signals within the payload. You must use the CAN ID, OBD2 mode, and OBD2 PID for unique signal identification. This is a form of multiplexing called ‘extended multiplexing‘, which can be implemented in DBC files.

CANedge: Your OBD2 Data Logger

The CANedge offers an easy way to record OBD2 data onto SD cards (8-32 GB). Simply connect it to a car or truck to begin logging. Use free software/APIs and the OBD2 DBC file to decode the data.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples: ISO-TP in Action

OBD2 communication relies on ISO-TP (ISO 15765-2) for all data transfer. While previous examples focused on single-frame communication, multi-frame communication is crucial for larger data payloads. Multi-frame OBD2 exchanges involve flow control frames. A static flow control frame, transmitted approximately 50 ms after the initial request, is often used in configurations like the CANedge example. Analyzing multi-frame OBD2 responses requires CAN software/API tools with ISO-TP support, such as CANedge MF4 decoders.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval

The Vehicle Identification Number (VIN) is essential for telematics, diagnostics, and more. To retrieve the VIN using OBD2, utilize mode 0x09 and PID 0x02.

The tester tool initiates with a Single Frame request, including the PCI field (0x02), service identifier (0x09), and PID (0x02). The vehicle responds with a First Frame containing PCI, length (0x014 = 20 bytes), mode (0x49), and PID (0x02). Following the PID is the Number Of Data Items (NODI) byte (0x01 in this case). The subsequent 17 bytes constitute the VIN, convertible from HEX to ASCII as 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, potentially spanning multiple frames via ISO-TP. While efficient for data collection, this method complicates signal encoding and generic DBC file usage. It’s generally not recommended for practical use.

The multi-frame response structure resembles the VIN example but includes requested PIDs and their corresponding data. PIDs are typically ordered as requested, though not strictly mandated by ISO 15031-5. Decoding such responses via generic DBC files is complex due to extended multiplexing and PID-specific payload positioning. Custom scripts and recording request messages can aid in interpretation, but these approaches are challenging to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

Mode 0x03, ‘Show stored Diagnostic Trouble Codes’, retrieves emissions-related DTCs. The request omits a PID. Responding ECUs indicate the number of stored DTCs (potentially zero), with each DTC occupying 2 bytes. Multi-frame responses are necessary when more than two DTCs are stored.

The 2-byte DTC value is categorized and encoded 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 DTCs can be looked up using OBD2 DTC lookup tools.

Alt text: Example of OBD2 DTC decoding and interpretation in DBC files.

OBD2 Data Logging Use Cases

OBD2 data from cars and light trucks has diverse applications:

Alt text: Image representing OBD2 data logging from a car for on-board diagnostics.

Car Data Logging

OBD2 data logging in cars can optimize fuel consumption, improve driving habits, facilitate prototype testing, and support insurance applications.

obd2 logger

Alt text: Graphic depicting OBD2 real-time streaming for vehicle diagnostics via USB.

Real-Time Car Diagnostics

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

obd2 streaming

Alt text: Image illustrating OBD2 data logging for predictive maintenance and telematics applications.

Predictive Maintenance

IoT-enabled OBD2 loggers can monitor cars and light trucks in the cloud for predictive maintenance, preventing breakdowns.

predictive maintenance

Alt text: Representation of a CAN bus data logger as a vehicle black box for insurance and warranty purposes.

Vehicle Black Box Logger

An OBD2 logger can function as a vehicle ‘black box’, providing crucial data for disputes or advanced diagnostics.

can bus blackbox

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

Explore our guides 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

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN