Decoding the OBDII Data Link Connector: Your Guide to Automotive Diagnostics

Want to understand the OBDII system and its crucial Data Link Connector?

This guide provides a comprehensive introduction to the On-Board Diagnostic (OBDII) protocol, focusing on the OBDII Data Link Connector (DLC), OBDII Parameter IDs (PIDs), and its connection to the Controller Area Network (CAN) bus.

This is designed as a practical guide for enthusiasts and professionals alike. You’ll learn how to request and interpret OBDII data, explore key applications, and gain valuable practical insights.

Discover why this has become a leading resource for understanding the OBDII system and its Data Link Connector.

You can also watch our introductory OBDII video above – or download our comprehensive PDF guide for offline access.

What is OBDII and the Data Link Connector?

OBDII, or On-Board Diagnostics II, is your car’s integrated self-diagnostic system. It’s a standardized protocol that enables the retrieval of diagnostic trouble codes (DTCs) and real-time vehicle data through the OBDII connector, formally known as the Data Link Connector (DLC).

You’ve likely already encountered OBDII in action:

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

That’s your vehicle signaling a potential issue. When you take your car to a mechanic, they use an OBDII scanner to pinpoint the problem.

To do this, the mechanic connects an OBDII reader to the OBDII 16-pin Data Link Connector located near the steering wheel. This tool sends ‘OBDII requests’ to the car, and the car responds with ‘OBDII responses’ containing information like speed, fuel level, or Diagnostic Trouble Codes (DTCs). This process significantly speeds up troubleshooting and repair. The Data Link Connector Obdii is the physical gateway to this vital diagnostic information.

Illustration depicting OBD2 On-Board Diagnostics and the Malfunction Indicator Light (MIL), highlighting the use of a scan tool connected to the Data Link Connector OBDII.

OBDII Compatibility: Does Your Car Have a Data Link Connector OBDII?

In short: Most likely, yes!

The vast majority of modern non-electric vehicles are equipped with OBDII and predominantly utilize the CAN bus communication protocol. For older vehicles, even if a 16-pin OBDII connector is present, it might not actually support the OBDII protocol. A reliable way to check for OBDII compliance is by considering the vehicle’s region and year of purchase:

Does My Car Have OBD2?
Infographic illustrating OBDII compliance by region and year, helping users determine if their car has the Data Link Connector OBDII and supports the protocol.

A Brief History of OBDII and the Data Link Connector

The origins of OBDII trace back to California, where the California Air Resources Board (CARB) mandated OBD systems in all new vehicles starting from 1991 for emission control.

The OBDII standard was further refined and recommended by the Society of Automotive Engineers (SAE), leading to the standardization of DTCs and the OBD connector – the Data Link Connector OBDII – across different manufacturers (SAE J1962).

From its Californian inception, the OBDII standard and the use of the standardized Data Link Connector OBDII were progressively implemented worldwide:

1996: OBDII became mandatory in the USA for cars and light trucks.
2001: Required in the EU for gasoline cars.
2003: Extended in the EU to include diesel cars (EOBD – European On-Board Diagnostics).
2005: OBDII mandate expanded in the US to medium-duty vehicles.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBDII communication.
2010: OBDII compliance became mandatory for heavy-duty vehicles in the US.

Graphical timeline illustrating the history of OBDII and emission control standards, emphasizing the role of the Data Link Connector OBDII in accessing vehicle data.

Timeline infographic providing an overview of OBDII history and the increasing adoption of the Data Link Connector OBDII across vehicle types and regions.

Conceptual image representing the future of OBD, including OBDIII, remote diagnostics, and cloud integration, hinting at the evolving role of the Data Link Connector OBDII in connected vehicles.

The Future of OBDII and the Data Link Connector

OBDII is firmly established, but its future form is evolving. Key trends are emerging:

Originally designed for emissions testing, legislated OBDII is not inherently required for electric vehicles (EVs). Consequently, most modern EVs do not support standard OBDII requests through the Data Link Connector OBDII. Instead, they often employ OEM-specific UDS communication protocols. This makes accessing data from EVs challenging, except when decoding rules are reverse-engineered, as demonstrated in our case studies for electric cars including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs. The Data Link Connector OBDII in EVs may exist but not function in the traditional OBDII manner.

