OBD2 Diagnostic Connector: Your Guide to Understanding and Using It

Want to dive into the world of OBD2 and understand the crucial Obd2 Diagnostic Connector?

This guide provides a practical introduction to the On-Board Diagnostics 2 (OBD2) protocol, focusing on the OBD2 connector, its pinout, and its role in accessing valuable vehicle data. We’ll also touch upon OBD2 parameter IDs (PIDs) and its connection to the CAN bus.

This is a hands-on introduction, designed to teach you how to request and decode OBD2 data, explore key applications, and offer practical tips for working with your OBD2 diagnostic connector.

Discover why this has become a go-to resource for understanding the OBD2 diagnostic connector and the broader OBD2 system.

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

Understanding OBD2 and the OBD2 Diagnostic Connector

OBD2 is essentially your car’s internal health monitor. It’s a standardized system that allows you to retrieve diagnostic trouble codes (DTCs) and access real-time vehicle data via the OBD2 diagnostic connector.

You’ve likely encountered OBD2 in action without even realizing it. Remember that check engine light, officially known as the malfunction indicator light, illuminating on your dashboard?

That’s your car signaling a potential issue. When you take your vehicle to a mechanic, they use an OBD2 scanner to pinpoint the problem.

This process begins with connecting the OBD2 scanner to the OBD2 16-pin diagnostic connector, typically located near the steering wheel. This OBD2 diagnostic connector serves as the gateway to your vehicle’s diagnostic data. The scan tool sends ‘OBD2 requests’ through this connector, and the car responds with ‘OBD2 responses’ containing information like speed, fuel level, or those crucial Diagnostic Trouble Codes (DTCs). This streamlined communication via the OBD2 diagnostic connector makes troubleshooting vehicle issues significantly faster and more efficient.

Understanding the Malfunction Indicator Light (MIL) in relation to OBD2 diagnostics.

OBD2 Compatibility: Is Your Car Equipped?

The short answer is: Most likely, yes!

Almost all modern gasoline and diesel cars, excluding fully electric vehicles, are equipped with OBD2 and often utilize the CAN bus communication protocol. However, for older vehicles, the presence of a 16-pin OBD2 diagnostic connector doesn’t automatically guarantee OBD2 compliance. Some older cars may have the connector but not fully support the OBD2 protocol. To confirm compatibility, consider the vehicle’s origin and year of purchase:

Timeline for OBD2 adoption in the US and EU based on vehicle purchase location and year.

A Brief History of OBD2 and the Diagnostic Connector

The story of OBD2 begins in California. The California Air Resources Board (CARB) mandated OBD in all new vehicles from 1991 onwards to monitor and control emissions.

The Society of Automotive Engineers (SAE) played a key role in standardizing OBD2, defining DTCs and, importantly, standardizing the OBD2 diagnostic connector across different manufacturers through SAE J1962. This standardization of the OBD2 diagnostic connector was crucial for ensuring compatibility between diagnostic tools and vehicles.

From its Californian roots, the OBD2 standard expanded progressively:

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

Visual representation of OBD2 history, emphasizing emission control and data access.

Timeline showcasing the evolution of OBD2 and on-board diagnostics.

Conceptual illustration of OBD3 and the future of remote vehicle diagnostics.

The Future of OBD2 and Vehicle Diagnostics

OBD2 is firmly established, but its future evolution is an ongoing discussion.

Originally designed for emissions monitoring, legislated OBD2 has not been deemed necessary for electric vehicles. Consequently, most modern EVs do not support standard OBD2 requests. Instead, they often use OEM-specific UDS communication, making data access challenging without reverse engineering efforts. However, there are successful cases of accessing data from electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs, as detailed in our case studies for electric cars.

Limitations in data richness and lower-layer protocols in traditional OBD2 have led to the development of alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). These aim to improve OBD communication using the UDS protocol as a base. Learn more in our intro to UDS.

In our increasingly connected world, manual OBD2 emission checks appear outdated. The proposed solution? OBD3 – integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder to vehicles, similar to those used for bridge tolls. This would enable wireless transmission of the vehicle identification number (VIN) and DTCs 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 support CAN or OBD2 data transfer via WiFi/cellular networks.

While convenient and cost-effective, OBD3 raises political concerns related to surveillance and data privacy.

