Understanding the OBD2 16 Pin Connector: Your Car's Diagnostic Port

Need a clear and practical introduction to the Obd2 16 pin connector?

This guide provides a comprehensive overview of the OBD2 system, focusing specifically on the 16 pin connector. We’ll explore its function, pinout, and its crucial role in modern vehicle diagnostics.

Whether you’re a car enthusiast, a seasoned mechanic, or just curious about that mysterious port in your car, this article will equip you with the knowledge you need.

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

What is the OBD2 16 Pin Connector?

The OBD2 (On-Board Diagnostics II) system is a standardized system in vehicles that allows access to vehicle subsystem information for diagnostics and monitoring. A key component of this system is the OBD2 16 pin connector, also known as the Diagnostic Link Connector (DLC). This connector is the gateway to your vehicle’s computer, providing access to a wealth of data related to engine performance, emissions, and overall vehicle health.

You’ve likely encountered the OBD2 system without realizing it. The check engine light, or malfunction indicator light (MIL), on your dashboard? That’s often a result of the OBD2 system detecting an issue. When you take your car to a mechanic for a diagnostic check, the first thing they usually do is connect an OBD2 scanner to this 16 pin connector.

Located typically under the dashboard on the driver’s side, the OBD2 16 pin connector allows diagnostic tools to communicate with the vehicle’s electronic control units (ECUs). Through this connector, mechanics and car owners can retrieve diagnostic trouble codes (DTCs), monitor real-time data parameters like speed and engine temperature, and gain insights into vehicle performance.

Image showing a malfunction indicator light and an OBD2 scan tool connected to a car, illustrating the use of OBD2 for diagnostics.

Is My Car Equipped with an OBD2 16 Pin Connector?

The answer is almost certainly yes, especially if you own a vehicle manufactured in recent decades.

OBD2 became mandatory in the United States for all cars and light trucks in 1996. Europe followed suit, making it mandatory for gasoline cars in 2001 and diesel cars in 2004 (EOBD). While older vehicles might have diagnostic ports, they may not adhere to the OBD2 standard. Even if you find a 16 pin connector, it’s not guaranteed to be OBD2 compliant.

To quickly determine if your car should have an OBD2 compliant 16 pin connector, consider the following guidelines based on the vehicle’s purchase location and year:

Does My Car Have OBD2?
Image showing a chart indicating OBD2 compliance by region and vehicle type, helping users quickly assess if their car is OBD2 compliant.

A Brief History of OBD2 and the 16 Pin Connector

The story of OBD2 begins in California. The California Air Resources Board (CARB) mandated OBD in all new cars from 1991 onwards to monitor emissions. This initial OBD system was the precursor to OBD2.

The Society of Automotive Engineers (SAE) played a crucial role in standardizing the system. They recommended the OBD2 standard, which included standardized DTCs and, importantly, a standardized OBD2 16 pin connector across different manufacturers. This standardization was formalized in SAE J1962, which specifically defines the physical connector.

The adoption of OBD2 and the 16 pin connector was phased in globally:

1996: OBD2 mandated in the USA for cars and light trucks.
2001: OBD2 required in the EU for gasoline vehicles.
2004: OBD2 (EOBD) required in the EU for diesel vehicles as well.
2005: OBD2 mandated 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 required for heavy-duty vehicles in the US.

Image depicting the historical timeline of OBD2 adoption, emphasizing its origins in emission control and its evolution over time.

Image showing a visual timeline summarizing the key milestones in OBD2 history and its global implementation.

Image illustrating the future trends of OBD, hinting at OBD3 and remote diagnostics, indicating the ongoing evolution of vehicle diagnostics.

The Future of OBD2 and Diagnostic Connectors

While OBD2 remains the standard for vehicle diagnostics, the automotive landscape is evolving. Electric vehicles (EVs), for instance, are not legally obliged to support OBD2, and many do not implement standard OBD2 protocols. Instead, they often use manufacturer-specific UDS communication, making it harder to access diagnostic data without specialized tools or reverse-engineered protocols.

