Decoding OBD2 Port Numbers: Your Guide to Understanding the OBD2 Connector

Want to understand Obd2 Port Numbers and the OBD2 connector?

This guide provides a simple, practical introduction to the On-Board Diagnostic (OBD2) protocol, focusing on the OBD2 connector and OBD2 port numbers. We’ll cover everything from the OBD2 pinout to its role in accessing vehicle data and diagnostic trouble codes.

Note: This is a practical introduction to help you understand OBD2 port numbers and how they are used in vehicle diagnostics and data access.

Discover why this is considered a top resource for understanding OBD2 port numbers and the OBD2 system.

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

What is OBD2 and Why are OBD2 Port Numbers Important?

OBD2 is your car’s built-in diagnostic system. It’s a standardized protocol that allows you to retrieve diagnostic trouble codes (DTCs) and real-time data through the OBD2 connector. Understanding OBD2 port numbers is crucial because these pins are the gateway to your vehicle’s health information.

You’ve likely encountered OBD2 without realizing it. That check engine light on your dashboard? That’s your car signaling an issue. Mechanics use an OBD2 scanner to pinpoint the problem by connecting to the OBD2 16 pin connector, usually located near the steering wheel. This tool sends ‘OBD2 requests’ through specific OBD2 port numbers, and the car responds with data like speed, fuel level, or DTCs – speeding up troubleshooting.

Does Your Car Have OBD2 Ports?

Most likely, yes!

Nearly all modern non-electric cars are equipped with OBD2 and often utilize CAN bus communication. However, even if you spot a 16-pin OBD2 connector in older vehicles, it might not fully support OBD2. A key indicator of OBD2 compliance is the car’s purchase location and year:

A Brief History of OBD2 and OBD2 Port Numbers

OBD2 originated in California, driven by the California Air Resources Board (CARB) mandate for OBD systems in all new cars from 1991 onwards for emission control.

The Society of Automotive Engineers (SAE) recommended the OBD2 standard, standardizing DTCs and the OBD connector, including the OBD2 port numbers, across different manufacturers through 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).
2005: OBD2 was required in the US for medium-duty vehicles.
2008: US cars were mandated to use ISO 15765-4 (CAN) as the foundation for OBD2.
2010: OBD2 became mandatory in US heavy-duty vehicles.

The Future of OBD2 and Accessing OBD2 Port Data

OBD2 is expected to remain relevant, but its form is evolving.

Originally designed for emissions control, legislated OBD2 isn’t mandatory for electric vehicles. Consequently, most modern EVs don’t support standard OBD2 requests, opting instead for OEM-specific UDS communication. This often restricts data access from EVs, except when decoding rules are reverse-engineered, as shown in our case studies for electric cars including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Limitations in data richness and lower-layer protocols in current OBD2 implementations have led to modern 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 the era of connected cars, manual OBD2 emission checks seem outdated. OBD3 proposes a solution: telematics integrated into all cars. OBD3 envisions adding a small radio transponder to vehicles, enabling wireless transmission of the vehicle identification number (VIN) and DTCs via WiFi to a central server for automated checks. Devices like the CANedge2 WiFi CAN logger and CANedge3 3G/4G CAN logger already facilitate CAN/OBD2 data transfer via WiFi/cellular. While convenient and cost-saving, OBD3 raises privacy concerns.

OBD2, initially for stationary emission controls, is now widely used by third parties for real-time data via OBD2 dongles, CAN loggers etc. However, the German car industry aims to restrict this:

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 involves disabling OBD2 functionality during driving, centralizing data collection with manufacturers, giving them control over ‘automotive big data’. Security (reducing car hacking risks) is cited as justification, though many perceive it as a commercial strategy https://www.navixy.com/blog/obd-trackers-what-future-awaits/. The future of third-party OBD2 services is uncertain.

Get our ‘Ultimate CAN Guide’

Want to become a CAN bus expert?

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

Download now

OBD2 Standards and OBD2 Port Numbers

On-board diagnostics, OBD2, is a higher layer protocol (like a language). CAN is a communication method (like a phone). OBD2 is similar to other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

OBD2 standards define the OBD2 connector, including OBD2 port numbers, lower-layer protocols, OBD2 parameter IDs (PIDs), and more. These standards can be viewed in a 7-layer OSI model. We’ll focus on the most crucial ones, particularly those related to OBD2 port numbers.

The OSI model shows that SAE and ISO standards cover multiple layers. SAE standards are generally for OBD in the USA, while ISO standards are for the EU. Many standards are technically similar, like SAE J1979 vs. ISO 15031-5 and SAE J1962 vs. ISO 15031-3.

The OBD2 Connector and OBD2 Port Numbers [SAE J1962]

