Need to understand your car’s diagnostics through the OBD2 system? This guide offers a practical introduction to the On-Board Diagnostic (OBD2) protocol, focusing on the Conector Dlc Obd2, OBD2 Parameter IDs (PIDs), and its connection to the CAN bus.
This is a hands-on introduction, teaching you how to request and interpret OBD2 data, exploring key applications, and providing useful tips. Discover why this is considered a leading OBD2 tutorial.
You can also watch our OBD2 introduction video or download the PDF guide for offline access.
Article Contents
Author: Martin Falch (Updated January 2025)
Download as PDF
What is OBD2 and Why is the DLC Connector Important?
OBD2 is your car’s integrated self-diagnostic system. It’s a standardized protocol that allows access to Diagnostic Trouble Codes (DTCs) and live data through the OBD2 connector, also known as the Data Link Connector (DLC).
You’ve likely already encountered OBD2. The malfunction indicator light, often called the “check engine light,” on your dashboard? That’s your vehicle signaling a problem. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the issue.
This process begins with connecting the OBD2 reader to the OBD2 16 pin connector dlc, usually found near the steering wheel. The scan tool sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’. These responses can include vital information like speed, fuel level, and DTCs, significantly speeding up troubleshooting. The conector dlc obd2 is therefore the crucial physical interface for accessing this diagnostic data.
OBD2 Compatibility: Does Your Car Have a DLC Connector?
In short: Most likely, yes!
Nearly all modern non-electric vehicles are OBD2 compliant and predominantly utilize CAN bus communication. However, for older vehicles, the presence of a 16-pin OBD2 connector dlc doesn’t automatically guarantee OBD2 support. To verify compatibility, consider the vehicle’s origin and purchase date:
A Brief History of OBD2 and the DLC Connector
OBD2’s origins trace back to California, where the California Air Resources Board (CARB) mandated OBD in all new vehicles from 1991 onwards for emission control.
The Society of Automotive Engineers (SAE) recommended the OBD2 standard, leading to the standardization of DTCs and the OBD connector dlc across manufacturers (SAE J1962).
The OBD2 standard implementation unfolded gradually:
- 1996: OBD2 became mandatory in the USA for cars and light trucks.
- 2001: Required in the EU for gasoline vehicles.
- 2003: Extended to diesel vehicles in the EU (EOBD).
- 2005: OBD2 required in the US for medium-duty vehicles.
- 2008: US vehicles mandated to use ISO 15765-4 (CAN) as the OBD2 foundation.
- 2010: OBD2 became mandatory for heavy-duty vehicles in the US.
The Future of OBD2 and the Data Link Connector
OBD2 is expected to remain relevant, but its form is evolving.
Originally designed for emission control and testing, legislated OBD2 has an interesting implication: electric vehicles aren’t obliged to support OBD2 in any form. This is evident as most modern EVs don’t support standard OBD2 requests, opting instead for OEM-specific UDS communication. This generally complicates data extraction from EVs unless decoding rules are reverse-engineered. Our case studies for electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs, illustrate this point.
Current OBD2 implementations face limitations in data richness and lower-layer protocols. Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged to address these. They aim to improve OBD communication by using the UDS protocol as a base. For more information, see our introduction to UDS.
In the era of connected vehicles, traditional OBD2 emission checks can seem inefficient. The proposed solution? OBD3 – integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder to vehicles, similar to those used for bridge tolls. This would allow the vehicle identification number (VIN) and DTCs to be wirelessly transmitted to a central server for automated checks.
Many current devices, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger, already support CAN or OBD2 data transfer via WiFi/cellular networks.
While this approach offers convenience and cost savings, it raises privacy concerns due to potential surveillance.
Originally intended for stationary emission controls, OBD2 is now widely used by third parties for real-time data generation via OBD2 dongles, CAN loggers and similar devices. However, the German automotive industry is considering changes that could impact this:
“OBD has been designed to service cars in repair shops. It was never intended to allow third parties to build a data-driven economy based on access through this interface.”
– Christoph Grote, SVP Electronics, BMW (2017)
The suggestion is to disable OBD2 functionality during driving, centralizing data collection with manufacturers. This would give manufacturers control over ‘automotive big data’.
Security concerns, such as reducing the risk of car hacking, are cited as justification, although some view this as a commercially motivated move. Whether this trend will materialize remains to be seen, but it could significantly disrupt the market for third-party OBD2 services.
Enhance Your CAN Bus Expertise
Want to master CAN bus technology?
Access our 12 ‘simple introductions’ in a comprehensive 160+ page PDF:
Download now
OBD2 Standards and the DLC Connector
On-board diagnostics, or OBD2, is a higher layer protocol (akin to a language). CAN bus serves as the communication method (like a phone line). This makes OBD2 comparable to other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.
OBD2 standards specifically define the OBD2 connector dlc, lower-layer protocols, OBD2 Parameter IDs (PIDs), and more. These standards can be categorized within a 7-layer OSI model, with the following sections focusing on the key aspects.
The OSI model highlights the overlap between SAE and ISO standards, reflecting US (SAE) and EU (ISO) OBD definitions. Many standards are technically very similar, for example, SAE J1979 versus ISO 15031-5, and SAE J1962 versus ISO 15031-3.
Understanding the OBD2 Connector [SAE J1962]
The 16-pin OBD2 connector, detailed in SAE J1962 / ISO 15031-3, provides straightforward access to your vehicle’s data. Often referred to as the Data Link Connector (DLC), the illustration shows a Type A OBD2 pin connector example.
Key features of the OBD2 DLC connector include:
- Location near the steering wheel, though it may be concealed.
- Pin 16 supplying battery power, often even when the ignition is off.
- Pinout configuration dependent on the communication protocol.
- Common use of CAN bus as the lower-layer protocol, typically connecting pins 6 (CAN-H) and 14 (CAN-L).
OBD2 Connector Types: A vs. B
You may encounter both Type A and Type B OBD2 connectors. Type A is typically used in cars, while Type B is common in medium and heavy-duty vehicles.
Although both types share similar OBD2 connector 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, the Type B OBD2 connector dlc has a distinctive interrupted groove in the middle. This means a Type B OBD2 adapter cable is compatible with both Type A and B sockets, whereas a Type A adapter will not fit into a Type B socket.
OBD2 and CAN Bus Communication [ISO 15765-4]
Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US-sold vehicles, as per ISO 15765.
ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies a set of rules for using the CAN standard (ISO 11898) in diagnostics.
It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:
- CAN bus bit-rate must be either 250K or 500K.
- CAN IDs can be 11-bit or 29-bit.
- Specific CAN IDs are designated for OBD requests and responses.
- Diagnostic CAN frame data length is fixed at 8 bytes.
- The OBD2 adapter cable length is limited to a maximum of 5 meters.
OBD2 CAN Identifiers (11-bit, 29-bit)
OBD2 communication is based on request/response message exchanges.
In most cars, 11-bit CAN IDs are used for OBD2. The ‘Functional Addressing’ ID is 0x7DF, used to query all OBD2-compatible ECUs if they have data for the requested parameter (ISO 15765-4). CAN IDs 0x7E0-0x7E7 are used for ‘Physical Addressing’ requests to specific ECUs, though less common.
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, especially vans and medium to heavy-duty vehicles, use extended 29-bit CAN identifiers for OBD2 communication instead of 11-bit IDs.
In these cases, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Responses use CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID may also be expressed in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is reserved for ISO 15765-2 in the J1939-71 standard.
OBD2 vs. OEM-Specific CAN Protocols
It’s crucial to understand that vehicle ECUs don’t rely on OBD2 for their primary functions. Original Equipment Manufacturers (OEMs) implement their own proprietary CAN protocols for vehicle control and communication. These protocols are often unique to the vehicle brand, model, and year. Interpreting this OEM-specific data typically requires reverse engineering.
Connecting a CAN bus data logger to your car’s OBD2 connector dlc might reveal OEM-specific CAN data, usually broadcast at 1000-2000 frames/second. However, many newer vehicles employ a ‘gateway’ that blocks access to this CAN data through the OBD2 connector, only allowing OBD2 communication.
Think of OBD2 as a separate, higher-layer protocol operating in parallel with the OEM-specific protocol. The conector dlc obd2 primarily provides access to this standardized diagnostic layer.
Bit-rate and ID Validation
OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern cars commonly use 500K with 11-bit IDs, but diagnostic tools should systematically verify this.
ISO 15765-4 offers initialization sequence guidelines to determine the correct combination. This method relies on the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see OBD2 PID section) and that incorrect bit-rates cause CAN error frames.
Newer versions of ISO 15765-4 acknowledge that vehicles may support OBD communication via OBDonUDS instead of OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on emission diagnostic service per ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service per ISO 14229, ISO 27145-3/SAE J1979-2).
To test for OBDonEDS vs. OBDonUDS, diagnostic tools may send UDS requests with 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 termed OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars today, while WWH-OBD is mainly used in EU trucks and buses.
Five Lower-Layer OBD2 Protocols
While CAN bus (ISO 15765) is now the dominant lower-layer protocol for OBD2, particularly in vehicles with an OBD2 connector dlc, older cars (pre-2008) might use other protocols. Understanding these can be helpful when working with legacy systems. Pinouts can sometimes indicate the protocol in use.
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used today.
- ISO14230-4 (KWP2000): Common in 2003+ vehicles, especially in Asia.
- ISO 9141-2: Used in EU, Chrysler, and Asian cars from 2000-04.
- SAE J1850 (VPW): Primarily used in older GM vehicles.
- SAE J1850 (PWM): Primarily used in older Ford vehicles.
ISO-TP for OBD2 Message Transport [ISO 15765-2]
All OBD2 data transmitted over CAN bus utilizes ISO-TP (ISO 15765-2), a transport protocol that enables communication of payloads exceeding 8 bytes. This is necessary for OBD2 operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly. For detailed information, refer to our introduction to UDS.
Often, OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF), where the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2 communication.
Decoding the OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]
To better grasp OBD2 communication over CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. Simplified, an OBD2 message consists of an identifier, data length (PCI field), and data. The data is further structured into Mode, Parameter ID (PID), and data bytes. Understanding this structure is key to effectively using the OBD2 connector dlc for diagnostics.
Example: OBD2 Request/Response
Consider this request/response example for ‘Vehicle Speed’.
A diagnostic tool sends a request message to the car via the OBD2 connector dlc, using CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds with CAN ID 0x7E8 and 3 payload bytes, including the vehicle speed value in the 4th byte, 0x32 (decimal 50).
By consulting the OBD2 PID 0x0D decoding rules, we find that the physical value is 50 km/h.
Next, we will explore OBD2 modes and PIDs in more detail.
The 10 OBD2 Services (Modes)
OBD2 defines 10 diagnostic services, or modes. Mode 0x01 provides current real-time data, while others are used to display/clear Diagnostic Trouble Codes (DTCs) or show freeze frame data.
Vehicles are not required to support all 10 standardized OBD2 modes and may also support OEM-specific modes beyond these.
In OBD2 messages, the mode is located in the second byte. In a request, the mode is included directly (e.g., 0x01), while in a response, 0x40 is added to the mode (e.g., resulting in 0x41).
OBD2 Parameter IDs (PIDs)
Each OBD2 mode contains Parameter IDs (PIDs).
For example, mode 0x01 includes approximately 200 standardized PIDs providing real-time data on parameters like speed, RPM, and fuel level. However, vehicles typically support only a subset of the available PIDs within a mode.
One PID is particularly significant: mode 0x01 PID 0x00.
If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID, the vehicle ECU indicates its support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental test for ‘OBD2 compatibility’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs. This initial check is often performed through the OBD2 connector dlc to establish communication capabilities.
Tip: OBD2 PID Overview Tool
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.
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, streamlining the process of interacting with the OBD2 connector dlc.
OBD2 PID overview tool
Logging and Decoding OBD2 Data: A Practical Guide
This section provides a practical example of logging OBD2 data using the CANedge CAN bus data logger. Connecting to the OBD2 connector dlc is simplified with the CANedge.
The CANedge allows configuration of custom CAN frames for transmission, making it suitable for OBD2 logging.
Once set up, the device easily connects to your vehicle via our OBD2-DB9 adapter cable, allowing you to record data directly from the conector dlc obd2.
Review responses to ‘Supported PIDs’ in asammdf.
#1: Bit-rate, ID & Supported PID Testing
ISO 15765-4 outlines how to determine the bit-rate and IDs used by a specific vehicle’s OBD2 connector dlc. The CANedge can facilitate this testing process (see CANedge Intro for details):
- Test CAN frame transmission at 500K; if unsuccessful, try 250K.
- Use the identified bit-rate for subsequent communication.
- Send multiple ‘Supported PIDs’ requests and analyze the responses.
- Determine 11-bit vs. 29-bit IDs based on response IDs.
- Identify supported PIDs from response data.
We provide plug-and-play configurations for these tests.
Most post-2008 non-EV cars support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol, accessible through the OBD2 connector dlc.
As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common due to using the 0x7DF request ID, which polls all ECUs. Because all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, many responses to this PID are typical. Subsequent ‘Supported PIDs’ requests usually receive fewer ECU responses. Notably, the ECM ECU (0x7E8) in this example supports all PIDs supported by other ECUs, suggesting that bus load could be reduced by directing future requests specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.
#2: Configuring OBD2 PID Requests
Once you’ve identified your vehicle’s supported OBD2 PIDs, bit-rate, and CAN IDs via the OBD2 connector dlc, you can configure your transmit list with relevant PIDs.
Consider these points:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses.
- Spacing: Introduce 300-500 ms intervals between OBD2 requests to prevent ECU overload.
- Battery Drain: Use triggers to halt transmissions when the vehicle is inactive to avoid unnecessary ECU activation.
- Filters: Implement filters to record only OBD2 responses, especially if OEM-specific CAN data is also present.
With these configurations, your device is ready to log raw OBD2 data from the OBD2 connector!
Example CANedge OBD2 PID request list.
Visualize DBC decoded OBD2 data in asammdf.
#3: DBC Decoding of Raw OBD2 Data
To analyze and visualize logged data from the OBD2 connector dlc, you need to decode the raw OBD2 data into physical values (e.g., km/h, °C).
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 simplify DBC decoding in most CAN bus software tools.
Decoding OBD2 data is somewhat more intricate than standard CAN signals because different OBD2 PIDs can share the same CAN ID (e.g., 0x7E8). Thus, the CAN ID alone isn’t enough to determine the signals within the payload.
To resolve this, you must use the CAN ID, OBD2 mode, and OBD2 PID to identify the signal. This is a form of multiplexing known as ‘extended multiplexing‘, which can be implemented in formats like DBC files. Using a proper DBC file ensures accurate interpretation of data obtained via the OBD2 connector dlc.
CANedge: Your OBD2 Data Logging Solution
The CANedge simplifies OBD2 data recording to an 8-32 GB SD card. Just connect it to your vehicle’s OBD2 connector dlc to start logging and decode data using free software/APIs and our OBD2 DBC.
OBD2 logger intro CANedge
OBD2 Multi-Frame Communication Examples [ISO-TP]
OBD2 communication, as per ISO 15765-2, always uses ISO-TP (transport protocol). While many examples are single-frame, multi-frame communication is essential for larger data sets.
Multi-frame OBD2 interactions require flow control frames (see our UDS intro). A common practice is to transmit a static flow control frame approximately 50 ms after the initial request frame, as shown in the CANedge configuration example.
Handling multi-frame OBD2 responses requires CAN software/API tools that support ISO-TP, such as the CANedge MF4 decoders. These tools are crucial when extracting data like VIN or DTCs through the OBD2 connector dlc.
Example 1: Retrieving Vehicle Identification Number (VIN) via OBD2
The Vehicle Identification Number (VIN) is important for telematics and diagnostics. To retrieve it using OBD2 requests via the OBD2 connector dlc, use mode 0x09 and PID 0x02:
The diagnostic tool sends a Single Frame request with PCI field (0x02), request service identifier (0x09), and PID (0x02) through the OBD2 connector.
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.
Example 2: OBD2 Multi-PID Request (6x)
Diagnostic tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame via the OBD2 connector dlc. The ECU should respond with data for supported PIDs (omitting unsupported ones), potentially using multiple frames as per ISO-TP.
This efficient method allows for higher frequency data collection. However, it also means the signal encoding is specific to the request method, complicating the use of generic OBD2 DBC files. We generally advise against this method in practice. Below is an example trace:
The multi-frame response is similar to the VIN example, but includes both the requested PIDs and their corresponding data. The PIDs in the example are ordered like the request, which is common but not mandated by ISO 15031-5.
Decoding this response using standard DBC files is challenging. Therefore, we don’t recommend this approach for practical data logging unless using tools with specific built-in support. It involves extended multiplexing, but with multiple instances throughout the payload. The DBC file would need to account for each PID’s specific payload position, making it difficult to generalize across vehicles with varying PID support. This becomes even more complex with multiple multi-PID requests, as distinguishing messages becomes difficult.
Workarounds might include custom scripts and recording transmit messages, allowing the script to interpret responses based on requests. However, such methods are hard to scale.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval
OBD2 can retrieve emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes’. No PID is included in the request. Targeted ECUs respond with the number of stored DTCs (possibly zero), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored, accessed through the OBD2 connector dlc.
The 2-byte DTC value is typically divided into two parts, 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, as illustrated. 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.
OBD2 Data Logging Use Cases
OBD2 data, readily accessible via the OBD2 connector dlc, from cars and light trucks has numerous applications:
Vehicle Data Logging
OBD2 data logging from cars can be used to reduce fuel costs, improve driving habits, test prototype parts, and for insurance purposes. The OBD2 connector dlc makes data access straightforward.
obd2 logger
Real-time Vehicle Diagnostics
OBD2 interfaces enable real-time streaming of human-readable OBD2 data, useful for diagnosing vehicle issues directly from the OBD2 connector dlc.
obd2 streaming
Predictive Maintenance
Cars and light trucks can be monitored via IoT OBD2 loggers in the cloud to predict and prevent breakdowns, leveraging data obtained through the OBD2 connector dlc.
predictive maintenance
Vehicle Black Box Logging
An OBD2 logger can act as a ‘black box’ for vehicles or equipment, providing valuable data for dispute resolution or detailed diagnostics, all initiated from the OBD2 connector dlc.
can bus blackbox
Do you have an OBD2 data logging application? Contact us for a free consultation!
Contact us
Explore our guides section for more introductions, or download the ‘Ultimate Guide’ PDF.
Need to log or stream OBD2 data?
Get your OBD2 data logger today!
Buy now Contact us
Recommended for You
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANEDGE2 – PRO CAN IoT LOGGER
[