However, for traditional combustion engine vehicles, OBD2 and the 16 pin connector are expected to remain relevant for the foreseeable future. Developments like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) aim to improve OBD communication by using the UDS protocol as a base, suggesting an evolution rather than a replacement of the existing system.

The concept of OBD3, which envisions adding telematics to vehicles for remote emissions monitoring, also indicates the enduring relevance of vehicle diagnostic data. While potentially facing political and privacy challenges, OBD3 reflects the increasing desire for real-time vehicle health monitoring.

Despite discussions in the automotive industry about potentially restricting third-party access to vehicle data via the OBD2 port for commercial and security reasons, the OBD2 16 pin connector remains a critical interface for vehicle diagnostics, repair, and data access for a wide range of applications.

Image depicting an OBD2 connector being removed from an electric vehicle, symbolizing the changing landscape of vehicle diagnostics in the EV era.

Deep Dive into the OBD2 16 Pin Connector

The OBD2 16 pin connector is more than just a physical interface; it’s a standardized gateway to your vehicle’s internal network. Understanding its pinout and the standards it adheres to is crucial for anyone working with vehicle diagnostics.

Get our ‘Ultimate CAN Guide’

Want to become a CAN bus expert?

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

Download now

CAN Bus – The Ultimate Guide Tutorial PDF

OBD2 Standards and the Connector

OBD2 operates as a higher-layer protocol on top of communication methods like CAN bus. Think of OBD2 as the language and CAN bus as the communication channel. The standards defining OBD2 encompass various aspects, including the OBD2 connector, communication protocols, and parameter IDs (PIDs).

These standards are often described using the 7-layer OSI model. Both SAE (US standards) and ISO (International standards) contribute to OBD2 specifications. Notably, SAE J1979 and ISO 15031-5 are nearly equivalent standards for diagnostic services, and SAE J1962 and ISO 15031-3 similarly align in defining the OBD2 16 pin connector.

Image illustrating the relationship between OBD2 and CAN bus within the OSI model, clarifying their roles in vehicle communication.

Image of an OBD2 connector pinout diagram, visually detailing the function of each pin in the 16-pin connector.

SAE J1962: The OBD2 Connector Standard

The OBD2 16 pin connector is formally specified in the SAE J1962 standard (and ISO 15031-3). This standard ensures interoperability of diagnostic tools across different vehicle makes and models. The connector is typically a female, 16-pin, Type A connector (DLC).

Key features of the OBD2 16 pin connector include:

Location: Usually located within reach of the driver, often under the dashboard, though sometimes hidden behind a panel.
Pin 16: Provides battery power (12V in Type A), even when the ignition is off, to power diagnostic tools.
Pinout Variability: The function of other pins depends on the communication protocol used by the vehicle.
CAN Bus Connection: In vehicles using CAN bus (the most common protocol since 2008), pins 6 (CAN High) and 14 (CAN Low) are crucial for communication.

OBD2 Connector Types: Type A vs. Type B

While Type A is standard in cars and light vehicles, Type B OBD2 16 pin connectors exist, primarily in medium and heavy-duty vehicles.

The main differences between Type A and Type B connectors are:

Power Supply: Type A provides 12V, while Type B provides 24V, reflecting the different electrical systems in cars versus larger vehicles.
Baud Rate: Cars (Type A) commonly use 500K baud rate for CAN communication, while heavy-duty vehicles (Type B) often use 250K (though 500K support is increasing).
Physical Keying: Type B connectors have an interrupted groove, making a Type B adapter compatible with both Type A and Type B sockets, but a Type A adapter only compatible with Type A.

Image comparing Type A and Type B OBD2 connectors, highlighting the differences in pin configuration and application for cars and trucks.

Image visually representing the relationship between OBD2 and CAN bus, reinforcing CAN bus as the primary communication protocol for OBD2.

OBD2 Communication over CAN Bus (ISO 15765-4)

Since 2008, CAN bus, as defined by ISO 15765, has become the mandatory lower-layer protocol for OBD2 in US vehicles. ISO 15765-4 (Diagnostics over CAN, or DoCAN) specifies how OBD2 communication is implemented over CAN.

