Understanding the OBD2 Port: Your Car's Diagnostic Gateway

Need a simple, practical intro to OBD2 ports?

In this guide, we introduce the On-Board Diagnostic (OBD2) system, focusing on the OBD2 port. We’ll cover the OBD2 connector, OBD2 parameter IDs (PIDs), and its connection to the CAN bus.

Note: This is a practical intro designed to help you understand the OBD2 port. You’ll learn how to access and interpret OBD2 data via the port, key use cases for data logging, and practical tips for working with your OBD2 port.

Discover why this guide is becoming a go-to resource for understanding the OBD2 port.

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

What is an OBD2 Port?

The OBD2 port is your vehicle’s access point to its built-in self-diagnostic system. It’s a standardized connector that allows you to retrieve diagnostic trouble codes (DTCs) and real-time data. Think of the OBD2 port as the gateway to your car’s health information.

You’ve likely encountered OBD2 indirectly:

Ever seen the malfunction indicator light (often called the “check engine light”) on your dashboard?

That light is your car signaling a potential issue. When you take your car to a mechanic, they use an OBD2 scanner to diagnose the problem, connecting it directly to the OBD2 port.

The OBD2 port is typically a 16-pin connector located near the steering wheel. Mechanics use an OBD2 reader to plug into this port, sending ‘OBD2 requests’ to the car’s computer. The car then responds with ‘OBD2 responses’ containing valuable data such as speed, fuel level, and Diagnostic Trouble Codes (DTCs). This direct access via the OBD2 port makes troubleshooting vehicle issues faster and more efficient.

Does Your Car Have an OBD2 Port?

In short: Almost certainly!

Nearly all modern, non-electric cars are equipped with an OBD2 port, and most of these systems communicate using the CAN bus protocol. For older vehicles, it’s worth noting that while a 16-pin connector might be present, it may not actually support OBD2. A quick way to check for OBD2 compatibility is to consider where and when your car was originally purchased:

Does My Car Have OBD2?

A Brief History of OBD2 and the OBD2 Port

The story of the OBD2 port begins in California. The California Air Resources Board (CARB) mandated the use of On-Board Diagnostics (OBD) in all new cars starting from 1991 for the purpose of controlling vehicle emissions.

The OBD2 standard, including the OBD2 port specification, was further refined and recommended by the Society of Automotive Engineers (SAE). This led to the standardization of DTCs and the OBD connector across different vehicle manufacturers through the SAE J1962 standard. This standardization is what ensures that any compliant OBD2 scanner can effectively interface with the OBD2 port of any compliant vehicle.

From its Californian origins, the OBD2 standard was progressively implemented worldwide:

1996: OBD2 became mandatory in the USA for all cars and light trucks.
2001: The European Union required OBD2 for gasoline cars.
2003: The EU extended the requirement to diesel cars as well (known as EOBD in Europe).
2005: OBD2 was mandated in the US for medium duty vehicles.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the communication protocol for OBD2 via the OBD2 port.
2010: Finally, OBD2 compliance through the OBD2 port was required for heavy duty vehicles in the US.

The Future of OBD2 Ports and Vehicle Diagnostics

The OBD2 port is expected to remain a key feature in vehicles, but its role and implementation are evolving.

Originally designed for emissions control and testing, legislated OBD2 is not strictly required for electric vehicles. Consequently, most modern EVs do not fully support standard OBD2 requests via the OBD2 port. Instead, they often utilize OEM-specific UDS communication protocols. This shift can make accessing data from EVs challenging, except in cases where decoding methods have been reverse-engineered. Examples of such reverse engineering efforts include studies on Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Today, OBD2 implementations and the data accessible through the OBD2 port can vary in richness and protocol complexity. Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are being developed to address these limitations. These protocols aim to enhance OBD communication by using the UDS protocol as a foundation. For a deeper understanding of these protocols, refer to our intro to UDS.

In an increasingly connected world, traditional OBD2 testing via the OBD2 port can seem outdated. 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 bridge tolls. This technology would allow the car’s 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 transferring CAN or OBD2 data via WiFi or cellular networks.

While offering convenience and cost savings, OBD3 also raises political challenges related to surveillance and data privacy.

