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

Want to understand your car’s diagnostics?

This guide provides a comprehensive introduction to the On-Board Diagnostics II (OBD2) protocol, focusing on the crucial 16-pin OBD2 connector, its function, and how it interfaces with your vehicle’s systems.

This in-depth guide will explain how to utilize the 16-pin interface to access OBD2 data, covering connector details, communication protocols, and practical applications. Discover why this has become a go-to resource for understanding the OBD2 system.

You can also explore our introductory OBD2 video above – or download the PDF guide for offline access.

What is OBD2 and Why the 16-Pin Connector Matters?

OBD2 is essentially your car’s internal health monitoring system. It’s a standardized system that allows access to crucial information like diagnostic trouble codes (DTCs) and real-time sensor data through a universal port: the 16-pin OBD2 connector.

You’re likely already familiar with OBD2 in some form:

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

That light is your car’s way of signaling a problem. When you take your vehicle to a mechanic, they use an OBD2 scanner to pinpoint the issue. This process begins with connecting the OBD2 reader to the 16 pin connector, typically found within easy reach under the dashboard, often near the steering column. This 16-pin interface is the gateway to your car’s diagnostic data. The scanner sends ‘OBD2 requests’ via this connector, and the car responds with valuable data including speed, engine temperature, fuel levels, and those all-important Diagnostic Trouble Codes (DTCs). This streamlined communication drastically reduces troubleshooting time and complexity.

Is My Car Equipped with a 16-Pin OBD2 Interface?

The short answer is: Almost certainly, yes!

Nearly all modern gasoline and diesel cars, excluding electric vehicles in some respects, are equipped with OBD2 and predominantly utilize the CAN bus communication protocol. Even if your older vehicle has a 16-pin connector, it’s not guaranteed to be OBD2 compliant. A key indicator of OBD2 compliance is the vehicle’s origin and year of manufacture:

A Brief History of OBD2 and the Standardization of the 16-Pin Interface

The OBD2 system originated in California, driven by the California Air Resources Board (CARB) regulations. Starting in 1991, CARB mandated OBD systems in all new vehicles sold in California for emissions monitoring.

The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBD2, leading to uniform DTCs and, significantly, the standardized 16-pin OBD connector. This standardization is documented under SAE J1962, ensuring interoperability across different vehicle manufacturers.

The rollout of the OBD2 standard was phased, becoming increasingly comprehensive over time:

1996: OBD2 became mandatory in the USA for all cars and light trucks.
2001: The standard became mandatory in the EU for gasoline vehicles.
2003: EU mandate extended to include diesel vehicles (referred to as EOBD in Europe).
2005: OBD2 requirement expanded in the US to include medium-duty vehicles.
2008: US regulations specified ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 mandate in the US finalized to encompass heavy-duty vehicles.

The Future of OBD2 and the 16-Pin Interface

While OBD2 is firmly established, its evolution and future applications are subjects of ongoing development.

Initially designed for emissions control and testing, legislative OBD2 requirements have not been uniformly applied to electric vehicles. Consequently, many modern EVs do not fully support standard OBD2 protocols. Instead, they often utilize OEM-specific UDS communication protocols. This shift poses challenges for accessing EV data, often requiring reverse engineering to decode proprietary communication – as demonstrated in case studies for electric car brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda.

Recognizing the limitations of current OBD2 implementations in terms of data richness and protocol efficiency, advancements like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These protocols aim to enhance OBD communication by using the UDS protocol as a foundation. For a deeper dive into these protocols, refer to our introduction to UDS.

In an increasingly connected world, traditional OBD2 testing methods are becoming less efficient. Manual emission checks are time-consuming and costly. The proposed solution? OBD3 – integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder to vehicles, similar to those used for electronic toll collection. This would enable vehicles to wirelessly transmit their Vehicle Identification Number (VIN) and DTCs to a central server for automated monitoring and diagnostics. Technologies already exist to facilitate CAN or OBD2 data transfer via WiFi/cellular, such as the CANedge2 WiFi CAN logger or the CANedge3 3G/4G CAN logger.

While offering convenience and cost savings, OBD3 also raises privacy concerns due to potential surveillance implications, making its widespread adoption politically complex.

Originally designed for stationary emission controls, OBD2 is now widely used by third parties to access real-time vehicle data through OBD2 dongles and CAN loggers. However, the German automotive industry is considering restricting this third-party access:

“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 normal driving, centralizing data collection through manufacturers’ servers. This would give manufacturers control over ‘automotive big data’. Arguments for this shift include enhanced security (reducing car hacking risks), although many perceive it as a commercially motivated move to control vehicle data, potentially disrupting the market for third-party OBD2 services.

Enhance Your Understanding with Our ‘Ultimate CAN Guide’

Ready to become a CAN bus expert?

Access our comprehensive collection of 12 ‘simple introductions’ in a single 160+ page PDF:

Download now

OBD2 Standards and the 16-Pin Connector: Key Specifications

On-board diagnostics, OBD2, operates as a higher-layer protocol, much like a language, while CAN functions as the communication method, similar to a phone line. OBD2 shares this layered approach with other CAN-based protocols like J1939, CANopen, and NMEA 2000.

OBD2 standards comprehensively define the 16-pin OBD2 connector interface, lower-layer communication protocols, OBD2 Parameter IDs (PIDs), and other critical aspects of vehicle diagnostics.

These standards can be visualized using the 7-layer OSI model. Notably, both SAE and ISO standards contribute to various layers, reflecting the standards defined in the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, such as SAE J1979 and ISO 15031-5 for diagnostic services, and SAE J1962 and ISO 15031-3 for the 16-pin connector specifications.

The 16-Pin OBD2 Connector [SAE J1962 / ISO 15031-3] in Detail

The 16-pin OBD2 connector is your primary access point for retrieving vehicle data, standardized under SAE J1962 and ISO 15031-3. This standardized interface ensures compatibility across a wide range of diagnostic tools and vehicles.

The illustration above details a typical Type A OBD2 pin connector, also known as a Data Link Connector (DLC). Key features of this 16-pin interface include:

Location: The connector is generally located near the steering wheel, though its exact placement can sometimes be concealed.
Power Supply: Pin 16 provides battery power, often remaining active even when the ignition is off, which is crucial for certain diagnostic functions.
Pinout Configuration: The specific function of each pin in the 16-pin connector is protocol-dependent.
CAN Bus Integration: For vehicles using CAN bus, pins 6 (CAN-High) and 14 (CAN-Low) are the communication channels, making them vital for data exchange.

OBD2 Connector Types: A vs. B – Understanding the 16-Pin Variations

You might encounter both Type A and Type B 16-pin OBD2 connectors. Type A is predominantly used in cars and light vehicles, while Type B is more common in medium and heavy-duty vehicles.

Visually, both types of 16-pin OBD2 sockets share similar pin layouts, but they differ in power supply outputs: Type A typically provides 12V, and Type B provides 24V. Baud rates can also vary; cars usually operate at 500K, while heavy-duty vehicles often use 250K (with increasing support for 500K).

A key physical difference is that the Type B 16-pin OBD2 connector has an interrupted groove in the middle. This design feature means a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, whereas a Type A adapter will not fit into a Type B socket.

OBD2 and CAN Bus [ISO 15765-4] Integration via the 16-Pin Connector

Since 2008, CAN bus has been mandated as the primary lower-layer protocol for OBD2 in all US vehicles, as defined by ISO 15765. This integration makes the 16-pin OBD2 connector a CAN bus interface in most modern vehicles.

ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies a set of constraints and guidelines for using CAN (ISO 11898) in diagnostic applications. It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:

Bit Rate: CAN bus bit rates must be either 250K or 500K.
CAN IDs: Supports both 11-bit and 29-bit CAN identifiers.
Specific CAN IDs: Prescribes specific CAN IDs for OBD requests and responses.
Data Frame Length: Diagnostic CAN frames are limited to a data length of 8 bytes.
Cable Length: The OBD2 adapter cable must not exceed 5 meters in length.

OBD2 CAN Identifiers (11-bit, 29-bit) and the 16-Pin Interface

OBD2 communication, accessed through the 16-pin connector, is structured around request and response messages.

In most passenger vehicles, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is typically 0x7DF, which broadcasts a request to all OBD2-compliant ECUs to report data for the requested parameter (as per ISO 15765-4). ‘Physical Addressing’ requests, directed to specific ECUs, use CAN IDs in the range 0x7E0-0x7E7, but are less frequently used.

ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most common response ID is 0x7E8 (Engine Control Module – ECM), followed by 0x7E9 (Transmission Control Module – TCM).

Some vehicles, particularly vans and medium to heavy-duty vehicles, may utilize extended 29-bit CAN identifiers for OBD2 communication via the 16-pin interface.