Key aspects of OBD2 over CAN (and thus relevant to the OBD2 16 pin connector usage) include:

CAN Bit-rate: Standardized at 250K or 500K.
CAN Identifiers: Supports both 11-bit and 29-bit CAN IDs.
Specific CAN IDs: Defined for OBD2 requests and responses.
Data Length: Diagnostic CAN frames are typically 8 bytes in length.
Cable Length: OBD2 adapter cables should be a maximum of 5 meters to ensure signal integrity.

CAN Identifiers for OBD2 Communication

OBD2 communication relies on request and response messages transmitted over the CAN bus via the OBD2 16 pin connector.

For 11-bit CAN IDs (common in most cars):

Functional Addressing Request ID: 0x7DF (used to query all OBD2-compliant ECUs).
Physical Addressing Request IDs: 0x7E0 – 0x7E7 (for targeting specific ECUs, less common).
Response IDs: 0x7E8 – 0x7EF (ECUs respond within this range, with 0x7E8 often from the Engine Control Module – ECM).

For 29-bit CAN IDs (sometimes used in vans, trucks, etc.):

Functional Addressing CAN ID: 0x18DB33F1.
Response IDs: 0x18DAF100 to 0x18DAF1FF (e.g., 0x18DAF110, 0x18DAF11E). Response ID sometimes shown in J1939 PGN format as PGN 0xDA00 (55808).

Image illustrating the request-response message flow in OBD2 communication, highlighting the role of PIDs and data parameters.

OBD2 OBD CAN bus Identifiers 7DF 7E8 7E0

Image contrasting OBD2 CAN bus data with proprietary OEM-specific CAN bus data, emphasizing the difference in standardization and accessibility.

OBD2 vs. OEM-Specific CAN Protocols

It’s important to understand that OBD2 is an additional protocol layered on top of the vehicle’s core communication network. Vehicle ECUs primarily use proprietary CAN protocols defined by the manufacturer for their internal operations. OBD2 is designed for standardized diagnostics and emissions monitoring, accessible through the OBD2 16 pin connector.

Connecting a CAN bus data logger to the OBD2 16 pin connector might reveal OEM-specific CAN data alongside OBD2 data, but interpreting the OEM data typically requires reverse engineering due to its proprietary nature. In newer vehicles, gateways may restrict access to OEM data through the OBD2 port, allowing only OBD2 communication.

Bit-rate and ID Validation for OBD2 Connection

To establish proper communication via the OBD2 16 pin connector, diagnostic tools need to determine the correct CAN bit-rate (250K or 500K) and CAN ID length (11-bit or 29-bit). This leads to four possible combinations. Modern cars commonly use 500K and 11-bit IDs, but automatic detection is essential for universal compatibility.

ISO 15765-4 provides a standardized initialization sequence to automatically detect the correct communication parameters. This process involves sending specific OBD2 requests and checking for valid responses, while also considering potential CAN error frames caused by incorrect bit-rate settings.

Image illustrating a flowchart of the OBD2 bit-rate and CAN ID validation process, outlining the steps for automatic protocol detection.

Image showing the five lower-layer protocols used for OBD2, including CAN (ISO 15765) and older protocols, highlighting the evolution of OBD2 communication.

Beyond CAN: Other OBD2 Protocols

While CAN bus is dominant, especially through the OBD2 16 pin connector in modern vehicles, older OBD2 implementations used other lower-layer protocols. Knowing these can be helpful when working with older cars:

ISO 15765 (CAN bus): Predominant since 2008.
ISO14230-4 (KWP2000): Common in 2003+ Asian vehicles.
ISO 9141-2: Used in EU, Chrysler, and Asian cars (2000-2004).
SAE J1850 (VPW & PWM): Used primarily in older GM and Ford vehicles, respectively. Pinouts on the OBD2 16 pin connector can sometimes indicate the protocol in older vehicles.

ISO-TP (ISO 15765-2) for OBD2 Messaging

OBD2 messages, especially those exceeding 8 bytes (like VIN or DTC requests), are transmitted over CAN using ISO-TP (ISO 15765-2), a transport protocol. ISO-TP handles segmentation, flow control, and reassembly of larger messages.