The OBD2 protocol, accessed through the OBD2 port, was initially intended for stationary emission controls.

However, today, the OBD2 port is widely used by third parties to generate real-time vehicle data via OBD2 dongles, CAN loggers and similar devices. This trend is facing pushback from the German car industry, which aims to restrict third-party access:

OBD was designed for servicing 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 industry proposal involves disabling OBD2 port functionality while driving, centralizing data collection with manufacturers. This would give manufacturers control over automotive big data and is argued to enhance security by reducing car hacking risks. However, critics view this as a commercially motivated move to control vehicle data, potentially disrupting the market for third-party OBD2 port services. Whether this trend will prevail remains to be seen, but it could significantly alter the landscape for OBD2 port applications.

Get our ‘Ultimate CAN Guide’

Want to become a CAN bus expert?

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

Download now

CAN Bus – The Ultimate Guide Tutorial PDF

OBD2 Standards and the OBD2 Port

On-board diagnostics, OBD2, operates as a higher layer protocol – essentially a language for vehicle communication. CAN, on the other hand, is the communication method, similar to a phone line. This makes OBD2 comparable to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

Specifically, OBD2 standards define the OBD2 port connector, lower-layer communication protocols, OBD2 parameter IDs (PIDs), and more.

These standards can be organized within a 7-layer OSI model. The following sections will focus on the most crucial aspects relevant to the OBD2 port.

In the OSI model context, you’ll notice that both SAE and ISO standards cover multiple layers. This reflects the development of OBD standards in the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, for instance, SAE J1979 corresponds to ISO 15031-5, and SAE J1962 is equivalent to ISO 15031-3 in terms of OBD2 port specifications.

Deep Dive into the OBD2 Port Connector (SAE J1962)

The 16-pin OBD2 port connector is your physical interface for accessing vehicle data. Its specifications are detailed in the SAE J1962 / ISO 15031-3 standards.

The illustration shows a typical Type A OBD2 pin connector (also known as the Data Link Connector, or DLC).

Key points to note about the OBD2 port:

The OBD2 port is usually located near the steering wheel, but it can sometimes be hidden.
Pin 16 provides battery power, often even when the ignition is off, allowing for scanner operation without the car running.
The OBD2 port pinout configuration varies depending on the communication protocol used.
CAN bus is the most prevalent lower-layer protocol, which means pins 6 (CAN-H) and 14 (CAN-L) on the OBD2 port are commonly used for communication.

OBD2 Connector Types: Type A vs. Type B

In practice, you might encounter both Type A and Type B OBD2 port connectors. Type A is standard in cars and light vehicles, while Type B is more common in medium and heavy-duty vehicles.

As shown in the illustration, both types have similar OBD2 pinouts but differ in power supply outputs: Type A typically provides 12V, while Type B provides 24V. Baud rates can also differ, with cars generally using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing).

To differentiate them physically, the Type B OBD2 port connector has a distinct interrupted groove in the middle. This design means a Type B OBD2 adapter cable is compatible with both Type A and Type B ports, whereas a Type A adapter will not fit into a Type B port.

OBD2 Communication over CAN Bus (ISO 15765-4)

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as specified by ISO 15765. This means that communication through the OBD2 port in most modern vehicles relies on CAN bus.

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) defines a set of constraints applied to the CAN standard (ISO 11898) for diagnostic purposes via the OBD2 port.

Specifically, it standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:

The CAN bus bit-rate must be either 250K or 500K for OBD2 port communication.
CAN IDs can be 11-bit or 29-bit.
Specific CAN IDs are designated for OBD requests and responses through the OBD2 port.
Diagnostic CAN frame data length is fixed at 8 bytes.
The OBD2 adapter cable connected to the OBD2 port must not exceed 5 meters in length.

OBD2 CAN Identifiers (11-bit and 29-bit)

All OBD2 communication via the OBD2 port involves request and response messages.