OBDII implementations vary and have limitations in data richness and lower-layer protocols. Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) aim to enhance OBD communication using the UDS protocol. Learn more in our introduction to UDS. These advancements potentially impact the future of the Data Link Connector OBDII and the protocols it supports.

In our increasingly connected world, manual OBDII emission tests seem outdated.

The envisioned solution is OBDIII – integrating telematics into all vehicles.

OBDIII would incorporate a small radio transponder in every car, similar to those used for bridge tolls. This would enable the car’s vehicle identification number (VIN) and DTCs to be wirelessly transmitted to a central server for automated checks. This evolution could reduce reliance on the physical Data Link Connector OBDII for basic emission checks.

Many current devices already facilitate CAN or OBDII data transfer via WiFi/cellular, such as the CANedge2 WiFi CAN logger or the CANedge3 3G/4G CAN logger. While convenient and cost-saving, OBDIII raises political concerns about surveillance. The future might see data accessed both through the Data Link Connector OBDII and wirelessly.

The OBDII protocol was initially conceived for stationary emission controls.

Today, third-party services extensively use OBDII for real-time data generation via OBDII dongles, CAN loggers etc. However, the German car industry aims to alter this:

“OBD has been designed to service cars in repair shops. It was never intended to enable third parties to build a data-driven economy based on access through this interface.“

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal suggests disabling OBDII functionality during driving, centralizing data collection with manufacturers. This would give manufacturers control over ‘automotive big data’.

Arguments cite security concerns, like reducing car hacking risks, though many view this as a commercial strategy. Whether this trend materializes remains to be seen, but it could significantly disrupt the market for third-party OBDII services and potentially diminish the role of the Data Link Connector OBDII as a publicly accessible interface.

Illustration depicting the potential future where electric vehicles might limit data access through the Data Link Connector OBDII, suggesting a shift in diagnostic approaches.

Get Our ‘Ultimate CAN Guide’

Want to become a CAN bus expert and deepen your OBDII knowledge?

Access our 12 ‘simple introductions’ in one comprehensive 160+ page PDF:

Download now

CAN Bus – The Ultimate Guide Tutorial PDF

OBDII Standards and the Data Link Connector

On-board diagnostics, OBDII, is a higher-layer protocol – akin to a language. CAN acts as the communication method, like a phone line. This positions OBDII similarly to other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000. The Data Link Connector OBDII serves as the physical interface for accessing these protocols.

Specifically, OBDII standards define the OBDII connector (Data Link Connector OBDII) specifications, lower-layer protocols, OBDII Parameter IDs (PIDs), and more.

These standards can be visualized using a 7-layer OSI model. We’ll focus on the most critical standards in the following sections, particularly those relating to the Data Link Connector OBDII.

In the OSI model, you’ll notice that both SAE and ISO standards cover multiple layers. This generally reflects the standards for OBD defined in the USA (SAE) and EU (ISO). Many standards are technically very similar, for example, SAE J1979 versus ISO 15031-5, and SAE J1962 versus ISO 15031-3, the latter being critical for the Data Link Connector OBDII.

OSI model diagram illustrating the relationship between OBDII, CAN bus, and relevant ISO and SAE standards, emphasizing the standardization of the Data Link Connector OBDII.

Pinout diagram for the OBDII Data Link Connector (DLC) Type A socket, detailing pin assignments for various communication protocols and power.

The OBDII Data Link Connector [SAE J1962 / ISO 15031-3]

The 16-pin OBDII Data Link Connector is your easy access point to vehicle data. It is meticulously specified in the SAE J1962 / ISO 15031-3 standard.

The illustration shows a Type A OBDII pin connector, also frequently referred to as the Data Link Connector (DLC).

Key points regarding the Data Link Connector OBDII:

It’s usually located near the steering wheel but can be hidden.
Pin 16 provides battery power, often even when the ignition is off, crucial for certain diagnostic operations.
The OBDII pinout configuration depends on the communication protocol used by the vehicle.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically connected in modern vehicles.

OBDII Data Link Connector – Type A vs. Type B

You might encounter both Type A and Type B OBDII Data Link Connectors. Type A is generally found in cars and light vehicles, while Type B is more common in medium and heavy-duty vehicles.