For shorter OBD2 messages that fit within a single CAN frame, ISO-TP uses ‘Single Frame’ (SF) formatting, where the first byte indicates payload length, leaving 7 bytes for OBD2 data.

Image illustrating different ISO-TP frame types used in OBD2 communication, including Single Frame and multi-frame messages.

Decoding OBD2 Diagnostic Messages

Understanding the structure of OBD2 messages is key to interpreting vehicle data accessed through the OBD2 16 pin connector. A simplified OBD2 message consists of:

Identifier (CAN ID)
Data Length (PCI field)
Data: Further broken down into:
- Mode (Service)
- Parameter ID (PID)
- Data Bytes (Value)

Image breaking down the structure of an OBD2 message, explaining the roles of Mode, PID, and data bytes within the CAN frame.

Example: Requesting Vehicle Speed via OBD2

Consider a request for vehicle speed. A diagnostic tool sends a request message via the OBD2 16 pin connector:

CAN ID: 0x7DF
Payload: Mode 0x01, PID 0x0D (for Vehicle Speed)

The vehicle responds:

CAN ID: 0x7E8
Payload: Mode 0x41 (0x01 + 0x40), data bytes including speed value (e.g., 0x32, which is 50 km/h).

Image demonstrating a request-response example for vehicle speed, showing the CAN IDs and payload data for both request and response messages.

Image specifically detailing the OBD2 PID 0x0D for vehicle speed, showing the data encoding and conversion to physical units.

OBD2 Services (Modes) and Parameter IDs (PIDs)

OBD2 defines 10 diagnostic services or modes. Mode 0x01 provides real-time data, while others handle DTCs, freeze frame data, and more. Vehicles don’t need to support all modes, and OEM-specific modes can exist beyond the standard ten.

In OBD2 messages, the mode is the second byte. Responses typically add 0x40 to the requested mode value (e.g., request mode 0x01, response mode 0x41).

Image listing the 10 standardized OBD2 service modes, providing a brief description of each mode’s function.

Each OBD2 mode contains Parameter IDs (PIDs). Mode 0x01, for example, has around 200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles usually support only a subset of these PIDs.

A crucial PID is Mode 0x01 PID 0x00. All emissions-related ECUs supporting OBD2 must support this PID. Responding to PID 0x00 indicates support for PIDs 0x01-0x20. PIDs 0x20, 0x40, etc., similarly indicate support for subsequent PID ranges. This makes PID 0x00 a fundamental OBD2 compatibility check.

Image repeated for context, again showing the request-response flow and the role of PIDs in requesting specific parameters.

OBD2 PID overview tool
Image showcasing an OBD2 PID overview tool, suggesting resources for users to explore available PIDs and their functionalities.

OBD2 PID Overview Tools

SAE J1979 and ISO 15031-5 appendices detail scaling information for standard OBD2 PIDs, allowing conversion of raw data to physical values. Online OBD2 PID tools can assist in constructing request frames and decoding responses.

OBD2 PID overview tool

Practical OBD2 Data Logging and Decoding

Logging OBD2 data through the OBD2 16 pin connector is straightforward with tools like the CANedge CAN bus data logger. CANedge allows configuration of custom CAN frames for OBD2 requests. Connecting it to the OBD2 16 pin connector via an OBD2-DB9 adapter cable enables data logging.

Image depicting an OBD2 data logger setup, showing the connection to the OBD2 port and the flow of data logging for PID requests.

OBD2 bit rate test
Image showing a bit-rate validation test for OBD2 communication, highlighting the importance of verifying communication parameters.

OBD2 Supported PIDs Test
Image of asammdf software displaying OBD2 PID test responses, demonstrating software tools for analyzing and validating OBD2 data.

Review supported PIDs via OBD2 lookup tool

Steps for OBD2 Data Logging