In most cars, 11-bit CAN IDs are used for OBD2 communication through the OBD2 port. The ‘Functional Addressing’ ID is 0x7DF, which is used to query all OBD2-compatible ECUs to check if they have data for the requested parameter (as per ISO 15765-4). CAN IDs from 0x7E0 to 0x7E7 are used for ‘Physical Addressing’ requests to specific ECUs, although this is less common for general OBD2 scanning via the OBD2 port.

ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module). These responses are typically sent back through the OBD2 port.

In some vehicles, particularly vans and light/medium/heavy-duty vehicles, OBD2 port communication may use extended 29-bit CAN identifiers instead of 11-bit IDs.

For 29-bit IDs, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses in 29-bit systems are seen with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (commonly 18DAF110 and 18DAF11E). The response ID is also sometimes represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which in the J1939-71 standard is ‘Reserved for ISO 15765-2’. All of these communications are designed to be accessed and interpreted via the OBD2 port.

OBD2 OBD CAN bus Identifiers 7DF 7E8 7E0

OBD2 vs. Proprietary CAN Protocols

It’s crucial to understand that your car’s electronic control units (ECUs) do not depend on OBD2 for their primary functions. Instead, each vehicle manufacturer (OEM) implements its own proprietary CAN protocols for core vehicle operations. These OEM-specific CAN protocols are often unique to the vehicle brand, model, and year. Unless you are the OEM, interpreting this proprietary data, even if accessible through the OBD2 port, is typically not possible without reverse engineering.

When you connect a CAN bus data logger to your car’s OBD2 port, you might observe OEM-specific CAN data, typically broadcast at a high rate of 1000-2000 frames per second. However, in many newer vehicles, a ‘gateway’ system restricts access to this CAN data through the OBD2 port, only allowing OBD2 communication.

In essence, think of OBD2 as an ‘additional’ higher-layer protocol that operates alongside the OEM-specific protocols. The OBD2 port serves as the standardized access point for this diagnostic layer, separate from the vehicle’s fundamental operational network.

Bit-rate and ID Validation

As discussed, OBD2 via the OBD2 port can use one of two bit-rates (250K, 500K) and either 11-bit or 29-bit CAN IDs. This leads to four possible combinations. Modern cars most commonly use 500K with 11-bit IDs, but external tools should systematically verify these settings when connecting to the OBD2 port.

ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination, illustrated in the flowchart. This method relies on the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request through the OBD2 port (see the OBD2 PID section for details). It also leverages the fact that transmitting data at an incorrect bit-rate will cause CAN error frames.

Newer 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). Both protocols are accessed through the same OBD2 port, but use different communication methods.

To test for OBDonEDS vs OBDonUDS protocols, a diagnostic tool can send additional request messages via the OBD2 port, specifically UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS must have ECUs that respond to this DID through the OBD2 port.

In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is used in most non-EV cars today, while WWH-OBD is primarily used in EU trucks and buses, both accessible via the OBD2 port.

Five Lower-Layer OBD2 Protocols

CAN is now the dominant lower-layer protocol for OBD2 in most vehicles, as per ISO 15765, and accessed through the OBD2 port.

However, when working with older vehicles (pre-2008), understanding the other four lower-layer protocols used for OBD2 is beneficial. The OBD2 port pinouts themselves can sometimes indicate which protocol is in use.

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now the most common protocol for OBD2 port communication.
ISO14230-4 (KWP2000): Keyword Protocol 2000, frequently used in 2003+ vehicles, particularly in Asia, accessed via the OBD2 port.
ISO 9141-2: Used in EU, Chrysler, and Asian cars from 2000-2004, also accessed through the OBD2 port.
SAE J1850 (VPW): Predominantly used in older GM vehicles, interfacing through the OBD2 port.
SAE J1850 (PWM): Mainly found in older Ford vehicles, again, accessed via the OBD2 port.

OBD2 Messaging and ISO-TP (ISO 15765-2)

All OBD2 data transmitted and received through the OBD2 port uses the ISO-TP (transport protocol) as defined in ISO 15765-2. This protocol enables the communication of data payloads larger than 8 bytes, which is necessary for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages for efficient OBD2 port communication. For more details, see our intro to UDS.

However, much OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF). Here, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for the actual OBD2 communication through the OBD2 port.

Understanding the OBD2 Diagnostic Message (SAE J1979, ISO 15031-5)