As shown, both types have similar OBDII pinouts but 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). The physical design of the Data Link Connector OBDII helps distinguish between types.

Type B OBDII Data Link Connectors have an interrupted groove in the middle, making a Type B OBDII adapter cable compatible with both Type A and B sockets. However, a Type A adapter will not fit into a Type B socket.

Diagram comparing OBDII Data Link Connector Type A and Type B, highlighting differences in voltage, groove, and typical vehicle applications as per SAE J1962.

Conceptual illustration depicting the relationship between OBDII and CAN bus within the ISO 15765 framework, emphasizing the Data Link Connector OBDII as the interface point.

OBDII and CAN Bus [ISO 15765-4] via the Data Link Connector

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBDII in all US-sold vehicles, according to ISO 15765. The Data Link Connector OBDII is the physical interface for this CAN bus communication.

ISO 15765-4 (Diagnostics over CAN or DoCAN) specifies restrictions applied to the CAN standard (ISO 11898). It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers, all accessible through the Data Link Connector OBDII:

CAN bus bit-rate must be 250K or 500K.
CAN IDs can be 11-bit or 29-bit.
Specific CAN IDs are reserved for OBDII requests and responses.
Diagnostic CAN frame data length is 8 bytes.
The OBDII adapter cable, connecting to the Data Link Connector OBDII, must be max 5 meters.

OBDII CAN Identifiers (11-bit, 29-bit) and the Data Link Connector

All OBDII communication involves request/response message pairs transmitted via the Data Link Connector OBDII.

In most cars, 11-bit CAN IDs are used for OBDII communication. The ‘Functional Addressing’ ID is 0x7DF, which queries all OBDII-compatible ECUs for data on the requested parameter (ISO 15765-4). CAN IDs 0x7E0-0x7E7 are for ‘Physical Addressing’ requests to specific ECUs, less commonly used in standard OBDII diagnostics via the Data Link Connector OBDII.

ECUs respond with 11-bit IDs 0x7E8-0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module) and, to some extent, 0x7E9 (TCM, Transmission Control Module), both communicating through the Data Link Connector OBDII.

Some vehicles (vans, light/medium/heavy-duty vehicles) use extended 29-bit CAN identifiers for OBDII communication through their Data Link Connector OBDII.

The ‘Functional Addressing’ CAN ID here is 0x18DB33F1.

Responses use CAN IDs 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is also sometimes represented as ‘J1939 PGN’ PGN 0xDA00 (55808), which in the J1939-71 standard is ‘Reserved for ISO 15765-2’. Regardless of the ID format, communication is channeled via the Data Link Connector OBDII.

Diagram illustrating OBDII protocol request and response frames, showing the flow of data through the Data Link Connector OBDII for parameter identification and data retrieval.

OBD2 OBD CAN bus Identifiers 7DF 7E8 7E0

Comparison graphic contrasting OBDII standard CAN bus data with proprietary OEM-specific CAN bus data, highlighting the role of the Data Link Connector OBDII in accessing both types of information.

OBDII vs. Proprietary CAN Protocols and the Data Link Connector

Vehicle Electronic Control Units (ECUs) operate using OEM-proprietary CAN protocols, independently of OBDII. These CAN protocols are specific to vehicle brand, model, and year. Unless you are the OEM or have reverse-engineered these protocols, this data is typically inaccessible. However, the Data Link Connector OBDII might still provide access to some of this data.

Connecting a CAN bus data logger to your car’s OBDII Data Link Connector may reveal OEM-specific CAN data, often broadcast at 1000-2000 frames/second. However, many newer vehicles use a ‘gateway’ to restrict access to this CAN data, allowing only OBDII communication via the Data Link Connector OBDII.

Think of OBDII as a higher-layer protocol running in parallel to the OEM-specific protocol, both potentially accessible through the Data Link Connector OBDII, though with varying degrees of restriction.

Bit-rate and ID Validation via the Data Link Connector

OBDII can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), creating 4 possible combinations for communication through the Data Link Connector OBDII. Modern cars commonly use 500K and 11-bit IDs, but diagnostic tools should systematically verify this.