In these systems, the ‘Functional Addressing’ CAN ID is 0x18DB33F1. Responses use CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (commonly 18DAF110 and 18DAF11E). These response IDs are sometimes represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated as ‘Reserved for ISO 15765-2’ in the J1939-71 standard.

OBD2 vs. Proprietary CAN Protocols: Data Access Through the 16-Pin Interface

It’s important to understand that your vehicle’s Electronic Control Units (ECUs) operate independently of OBD2 for their core functions. Each Original Equipment Manufacturer (OEM) implements proprietary CAN protocols for internal vehicle communication. These protocols are often specific to vehicle brand, model, and year. Generally, this OEM-specific CAN data is inaccessible without reverse engineering, unless you are the OEM.

When connecting a CAN bus data logger to your car’s 16-pin OBD2 connector, you might observe OEM-specific CAN data, typically transmitted at high rates (1000-2000 frames/second). However, many newer vehicles incorporate a ‘gateway’ that restricts access to this OEM CAN data through the OBD2 port, allowing only OBD2 communication via the 16-pin interface.

In essence, think of OBD2 as a supplementary, higher-layer protocol that operates in parallel with the OEM-specific communication protocol. Both are accessible via the 16-pin connector, but provide fundamentally different types of data.

Bit-Rate and ID Validation for OBD2 Communication via the 16-Pin Connector

As discussed, OBD2 over CAN bus can use two bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern vehicles commonly use 500K and 11-bit IDs. Diagnostic tools should systematically validate these parameters to ensure correct communication through the 16-pin OBD2 interface.

ISO 15765-4 outlines a systematic initialization sequence to determine the correct combination. This process leverages the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see OBD2 PID section) and detects CAN error frames that occur when data is transmitted at an incorrect bit rate.

More recent versions of ISO 15765-4 account for vehicles that may support OBD communication via OBDonUDS rather than OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).

To differentiate between OBDonEDS and OBDonUDS protocols, diagnostic tools may send additional UDS requests using 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.

In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV vehicles today, while WWH-OBD is primarily used in EU trucks and buses.

Five Lower-Layer OBD2 Protocols and the 16-Pin Connector

While CAN (ISO 15765) is now the dominant lower-layer protocol for OBD2 in most vehicles, especially those manufactured post-2008, older vehicles may use other protocols. When working with older cars, it’s useful to know the five lower-layer protocols that have been used for OBD2 and how they relate to the 16-pin connector:

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and now the most common globally. Pins 6 and 14 of the 16-pin connector are key for CAN communication.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, particularly in Asia. Pin 7 (K-line) of the 16-pin connector is used.
ISO 9141-2: Used in EU, Chrysler, and Asian vehicles around 2000-2004. Pins 7 (K-line) and 15 (L-line) of the 16-pin connector are relevant.
SAE J1850 (VPW): Variable Pulse Width Modulation, primarily used in older GM vehicles. Pin 2 of the 16-pin connector is the J1850 bus positive line.
SAE J1850 (PWM): Pulse Width Modulation, mainly found in older Ford vehicles. Pins 2 and 10 of the 16-pin connector are used for J1850 bus.

Understanding these protocols and their corresponding pins on the 16-pin OBD2 connector is essential for diagnosing older vehicles.

Transporting OBD2 Messages via ISO-TP [ISO 15765-2] Through the 16-Pin Interface

All OBD2 data transmitted via the 16-pin connector over CAN bus uses ISO-TP (ISO 15765-2), a transport protocol. ISO-TP allows for payloads larger than 8 bytes, necessary 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, see our introduction to UDS.

However, many OBD2 data requests and responses fit within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF) format. The first byte of data (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-related communication within the CAN frame transmitted through the 16-pin connector.

The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5] Structure via the 16-Pin Connector

To better understand OBD2 communication through the 16-pin connector and over CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message consists of a CAN identifier, a data length indicator (PCI field), and the data payload. The payload is further structured into Mode, Parameter ID (PID), and data bytes.

Example: OBD2 Request/Response via the 16-Pin Interface

Consider a practical example: requesting ‘Vehicle Speed’ via the 16-pin connector.

An external tool sends a request message with CAN ID 0x7DF and a 2-byte payload: Mode 0x01 and PID 0x0D. The vehicle responds with CAN ID 0x7E8 and a 3-byte payload, including the Vehicle Speed value in the 4th byte, 0x32 (50 in decimal).

By consulting the OBD2 PID specifications for PID 0x0D, we can determine that 0x32 corresponds to a physical value of 50 km/h. This exchange happens entirely through the 16-pin OBD2 interface.