To better understand OBD2 communication via the OBD2 port and CAN, let’s examine a simplified ‘Single Frame’ OBD2 CAN message. An OBD2 message, in its basic form, includes an identifier, a data length indicator (PCI field), and the data itself. The data is further structured into Mode, parameter ID (PID), and data bytes.

Example: OBD2 Request/Response

Before detailing each part of the OBD2 message structure, let’s consider a practical example: requesting and receiving ‘Vehicle Speed’ data through the OBD2 port.

In this scenario, an external tool sends a request message to the car via the OBD2 port. This message has a CAN ID of 0x7DF and contains 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds via the OBD2 port with a CAN ID of 0x7E8 and 3 payload bytes. The 4th byte in the response, 0x32 (50 in decimal), represents the Vehicle Speed value.

By consulting the decoding rules for OBD2 PID 0x0D, we can determine that the physical value is 50 km/h. This entire exchange occurs through the OBD2 port.

Next, we will delve into OBD2 modes and PIDs, which are fundamental to interpreting data accessed via the OBD2 port.

The 10 OBD2 Services (Modes)

There are 10 defined OBD2 diagnostic services, often referred to as modes, which are accessed through the OBD2 port. Mode 0x01 is used to request current real-time data, while other modes are used to manage diagnostic trouble codes (DTCs), access freeze frame data, and more.

Vehicles are not required to support all 10 OBD2 modes via the OBD2 port, and manufacturers may also implement additional, non-standardized modes (OEM-specific OBD2 modes).

In OBD2 messages exchanged through the OBD2 port, the mode is indicated in the second byte of the data payload. In a request message, the mode is included directly (e.g., 0x01). In a response message, 0x40 is added to the requested mode (e.g., a response to mode 0x01 will start with 0x41).

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, there are Parameter IDs (PIDs). These PIDs are codes used to request specific data parameters from the vehicle’s ECUs via the OBD2 port.

For example, mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on parameters like speed, RPM, and fuel level, all accessible through the OBD2 port. However, vehicles are not obligated to support every OBD2 PID within a mode. In practice, most vehicles only support a subset of the available PIDs via their OBD2 port.

One PID is particularly significant in the context of OBD2 port interaction.

Specifically, if an emissions-related ECU supports any OBD2 services accessed through the OBD2 port, then it must support mode 0x01 PID 0x00. When PID 0x00 is requested in mode 0x01, the vehicle ECU responds by indicating which PIDs in the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’ when initiating communication through the OBD2 port. Furthermore, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs, all accessible via the OBD2 port.

OBD2 PID overview tool

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 contain scaling information for standard OBD2 PIDs, which is essential for decoding raw data into meaningful physical values (as explained in our CAN bus intro). This decoding process is crucial when working with data obtained through the OBD2 port.

If you need to quickly look up a mode 0x01 PID and understand its parameters for use with your OBD2 port, check out our OBD2 PID overview tool. This tool helps you construct OBD2 request frames and dynamically decode OBD2 responses, making it easier to interact with your OBD2 port.

OBD2 PID overview tool

How to Log and Decode OBD2 Port Data

In this section, we’ll provide a practical example of how to log OBD2 data using the CANedge CAN bus data logger, connected via the OBD2 port.

The CANedge allows you to configure custom CAN frames for transmission, making it ideal for OBD2 logging through the OBD2 port.

Once configured, the CANedge can be easily connected to your vehicle’s OBD2 port using our OBD2-DB9 adapter cable.

OBD2 bit rate test You can send a CAN frame at e.g. 500K, then check if it is successfully sent

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

Review supported PIDs via OBD2 lookup tool

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

As previously discussed, ISO 15765-4 outlines how to determine the bit-rate and CAN IDs used by a specific vehicle’s OBD2 port. You can perform these tests using the CANedge as follows (refer to the CANedge Intro for detailed instructions):

Send CAN frame at 500K and check if successful: If not, try 250K to establish communication with the OBD2 port.
Use the identified bit-rate for all subsequent communication via the OBD2 port.
Send multiple ‘Supported PIDs’ requests through the OBD2 port and analyze the responses.
Determine 11-bit vs. 29-bit CAN IDs based on the response IDs received from the OBD2 port.
Identify supported PIDs by examining the response data received through the OBD2 port.