ISO 15765-4 recommends an initialization sequence to determine the correct combination. This process leverages the fact that OBDII-compliant vehicles must respond to a mandatory OBDII request (see OBDII PID section) and that incorrect bit-rates cause CAN error frames. Testing these combinations is typically done via the Data Link Connector OBDII.

Newer ISO 15765-4 versions account for OBD communication via OBDonUDS versus OBDonEDS. This article mainly discusses OBDII/OBDonEDS (OBD on Emission Diagnostic Service per ISO 15031-5/SAE J1979) rather than WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service per ISO 14229, ISO 27145-3/SAE J1979-2). The protocol in use affects communication methods through the Data Link Connector OBDII.

To differentiate between OBDonEDS and OBDonUDS, test tools may send additional UDS requests via the Data Link Connector OBDII, using 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.

OBDonEDS (OBDII, SAE OBD, EOBD, or ISO OBD) is prevalent in non-EV cars today, while WWH-OBD is primarily used in EU trucks/buses. Diagnostic tools must correctly interpret responses received through the Data Link Connector OBDII based on these protocols.

Flowchart illustrating the OBDII bit-rate and CAN ID validation process according to ISO 15765-4, essential for establishing correct communication via the Data Link Connector OBDII.

Diagram outlining the five lower-layer OBDII protocols including CAN (ISO 15765), KWP2000, SAE J1850, and ISO 9141, showing the evolution of communication standards accessible through the Data Link Connector OBDII.

Five Lower-Layer OBDII Protocols and the Data Link Connector

CAN is now the dominant lower-layer protocol for OBDII as per ISO 15765. However, older (pre-2008) vehicles may use other protocols. Understanding these and their Data Link Connector OBDII pinouts is useful for diagnostics on older cars:

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

Understanding these protocols helps in diagnosing a wider range of vehicles using the Data Link Connector OBDII.

Transporting OBDII Messages via ISO-TP [ISO 15765-2] through the Data Link Connector

All OBDII data is transmitted over CAN bus using ISO-TP (ISO 15765-2), a transport protocol that enables payloads exceeding 8 bytes. This is crucial for OBDII functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of messages transmitted via the Data Link Connector OBDII. For more details, refer to our UDS introduction.

Often, OBDII data fits within a single CAN frame. ISO 15765-2 specifies ‘Single Frame’ (SF) usage, where the first data byte (PCI field) contains the payload length (excluding padding), leaving 7 bytes for OBDII communication within each frame sent through the Data Link Connector OBDII.

Diagram illustrating ISO 15765-2 ISO-TP OBDII frame types, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame, detailing how data is structured for transmission via the Data Link Connector OBDII.

The OBDII Diagnostic Message [SAE J1979, ISO 15031-5] via the Data Link Connector

To understand OBDII on CAN, consider a raw ‘Single Frame’ OBDII CAN message transmitted and received through the Data Link Connector OBDII. An OBDII message comprises an identifier, data length (PCI field), and data. The data section is further divided into Mode, Parameter ID (PID), and data bytes.

Breakdown of an OBDII message structure, showing the arrangement of Mode, Parameter ID (PID), and data bytes within a CAN frame transmitted via the Data Link Connector OBDII.

Example: OBDII Request/Response via the Data Link Connector

Consider a request/response example for ‘Vehicle Speed’ parameter accessed via the Data Link Connector OBDII.

An external tool sends a request message to the car with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds via CAN ID 0x7E8 with 3 payload bytes, including the Vehicle Speed value in the 4th byte, 0x32 (50 in decimal). This entire exchange happens via the Data Link Connector OBDII.

Referring to OBDII PID 0x0D decoding rules, the physical value is 50 km/h.

Next, we will explore OBDII modes and PIDs in detail, all relevant to data accessed via the Data Link Connector OBDII.

Example of an OBDII request (ID 7DF) and response (ID 7E8) for vehicle speed, illustrating the communication flow through the Data Link Connector OBDII.

Detailed example of OBDII PID 0D for Vehicle Speed, showing the data encoding and decoding process relevant to data accessed via the Data Link Connector OBDII.

Overview of OBDII service modes including current data, freeze frame, and clear DTC, outlining the diagnostic services available through the Data Link Connector OBDII.

The 10 OBDII Services (Modes) via the Data Link Connector