The 10 OBD2 Services (Modes) and the 16-Pin Interface

OBD2 defines 10 diagnostic services, also referred to as modes, accessible through the 16-pin connector. Mode 0x01 is used for real-time data, while others manage Diagnostic Trouble Codes (DTCs) and 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 indicated in the second byte. In a request, the mode is directly included (e.g., 0x01). In a response, 0x40 is added to the mode value (e.g., becoming 0x41). All communication for these services passes through the 16-pin OBD2 interface.

OBD2 Parameter IDs (PIDs) and Data Access via the 16-Pin Connector

Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the data being requested or reported via the 16-pin connector.

For example, Mode 0x01 includes approximately 200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles typically support only a subset of these PIDs within a given mode.

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 ECU indicates its support for PIDs 0x01-0x20. Thus, PID 0x00 serves as a basic ‘OBD2 compatibility test’ for the 16-pin interface. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for subsequent ranges of mode 0x01 PIDs.

Tip: OBD2 PID Overview Tool for 16-Pin Interface Diagnostics

SAE J1979 and ISO 15031-5 appendices provide scaling information for standard OBD2 PIDs, enabling the conversion of raw data into physical values, as explained in our CAN bus introduction. This decoding process is crucial when interpreting data accessed through the 16-pin connector.

For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is invaluable. It helps you construct OBD2 request frames and dynamically decode OBD2 responses received via the 16-pin interface.

OBD2 PID overview tool

Logging and Decoding OBD2 Data from the 16-Pin Interface

This section provides a practical guide on logging OBD2 data using the CANedge CAN bus data logger, connected via the 16-pin OBD2 connector.

The CANedge allows configuration of custom CAN frames for transmission, making it ideal for OBD2 logging. Connecting the CANedge to your vehicle is straightforward using our OBD2-DB9 adapter cable, which interfaces directly with the 16-pin OBD2 port.

Verifying successful CAN frame transmission at 500K for bit-rate validation

Reviewing ‘Supported PIDs’ responses in asammdf

#1: Bit-Rate, ID, and Supported PID Testing via the 16-Pin Interface

ISO 15765-4 provides guidelines for determining the correct bit rate and IDs for OBD2 communication. You can test these parameters using CANedge connected to the 16-pin OBD2 connector, following these steps (see CANedge Intro for detailed instructions):

Test at 500K: Send a CAN frame at 500K and verify successful transmission. If unsuccessful, try 250K.
Bit Rate Configuration: Use the validated bit rate for all subsequent communication.
Supported PID Requests: Send multiple ‘Supported PIDs’ requests and analyze the responses.
ID Type Determination: Based on response IDs, determine whether 11-bit or 29-bit IDs are in use.
PID Support Verification: Analyze response data to identify supported PIDs.

We provide plug-and-play configurations to simplify these initial tests when connecting via the 16-pin OBD2 interface.

Most non-EV vehicles manufactured from 2008 onwards 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 when using the 0x7DF request ID, which queries all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are often observed. Subsequent ‘Supported PIDs’ requests typically elicit fewer responses, as fewer ECUs support those specific PIDs. Notice that the ECM ECU (0x7E8) supports all PIDs supported by other ECUs in this example. To reduce bus load, you could directly query only the ECM by switching to ‘Physical Addressing’ CAN ID 0x7E0 for subsequent communication.

#2: Configuring OBD2 PID Requests for the 16-Pin Interface

Once you’ve identified the supported OBD2 PIDs, bit rate, and CAN IDs for your vehicle, configure your transmit list with the PIDs of interest. Consider these points for efficient data logging through the 16-pin OBD2 connector:

CAN IDs: Use ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses per request.
Request Spacing: Introduce a delay of 300-500 ms between OBD2 requests to prevent ECU overload and ensure reliable responses.
Battery Management: Implement triggers to halt transmission when the vehicle is inactive to prevent battery drain.
Data Filtering: Apply filters to record only OBD2 responses if OEM-specific CAN data is also present on the bus.

With these configurations, your device is ready to log raw OBD2 data from the 16-pin interface!

Example CANedge OBD2 PID request list

DBC decoded and visualized OBD2 data in asammdf

#3: DBC Decoding of Raw OBD2 Data from the 16-Pin Interface

To analyze and visualize logged OBD2 data, you need to decode the raw data into physical values (e.g., km/h, °C). This decoding process is essential for making sense of the data obtained through the 16-pin OBD2 connector.

Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, we offer a free OBD2 DBC file to facilitate DBC decoding of raw OBD2 data in most CAN bus software tools.