We provide plug-and-play configurations to simplify these initial tests when connecting to an OBD2 port.

Most non-EV cars manufactured from 2008 onwards typically support 40-80 PIDs via the OBD2 port, using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

As shown in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBD request, especially when using the 0x7DF request ID. This is because 0x7DF is a functional address that polls all ECUs for a response through the OBD2 port. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, you often get numerous responses to this specific PID. Subsequent ‘Supported PIDs’ requests usually result in fewer ECU responses, as fewer ECUs support a broader range of PIDs via the OBD2 port. Note also that the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs. This means you could reduce bus load by directing subsequent requests only to the ECM using ‘Physical Addressing’ with CAN ID 0x7E0 for more targeted communication via the OBD2 port.

#2: Configure OBD2 PID Requests

Once you’ve identified the OBD2 PIDs supported by your vehicle and the correct bit-rate and CAN IDs to use for communication through the OBD2 port, the next step is to configure your data logger to request the PIDs of interest.

Consider these points when setting up your PID requests for OBD2 port logging:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses to each request, streamlining data from the OBD2 port.
Spacing: Add 300-500 ms intervals between each OBD2 request to prevent overwhelming the ECUs, ensuring reliable responses via the OBD2 port.
Battery drain: Use triggers to stop transmitting requests when the vehicle is inactive to prevent battery drain, especially during prolonged OBD2 port connections when the vehicle is off.
Filters: Implement filters to record only OBD2 responses if your vehicle also broadcasts OEM-specific CAN data through the OBD2 port, reducing data clutter and focusing on relevant diagnostic information.

With these configurations, your device is ready to efficiently log raw OBD2 data from the OBD2 port.

obd2-transmit-list-example-canedge An example list of CANedge OBD2 PID requests

OBD2 data decoded visual plot asammdf CAN bus DBC file asammdf lets you DBC decode and visualize OBD2 data

#3: DBC Decode Raw OBD2 Data

Finally, to analyze and visualize the logged OBD2 data from your OBD2 port, you need to decode the raw data into ‘physical values’ such as km/h or °C.

The necessary decoding information is specified in ISO 15031-5/SAE J1979 and is also widely available (e.g., on Wikipedia). For convenience, we provide a free OBD2 DBC file that simplifies DBC decoding of raw OBD2 data in most CAN bus software tools. This DBC file is essential for making sense of the data collected from your OBD2 port.

Decoding OBD2 data is somewhat more complex than standard CAN signal decoding because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is insufficient to determine the signals encoded in the payload received from the OBD2 port.

To solve this, you must use the CAN ID, OBD2 mode, and OBD2 PID together to correctly identify each signal. This technique is a form of multiplexing known as ‘extended multiplexing,’ which can be effectively implemented using DBC files. Using a DBC file tailored for OBD2 ensures accurate interpretation of the data from your OBD2 port.

CANedge: OBD2 Data Logger

The CANedge provides an easy way to record OBD2 data from your OBD2 port directly to an 8-32 GB SD card. Simply connect it to your car or truck’s OBD2 port to start logging. You can then decode and analyze the data using free software and APIs and our OBD2 DBC file.

OBD2 logger intro

CANedge

OBD2 Multi-Frame Examples (ISO-TP)

All OBD2 data communication through the OBD2 port uses the ISO-TP (transport protocol) as per ISO 15765-2. While many examples involve single-frame communication, some OBD2 functions require multi-frame communication.

Multi-frame OBD2 communication, essential for transmitting larger datasets via the OBD2 port, requires flow control frames (see our UDS intro). In practice, this can be managed by transmitting a static flow control frame approximately 50 ms after the initial request frame, as shown in the CANedge configuration example.

Furthermore, processing multi-frame OBD2 responses from the OBD2 port requires CAN software and API tools that support ISO-TP, such as the CANedge MF4 decoders.

OBD2-multi-frame-request-message-vehicle-identification-number

Example 1: OBD2 Vehicle Identification Number (VIN)

