Want to demystify your car’s OBD2 port?
This guide provides a comprehensive introduction to On-Board Diagnostics 2 (OBD2) ports, including their function, location, and importance for vehicle diagnostics and data access. We’ll explore the OBD2 connector, OBD2 protocols, and how to utilize Obd2 Ports for various applications.
Discover why this has become a leading resource for understanding OBD2 ports.
You can also explore our introductory video on OBD2 or download the PDF version for offline access.
Decoding OBD2 Ports: What You Need to Know
OBD2 is essentially your vehicle’s internal health monitoring system, and the OBD2 port is the access point to this system. It’s a standardized port that allows mechanics and car owners to retrieve diagnostic trouble codes (DTCs) and real-time data from your vehicle.
Have you ever seen the check engine light illuminate on your dashboard?
That’s your car signaling a potential problem. To understand what’s wrong, a mechanic uses an OBD2 scanner to connect to your car through the OBD2 port, typically a 16-pin connector located near the steering wheel. This connection enables communication between the scanner and your car’s computer system. The scanner sends ‘OBD2 requests’, and the car responds with ‘OBD2 responses’ containing valuable information like speed, engine temperature, fuel levels, and DTCs. This streamlined process significantly speeds up troubleshooting and vehicle maintenance.
Alt text: Malfunction Indicator Light (MIL) or Check Engine Light illuminated on a car dashboard, indicating a potential issue that can be diagnosed using an OBD2 scanner connected to the OBD2 port.
Does Your Car Have an OBD2 Port?
Most likely, yes!
Nearly all modern non-electric vehicles are equipped with OBD2 ports and often utilize the CAN bus communication protocol. However, even if your older car has a 16-pin port, it might not fully support the OBD2 standard. To confirm OBD2 compliance, consider the vehicle’s origin and year of purchase:
Alt text: Chart illustrating OBD2 compliance by region and vehicle type, showing timelines for mandatory OBD2 implementation in the US and EU for cars and trucks.
A Brief History of OBD2 Ports
The concept of OBD2 originated in California, driven by the California Air Resources Board (CARB), who mandated OBD systems in all new cars from 1991 onwards for emission control.
The Society of Automotive Engineers (SAE) further developed the standard, leading to standardized DTCs and the universally adopted OBD connector (SAE J1962), ensuring compatibility across different vehicle manufacturers.
The OBD2 standard adoption unfolded gradually:
- 1996: OBD2 became mandatory in the USA for cars and light trucks.
- 2001: The EU mandated OBD2 for gasoline cars.
- 2003: The EU extended the mandate to include diesel cars (EOBD).
- 2005: OBD2 was required in the US for medium-duty vehicles.
- 2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
- 2010: OBD2 became mandatory for heavy-duty vehicles in the US.
Alt text: Diagram showing OBD2 history timeline, highlighting key milestones in emission control regulations and the evolution of OBD standards, including EOBD and EOBDII.
Alt text: Timeline infographic visually summarizing the history of OBD2, from its origins in emission control to its mandatory implementation across vehicle categories and regions.
Alt text: Graphic depicting the future of OBD3 and remote vehicle diagnostics, showcasing trends like cloud connectivity, IoT integration, and remote emissions testing.
The Future of OBD2 Ports and Vehicle Diagnostics
While OBD2 ports are currently essential, their role is evolving.
Originally designed for emission control and testing, legislated OBD2 faces new challenges and trends. Electric vehicles (EVs), for instance, are not obligated to support OBD2, and most modern EVs indeed lack standard OBD2 implementations. Instead, they often utilize OEM-specific UDS communication, making data retrieval challenging without reverse engineering efforts. However, successful case studies exist for EVs like Tesla, Hyundai/Kia, Nissan, and VW/Skoda, demonstrating reverse-engineered data access methods.
Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging to address limitations in data richness and lower-layer protocols. These advancements aim to improve OBD communication by utilizing the UDS protocol as a base.
In the era of connected cars, manual emission checks via OBD2 ports seem outdated. OBD3 proposes a solution: integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder to cars, enabling wireless transmission of the Vehicle Identification Number (VIN) and DTCs to a central server for automated checks. Devices like the CANedge2 WiFi CAN logger and CANedge3 3G/4G CAN logger already facilitate data transfer via WiFi/cellular networks.
However, while convenient and cost-saving, OBD3 raises privacy concerns related to surveillance.
The automotive industry is also debating the future accessibility of OBD2 ports for third-party data access. Concerns exist about third parties building data-driven economies on OBD2 access, as OBD2 was initially intended for repair shop servicing. Proposals suggest “turning off” OBD2 functionality during driving and centralizing data collection with manufacturers. This move, framed as a security measure against car hacking risks, is viewed by some as a commercial strategy to control automotive big data. Whether this trend will materialize remains to be seen, but it could significantly impact the market for third-party OBD2 services.
Alt text: Illustration depicting the removal of the OBD2 connector from an electric vehicle, symbolizing the trend of EVs moving away from traditional OBD2 standards and towards proprietary diagnostic systems.
Enhance Your Vehicle Expertise with Our CAN Bus Guide
Want to become proficient in CAN bus technology?
Our comprehensive 160+ page PDF guide offers 12 ‘simple intros’ to CAN bus.
Download now
OBD2 Port Standards and Protocols
On-board diagnostics 2 (OBD2) operates as a higher-layer protocol, similar to a language, while CAN bus functions as the communication method, akin to a telephone line. OBD2 shares similarities with other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.
OBD2 standards define specifications for the OBD2 connector, lower-layer protocols, OBD2 parameter IDs (PIDs), and more.
These standards can be categorized within a 7-layer OSI model. Notably, both SAE and ISO standards cover various layers, reflecting OBD standard development in the USA (SAE) and EU (ISO). Many standards are technically equivalent, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.
Alt text: OSI Model diagram comparing OBD2 and CAN Bus in the context of ISO 15765 and ISO 11898 standards, illustrating the layered architecture of automotive communication protocols.
Alt text: OBD2 Connector Pinout diagram for a Type A socket (female), detailing the pin assignments for a Data Link Connector (DLC).
The OBD2 Connector: SAE J1962 Standard
The 16-pin OBD2 connector is your primary interface for accessing vehicle data and is standardized under SAE J1962 / ISO 15031-3.
The illustration shows a Type A OBD2 pin connector, also known as a Data Link Connector (DLC).
Key features of the OBD2 connector:
- Typically located near the steering wheel, although it may be concealed.
- Pin 16 provides battery power, often even when the ignition is off.
- The OBD2 pinout varies depending on the communication protocol used.
- CAN bus is the most prevalent lower-layer protocol, commonly utilizing pins 6 (CAN-H) and 14 (CAN-L).
OBD2 Connector Types: A vs. B
You might encounter both Type A and Type B OBD2 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) and often baud rates (500K for cars, 250K or 500K for heavy-duty vehicles).
Type B connectors feature an interrupted groove in the middle, allowing Type B OBD2 adapter cables to be compatible with both Type A and B sockets, whereas Type A adapters only fit Type A sockets.
Alt text: Diagram illustrating the differences between OBD2 Connector Type A and Type B as per SAE J1962, highlighting variations in voltage (12V vs 24V) and physical groove design for car and truck applications.
Alt text: Visual representation comparing OBD2 and CAN bus within the ISO15765 framework, emphasizing their relationship in automotive diagnostics and communication.
OBD2 Communication and CAN Bus: ISO 15765-4
Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US vehicles, as defined by ISO 15765.
ISO 15765-4 (Diagnostics over CAN or DoCAN) specifies restrictions on the CAN standard (ISO 11898) for diagnostic purposes, focusing on the physical, data link, and network layers:
- CAN bus bit rate: 250K or 500K.
- CAN IDs: 11-bit or 29-bit.
- Specific CAN IDs for OBD requests/responses.
- Diagnostic CAN frame data length: 8 bytes.
- OBD2 adapter cable length: maximum 5 meters.
OBD2 CAN Identifiers: 11-bit and 29-bit
OBD2 communication is based on request/response message exchanges.
Most cars utilize 11-bit CAN IDs for OBD2. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs for data on a requested parameter (ISO 15765-4). ‘Physical Addressing’ requests to specific ECUs (less common) use CAN IDs 0x7E0-0x7E7.
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 frequent response IDs.
Some vehicles, particularly vans and medium/heavy-duty vehicles, may employ extended 29-bit CAN identifiers for OBD2 communication.
The ‘Functional Addressing’ CAN ID in this case is 0x18DB33F1.
Responses use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is sometimes presented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is reserved for ISO 15765-2 in the J1939-71 standard.
Alt text: Diagram illustrating OBD2 protocol request and response frames, detailing the structure of messages and the flow of data exchange for parameter identification (PID) and data retrieval.
Alt text: Comparison diagram contrasting OBD2 and proprietary CAN bus protocols, highlighting the differences in data accessibility and standardization between generic OBD2 diagnostics and OEM-specific vehicle communication.
OBD2 vs. Proprietary CAN Protocols
Vehicle ECUs primarily rely on OEM-specific CAN protocols for internal operations, not OBD2. These proprietary protocols are unique to each vehicle brand, model, and year. Interpreting this OEM-specific data is typically not possible without OEM tools or reverse engineering.
Connecting a CAN bus data logger to the OBD2 port might capture OEM-specific CAN data, often broadcast at high rates (1000-2000 frames/second). However, newer vehicles often employ a ‘gateway’ that restricts OBD2 port access to OBD2 communication only, blocking OEM data.
Think of OBD2 as a supplementary higher-layer protocol coexisting with the OEM-specific protocol.
Bit-Rate and ID Validation
OBD2 can utilize two bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern cars commonly use 500K with 11-bit IDs, but external tools should systematically verify this.
ISO 15765-4 provides a flowchart for a systematic initialization sequence to determine the correct combination. This method leverages the mandatory OBD2 response to a specific request (see OBD2 PID section) and the occurrence of CAN error frames when using an incorrect bit rate.
Newer ISO 15765-4 versions account for vehicles supporting OBD communication via OBDonUDS instead of OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on emission diagnostic service as per ISO 15031-5/SAE J1979) versus WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).
To test for OBDonEDS vs OBDonUDS, tools may send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). OBDonUDS-compliant vehicles must respond to this DID.
OBDonEDS (aka OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars, while WWH-OBD is mainly used in EU trucks/buses.
Alt text: Flowchart illustrating the OBD2 bit-rate and CAN ID validation process according to ISO 15765-4, outlining steps to determine the correct communication parameters for OBD2 diagnostics.
Alt text: Diagram showcasing the five lower-layer OBD2 protocols: CAN (ISO 15765), KWP2000 (ISO14230-4), SAE J1850 (VPW & PWM), and ISO 9141, highlighting the evolution and variety of communication standards used in OBD2 systems.
Five Lower-Layer OBD2 Protocols
While CAN is the dominant lower-layer protocol for OBD2 today (ISO 15765), older vehicles may use other protocols. Understanding these is useful when working with pre-2008 cars. Connector pinouts can sometimes indicate the protocol in use.
- ISO 15765 (CAN bus): Mandatory in US cars since 2008; now widely used.
- ISO14230-4 (KWP2000): Common in 2003+ Asian cars.
- ISO 9141-2: Used in EU, Chrysler, and Asian cars (2000-04).
- SAE J1850 (VPW): Primarily used in older GM vehicles.
- SAE J1850 (PWM): Primarily used in older Ford vehicles.
ISO-TP: Transporting OBD2 Messages (ISO 15765-2)
OBD2 data is transmitted over CAN bus using ISO-TP (ISO 15765-2), a transport protocol that allows for payloads exceeding 8 bytes. This is crucial for OBD2 functions like retrieving VIN or DTCs. ISO 15765-2 handles segmentation, flow control, and reassembly.
For smaller OBD2 data packets (fitting within a single CAN frame), ISO 15765-2 uses ‘Single Frame’ (SF) format. The first data byte (PCI field) indicates the payload length, leaving 7 bytes for OBD2 communication.
Alt text: Diagram illustrating ISO 15765-2 ISO-TP OBD2 frame types, including Single Frame (SF), First Frame (FF), Consecutive Frame (CF), and Flow Control (FC), explaining the different frame formats used for OBD2 message transport.
The OBD2 Diagnostic Message: SAE J1979, ISO 15031-5
A raw ‘Single Frame’ OBD2 CAN message consists of an identifier, data length (PCI field), and data, which is further divided into Mode, parameter ID (PID), and data bytes.
Alt text: Breakdown of the OBD2 message structure, explaining the components like Mode, Parameter ID (PID), Identifier (ID), and data bytes within an OBD2 frame.
OBD2 Request/Response Example
Consider a request/response example for ‘Vehicle Speed’.
An external tool sends a request message (CAN ID 0x7DF) with 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds (CAN ID 0x7E8) with 3 payload bytes, including the speed value in the 4th byte, 0x32 (50 decimal).
Referring to OBD2 PID 0x0D decoding rules, 0x32 corresponds to 50 km/h.
Alt text: Example of an OBD2 request and response sequence for Vehicle Speed, showing CAN IDs 7DF for request and 7E8 for response, and the data bytes for Mode, PID, and speed value.
Alt text: Detailed example of OBD2 PID 0x0D for Vehicle Speed, illustrating the PID value, data bytes, and the conversion to physical units (km/h).
Alt text: Diagram outlining the 10 OBD2 service modes or diagnostic services, including modes for current data, freeze frame data, clearing DTCs, and other diagnostic functions.
The 10 OBD2 Services (Modes)
OBD2 defines 10 diagnostic services (modes). Mode 0x01 provides real-time data, while others handle DTCs and freeze frame data.
Vehicles are not required to support all 10 OBD2 modes and may include OEM-specific modes beyond these standard ones.
In OBD2 messages, the mode is in the 2nd byte. Requests use the mode directly (e.g., 0x01), while responses add 0x40 to the mode value (e.g., 0x41).
OBD2 Parameter IDs (PIDs)
Each OBD2 mode contains Parameter IDs (PIDs).
Mode 0x01, for example, includes ~200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles typically support only a subset of PIDs within each mode.
PID 0x00 in mode 0x01 is crucial. If an emissions-related ECU supports OBD2, 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, …, 0xC0 can be used to check support for subsequent mode 0x01 PIDs.
Alt text: Diagram reiterating the OBD2 protocol request and response frames in the context of Parameter IDs (PIDs), emphasizing the role of PIDs in data requests and the structure of data parameters within OBD2 messages.
Alt text: Screenshot of an OBD2 PID overview tool, showcasing a user interface for exploring and understanding OBD2 Parameter IDs and service 01 data.
Tip: OBD2 PID Overview Tool
SAE J1979 and ISO 15031-5 appendices detail scaling information for standard OBD2 PIDs, enabling conversion of raw data to physical values.
Our OBD2 PID overview tool simplifies looking up mode 0x01 PIDs, constructing request frames, and dynamically decoding responses.
OBD2 PID overview tool
Practical Guide: Logging and Decoding OBD2 Data
This section demonstrates OBD2 data logging using the CANedge CAN bus data logger.
CANedge allows configuration of custom CAN frames for transmission, making it suitable for OBD2 logging.
Connect CANedge to your vehicle’s OBD2 port using an OBD2-DB9 adapter cable.
Alt text: Diagram illustrating an OBD2 PID data logger setup, showing the connection for requesting PIDs using CAN IDs 7DF and 7E8 for OBD2 data logging.
Alt text: Screenshot from asammdf software displaying OBD2 validation PID test responses, showing the data received in response to ‘Supported PIDs’ requests.
Step #1: Bit-rate, IDs & Supported PIDs Validation
ISO 15765-4 outlines how to determine the bit rate and IDs for a vehicle. Use CANedge to test this:
- Send CAN frame at 500K; check success (if not, try 250K).
- Use the validated bit rate for further communication.
- Send ‘Supported PIDs’ requests and analyze responses.
- Determine 11-bit vs. 29-bit IDs from response IDs.
- Identify supported PIDs from response data.
Pre-configured settings are available for these tests.
Most post-2008 non-EV cars support 40-80 PIDs via 500K bit rate, 11-bit CAN IDs, and OBD2/OBDonEDS protocol.
As shown in the asammdf GUI, multiple responses to a single OBD request are common due to the 0x7DF request ID polling all ECUs. All OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, leading to numerous responses to this PID. Fewer ECUs respond to subsequent ‘Supported PIDs’ requests. The ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, allowing for reduced bus load by specifically querying only this ECU using ‘Physical Addressing’ CAN ID 0x7E0 for subsequent communication.
Step #2: Configure OBD2 PID Requests
After identifying supported PIDs, bit rate, and CAN IDs, configure your transmit list with desired PIDs.
Considerations:
- CAN IDs: Use ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses.
- Spacing: Add 300-500 ms delay between requests to prevent ECU overload.
- Battery drain: Use triggers to stop transmission when the vehicle is inactive.
- Filters: Filter for OBD2 responses if OEM-specific CAN data is also present.
CANedge is now configured to log raw OBD2 data.
Alt text: Example of a CANedge OBD2 PID request transmit list, showing configured PIDs and request parameters for OBD2 data logging.
Alt text: Visual plot of decoded OBD2 data in asammdf, using a CAN bus DBC file, demonstrating data visualization and analysis capabilities.
Step #3: DBC Decode Raw OBD2 Data
To analyze and visualize logged data, decode raw OBD2 data into physical values.
Decoding information is in ISO 15031-5/SAE J1979 and online resources. A free OBD2 DBC file is available for DBC decoding in CAN bus software tools.
OBD2 data decoding is more complex than regular CAN signals because different PIDs share the same CAN ID (e.g., 0x7E8). CAN ID alone is insufficient to identify signals.
Signal identification requires CAN ID, OBD2 mode, and PID. This is ‘extended multiplexing,’ implemented in DBC files.
CANedge: Your OBD2 Data Logger
The CANedge easily logs OBD2 data to an 8-32 GB SD card. Connect to a vehicle to start logging and decode data using free software/APIs and our OBD2 DBC file.
OBD2 logger intro CANedge
OBD2 Multi-Frame Examples (ISO-TP)
OBD2 data uses ISO-TP (ISO 15765-2), including multi-frame communication. Multi-frame OBD2 requires flow control frames. A static flow control frame can be transmitted ~50 ms after the initial request.
Multi-frame OBD2 responses need CAN software/API tools supporting ISO-TP, like CANedge MF4 decoders.
Alt text: Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN), illustrating the structure of a multi-frame request in OBD2 communication.
Example 1: OBD2 Vehicle Identification Number (VIN)
VIN retrieval is important for telematics and diagnostics. Use mode 0x09 and PID 0x02 to request VIN via OBD2:
The tester tool sends a Single Frame request with PCI (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). Byte 0x01 (Number Of Data Items – NODI) follows the PID. The remaining 17 bytes are the VIN, convertible from HEX to ASCII.
Example 2: OBD2 Multi-PID Request (6x)
Tools can request up to 6 mode 0x01 PIDs in one request frame. The ECU responds with data for supported PIDs, possibly across multiple frames via ISO-TP.
While efficient, this method complicates signal encoding and generic DBC file use. It’s generally not recommended.
The multi-frame response is similar to VIN retrieval but includes requested PIDs and their data. PIDs are often ordered as requested.
DBC decoding is complex for this method, making generic DBC files unsuitable. Custom scripts and recording request messages might help, but scalability is challenging.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs)
Mode 0x03 (‘Show stored Diagnostic Trouble Codes’) retrieves emissions-related DTCs. No PID is in the request. ECUs respond with the number of stored DTCs (possibly 0), each DTC being 2 bytes. Multi-frame responses are needed for more than 2 DTCs.
The 2-byte DTC value is categorized and includes a 4-digit hexadecimal code. Decoded DTCs can be looked up using OBD2 DTC lookup tools.
Example: Request to an ECU with 6 DTCs stored.
Alt text: OBD2 DTC (Diagnostic Trouble Code) DBC interpretation example, showing how DTC codes are structured and decoded within the OBD2 protocol.
OBD2 Data Logging: Use Case Examples
OBD2 data from cars and light trucks has diverse applications:
Alt text: OBD2 data logger in a car, illustrating the use of OBD2 data logging for on-board diagnostics and vehicle monitoring.
Car Data Logging
OBD2 data can reduce fuel costs, improve driving habits, test prototype parts, and inform insurance models.
obd2 logger
Alt text: OBD2 real-time streaming diagnostics setup, showing data streaming via USB for real-time vehicle diagnostics and analysis.
Real-Time Car Diagnostics
OBD2 interfaces enable real-time streaming of human-readable data for diagnosing vehicle issues.
obd2 streaming
Alt text: OBD2 data logger for predictive maintenance, depicting the use of OBD2 data in IoT systems for predictive vehicle maintenance and breakdown prevention.
Predictive Maintenance
IoT OBD2 loggers monitor vehicles in the cloud to predict and prevent breakdowns.
predictive maintenance
Alt text: Black box CAN logger for insurance and warranty purposes, illustrating the use of CAN bus data loggers as black boxes in vehicles for data recording and analysis.
Vehicle Black Box Logger
OBD2 loggers serve as ‘black boxes’ for vehicles, providing data for disputes or diagnostics.
can bus blackbox
Have an OBD2 data logging application? Contact us for expert consultation!
Contact us
Explore our guides section or download the ‘Ultimate Guide’ PDF for more introductions.
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
[
