Understanding the OBD2 Connector: Your Essential Guide to Vehicle Diagnostics

Need to understand the OBD2 connector?

In this guide, we delve into the OBD2 connector, a critical component of the On-Board Diagnostic (OBD2) system, which is essential for modern vehicle diagnostics and data access. We’ll explore its function, pinout, types, and its role in vehicle communication, particularly with the CAN bus.

This is a practical guide, designed to give you a clear understanding of the OBD2 connector and its significance in automotive repair and data retrieval.

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

What is an OBD2 Connector?

The OBD2 connector is a standardized 16-pin interface that provides access to your vehicle’s On-Board Diagnostic system (OBD2). It’s the physical port through which mechanics and car enthusiasts can retrieve diagnostic trouble codes (DTCs) and real-time data from your car.

You’re likely familiar with the OBD2 system, even if indirectly:

Have you ever seen the check engine light or malfunction indicator light illuminate on your dashboard?

This light signals a problem detected by your car’s self-diagnostic system. To pinpoint the issue, a mechanic uses an OBD2 scanner.

They connect this OBD2 reader to the OBD2 connector, typically a 16 pin connector located near the steering wheel. The scanner sends ‘OBD2 requests’ to the vehicle, and the car responds with ‘OBD2 responses’ containing information like speed, fuel level, or DTCs. This process significantly speeds up troubleshooting and repair.

Image showing a malfunction indicator light (MIL) and an OBD2 scan tool being used on a car, illustrating the diagnostic process.

Does Your Car Have an OBD2 Connector?

In most cases: Yes!

Nearly all modern non-electric vehicles are equipped with an OBD2 connector, and the majority communicate using the CAN bus protocol. For older vehicles, even if a 16-pin OBD2 connector is present, it might not actually support the OBD2 standard. The vehicle’s origin and purchase date are key indicators:

Image showing a table indicating OBD2 compliance by region and year, helping users determine if their car has OBD2.

OBD2 Connector History

The OBD2 standard and its connector have roots in California. The California Air Resources Board (CARB) mandated OBD in all new vehicles from 1991 onwards for emission control.

The Society of Automotive Engineers (SAE) recommended the OBD2 standard, which standardized DTCs and, importantly, the OBD connector across different manufacturers (SAE J1962).

The OBD2 standard was progressively implemented:

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

Image illustrating the history of OBD2 development, highlighting emission control and the evolution towards CAN bus.

Image depicting a timeline of OBD2 history, visually summarizing the key milestones and dates of implementation.

Image visualizing the future trends of OBD towards OBD3, remote diagnostics, and IoT integration.

Future of the OBD2 Connector

While the OBD2 connector and protocol are well-established, their future is evolving.

Originally designed for emissions control and testing, legislated OBD2 has limitations, especially with electric vehicles. Electric vehicles aren’t obligated to support OBD2 in its traditional form. In fact, most modern EVs don’t support standard OBD2 requests, opting instead for OEM-specific UDS communication. This often makes accessing data from EVs challenging, except in cases where reverse engineering has uncovered the communication protocols, as seen in studies for brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda.

Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging to address OBD2’s limitations in data richness and lower-layer protocols. These aim to improve OBD communication by using the UDS protocol as a base. For more information, see our introduction to UDS.

In our connected world, manual OBD2 emission checks are becoming less efficient.

The proposed solution is OBD3, which envisions adding telematics to vehicles.

OBD3 would integrate a small radio transponder into cars, enabling the car’s vehicle identification number (VIN) and DTCs to be transmitted wirelessly via WiFi 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 transferring CAN or OBD2 data via WiFi/cellular.

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

OBD2 was initially designed for stationary emission testing.