The 16-pin OBD2 connector, specified in SAE J1962 / ISO 15031-3, provides easy access to your car’s data. Understanding the OBD2 port numbers of this connector is essential for anyone working with vehicle diagnostics.

The illustration shows a Type A OBD2 pin connector (Data Link Connector, DLC). Key points about OBD2 port numbers and the connector:

The connector is usually near the steering wheel, but can be hidden.
Pin 16: This OBD2 port number provides battery power (often when the ignition is off).
OBD2 Pinout Variability: The function of other OBD2 port numbers depends on the communication protocol used by the vehicle.
CAN Bus Dominance: CAN bus is the most common lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically active OBD2 port numbers in modern vehicles.

OBD2 Connector Types: Type A vs. Type B and OBD2 Port Number Differences

You’ll find both Type A and Type B OBD2 connectors. Type A is standard in cars, while Type B is common in medium and heavy-duty vehicles.

Both types have similar OBD2 port numbers, but they differ in power supply: Type A provides 12V, and Type B provides 24V. 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. A Type B OBD2 adapter cable is compatible with both Type A and B sockets, but a Type A adapter will not fit a Type B socket. Always check your vehicle’s documentation to identify the correct OBD2 port numbers and connector type.

OBD2 and CAN Bus Communication [ISO 15765-4]

Since 2008, CAN bus is the mandatory lower-layer protocol for OBD2 in US cars, according to ISO 15765. This standard impacts how OBD2 port numbers are utilized for data transmission.

ISO 15765-4 (Diagnostics over CAN or DoCAN) specifies restrictions for the CAN standard (ISO 11898), standardizing the CAN interface for test equipment, focusing on 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/responses through specific OBD2 port numbers.
Diagnostic CAN frame data length: Fixed at 8 bytes.
OBD2 adapter cable: Maximum length of 5 meters.

OBD2 CAN Identifiers (11-bit, 29-bit) and OBD2 Port Communication

OBD2 communication relies on request/response message exchanges through the OBD2 port numbers connected to the CAN bus.

Most cars use 11-bit CAN IDs for OBD2. The ‘Functional Addressing’ ID is 0x7DF, broadcasting requests to all OBD2-compatible ECUs to check for data on the 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 0x7E8-0x7EF. 0x7E8 (ECM, Engine Control Module) and 0x7E9 (TCM, Transmission Control Module) are the most frequent response IDs, transmitted back through the OBD2 port numbers.

Some vehicles, especially vans and medium/heavy-duty vehicles, use extended 29-bit CAN identifiers for OBD2 instead of 11-bit IDs. Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID may also be in ‘J1939 PGN’ format, PGN 0xDA00 (55808), reserved for ISO 15765-2 in J1939-71.

OBD2 vs. Proprietary CAN Protocols and OBD2 Port Access

Your car’s ECUs operate using OEM-specific CAN protocols, not OBD2. These proprietary CAN protocols are unique to vehicle brand, model, and year. Interpreting this data without OEM knowledge or reverse engineering is generally impossible.

Connecting a CAN bus data logger to your car’s OBD2 connector might capture OEM-specific CAN data, often broadcast at 1000-2000 frames/second. However, newer cars often use a ‘gateway’ to block access to this CAN data via the OBD2 connector, allowing only OBD2 communication through the designated OBD2 port numbers.

Think of OBD2 as an ‘extra’ higher-layer protocol alongside the OEM-specific protocol. OBD2 port numbers provide a standardized access point, but the underlying data and protocols can be much more complex.

Bit-rate and ID Validation for OBD2 Port Communication

OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in 4 possible combinations for communication through the OBD2 port numbers. Modern cars commonly use 500K and 11-bit IDs, but external tools should systematically verify this.

ISO 15765-4 outlines a systematic initialization sequence to determine the correct combination, using the fact that OBD2-compliant vehicles must respond to a mandatory OBD2 request (see OBD2 PID section) and that incorrect bit-rates cause CAN error frames.

Newer ISO 15765-4 versions account for OBD communication via OBDonUDS versus 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 differentiate between OBDonEDS and OBDonUDS, test tools can send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). OBDonUDS-supporting vehicles must have ECUs that respond to this DID via the OBD2 port numbers.

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

Five Lower-Layer OBD2 Protocols and OBD2 Port Compatibility

While CAN is now dominant for OBD2 (ISO 15765), older cars (pre-2008) may use other lower-layer protocols. Understanding these is helpful when diagnosing older vehicles and their OBD2 port number configurations. Pinouts can indicate the protocol in use.

ISO 15765 (CAN bus): Mandatory in US cars since 2008, now widely used.
ISO14230-4 (KWP2000): Common in 2003+ cars, especially in Asia.
ISO 9141-2: Used in EU, Chrysler & Asian cars (2000-04).
SAE J1850 (VPW): Primarily in older GM cars.
SAE J1850 (PWM): Mostly in older Ford cars.

