The On-Board Diagnostic system, or OBD2, has revolutionized vehicle maintenance and repair. At the heart of this system is the Obd2 Scanner Connector, a standardized interface that provides access to your vehicle’s health data. This guide provides a deep dive into the OBD2 connector, its function, and how it serves as the gateway for automotive diagnostics using OBD2 scanners.
Whether you’re a seasoned mechanic or a car owner looking to understand your vehicle better, mastering the OBD2 scanner connector is crucial. Let’s explore everything you need to know about this essential component of modern automotive technology.
In this article
Author: Martin Falch (updated January 2025)
Download as PDF
What is the OBD2 Connector?
The OBD2 connector, formally known as the SAE J1962 connector, is a 16-pin Diagnostic Link Connector (DLC) standardized across most modern vehicles. It serves as the physical interface point for accessing your car’s On-Board Diagnostic system. This connector is where you plug in an OBD2 scanner to communicate with your vehicle’s computer and retrieve valuable diagnostic information.
Think of the malfunction indicator light (MIL), often called the “check engine light,” on your dashboard. When this light illuminates, it signals an issue detected by your car’s self-diagnostic system. To understand the problem, mechanics and car enthusiasts use an OBD2 scanner connector to interface with the vehicle’s system. By connecting an OBD2 reader to the OBD2 16 pin connector, typically found near the steering wheel, users can send ‘OBD2 requests’ and receive ‘OBD2 responses’. These responses can include critical data like speed, fuel level, and Diagnostic Trouble Codes (DTCs), allowing for efficient troubleshooting.
Understanding the OBD2 system and malfunction indicator light, highlighting the role of the OBD2 scanner connector in diagnostics.
OBD2 Connector Compatibility: Does Your Car Have One?
The good news is that if you own a relatively recent non-electric car, it almost certainly has an OBD2 connector. While the presence of a 16-pin connector is a strong indicator, it’s not a guarantee of OBD2 compliance, especially in older models. Some older vehicles may feature a 16-pin connector that doesn’t fully support the OBD2 protocol. To confirm OBD2 compliance, consider the vehicle’s origin and year of purchase:
Timeline for OBD2 adoption in different regions, helping users determine if their car is likely to have an OBD2 scanner connector.
A Brief History of the OBD2 Connector Standard
The OBD2 standard, including the OBD2 scanner connector, has its roots in California. The California Air Resources Board (CARB) mandated OBD systems in new cars from 1991 onwards for emissions monitoring.
The Society of Automotive Engineers (SAE) played a key role in standardizing OBD2, particularly the DTCs and the OBD connector, documented under SAE J1962.
The OBD2 implementation timeline expanded globally:
- 1996: OBD2 became mandatory in the USA for cars and light trucks.
- 2001: The EU required OBD2 for gasoline cars.
- 2003: OBD2 (EOBD) became mandatory for diesel cars in the EU.
- 2005: OBD2 was required in the US for medium-duty vehicles.
- 2008: US vehicles were mandated to use ISO 15765-4 (CAN) as the foundation for OBD2 communication through the OBD2 scanner connector.
- 2010: OBD2 requirements extended to heavy-duty vehicles in the US.
Visual representation of OBD2 history and its relation to emission control, emphasizing the standardization of the OBD2 scanner connector.
Timeline overview of OBD2 history, reinforcing the importance of the OBD2 scanner connector as a consistent interface over time.
Future trends in OBD technology, hinting at the evolution of the OBD2 scanner connector and data access.
The Future of OBD2 and the Scanner Connector
While OBD2 is firmly established, its future is evolving. Originally designed for emissions control, its role is shifting in the era of electric vehicles and connected cars. Electric vehicles, focused less on traditional emissions, often don’t fully support standard OBD2 protocols via the OBD2 scanner connector. Many EVs utilize OEM-specific UDS communication, making standard OBD2 scanners less effective unless decoding rules are reverse-engineered.
Modern alternatives like WWH-OBD and OBDonUDS are emerging to enhance OBD communication, using the UDS protocol as a base. These aim to address limitations in data richness and communication protocols within the traditional OBD2 framework accessed through the OBD2 scanner connector.
The concept of OBD3 introduces telematics for remote diagnostics. Imagine vehicles equipped with radio transponders that could transmit VIN and DTCs wirelessly for centralized monitoring. While convenient, this raises privacy concerns.
The automotive industry is also debating control over vehicle data accessed via the OBD2 scanner connector. Proposals to limit third-party access to OBD2 data while driving are being considered, with manufacturers potentially seeking to centralize data collection. This could impact the aftermarket OBD2 service and tool industry significantly.
Illustration of challenges and future directions for OBD2 in electric vehicles, highlighting potential changes in access through the OBD2 scanner connector.
Enhance Your Vehicle Expertise with Our ‘Ultimate CAN Guide’
Want to become a CAN bus expert?
Our comprehensive 160+ page PDF guide provides 12 simple introductions to CAN bus technology.
Download now
OBD2 Standards and the Connector
OBD2 operates as a higher-layer protocol, much like a language, while CAN bus is the communication method, like a telephone line. The OBD2 scanner connector and related standards are specified in documents like SAE J1962 and ISO 15031-3. These standards define the connector itself, lower-layer protocols, OBD2 parameter IDs (PIDs), and more.
The OBD2 standards can be understood in the context of the 7-layer OSI model. Interestingly, both SAE and ISO standards cover various layers, reflecting US (SAE) and EU (ISO) standardization efforts. Many of these standards are technically very similar, such as SAE J1979 and ISO 15031-5 for diagnostics, and SAE J1962 and ISO 15031-3 for the OBD2 connector.
OSI model illustrating the relationship between OBD2 and CAN bus standards, showing where the OBD2 scanner connector fits within the communication layers.
Image of an OBD2 connector pinout, visually detailing the interface that OBD2 scanners use to connect to vehicles.
The OBD2 Connector [SAE J1962 / ISO 15031-3] in Detail
The 16-pin OBD2 connector is your direct access point to vehicle data, standardized under SAE J1962 and ISO 15031-3. The illustration above shows a Type A OBD2 pin connector, often referred to as the Data Link Connector (DLC).
Key points about the OBD2 scanner connector:
- Location: Typically found near the steering wheel, though its exact placement can be hidden.
- Pin 16: Provides battery power, often even when the ignition is off, to power connected devices like OBD2 scanners.
- Pinout variability: The specific pinout is protocol-dependent, but standardization efforts ensure commonality for diagnostic purposes.
- CAN bus connection: In most modern vehicles, pins 6 (CAN-H) and 14 (CAN-L) are connected for CAN bus communication, the predominant protocol used via the OBD2 scanner connector.
OBD2 Connector Types: A vs. B
You might encounter Type A and Type B OBD2 scanner connectors. Type A is standard in cars, while Type B is more common in medium and heavy-duty vehicles.
While both types share similar pinouts, they differ in power supply outputs: 12V for Type A and 24V for Type B. Baud rates can also vary, with cars typically using 500K and heavy-duty vehicles often using 250K (with increasing support for 500K).
Visually, Type B connectors have an interrupted groove in the middle, distinguishing them from Type A. A Type B OBD2 adapter cable is often compatible with both Type A and B sockets, whereas a Type A adapter might not fit into a Type B socket.
Illustration differentiating OBD2 Connector Type A and Type B, crucial for selecting the correct OBD2 scanner connector adapter.
Diagram showing the relationship between OBD2, CAN bus, and ISO 15765, underpinning the communication facilitated by the OBD2 scanner connector.
OBD2 and CAN Bus [ISO 15765-4] Communication via the Connector
Since 2008, CAN bus has been the mandated lower-layer protocol for OBD2 in US vehicles, as per ISO 15765. ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies how CAN is used for OBD2 through the OBD2 scanner connector. It standardizes the CAN interface for diagnostic equipment, focusing on physical, data link, and network layers:
- Bit-rate: CAN bus must operate at 250K or 500K.
- CAN IDs: Supports both 11-bit and 29-bit CAN identifiers.
- Specific CAN IDs: Defined for OBD requests and responses transmitted through the OBD2 scanner connector.
- Data length: Diagnostic CAN frames are limited to 8 bytes.
- Cable length: The OBD2 adapter cable should be a maximum of 5 meters.
OBD2 CAN Identifiers (11-bit, 29-bit) and the Scanner Connector
OBD2 communication via the OBD2 scanner connector is based on request/response messages. In most cars, 11-bit CAN IDs are used for OBD2. The ‘Functional Addressing’ ID, 0x7DF, queries all OBD2-compatible ECUs. ‘Physical Addressing’ requests, using CAN IDs 0x7E0-0x7E7, target specific ECUs but are less common in standard OBD2 scanning via the OBD2 scanner connector.
ECUs respond with 11-bit IDs in the range 0x7E8-0x7EF. The most frequent response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module).
Some vehicles, particularly vans and medium/heavy-duty vehicles, use extended 29-bit CAN identifiers for OBD2 communication through the OBD2 scanner connector. The ‘Functional Addressing’ CAN ID here is 0x18DB33F1. Responses use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). This response ID is also recognized as J1939 PGN 0xDA00 (55808), reserved for ISO 15765-2 in the J1939-71 standard.
Diagram illustrating OBD2 request and response frames, showing data flow through the OBD2 scanner connector.
Comparison of OBD2 and proprietary CAN bus protocols, highlighting that the OBD2 scanner connector primarily accesses standardized diagnostic data.
OBD2 vs. Proprietary CAN Protocols and the Scanner Connector
It’s important to understand that vehicle ECUs primarily operate using OEM-specific CAN protocols, independent of OBD2. These proprietary protocols are unique to vehicle brands, models, and years. Unless reverse-engineered, this OEM-specific data is generally inaccessible to third parties via the OBD2 scanner connector using standard OBD2 tools.
When you connect a CAN bus data logger or an OBD2 scanner to the OBD2 scanner connector, you might see OEM-specific CAN data, often broadcast at high rates. However, in many newer vehicles, a ‘gateway’ restricts access to this data, allowing only OBD2 communication through the OBD2 scanner connector.
Think of OBD2 as an additional, standardized higher-layer protocol running alongside the OEM-specific protocols. The OBD2 scanner connector is designed to tap into this standardized diagnostic layer.
Bit-rate and ID Validation for OBD2 Scanner Connection
OBD2 communication via the OBD2 scanner connector can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern cars commonly use 500K and 11-bit IDs. Diagnostic tools, including OBD2 scanners, should systematically validate these parameters.
ISO 15765-4 provides initialization sequences to determine the correct combination. This process leverages the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request via the OBD2 scanner connector. Incorrect bit-rate transmissions will cause CAN error frames, aiding in identification.
Newer versions of ISO 15765-4 account for OBDonUDS (OBD on Unified Diagnostic Service) alongside OBDonEDS (OBD on emission diagnostic service). While this article mainly focuses on OBDonEDS (commonly known as OBD2), it’s worth noting WWH-OBD/OBDonUDS, primarily used in EU trucks/buses.
To differentiate between OBDonEDS and OBDonUDS protocols when using an OBD2 scanner connector, advanced tools may send UDS requests for service 0x22 and data identifier (DID) 0xF810. Vehicles supporting OBDonUDS should respond to this DID.
In practice, OBDonEDS is prevalent in most non-EV cars, while WWH-OBD is more common in EU commercial vehicles.
Flowchart illustrating the process of validating bit-rate and CAN ID when establishing communication through the OBD2 scanner connector.
Overview of the five lower-layer OBD2 protocols, highlighting CAN (ISO 15765) as the dominant protocol accessed via the OBD2 scanner connector.
Five Lower-Layer OBD2 Protocols and Connector Pinouts
While CAN (ISO 15765) is now dominant, especially for accessing data through the OBD2 scanner connector in post-2008 vehicles, older cars used other lower-layer protocols. Understanding these is helpful for diagnosing older vehicles:
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used today.
- ISO14230-4 (KWP2000): Common in 2003+ Asian cars.
- ISO 9141-2: Used in EU, Chrysler & Asian cars in 2000-04.
- SAE J1850 (VPW): Primarily in older GM vehicles.
- SAE J1850 (PWM): Mostly in older Ford vehicles.
Connector pinouts can sometimes indicate which protocol is in use, especially in older vehicles. However, for modern diagnostics using an OBD2 scanner connector, CAN bus is the expected protocol.
ISO-TP [ISO 15765-2] for OBD2 Message Transport
OBD2 data is transmitted over CAN bus using 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) through the OBD2 scanner connector. ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages.
Often, OBD2 data fits within a single CAN frame. In such cases, ISO 15765-2 specifies ‘Single Frame’ (SF) usage, where the first data byte indicates payload length, leaving 7 bytes for OBD2 communication via the OBD2 scanner connector.
Illustration of ISO-TP frame types used in OBD2 communication, essential for understanding data transmission via the OBD2 scanner connector.
The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5] and Scanner Interaction
To understand OBD2 on CAN, consider a raw ‘Single Frame’ OBD2 CAN message transmitted via the OBD2 scanner connector. An OBD2 message includes an identifier, data length (PCI field), and data. The data itself is structured into Mode, parameter ID (PID), and data bytes.
Breakdown of an OBD2 message structure, showing how OBD2 scanners request and interpret data through the OBD2 scanner connector.
Example: OBD2 Request/Response via Scanner Connector
Consider an example of requesting ‘Vehicle Speed’ using an OBD2 scanner connector. The external scanner sends a request message with CAN ID 0x7DF and two payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds via CAN ID 0x7E8 with three payload bytes, including the speed value in the fourth byte, 0x32 (50 in decimal).
By consulting OBD2 PID documentation, PID 0x0D is identified as Vehicle Speed, and the value 0x32 translates to 50 km/h. This illustrates the basic request-response mechanism facilitated by the OBD2 scanner connector.
Example of an OBD2 request and response for vehicle speed, demonstrating scanner interaction through the OBD2 scanner connector.
Detailed example of OBD2 PID 0D (Vehicle Speed), explaining data interpretation when using an OBD2 scanner connector.
Overview of the 10 OBD2 service modes, accessible via OBD2 scanners through the OBD2 scanner connector.
The 10 OBD2 Services (Modes) and Scanner Functions
There are 10 standardized OBD2 diagnostic services or modes. Mode 0x01 provides real-time data, while others are used for DTCs, freeze frame data, and more. OBD2 scanners utilize these modes to perform various diagnostic functions via the OBD2 scanner connector.
Vehicles aren’t required to support all OBD2 modes, and OEM-specific modes may exist beyond the standard ten. In OBD2 messages, the mode is in the second byte. In a request, the mode is direct (e.g., 0x01), and in the response, 0x40 is added to the mode value (e.g., 0x41).
OBD2 Parameter IDs (PIDs) Accessed via Scanner Connector
Within each OBD2 mode are Parameter IDs (PIDs). For example, Mode 0x01 contains around 200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles typically support only a subset of these PIDs when accessed through the OBD2 scanner connector.
One PID is particularly important: Mode 0x01 PID 0x00. If an emissions-related ECU supports any OBD2 services, it must support this PID. Responding to PID 0x00, the ECU indicates support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’ for OBD2 scanners connecting via the OBD2 scanner connector. Similarly, PIDs 0x20, 0x40, etc., determine support for subsequent PIDs in Mode 0x01.
Diagram illustrating OBD2 request and response frames with PID data parameters, showing scanner interaction through the OBD2 scanner connector.
Screenshot of an OBD2 PID overview tool, demonstrating resources available for users of OBD2 scanners and connectors.
Tip: OBD2 PID Overview Tool for Scanner Users
SAE J1979 and ISO 15031-5 appendices provide scaling information for standard OBD2 PIDs, enabling data decoding into physical values. Our OBD2 PID overview tool simplifies constructing OBD2 requests and decoding responses, aiding users of OBD2 scanners connected via the OBD2 scanner connector.
OBD2 PID overview tool
Logging and Decoding OBD2 Data from the Scanner Connector
Let’s explore a practical example of logging OBD2 data using a CANedge CAN bus data logger, connected via an OBD2-DB9 adapter cable to the OBD2 scanner connector. The CANedge can be configured to transmit custom CAN frames for OBD2 logging.
Diagram showing an OBD2 data logger requesting PID data through the OBD2 scanner connector.
Screenshot of a bit-rate validation test, demonstrating initial steps in establishing communication via the OBD2 scanner connector.
Screenshot showing responses to ‘Supported PIDs’ requests, illustrating how to verify OBD2 compatibility through the scanner connector.
#1: Testing Bit-rate, IDs & Supported PIDs via Scanner Connector
ISO 15765-4 guidelines help determine the bit-rate and IDs for a specific vehicle. You can test this using a CANedge or similar tool connected to the OBD2 scanner connector:
- Test at 500K bit-rate. If successful, proceed; otherwise, try 250K.
- Use the identified bit-rate for subsequent communication.
- Send ‘Supported PIDs’ requests and review responses.
- Determine 11-bit or 29-bit IDs based on response IDs.
- Identify supported PIDs from response data.
Plug & play configurations are often available to simplify these tests when using tools connected via the OBD2 scanner connector. Most post-2008 non-EV cars support 40-80 PIDs using 500K bit-rate, 11-bit CAN IDs, and OB