The original purpose of OBD2 was for in-garage emission controls. However, third-party usage for real-time data generation via OBD2 dongles and CAN loggers has become widespread. The German car industry is pushing back against this trend:

“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 is to disable OBD2 functionality during driving, centralizing data collection with manufacturers. This would give manufacturers control over ‘automotive big data’.

Arguments for this shift include security improvements, aiming to reduce the risk of car hacking. However, many perceive this as a commercially motivated move to control valuable vehicle data. The future of OBD2 third-party services remains uncertain.

Illustration of potential data access restrictions in electric vehicles affecting the OBD2 connector.

Get our ‘Ultimate CAN Guide’

Ready to become a CAN bus expert?

Access our 12 ‘simple intros’ in one comprehensive 160+ page PDF:

Download now

OBD2 Standards and Protocols

On-board diagnostics, OBD2, operates as a higher-layer protocol, similar to a language, while CAN acts as the communication method, like a phone line. OBD2 shares this layered approach with other CAN-based protocols such as J1939, CANopen and NMEA 2000.

OBD2 standards define various aspects, including the OBD2 diagnostic connector, lower-layer communication protocols, and OBD2 parameter IDs (PIDs).

These standards can be visualized using the 7-layer OSI model. Notice that both SAE and ISO standards cover multiple layers, reflecting the US (SAE) and EU (ISO) standardization efforts for OBD. Many standards are technically very similar, for example, SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3, the latter being particularly relevant to the OBD2 diagnostic connector.

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

Diagram of the OBD2 connector pinout, Type A, female socket.

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

The 16-pin OBD2 diagnostic connector is your physical interface for accessing vehicle data, as specified in SAE J1962 / ISO 15031-3.

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

Key points about the OBD2 diagnostic connector:

It is typically located near the steering wheel, though its exact location can be hidden depending on the vehicle model.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 connector pinout varies depending on the communication protocol used by the vehicle.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are commonly used in the OBD2 diagnostic connector.

OBD2 Connector Types: A vs. B

You may encounter both Type A and Type B OBD2 diagnostic connectors. Type A is standard in cars and light-duty vehicles, while Type B is more common in medium and heavy-duty vehicles.

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

Visually, the Type B OBD2 diagnostic connector has a distinguishing interrupted groove in the middle. A Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, but a Type A adapter will not fit a Type B socket.

Comparison of OBD2 Connector Type A and Type B, highlighting voltage and application differences.

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

OBD2 Communication over CAN Bus [ISO 15765-4]

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in US vehicles, according to ISO 15765.

ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies requirements for using CAN (ISO 11898) for diagnostics.

Specifically, it standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:

CAN bus bit rate: must be 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: must be 8 bytes.
OBD2 adapter cable length: maximum 5 meters.

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

OBD2 communication relies on request/response message exchanges.

Most cars use 11-bit CAN IDs for OBD2. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compliant ECUs for data on a requested parameter (ISO 15765-4). ‘Physical Addressing’ requests to specific ECUs use CAN IDs 0x7E0-0x7E7 but are less common.

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

Some vehicles, particularly vans and medium/heavy-duty vehicles, may use extended 29-bit CAN identifiers for OBD2 communication.

Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

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

Illustration of OBD2 request and response frames with PID and data parameters.

Diagram contrasting OBD2 data with OEM-specific CAN bus data.

OBD2 vs. OEM-Specific CAN Protocols

It’s important to understand that vehicle ECUs primarily rely on OEM-proprietary CAN protocols for their core functions, not OBD2. These proprietary protocols are often unique to the vehicle brand, model, and year. Interpreting this OEM-specific CAN data is usually not possible without OEM documentation or reverse engineering expertise.

Connecting a CAN bus data logger to your car’s OBD2 diagnostic connector may capture OEM-specific CAN data, typically transmitted at 1000-2000 frames/second. However, many newer vehicles employ a ‘gateway’ that restricts access to this data via the OBD2 diagnostic connector, allowing only OBD2 communication.

Think of OBD2 as a supplementary higher-layer protocol operating alongside the OEM-specific protocol, accessed through the OBD2 diagnostic connector.

Bit-rate and ID Validation

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. Diagnostic tools should systematically verify these parameters.

ISO 15765-4 provides a recommended initialization sequence to determine the correct combination. This method relies on the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit rates cause CAN error frames.