Decoding OBD2 data is more complex than standard CAN signal decoding. Since different OBD2 PIDs share the same CAN ID (e.g., 0x7E8), the CAN ID alone is insufficient to identify the payload signals.

To address this, signal identification requires considering the CAN ID, OBD2 mode, and OBD2 PID. This multiplexing technique, known as ‘extended multiplexing‘, can be implemented in DBC files, enabling accurate interpretation of OBD2 data logged via the 16-pin connector.

CANedge: Your OBD2 Data Logger for the 16-Pin Interface

The CANedge simplifies OBD2 data recording to an 8-32 GB SD card. Just connect it to your vehicle’s 16-pin OBD2 port to start logging. Decode your data using free software/APIs and our OBD2 DBC.

OBD2 logger intro

CANedge

OBD2 Multi-Frame Examples [ISO-TP] via the 16-Pin Interface

OBD2 communication via the 16-pin connector relies on ISO-TP (ISO 15765-2) for all data transmission. While previous examples focused on single-frame communication, multi-frame communication is necessary for larger datasets.

Multi-frame OBD2 communication requires flow control frames (see our UDS intro). A practical approach is to transmit a static flow control frame approximately 50 ms after the initial request frame, as shown in the CANedge configuration example.

Analyzing multi-frame OBD2 responses necessitates CAN software/API tools that support ISO-TP, such as the CANedge MF4 decoders. These tools are essential for correctly interpreting complex diagnostic data obtained through the 16-pin OBD2 interface.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval via the 16-Pin Connector

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more (see our intro to UDS). To retrieve the VIN using OBD2 requests through the 16-pin connector, 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, representing the Number Of Data Items (NODI), which is 1 in this case (see ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes contain the VIN, which can be converted from HEX to ASCII as described in our UDS introduction. All this data is transmitted and received via the 16-pin OBD2 interface.

Example 2: OBD2 Multi-PID Request (6x) via the 16-Pin Connector

External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame via the 16-pin interface. The ECU should respond with data for supported PIDs (omitting unsupported ones), potentially using multi-frame responses as per ISO-TP.

This method allows for more efficient data collection at higher frequencies. However, the signal encoding becomes specific to the request method, complicating the use of generic OBD2 DBC files. We generally advise against this method in practice. The following trace illustrates an example:

The multi-frame response is similar to the VIN example, but the payload includes both the requested PIDs and their corresponding data. The PIDs in the example are ordered similarly to the request order, which is common but not strictly mandated by ISO 15031-5.

Decoding these responses using generic DBC files is challenging. We advise against this approach for practical data logging unless you are using tools with built-in support for multi-PID requests. This scenario involves extended multiplexing, with multiple instances throughout the payload. Your DBC file would need to account for the specific payload position of each PID, making it difficult to generalize across vehicles with varying PID support. Handling multiple multi-PID requests further complicates DBC management, as uniquely identifying messages becomes problematic.

Workarounds could involve custom scripts that interpret responses based on corresponding requests, but these are difficult to scale and manage.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval via the 16-Pin Connector

OBD2 can be used to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes’, accessed via the 16-pin connector. No PID is included in the request. Responding ECUs report the number of stored DTCs (possibly zero if none are stored), with each DTC occupying 2 data bytes. Multi-frame responses are required when more than two DTCs are stored.

The 2-byte DTC value is structured as per ISO 15031-5/ISO 15031-6. The first two bits define the ‘category’, and the remaining 14 bits form a 4-digit hexadecimal code. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.

The example below shows a request to an ECU with 6 stored DTCs, all communicated through the 16-pin OBD2 interface.

OBD2 Data Logging Use Cases via the 16-Pin Interface

OBD2 data, accessed through the 16-pin connector, from cars and light trucks has diverse applications:

Logging Data from Cars

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

obd2 logger

Real-Time Car Diagnostics

OBD2 interfaces enable real-time streaming of human-readable diagnostic data, aiding in vehicle issue diagnosis and troubleshooting.

obd2 streaming

Predictive Maintenance

IoT-enabled OBD2 loggers allow for remote vehicle monitoring to predict and prevent breakdowns, enhancing vehicle uptime and reducing maintenance costs.

predictive maintenance

Vehicle Black Box Logger

An OBD2 logger functions as a ‘black box’ for vehicles, providing crucial data for incident analysis, dispute resolution, and diagnostic forensics.

can bus blackbox

Do you 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

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN

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

In this article