OBDII defines 10 diagnostic services or modes, all accessible through the Data Link Connector OBDII. Mode 0x01 displays real-time data, while others show/clear DTCs or display freeze frame data.

Vehicles are not required to support all OBDII modes and may have OEM-specific modes beyond the 10 standard ones. The availability of these modes can be interrogated via the Data Link Connector OBDII.

In OBDII messages, the mode is in the 2nd byte. In requests, the mode is direct (e.g., 0x01), while in responses, 0x40 is added to the mode (e.g., resulting in 0x41). These mode codes are crucial for interpreting data received via the Data Link Connector OBDII.

OBDII Parameter IDs (PIDs) and the Data Link Connector

Each OBDII mode contains Parameter IDs (PIDs). Mode 0x01, for instance, has ~200 standardized PIDs for real-time data like speed, RPM, and fuel level, all retrievable through the Data Link Connector OBDII. However, vehicles typically support only a subset of PIDs within each mode.

One PID is particularly important:

If an emissions-related ECU supports any OBDII 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 ‘OBDII compatibility test’ when connecting via the Data Link Connector OBDII. Similarly, PIDs 0x20, 0x40, …, 0xC0 determine support for subsequent mode 0x01 PIDs.

(Reused image) Diagram illustrating OBDII protocol request and response frames, emphasizing PID data parameters and their access via the Data Link Connector OBDII.

OBD2 PID overview tool
Screenshot of an OBDII PID overview tool, demonstrating how to look up and interpret PID data obtained through the Data Link Connector OBDII.

Tip: OBDII PID Overview Tool for Data Link Connector Users

SAE J1979 and ISO 15031-5 appendices provide scaling information for standard OBDII PIDs, allowing you to decode data into physical values, as explained in our CAN bus intro. This decoding is crucial for interpreting data from the Data Link Connector OBDII.

For quick lookup of mode 0x01 PIDs, use our OBDII PID overview tool. It helps construct OBDII request frames and dynamically decode OBDII responses obtained via the Data Link Connector OBDII.

OBDII PID overview tool

How to Log and Decode OBDII Data from the Data Link Connector

This section demonstrates how to log OBDII data using the CANedge CAN bus data logger, connected through the Data Link Connector OBDII.

The CANedge allows configuration of custom CAN frames for transmission, enabling its use for OBDII logging via the Data Link Connector OBDII.

Once configured, connect the CANedge to your vehicle using our OBDII-DB9 adapter cable and the Data Link Connector OBDII.

Diagram illustrating an OBDII PID data logger requesting data via CAN IDs 7DF and 7E8 through the Data Link Connector OBDII.

OBD2 bit rate test
Screenshot showing bit-rate validation for OBDII communication, a necessary step before logging data through the Data Link Connector OBDII.

OBD2 Supported PIDs Test
Screenshot from asammdf software showing OBDII supported PIDs test responses, useful for verifying data availability through the Data Link Connector OBDII.

Review supported PIDs via OBD2 lookup tool

#1: Test Bit-rate, IDs & Supported PIDs via the Data Link Connector

As discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a vehicle. Test this using CANedge as follows (see CANedge Intro for details):

Send a CAN frame at 500K and check for success (if not, try 250K) through the Data Link Connector OBDII.
Use the identified bit-rate for subsequent communication via the Data Link Connector OBDII.
Send multiple ‘Supported PIDs’ requests and review results obtained through the Data Link Connector OBDII.
Determine 11-bit vs. 29-bit IDs based on response IDs received via the Data Link Connector OBDII.
Identify supported PIDs based on response data retrieved through the Data Link Connector OBDII.

We provide plug & play configurations to perform these tests via the Data Link Connector OBDII.

Most 2008+ non-EV cars support 40-80 PIDs using 500K bit-rate, 11-bit CAN IDs, and the OBDII/OBDonEDS protocol, all accessible through the Data Link Connector OBDII.

As illustrated in the asammdf GUI screenshot, multiple responses to a single OBD request are common due to the use of the 0x7DF request ID, which polls all ECUs. Since all OBDII/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, many responses to this PID are typical. Subsequent ‘Supported PIDs’ requests receive fewer responses. The ECM ECU (0x7E8) often supports all PIDs supported by other ECUs in this example. Thus, reducing busload is possible by specifically requesting responses from this ECU using ‘Physical Addressing’ CAN ID 0x7E0 for subsequent communication via the Data Link Connector OBDII.