Transporting OBD2 Messages via ISO-TP [ISO 15765-2] Through OBD2 Ports

OBD2 data communication on CAN bus uses ISO-TP (ISO 15765-2), a transport protocol, through the OBD2 port numbers. ISO-TP enables transmission of payloads larger than 8 bytes, necessary for OBD2 tasks like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly. See our UDS intro for details.

Often, OBD2 data fits within a single CAN frame. ISO 15765-2 specifies ‘Single Frame’ (SF) usage, where the 1st data byte (PCI field) indicates payload length (excluding padding), leaving 7 bytes for OBD2 communication through the OBD2 port numbers.

The OBD2 Diagnostic Message Structure [SAE J1979, ISO 15031-5] and OBD2 Port Data

To understand OBD2 on CAN, consider a raw ‘Single Frame’ OBD2 CAN message transmitted and received via OBD2 port numbers. A simplified OBD2 message includes an identifier, data length (PCI field), and data. The data is structured into Mode, parameter ID (PID), and data bytes.

Example: OBD2 Request/Response via OBD2 Port Numbers

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

An external tool sends a request to the car via OBD2 port numbers with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds through OBD2 port numbers with CAN ID 0x7E8 and 3 payload bytes, including the Vehicle Speed value in the 4th byte, 0x32 (50 decimal).

Using OBD2 PID 0x0D decoding rules, the physical value is 50 km/h.

Next, we’ll explore OBD2 modes and PIDs.

The 10 OBD2 Services (Modes) and OBD2 Port Functionality

There are 10 OBD2 diagnostic services (modes). Mode 0x01 shows real-time data, while others display/clear diagnostic trouble codes (DTCs) or show freeze frame data, all accessible through OBD2 port numbers.

Vehicles don’t have to support all OBD2 modes and may include OEM-specific modes beyond the 10 standard modes.

In OBD2 messages, the mode is in the 2nd byte. In requests, the mode is direct (e.g., 0x01), while responses add 0x40 to the mode (e.g., 0x41).

OBD2 Parameter IDs (PIDs) and OBD2 Port Data Parameters

Each OBD2 mode contains parameter IDs (PIDs).

For instance, mode 0x01 has ~200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles usually support only a subset of PIDs in each mode, accessible via the OBD2 port numbers.

One PID is particularly important. If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the ECU indicates support for PIDs 0x01-0x20. PID 0x00 serves as a fundamental ‘OBD2 compatibility test’. PIDs 0x20, 0x40, …, 0xC0 determine support for remaining mode 0x01 PIDs.

Tip: OBD2 PID Overview Tool for OBD2 Port Data Analysis

SAE J1979 and ISO 15031-5 appendices provide scaling information for standard OBD2 PIDs, enabling data decoding into physical values (see our CAN bus intro).

Use our OBD2 PID overview tool to look up mode 0x01 PIDs. It helps construct OBD2 request frames and dynamically decode OBD2 responses, aiding in understanding data from your OBD2 port numbers.

OBD2 PID overview tool

How to Log and Decode OBD2 Data from OBD2 Port Numbers

This section demonstrates logging OBD2 data using the CANedge CAN bus data logger connected to your OBD2 port numbers.

The CANedge allows configuration of custom CAN frames for transmission, enabling OBD2 logging. Connect it to your vehicle’s OBD2 port numbers using our OBD2-DB9 adapter cable.

The responses to ‘Supported PIDs’ can be reviewed in asammdf

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

ISO 15765-4 describes determining bit-rate and IDs used by a vehicle’s OBD2 port numbers. Test this with CANedge as follows (see CANedge Intro for details):

Send CAN frame at 500K, check success (else try 250K).
Use the identified bit-rate for further communication through OBD2 port numbers.
Send multiple ‘Supported PIDs’ requests and analyze results.
Determine 11-bit vs. 29-bit based on response IDs.
Identify supported PIDs from response data.

We offer plug & play configs for these tests. Most 2008+ non-EV cars support 40-80 PIDs using 500K bit-rate, 11-bit CAN IDs, and OBD2/OBDonEDS protocol via OBD2 port numbers.

As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common due to using the 0x7DF request ID, polling all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, many responses occur, especially for this PID. Subsequent ‘Supported PIDs’ requests get fewer ECU responses. The ECM ECU (0x7E8) supports all PIDs supported by other ECUs, so busload can be reduced by directing requests only to this ECU using ‘Physical Addressing’ CAN ID 0x7E0 for subsequent communication via OBD2 port numbers.

#2: Configure OBD2 PID Requests for OBD2 Port Logging

After identifying supported OBD2 PIDs and the correct bit-rate and CAN IDs, configure your transmit list with relevant PIDs for logging data from the OBD2 port numbers.