The Vehicle Identification Number (VIN), often crucial for telematics and diagnostics (see our intro to UDS for details), can be retrieved from a vehicle using OBD2 requests via the OBD2 port. To extract the VIN, use mode 0x09 and PID 0x02:

VIN Vehicle Identification Number OBD2 Example multi-frame

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

The vehicle responds via the OBD2 port with a First Frame containing the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is the byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case (see ISO 15031-5 / SAE J1979 for more details). The subsequent 17 bytes contain the VIN, which can be converted from HEX to ASCII format using methods described in our UDS introduction. This entire process leverages the OBD2 port for communication.

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

External diagnostic tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame through the OBD2 port. The ECU will respond with data for all supported PIDs (omitting data for unsupported PIDs in the response), potentially using multiple frames as per ISO-TP if necessary.

This multi-PID request feature can enhance data collection frequency and efficiency via the OBD2 port. However, it also complicates signal encoding, making standard OBD2 DBC files less effective for decoding. We generally advise against using this method in practice due to its complexity. Below is an example trace illustrating how such a multi-PID request might appear when interacting with the OBD2 port:

Requesting multiple PIDs in one request

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

Decoding these multi-PID responses using standard DBC files is challenging. Therefore, we do not recommend this approach for typical data logging via the OBD2 port, unless you are using tools specifically designed to handle it. Effectively, you are dealing with extended multiplexing, but with multiple instances within a single payload. Your DBC file would need to account for the payload position of each PID, making it difficult to create a generalized DBC that works across different vehicles with varying supported PIDs when accessing data through the OBD2 port.

Handling this complexity purely through DBC manipulation becomes increasingly difficult, particularly if you are sending multiple multi-PID requests. You would lack a straightforward method to differentiate these messages from each other.

Workarounds could involve custom scripts that interpret response messages in conjunction with request messages, perhaps by also recording transmit messages from your diagnostic tool. However, such methods are generally complex to scale and manage for routine OBD2 port data logging.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

You can use OBD2 to request emissions-related Diagnostic Trouble Codes (DTCs) via the OBD2 port using mode 0x03, i.e., ‘Show stored Diagnostic Trouble Codes’. No PID is included in the request. The targeted ECU(s) will respond with the number of DTCs stored (which could be zero if no DTCs are present), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than two DTCs are stored.

The 2-byte DTC value is typically structured into two parts, as specified in ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’ of the DTC, while the remaining 14 bits form a 4-digit code (displayed in hexadecimal), as shown in the visual. Decoded DTC values can be looked up using various OBD2 DTC lookup tools like repairpal.com. These lookup tools help in understanding the fault codes retrieved from the OBD2 port.

The example below illustrates a request to an ECU with 6 stored DTCs, all communicated through the OBD2 port.

OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response Example

OBD2 Data Logging – Use Case Examples

OBD2 data, easily accessible via the OBD2 port of cars and light trucks, has numerous applications:

Logging Data from Cars

OBD2 data from cars, logged through the OBD2 port, can be used to optimize fuel consumption, improve driving habits, test prototype components, and for insurance telematics.

obd2 logger

Real-time Car Diagnostics

OBD2 interfaces connected to the OBD2 port enable real-time streaming of human-readable OBD2 data, which is invaluable for diagnosing vehicle issues on the fly.

obd2 streaming

Predictive Maintenance

Cars and light trucks equipped with IoT OBD2 loggers connected to the OBD2 port can be remotely monitored in the cloud to predict and prevent potential breakdowns, enhancing vehicle uptime and reducing maintenance costs.

predictive maintenance

Vehicle Blackbox Logger

An OBD2 logger connected to the OBD2 port can serve as a ‘black box’ for vehicles or equipment, providing crucial data for dispute resolution, accident reconstruction, and in-depth diagnostics.

can bus blackbox

Do you have an OBD2 data logging use case in mind? Reach out for a free consultation!

For more introductory guides, explore our guides section or download our comprehensive ‘Ultimate Guide’ PDF.

Need to log or stream OBD2 data from your OBD2 port?

Get your OBD2 data logger today!

Buy now

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

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

[

Understanding the OBD2 Port: Your Car’s Diagnostic Gateway