#2: Configure OBDII PID Requests for Data Link Connector Logging

Now that you know your vehicle’s supported OBDII PIDs, bit-rate, and CAN IDs, configure your transmit list with desired PIDs for logging via the Data Link Connector OBDII.

Consider these points:

CAN IDs: Shift to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses and reduce busload when communicating through the Data Link Connector OBDII.
Spacing: Add 300-500 ms between OBDII requests. ECUs may not respond if spammed, affecting data logging via the Data Link Connector OBDII.
Battery Drain: Use triggers to stop transmissions when the vehicle is inactive to prevent ECU ‘wake-up’ and battery drain during logging sessions via the Data Link Connector OBDII.
Filters: Add filters to record only OBDII responses if your vehicle also outputs OEM-specific CAN data through the Data Link Connector OBDII.

After configuration, the device is ready to log raw OBDII data from the Data Link Connector OBDII!

obd2-transmit-list-example-canedge
Example of a CANedge OBDII PID request transmit list, showing configuration for data logging via the Data Link Connector OBDII.

OBD2 data decoded visual plot asammdf CAN bus DBC file
Visualization of decoded OBDII data plotted in asammdf using a CAN bus DBC file, illustrating data analysis after logging via the Data Link Connector OBDII.

#3: DBC Decode Raw OBDII Data from the Data Link Connector

To analyze and visualize logged data from the Data Link Connector OBDII, decode the raw OBDII data into ‘physical values’ (e.g., km/h, °C).

Decoding information is in ISO 15031-5/SAE J1979 and online resources like Wikipedia. We offer a free OBDII DBC file for easy DBC decoding of raw OBDII data in most CAN bus software tools. This DBC file is essential for interpreting data captured from the Data Link Connector OBDII.

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

Solution: Use the CAN ID, OBDII mode, and OBDII PID to identify the signal. This ‘extended multiplexing’ is implementable in DBC files. Proper DBC files are crucial for correctly interpreting data logged via the Data Link Connector OBDII.

CANedge: OBDII Data Logger for the Data Link Connector

The CANedge simplifies OBDII data recording to an 8-32 GB SD card when connected to the Data Link Connector OBDII. Simply connect to a car/truck to start logging and decode data using free software/APIs and our OBDII DBC.

OBDII logger intro
CANedge

OBDII Multi-Frame Examples [ISO-TP] via the Data Link Connector

OBDII data communication, including multi-frame, uses ISO-TP (ISO 15765-2) via the Data Link Connector OBDII. Most examples so far are single-frame. This section shows multi-frame communication examples.

Multi-frame OBDII communication requires flow control frames (see our UDS intro). A static flow control frame can be sent ~50 ms after the initial request, as shown in the CANedge configuration example. These frames are exchanged via the Data Link Connector OBDII.

Multi-frame OBDII responses need CAN software/API tools supporting ISO-TP, like CANedge MF4 decoders. These tools are essential for processing complex data from the Data Link Connector OBDII.

OBD2-multi-frame-request-message-vehicle-identification-number
Example of an OBDII multi-frame request message for Vehicle Identification Number (VIN), demonstrating complex data requests via the Data Link Connector OBDII.

Example 1: OBDII Vehicle Identification Number (VIN) Retrieval via the Data Link Connector

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, etc. (see our UDS intro). Retrieve VIN using OBDII mode 0x09 and PID 0x02 via the Data Link Connector OBDII:

VIN Vehicle Identification Number OBD2 Example multi-frame

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

The vehicle responds with a First Frame containing PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Byte 0x01 follows the PID, representing Number Of Data Items (NODI), in this case, 1 (ISO 15031-5 / SAE J1979). The remaining 17 bytes are the VIN, convertible from HEX to ASCII using methods in our UDS intro. All data exchange occurs via the Data Link Connector OBDII.

Example 2: OBDII Multi-PID Request (6x) via the Data Link Connector

External tools can request up to 6 mode 0x01 OBDII PIDs in a single request frame via the Data Link Connector OBDII. The ECU responds with data for supported PIDs (omitting unsupported ones), possibly across multiple frames (ISO-TP).