However, third-party applications extensively use OBD2 for real-time data acquisition via OBD2 dongles, CAN loggers. The German automotive industry is considering changes to this [https://www.eenewsautomotive.com/news/german-car-industry-plans-close-obd-interface?news_id=93237]:

OBD was intended for repair shop servicing, “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,” according to Christoph Grote, SVP Electronics, BMW (2017).

The proposal suggests disabling OBD2 functionality during driving, centralizing data collection with manufacturers to control ‘automotive big data’.

Arguments for this include security improvements, such as reducing car hacking risks, but many view it as a commercial strategy [https://www.navixy.com/blog/obd-trackers-what-future-awaits/]. The future of OBD2 and third-party access remains uncertain, but these developments could significantly alter the market for OBD2 services.

Image depicting the potential removal of the OBD2 connector in electric vehicles, highlighting the shift in data access.

Get our ‘Ultimate CAN Guide’

Want to master CAN bus technology?

Our comprehensive 160+ page PDF combines 12 ‘simple intros’:

Download now

OBD2 Connector Standards

On-board diagnostics, or OBD2, is a higher-layer protocol – a communication language. CAN, on the other hand, is the communication method, akin to a telephone line. OBD2 is similar to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

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

These standards can be visualized using a 7-layer OSI model. Notably, both SAE and ISO standards cover multiple layers, reflecting OBD standards defined in the US (SAE) and EU (ISO). Many standards are technically very similar, for instance, SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3.

Image depicting the OSI model for OBD2 and CAN bus, highlighting the layered standards ISO 15765 and ISO 11898.

Image of an OBD2 connector pinout diagram (Type A), illustrating the layout and functions of each pin in the Data Link Connector (DLC).

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

The 16-pin OBD2 connector is your gateway to accessing vehicle data, standardized under SAE J1962 / ISO 15031-3.

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

Key points about the OBD2 connector:

It’s usually located near the steering wheel, but its exact position can be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout configuration varies based on the communication protocol used.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are commonly connected.

OBD2 Connector – Type A vs. Type B

You may encounter both Type A and Type B OBD2 connectors. Type A is typical in cars, 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: 12V for Type A and 24V for Type B. Baud rates can also vary; cars typically use 500K, while heavy-duty vehicles often use 250K (with increasing support for 500K).

Visually, Type B OBD2 connectors have an interrupted groove in the middle, distinguishing them from Type A. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and B sockets, but a Type A adapter will not fit into a Type B socket.

Image contrasting OBD2 Connector Type A and Type B, highlighting the differences in voltage (12V vs 24V) and physical characteristics for cars and trucks.

Image illustrating the relationship between OBD2 and CAN bus according to ISO 15765 standards.

OBD2 Connector and CAN Bus [ISO 15765-4]

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

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies constraints on the CAN standard (ISO 11898).

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

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

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

OBD2 communication is based on request/response messaging.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, used to query all OBD2-compatible ECUs for data on a requested parameter (ISO 15765-4). CAN IDs 0x7E0-0x7E7 are for ‘Physical Addressing’ requests to specific ECUs (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 instead of 11-bit IDs.

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

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

Image illustrating the OBD2 protocol request and response frames, showing the flow of data and parameters.

Image comparing OBD2 and proprietary CAN bus data, highlighting the differences in accessibility and standardization.

OBD2 Connector vs. Proprietary CAN Protocols

It’s crucial to understand that your car’s electronic control units (ECUs) operate using OEM-proprietary CAN protocols, not OBD2. OBD2 is an additional protocol implemented for diagnostics. These OEM protocols are often specific to vehicle brand, model, and year, and are generally undecipherable without OEM documentation or reverse engineering.

Connecting a CAN bus data logger to your car’s OBD2 connector may reveal OEM-specific CAN data, typically broadcast at high rates (1000-2000 frames/second). However, newer vehicles often have a ‘gateway’ that restricts access to this data, allowing only OBD2 communication through the OBD2 connector.

Think of OBD2 as a supplementary higher-layer protocol that exists alongside the OEM-specific protocol.

Bit-rate and ID Validation

OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), creating 4 possible combinations. Modern cars commonly use 500K and 11-bit IDs. Diagnostic tools should systematically verify these settings.

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

Newer versions of ISO 15765-4 acknowledge that vehicles may support OBD communication via OBDonUDS rather than OBDonEDS. This article primarily discusses OBD2/OBDonEDS (OBD on Emission Diagnostic Service per ISO 15031-5/SAE J1979) versus WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service per ISO 14229, ISO 27145-3/SAE J1979-2).

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

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.

Image of a flowchart illustrating the OBD2 bit-rate and CAN ID validation process, as per ISO 15765-4.

Image depicting 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 use other protocols. Understanding these is helpful when working with older vehicles. 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+ vehicles, especially in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian cars from 2000-04.
SAE J1850 (VPW – Variable Pulse Width): 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]

All OBD2 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 manages segmentation, flow control, and reassembly of these larger messages. For more details, refer to our UDS introduction.

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 communication.

Image illustrating ISO 15765-2 ISO-TP OBD2 frame types, showing Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

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

To better grasp OBD2 over CAN, let’s examine a ‘Single Frame’ OBD2 CAN message. Simplified, an OBD2 message includes an identifier, data length (PCI field), and data. The data section is further divided into Mode, parameter ID (PID), and data bytes.

Image breaking down the structure of an OBD2 message, explaining Mode, PID, and Data Bytes within the frame.

OBD2 Request/Response Example

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

An external tool sends a request to the car with CAN ID 0x7DF, containing 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 find the physical value is 50 km/h.

Let’s now explore OBD2 modes and PIDs in detail.

Image demonstrating an OBD2 request and response sequence (7DF request, 7E8 response) for vehicle speed, showing data flow.

Image providing an example of OBD2 PID 0D for vehicle speed, detailing the data interpretation and physical value.

Image outlining the 10 OBD2 service modes or diagnostic services, including current data, freeze frame, and DTC clearing.

The 10 OBD2 Services (Modes)

There are 10 standardized OBD2 diagnostic services, often referred to as modes. Mode 0x01 provides real-time data, while others are used for viewing and clearing diagnostic trouble codes (DTCs) or accessing freeze frame data.

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 2nd byte. In a request, the mode is directly included (e.g., 0x01), whereas in the response, 0x40 is added to the mode value (resulting in 0x41 for a response to mode 0x01).

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, there are Parameter IDs (PIDs).

For example, mode 0x01 contains 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.

One PID is particularly significant:

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, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.