Test Bit-rate, IDs, and Supported PIDs: Use the ISO 15765-4 initialization sequence to determine the correct bit-rate and CAN IDs. Send ‘Supported PIDs’ requests (Mode 0x01 PID 0x00) to identify supported PIDs.
Configure OBD2 PID Requests: Create a transmit list with desired PIDs. Consider using ‘Physical Addressing’ (e.g., CAN ID 0x7E0) to target specific ECUs and reduce bus load. Add spacing (300-500ms) between requests. Implement triggers to prevent battery drain when the vehicle is off. Use filters to record only relevant OBD2 responses.
DBC Decode Raw OBD2 Data: Use a DBC file (like the free OBD2 DBC available) and CAN bus software (e.g., asammdf) to decode raw OBD2 data into physical values. OBD2 decoding requires considering CAN ID, OBD2 mode, and PID due to extended multiplexing.

obd2-transmit-list-example-canedge
Image showing an example transmit list for OBD2 PID requests in CANedge configuration, demonstrating practical setup for data logging.

OBD2 data decoded visual plot asammdf CAN bus DBC file
Image of asammdf software displaying decoded and visualized OBD2 data, demonstrating data analysis and interpretation using DBC files.

CANedge: A Dedicated OBD2 Data Logger

The CANedge is designed for easy OBD2 data recording via the OBD2 16 pin connector. It logs data to an SD card and offers free software and APIs for data analysis using the OBD2 DBC file.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Communication Examples (ISO-TP)

For messages exceeding a single CAN frame, OBD2 uses multi-frame communication via ISO-TP. This involves flow control frames. Tools and software supporting ISO-TP, like CANedge MF4 decoders, are needed for handling multi-frame OBD2 responses.

OBD2-multi-frame-request-message-vehicle-identification-number
Image showing an example of an OBD2 multi-frame request message for VIN retrieval, demonstrating multi-frame communication in OBD2.

Example 1: Retrieving Vehicle Identification Number (VIN)

VIN retrieval uses OBD2 mode 0x09 and PID 0x02. It typically involves multi-frame responses because the VIN is longer than 7 data bytes.

VIN Vehicle Identification Number OBD2 Example multi-frame

Example 2: Multi-PID Requests (Not Recommended)

While OBD2 allows requesting up to 6 PIDs in a single request, this method is complex for decoding and not generally recommended for practical data logging due to difficulties in using generic DBC files.

Requesting multiple PIDs in one request

Example 3: Diagnostic Trouble Codes (DTCs)

Requesting DTCs (mode 0x03) often involves multi-frame responses if multiple DTCs are stored. DTCs are 2-byte codes, and multi-frame responses are needed when more than 2 DTCs are present. DTC values can be decoded using OBD2 DTC lookup tools.

Image explaining the structure and decoding process of OBD2 DTCs, showing how 2-byte DTC values are interpreted.

OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response Example

Real-World Applications of OBD2 Data Logging

OBD2 data, accessed via the OBD2 16 pin connector, has numerous applications:

Image representing OBD2 data logging in a car, symbolizing various applications like fuel efficiency monitoring and driver behavior analysis.

Car Data Logging

OBD2 data can be used for fuel efficiency analysis, driving behavior improvement, prototype testing, and insurance telematics.

obd2 logger

Image depicting real-time OBD2 data streaming, representing applications like live vehicle diagnostics and performance monitoring.

Real-time Car Diagnostics

OBD2 interfaces enable real-time streaming of vehicle data for diagnosing issues and monitoring performance.

obd2 streaming

Image illustrating predictive maintenance using OBD2 data and IoT, representing applications like remote vehicle health monitoring and breakdown prediction.

Predictive Maintenance

IoT-enabled OBD2 loggers can monitor vehicles in the cloud for predictive maintenance and breakdown prevention.

predictive maintenance

Image symbolizing a black box CAN logger, representing applications like accident data recording and vehicle event logging for insurance and warranty purposes.

Vehicle Black Box

OBD2 loggers can act as vehicle ‘black boxes’ for accident analysis, dispute resolution, and diagnostics.

can bus blackbox

Have an OBD2 data logging application? Contact us for expert advice!

Explore our guides for more introductions, or download the ‘Ultimate Guide’ PDF.

Ready 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

Understanding the OBD2 16 Pin Connector: Your Car’s Diagnostic Port

In this article