Newer versions of ISO 15765-4 account for OBD communication via OBDonUDS in addition to OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979) rather than WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per 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). OBDonUDS-compliant vehicles should have ECUs that respond to this DID.

OBDonEDS (aka OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars today, while WWH-OBD is mainly used in EU trucks and buses.

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

Visual representation of the five lower-layer OBD2 protocols including CAN, KWP2000, SAE J1850, and ISO 9141.

Five Lower-Layer OBD2 Protocols

While CAN is now the dominant lower-layer protocol for OBD2 (ISO 15765), older vehicles (pre-2008) may use one of four other protocols. The OBD2 connector pinout can sometimes indicate the protocol in use.

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

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

OBD2 data communication over CAN bus utilizes ISO-TP (ISO 15765-2), a transport protocol enabling payloads larger than 8 bytes. This is 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 detailed information, refer to our intro to UDS.

However, much OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies ‘Single Frame’ (SF) usage. The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-related communication.

Diagram illustrating ISO-TP frame types used in OBD2 communication.

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

To understand OBD2 over CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. Simplified, an OBD2 message consists of an identifier, data length (PCI field), and data. The data section is further broken down into Mode, parameter ID (PID), and data bytes.

Breakdown of the OBD2 message structure, highlighting Mode, PID and Data Bytes.

OBD2 Request/Response Example

Consider this request/response example for ‘Vehicle Speed’.

A diagnostic tool sends a request message to the car 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 Vehicle Speed value in the 4th byte, 0x32 (50 in decimal).

Using OBD2 PID 0x0D decoding rules, we determine the physical value to be 50 km/h.

Let’s delve into OBD2 modes and PIDs.

Example of an OBD2 request and response sequence using CAN IDs 0x7DF and 0x7E8.

Specific example of OBD2 PID 0x0D for Vehicle Speed.

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

The 10 OBD2 Services (Modes)

OBD2 defines 10 diagnostic services, also called modes. Mode 0x01 provides current real-time data, while others are used for diagnostic trouble codes (DTCs) or freeze frame data.

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

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

OBD2 Parameter IDs (PIDs)

Each OBD2 mode contains parameter IDs (PIDs).

For example, mode 0x01 includes approximately 200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles typically support only 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 PID 0x00, the ECU indicates its support for PIDs 0x01-0x20. PID 0x00 is therefore useful as a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to check support for the remaining mode 0x01 PIDs.

(Repeated image) Illustration of OBD2 request and response frames with PID and data parameters.

Screenshot of an OBD2 PID overview tool for service 0x01.

Tip: OBD2 PID Overview Tool

SAE J1979 and ISO 15031-5 appendices provide scaling information for standard OBD2 PIDs, enabling conversion of raw data to physical values (as explained in our CAN bus intro).

For quick lookup of mode 0x01 PIDs, use our OBD2 PID overview tool. It helps construct OBD2 request frames and dynamically decode responses.

OBD2 PID overview tool

Logging and Decoding OBD2 Data: A Practical Guide

This section provides a practical example of logging OBD2 data using the CANedge CAN bus data logger.

The CANedge allows custom CAN frame transmission, making it suitable for OBD2 logging.

Connect the CANedge to your vehicle via our OBD2-DB9 adapter cable for easy setup.

Diagram showing an OBD2 data logger requesting PIDs using CAN IDs 0x7DF and 0x7E8.

Screenshot showing bit-rate validation in OBD2 communication.

Screenshot from asammdf software showing OBD2 Supported PIDs test responses.

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

ISO 15765-4 outlines how to determine the bit rate and IDs used by a vehicle. Use the CANedge for this validation (see the CANedge Intro for details):

Transmit a CAN frame at 500K; check for success (if not, try 250K).
Use the identified bit rate for subsequent communication.
Send ‘Supported PIDs’ requests and analyze the responses.
Response IDs indicate 11-bit or 29-bit CAN IDs.
Response data reveals supported PIDs.

We provide plug-and-play configurations for these tests.

Most 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 screenshot, multiple responses to a single OBD request are common due to the use of the 0x7DF request ID, which polls all ECUs. Because all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, many responses are often received for this PID. Fewer ECUs respond to subsequent ‘Supported PIDs’ requests. The ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, reducing bus load by directly requesting responses from this ECU using the ‘Physical Addressing’ CAN ID 0x7E0.

#2: Configuring OBD2 PID Requests

After identifying supported PIDs, bit rate, and CAN IDs, configure your transmit list with relevant PIDs.

Consider these points:

CAN IDs: Use ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses per request.
Spacing: Add 300-500 ms intervals between OBD2 requests to prevent ECU overload.
Battery drain: Use triggers to stop transmissions when the vehicle is inactive.
Filters: Implement filters to record only OBD2 responses (if OEM-specific CAN data is also present).

With these configurations, the CANedge is ready to log raw OBD2 data.

Example transmit list for OBD2 PID requests using CANedge.

Decoded and visualized OBD2 data in asammdf using a CAN bus DBC file.

#3: DBC Decoding of Raw OBD2 Data

To analyze and visualize logged data, decode the raw OBD2 data into physical values (e.g., km/h, °C).

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

Decoding OBD2 data is more complex than standard CAN signals because different OBD2 PIDs use the same CAN ID (e.g., 0x7E8). The CAN ID alone isn’t enough to identify signals within the payload.

Therefore, decoding requires using the CAN ID, OBD2 mode, and OBD2 PID—a form of multiplexing called ‘extended multiplexing‘, implementable in DBC files.

CANedge: OBD2 Data Logger

The CANedge easily records OBD2 data to 8-32 GB SD cards. Connect it to a vehicle to start logging and decode data using free software/APIs and our OBD2 DBC.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples [ISO-TP]

OBD2 uses ISO-TP (ISO 15765-2) for all data communication. Most examples so far have been single-frame. This section provides multi-frame communication examples.

Multi-frame OBD2 communication requires flow control frames (see our UDS intro). A static flow control frame can be transmitted ~50 ms after the initial request, as shown in the CANedge configuration example.

Multi-frame OBD2 responses need 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: OBD2 Vehicle Identification Number (VIN)

The Vehicle Identification Number (VIN) is important for telematics and diagnostics (see our intro to UDS). Request the VIN using OBD2 mode 0x09 and PID 0x02:

The diagnostic 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 byte 0x01 (Number Of Data Items – NODI), in this case 1 (ISO 15031-5 / SAE J1979). The remaining 17 bytes are the VIN, convertible from HEX to ASCII.

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

Diagnostic tools can request up to 6 mode 0x01 OBD2 PIDs in one request frame. The ECU responds with data for supported PIDs (skipping unsupported ones), potentially using multiple frames via ISO-TP.

This increases data collection efficiency, but signal encoding becomes request-specific, complicating generic OBD2 DBC file use. We advise against this method in practice. Below is an example trace:

The multi-frame response is similar to the VIN example, but the payload includes requested PIDs and their data. PIDs are typically ordered as requested, although the ISO 15031-5 standard doesn’t strictly require this.

Decoding these responses via DBC files is complex and not recommended for practical data logging unless using tools with specific built-in support. This approach involves extended multiplexing, making generic DBC files difficult to use across different vehicles and PID configurations. Handling multiple multi-PID requests with pure DBC manipulation becomes challenging.

Workarounds may involve custom scripts and recording transmit messages, allowing interpretation of responses based on requests. However, these methods are hard to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

OBD2 mode 0x03 (‘Show stored Diagnostic Trouble Codes’) retrieves emissions-related DTCs. No PID is included in the request. Responding ECUs indicate the number of stored DTCs (possibly 0), with each DTC using 2 data bytes. Multi-frame responses are needed for more than 2 DTCs.

The 2-byte DTC value is 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. 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.

Example of OBD2 DTC decoding and interpretation.

OBD2 Data Logging – Use Case Examples

OBD2 data from cars and light trucks has various applications:

Logging Data from Cars

OBD2 data logging in cars can help reduce fuel costs, improve driving habits, test prototype components, and inform insurance models.

obd2 logger

Real-Time Car Diagnostics

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

obd2 streaming

Predictive Maintenance

IoT OBD2 loggers can monitor cars and light trucks in the cloud to predict and prevent breakdowns through predictive maintenance.

predictive maintenance

Vehicle Black Box Logger

An OBD2 logger can serve as a vehicle ‘black box’ for data in disputes or for detailed diagnostics.

can bus blackbox

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

For more introductory guides, see our guides section or download the ‘Ultimate Guide’ PDF.

Need to log/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