Image again showing the OBD2 protocol request and response frames, emphasizing PID data parameters in communication.

Image of an OBD2 PID overview tool interface, showcasing its functionality for service 01 and PID lookup.

Tip: OBD2 PID Overview Tool

SAE J1979 and ISO 15031-5 appendices contain scaling information for standard OBD2 PIDs, allowing conversion of data to physical values (as described in our CAN bus introduction).

For quick lookup of mode 0x01 PIDs, use our OBD2 PID overview tool. It aids in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

How to Log and Decode OBD2 Data

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

The CANedge allows configuration of custom CAN frames for transmission, enabling OBD2 logging.

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

Image illustrating an OBD2 PID data logger setup, showing the request (7df) and response (7e8) flow in data logging.

Image of a bit-rate validation test for OBD2, indicating successful transmission at 500K.

Image showing OBD2 supported PIDs test responses in asammdf, reviewing responses to ‘Supported PIDs’ requests.

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

As mentioned, ISO 15765-4 details how to determine the bit-rate and IDs used by a vehicle. Test this with CANedge as follows (see CANedge Intro for details):

Send a CAN frame at 500K and check for success (if not, try 250K).
Use the validated bit-rate for subsequent communication.
Send multiple ‘Supported PIDs’ requests and review responses.
Determine 11-bit or 29-bit IDs based on response IDs.
Identify supported PIDs from response data.

We offer plug-and-play configurations for 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 screenshot, multiple responses to a single OBD request are common due to the 0x7DF request ID, which polls all ECUs. Since all OBD2/OBDonEDS ECUs must support service 0x01 PID 0x00, numerous responses to this PID are typical. Subsequent ‘Supported PIDs’ requests receive fewer ECU responses. Notably, the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, potentially reducing bus load by directing future requests specifically to this ECU using ‘Physical Addressing’ CAN ID 0x7E0.

#2: Configure OBD2 PID Requests

Once you’ve identified supported OBD2 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: Filter to record only OBD2 responses if OEM-specific CAN data is also present.

With configuration complete, your device is ready for raw OBD2 data logging!

Image displaying an example list of CANedge OBD2 PID requests, illustrating configuration for data logging.

Image showing OBD2 data decoded and plotted in asammdf, using a CAN bus DBC file for visualization.

#3: DBC Decode 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 resources like Wikipedia). For convenience, we provide a free OBD2 DBC file to simplify DBC decoding in most CAN bus software tools.

Decoding OBD2 data is more complex 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 payload signals.

Instead, signal identification requires CAN ID, OBD2 mode, and OBD2 PID, a form of multiplexing called ‘extended multiplexing‘. This can be implemented in DBC files.

CANedge: OBD2 Data Logger

The CANedge facilitates easy OBD2 data recording to an 8-32 GB SD card. 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 communication uses ISO-TP (ISO 15765-2), as previously mentioned. Most examples so far have been single-frame. Here are multi-frame 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 frame, as shown in the CANedge configuration example.

Multi-frame OBD2 responses require CAN software/API tools supporting ISO-TP, like CANedge MF4 decoders.

Image illustrating an OBD2 multi-frame request message for the Vehicle Identification Number (VIN).

Example 1: OBD2 Vehicle Identification Number (VIN)

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

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

The vehicle responds with a First Frame containing PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is byte 0x01, the Number Of Data Items (NODI), in this case 1 (see ISO 15031-5 / SAE J1979). The remaining 17 bytes constitute the VIN, convertible from HEX to ASCII as discussed in our UDS intro.

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 should respond with data for supported PIDs (omitting unsupported ones), potentially using multiple frames via ISO-TP.

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

The multi-frame response is similar to the VIN example, but includes requested PIDs and their data. PIDs in the example are ordered like the request, common practice but not strictly ISO 15031-5 standard.

Decoding this response via DBC files is complex and not recommended for practical data logging unless your tool specifically supports it. It’s a form of extended multiplexing, complicated by payload position variability and DBC generalization challenges across vehicles with differing supported PIDs. Managing multiple multi-PID requests via DBC alone is very difficult.

Workarounds might involve custom scripts and recording transmit messages, allowing response interpretation based on request messages. However, such approaches 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 in the request. Responding ECU(s) indicate the number of stored DTCs (possibly 0 if none), with each DTC using 2 data bytes. Multi-frame responses are needed for more than 2 DTCs.

The 2-byte DTC value is typically split 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, as shown visually. Decoded DTC values can be looked up in OBD2 DTC lookup tools like repairpal.com.

The example below shows a request to an ECU with 6 stored DTCs.

Image demonstrating OBD2 DTC decoding and interpretation, showing the structure of the 2-byte DTC value.

OBD2 Data Logging – Use Case Examples

OBD2 data from cars and light trucks has diverse applications:

Logging Data from Cars

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

obd2 logger

Real-Time Car Diagnostics

OBD2 interfaces facilitate 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 for predictive maintenance, helping to prevent breakdowns.

predictive maintenance

Vehicle Blackbox Logger

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

can bus blackbox

Have an OBD2 data logging use case? Contact us for a free consultation!

Explore more introductions in our guides section or download the ‘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