Consider these factors:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses via OBD2 port.
Spacing: Add 300-500 ms between OBD2 requests (excessive ECU polling may cause no response).
Battery drain: Use triggers to stop transmitting when the vehicle is inactive (prevent ECU ‘wake-up’ via OBD2 port numbers).
Filters: Filter to record only OBD2 responses (if vehicle outputs OEM-specific CAN data alongside OBD2 through the OBD2 port).

Once configured, the device is ready to log raw OBD2 data from the OBD2 port numbers!

An example list of CANedge OBD2 PID requests

asammdf lets you DBC decode and visualize OBD2 data

#3: DBC Decode Raw OBD2 Data from OBD2 Port

To analyze/visualize logged data, decode raw OBD2 data into ‘physical values’ (km/h, degC). Decoding information is in ISO 15031-5/SAE J1979 (and Wikipedia). We provide a free OBD2 DBC file for easy DBC decoding of raw OBD2 data in most CAN bus software tools, interpreting data received via OBD2 port numbers.

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

Signal identification requires using the CAN ID, OBD2 mode, and OBD2 PID. This ‘extended multiplexing’ is implementable in DBC files.

CANedge: OBD2 Data Logger for OBD2 Port Data

The CANedge easily records OBD2 data to an 8-32 GB SD card when connected to OBD2 port numbers. Simply connect to a car/truck to start logging and decode data using free software/APIs and our OBD2 DBC.

OBD2 logger intro CANedge

OBD2 Multi-Frame Examples [ISO-TP] and OBD2 Port Communication

OBD2 communication uses ISO-TP (transport protocol) per ISO 15765-2, as seen in data exchanged through OBD2 port numbers. Most examples so far are single-frame communication. 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 frame, as in the CANedge configuration example.

Multi-frame OBD2 responses require CAN software/API tools supporting ISO-TP, like CANedge MF4 decoders for processing data from OBD2 port numbers.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval via OBD2 Port

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, etc. (see our UDS intro). Retrieve VIN using OBD2 mode 0x09 and PID 0x02 via OBD2 port numbers:

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

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

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

External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame through OBD2 port numbers. The ECU responds with data for supported PIDs (excluding unsupported ones), possibly across multiple frames per ISO-TP.

This efficient method allows higher frequency data collection but makes generic OBD2 DBC files less useful due to signal encoding specific to the request method. We advise against this method practically. Below is an example trace:

The multi-frame response resembles the VIN example, but the payload includes requested PIDs and their data. PIDs are often ordered as requested (common but not ISO 15031-5 standard requirement), received through OBD2 port numbers.

Decoding this response via DBC files is challenging. It involves extended multiplexing, with multiple instances throughout the payload. DBC files would need to account for each PID’s specific payload position, making DBC generalization across vehicles with varying supported PIDs difficult. Handling becomes very complex, even impossible via DBC manipulations, if sending multiple multi-PID requests, lacking a method to uniquely identify messages from each other from the OBD2 port.

Workarounds include custom scripts and recording transmit messages, allowing script logic to interpret responses based on requests. However, such approaches are hard to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) via OBD2 Port

Use OBD2 mode 0x03 (‘Show stored Diagnostic Trouble Codes’) to request emissions-related DTCs via OBD2 port numbers. No PID is in the request. Targeted ECU(s) respond with the number of stored DTCs (possibly 0), each DTC being 2 data bytes, requiring multi-frame responses for more than 2 DTCs.

The 2-byte DTC value is split into two parts (ISO 15031-5/ISO 15031-6). The first 2 bits define the ‘category,’ and the remaining 14 bits define a 4-digit hexadecimal code, as shown. Decoded DTC values can be looked up in OBD2 DTC lookup tools like repairpal.com.

Below is an example request to an ECU with 6 stored DTCs, communicated through OBD2 port numbers.

OBD2 Data Logging Use Cases via OBD2 Port

OBD2 data from cars and light trucks, accessed through OBD2 port numbers, has various applications:

Logging car data via OBD2 Port

OBD2 data from cars can reduce fuel costs, improve driving, test prototype parts, and aid insurance applications when accessed through OBD2 port numbers.

obd2 logger

Real-time car diagnostics via OBD2 Port

OBD2 interfaces stream human-readable OBD2 data in real-time for diagnosing vehicle issues when connected to OBD2 port numbers.

obd2 streaming

Predictive maintenance via OBD2 Port Data

Cars and light trucks can be monitored via IoT OBD2 loggers in the cloud to predict and prevent breakdowns using data from OBD2 port numbers.

predictive maintenance

Vehicle black box logger via OBD2 Port

An OBD2 logger serves as a ‘black box’ for vehicles or equipment, providing data for disputes or diagnostics, utilizing data accessed through OBD2 port numbers.

can bus blackbox

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

For more introductions, 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

[