This efficient method increases data collection frequency, but signal encoding is request-specific, complicating generic OBDII DBC file use. We advise against this method practically. Below is a sample trace of such communication through the Data Link Connector OBDII:

Requesting multiple PIDs in one request

The multi-frame response resembles the VIN example, but the payload includes requested PIDs and their data. PIDs in the example are ordered as requested (common but not ISO 15031-5 standard requirement). Decoding these complex responses requires careful handling of data from the Data Link Connector OBDII.

DBC file decoding of these responses is challenging, making this approach impractical for data logging unless using tools with built-in support. It involves extended multiplexing with multiple instances throughout the payload. DBC files would need to account for each PID’s specific payload position, making generalization across vehicles difficult. Handling multiple multi-PID requests via pure DBC manipulations becomes nearly impossible. Analyzing such data streams from the Data Link Connector OBDII requires specialized tools and techniques.

Workarounds include custom scripts and recording transmit messages to interpret responses based on requests, but these are difficult to scale. For most users, standard PID requests via the Data Link Connector OBDII are more manageable.

Example 3: OBDII Diagnostic Trouble Codes (DTCs) via the Data Link Connector

Use OBDII mode 0x03 (‘Show stored Diagnostic Trouble Codes’) to request emissions-related DTCs via the Data Link Connector OBDII. No PID is included in the request. Targeted ECUs respond with the number of stored DTCs (possibly 0), each DTC being 2 data bytes. Multi-frame responses are necessary for more than 2 DTCs, all communicated via the Data Link Connector OBDII.

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 form a 4-digit hexadecimal code (see visual). Decoded DTC values can be looked up using OBDII DTC lookup tools like repairpal.com. These tools help interpret diagnostic information obtained via the Data Link Connector OBDII.

Example below shows a request to an ECU with 6 stored DTCs, all accessed and retrieved through the Data Link Connector OBDII.

Diagram explaining OBDII DTC decoding and interpretation, showing how diagnostic trouble codes retrieved via the Data Link Connector OBDII are structured and analyzed.

OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response Example

OBDII Data Logging – Use Case Examples via the Data Link Connector

OBDII data from cars and light trucks, accessed via the Data Link Connector OBDII, has numerous applications:

Icon depicting OBDII data logging in a car, representing use cases enabled by accessing vehicle data through the Data Link Connector OBDII.

Logging data from cars via the Data Link Connector

OBDII data, obtained via the Data Link Connector OBDII, can reduce fuel costs, improve driving habits, test prototype parts, and inform insurance policies.

obd2 logger

Icon illustrating OBDII real-time streaming diagnostics, showcasing the use of the Data Link Connector OBDII for live vehicle data monitoring.

Real-time car diagnostics via the Data Link Connector

OBDII interfaces, connected via the Data Link Connector OBDII, enable real-time streaming of human-readable OBDII data for diagnosing vehicle issues.

obd2 streaming

Icon representing OBDII data logger use for predictive maintenance, highlighting how data from the Data Link Connector OBDII can be used for vehicle health monitoring.

Predictive maintenance via the Data Link Connector

Cars and light trucks monitored via IoT OBDII loggers, connected through the Data Link Connector OBDII, in the cloud can predict and prevent breakdowns.

predictive maintenance

Icon depicting a black box CAN logger, representing the use of Data Link Connector OBDII data for vehicle black box applications in insurance and warranty scenarios.

Vehicle black box logger via the Data Link Connector

An OBDII logger, utilizing the Data Link Connector OBDII, can serve as a ‘black box’ for vehicles or equipment, providing data for disputes or diagnostics.

can bus blackbox

Do you have an OBDII data logging use case leveraging the Data Link Connector OBDII? Reach out for free consultation!

For more introductions, see our guides section or download the ‘Ultimate Guide’ PDF.

Need to log/stream OBDII data via the Data Link Connector?

Get your OBDII data logger today!

Buy now
Contact us

Recommended for you

OBDII DATA LOGGER: EASILY LOG & CONVERT OBDII DATA

CANedge2 – Dual CAN Bus Telematics Dongle
CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBDII DATA WITH SAVVYCAN