Can My Car Speak OBD2? Understanding Your Vehicle's Diagnostic Protocol

Wondering if your car uses the OBD2 protocol?

This guide provides a straightforward and practical introduction to the On-Board Diagnostics 2 (OBD2) protocol, including the OBD2 connector, OBD2 Parameter IDs (PIDs), and its connection to the CAN bus.

This is designed as a user-friendly guide, so you’ll also learn how to check if your car uses OBD2, how to request and understand OBD2 data, key applications for data logging, and helpful tips.

Discover why this is considered a top resource for understanding OBD2.

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

Article Contents

Author: Martin Falch (Updated January 2025)

Download this guide as a PDF

What Exactly Is OBD2 Protocol?

OBD2 is essentially your car’s internal health monitoring system. It’s a standardized protocol that allows access to diagnostic trouble codes (DTCs) and real-time vehicle data through the OBD2 port.

You’ve likely already encountered OBD2 in action:

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

That light is your car signaling that something is amiss. When you take your car to a mechanic, they use an OBD2 scanner to figure out what’s wrong.

To do this, the mechanic plugs an OBD2 reader into the 16-pin OBD2 connector, usually located near the steering wheel. This tool sends ‘OBD2 requests’ to your car, and the car responds with ‘OBD2 responses’. These responses can include data like speed, fuel level, or Diagnostic Trouble Codes (DTCs), enabling quicker and more efficient troubleshooting.

Is My Car OBD2 Protocol Compatible?

The short answer: Most likely, yes!

Nearly all modern non-electric vehicles are OBD2 compatible, and most of these operate on the CAN bus protocol. However, for older vehicles, even if you find a 16-pin OBD2 connector, it might not actually support the OBD2 protocol. A key way to check compatibility is by considering where and when your car was originally purchased:

A Brief History of the OBD2 Protocol

The story of OBD2 begins in California. The California Air Resources Board (CARB) mandated OBD in all new vehicles starting from 1991 for the purpose of emissions control.

The OBD2 standard was then refined and recommended by the Society of Automotive Engineers (SAE), leading to standardized DTCs and a universal OBD connector across different car manufacturers (SAE J1962).

From this point, the OBD2 standard was progressively implemented worldwide:

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

The Future Path of OBD2

OBD2 is firmly established, but its future form is evolving.

Here are some key trends to consider:

Initially, regulatory OBD2 was created for emissions monitoring and testing. Consequently, electric vehicles aren’t obligated to support OBD2 in any form. This is evident as most modern EVs do not support standard OBD2 requests. Instead, they often utilize OEM-specific UDS communication protocols. This typically makes accessing data from electric vehicles challenging, except in cases where decoding methods have been reverse-engineered. Examples include our case studies on electric cars, covering brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Today, OBD2 implementation varies significantly and faces limitations in data richness and underlying communication protocols. In response, newer standards like WWH-OBD (World-Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. Both aim to improve OBD communication by using the UDS protocol as a base. For a deeper understanding of these protocols, see our introduction to UDS.

In our increasingly connected world, traditional OBD2 testing methods can seem outdated. Manual emission checks are time-consuming and costly.

The proposed solution? OBD3 – integrating telematics into all vehicles.

OBD3 concept involves adding a small radio transponder (similar to those used for toll roads) to all cars. This 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 already facilitate CAN or OBD2 data transfer via WiFi or cellular networks—for example, the CANedge2 WiFi CAN logger or the CANedge3 3G/4G CAN logger.

While this offers cost and convenience benefits, it also raises political and privacy concerns due to potential surveillance implications.

The OBD2 protocol was originally designed for in-garage emission testing.

However, today it’s widely used by third parties to generate real-time vehicle data using OBD2 dongles, CAN loggers and similar tools. Interestingly, the German automotive industry is seeking to restrict this:

“OBD was 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 proposal suggests disabling OBD2 functionality while driving and instead collecting data on a central server. This would essentially give manufacturers control over the ‘automotive big data’.

The rationale is based on security concerns (like reducing the risk of car hacking), although many perceive it as a commercially motivated move. Whether this becomes a prevalent trend remains to be seen, but it could significantly impact the market for third-party OBD2 services.

Enhance Your CAN Bus Expertise

Want to master CAN bus technology?

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

Download the Ultimate CAN Bus Guide Now

Understanding OBD2 Standards

On-board diagnostics, or OBD2, operates as a higher-layer protocol—similar to a language in communication terms. CAN (Controller Area Network) acts as the communication method itself—akin to a phone line. This positions OBD2 alongside other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

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

These standards can be organized using the 7-layer OSI model. The following sections will focus on the most critical aspects.

Looking at the OSI model, you’ll notice that SAE and ISO standards cover multiple layers. This generally reflects the standards for OBD defined in the US (SAE) and Europe (ISO). Several standards are technically very similar, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector provides easy access to your vehicle’s data and is detailed in the SAE J1962 / ISO 15031-3 standard.

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

Key points to note:

The connector is usually near the steering wheel but can sometimes be hidden.
Pin 16 provides battery power (often even when the ignition is off).
The OBD2 pinout configuration depends on the communication protocol used.
CAN bus is the most common lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically connected.

OBD2 Connector Types: A vs. B

You might encounter both Type A and Type B OBD2 connectors. Type A is generally found in cars, while Type B is common in medium and heavy-duty vehicles.

As shown in the illustration, both types have similar OBD2 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 (though 500K support is increasing).

To distinguish them physically, Type B OBD2 connectors have an interrupted groove in the center. Consequently, a Type B OBD2 adapter cable will fit both Type A and Type B sockets, but a Type A cable will not fit into a Type B socket.

OBD2 and 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, according to ISO 15765.

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) outlines specific constraints applied to the CAN standard (ISO 11898).

Specifically, 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.
OBD2 adapter cable length must not exceed 5 meters.

OBD2 CAN Identifiers: 11-bit and 29-bit

OBD2 communication always involves request and response message pairs.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID here is 0x7DF, which is used to query all OBD2-compatible ECUs to see if they have data to report on the requested parameter (as per ISO 15765-4). Conversely, CAN IDs ranging from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’ requests to specific ECUs (less commonly used).

ECUs can respond using 11-bit IDs from 0x7E8 to 0x7EF. The most frequent response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module).

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

In these cases, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses from the vehicle will use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is also sometimes presented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which in the J1939-71 standard is noted as ‘Reserved for ISO 15765-2’.

OBD2 vs. Proprietary CAN Protocols

It’s important to understand that your car’s Electronic Control Units (ECUs) do not depend on OBD2 for their primary functions. Instead, each Original Equipment Manufacturer (OEM) develops its own proprietary CAN protocols for these purposes. These proprietary CAN protocols are often unique to the specific vehicle brand, model, and year. Unless you are the OEM, interpreting this proprietary data is generally not possible without reverse engineering it.

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

In essence, think of OBD2 as an ‘additional’ higher-layer protocol operating alongside the OEM-specific protocol.

Bit-rate and ID Validation

As mentioned, OBD2 can use two different bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit). This results in four potential combinations. In contemporary vehicles, 500K and 11-bit IDs are most common, but external tools should systematically verify this.

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

Newer versions of ISO 15765-4 acknowledge that vehicles 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 test for the ‘protocol’ type—OBDonEDS versus OBDonUDS—a diagnostic tool might send additional request messages, specifically 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 known as OBD2, SAE OBD, EOBD, or ISO OBD) is predominantly used in non-EV cars today, while WWH-OBD is mainly found in EU trucks and buses.

Five Lower-Layer OBD2 Protocols

While CAN is now the dominant lower-layer protocol for OBD2 under ISO 15765 in most vehicles, particularly those from 2008 onwards, it’s helpful to know about the four other protocols used in older cars. The pinouts can also help identify which protocol your vehicle might be using.

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and widely used today.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, especially in Asia.
ISO 9141-2: Used in European, Chrysler, and Asian vehicles from 2000-2004.
SAE J1850 (VPW): Predominantly used in older General Motors (GM) vehicles.
SAE J1850 (PWM): Mainly used in older Ford vehicles.

Transporting OBD2 Messages via ISO-TP: ISO 15765-2

All OBD2 data transmission over CAN bus utilizes a transport protocol called ISO-TP (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 more details, refer to our introduction to UDS.

However, much of the time, 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) contains the payload length (excluding padding), leaving 7 bytes for OBD2-related communication.

The OBD2 Diagnostic Message: SAE J1979, ISO 15031-5

To better understand OBD2 over CAN, let’s examine a basic ‘Single Frame’ OBD2 CAN message. In simple terms, an OBD2 message consists of an identifier, a data length (PCI field), and the actual data. The data section is further divided into Mode, Parameter ID (PID), and data bytes.

Example: OBD2 Request and Response

Before diving into each part of the OBD2 message, consider this example of a request and response for ‘Vehicle Speed’.

Here, an external diagnostic tool sends a request message to the car with CAN ID 0x7DF, containing 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds with a message via CAN ID 0x7E8, which includes 3 payload bytes, with the Vehicle Speed value in the 4th byte, 0x32 (50 in decimal).

By consulting the decoding rules for OBD2 PID 0x0D, we determine that the physical value is 50 km/h.

Next, we will explore OBD2 modes and PIDs in detail.

The 10 OBD2 Services (Modes)

There are 10 defined OBD2 diagnostic services, often referred to as modes. Mode 0x01 is used to access current, real-time data, while others are used for displaying or clearing diagnostic trouble codes (DTCs), or for accessing freeze frame data.

Vehicles are not required to support all OBD2 modes, and they may also support additional modes beyond these 10 standard ones, which are known as OEM-specific OBD2 modes.

In OBD2 messages, the mode is located in the second byte. In a request message, the mode is included directly (e.g., 0x01), while in a response, 0x40 is added to the mode value (resulting in 0x41 for mode 0x01).

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, there are Parameter IDs (PIDs).

For instance, mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on parameters like speed, RPM, and fuel level. However, a vehicle does not need to support all possible OBD2 PIDs within a mode. In practice, most vehicles only support a subset of these PIDs.

One PID is particularly significant.

Specifically, if an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. In response to this PID, the vehicle’s ECU communicates which PIDs from 0x01 to 0x20 it supports. This makes PID 0x00 a fundamental tool for ‘OBD2 compatibility testing’. Furthermore, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for the remaining mode 0x01 PIDs in blocks of 32.

Tip: OBD2 PID Overview Tool

In the appendices of SAE J1979 and ISO 15031-5, you can find scaling information for standard OBD2 PIDs. This information is crucial for decoding the raw data into meaningful physical values, as detailed in our CAN bus introduction.

If you need to quickly look up a mode 0x01 PID, our OBD2 PID overview tool is a helpful resource. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.

Access the OBD2 PID overview tool here

How to Log and Decode OBD2 Data Practically

In this section, we’ll demonstrate how to practically log OBD2 data using the CANedge CAN bus data logger.

The CANedge allows configuration of custom CAN frames for transmission, making it suitable for OBD2 data logging.

Once set up, the CANedge can be easily connected to your vehicle using our OBD2-DB9 adapter cable.

You can test by sending a CAN frame at 500K to verify successful transmission

Review responses to ‘Supported PIDs’ in asammdf

Step #1: Bit-rate, IDs, and Supported PIDs Verification

As previously discussed, ISO 15765-4 details how to determine the bit rate and IDs used by a specific vehicle. You can test this with the CANedge as follows (refer to the CANedge Intro for detailed instructions):

Transmit a CAN frame at 500K and check for successful transmission (if unsuccessful, try 250K).
Use the confirmed bit rate for all subsequent communication.
Send multiple ‘Supported PIDs’ requests and analyze the responses.
Determine whether 11-bit or 29-bit IDs are in use based on response IDs.
Identify supported PIDs from the response data.

We offer plug-and-play configurations to facilitate these tests.

Most non-EV cars manufactured in 2008 or later support 40-80 PIDs, utilizing a 500K bit rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

As illustrated in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBD request. This is because we use the 0x7DF request ID, which broadcasts the request to all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are typical. As you can see, for subsequent ‘Supported PIDs’ requests, fewer ECUs respond. Note also that the ECM ECU (0x7E8) itself supports all PIDs supported by other ECUs in this example. This means bus load could be reduced by directing requests specifically to this ECU using ‘Physical Addressing’ CAN ID 0x7E0 for future communication.

Step #2: Configuring OBD2 PID Requests

Once you’ve identified the OBD2 PIDs supported by your vehicle, and the correct bit rate and CAN IDs to use, you can configure your transmit list with the PIDs you are interested in logging.

Consider these points when configuring:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses per request.
Spacing: Add a delay of 300-500 ms between each OBD2 request to prevent overwhelming the ECUs, which could cause them to stop responding.
Battery Drain: Use triggers to stop transmissions when the vehicle is inactive to prevent unnecessary battery drain by ‘waking up’ ECUs.
Filters: Implement filters to record only OBD2 responses, especially if your vehicle also broadcasts OEM-specific CAN data.

With these configurations, your device is ready to log raw OBD2 data effectively!

Example list of CANedge OBD2 PID requests

asammdf allows DBC decoding and visualization of OBD2 data

Step #3: DBC Decode of Raw OBD2 Data

Finally, to analyze and visualize your logged data, you need to decode the raw OBD2 data into ‘physical values’ like km/h or degrees Celsius.

The necessary decoding information is available in ISO 15031-5/SAE J1979 and also on platforms like Wikipedia. For convenience, we provide a free OBD2 DBC file that simplifies DBC decoding of raw OBD2 data in most CAN bus software tools.

Decoding OBD2 data is slightly more complex than regular CAN signals because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone isn’t sufficient to determine the signals encoded in the payload.

To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID to correctly identify the signal. This form of multiplexing is known as ‘extended multiplexing‘, which can be implemented in formats like DBC files.

CANedge: Your OBD2 Data Logging Solution

The CANedge makes it easy to record OBD2 data directly to an 8-32 GB SD card. Simply connect it to your car or truck to start logging, and then decode the data using free software/APIs and our OBD2 DBC file.

Explore the OBD2 logger intro
Learn more about CANedge

OBD2 Multi-Frame Examples: ISO-TP in Action

All OBD2 data communication utilizes the ISO-TP (transport protocol) as per ISO 15765-2. Most examples discussed so far have been single-frame communications. This section provides examples of multi-frame communication scenarios.

Multi-frame OBD2 communication requires flow control frames (see our UDS introduction for details). In practice, a static flow control frame can be transmitted approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.

Additionally, analyzing multi-frame OBD2 responses necessitates CAN software/API tools that support ISO-TP, such as the CANedge MF4 decoders.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more (see our UDS introduction for further details). To retrieve the VIN from a vehicle using OBD2 requests, use mode 0x09 and PID 0x02:

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

The vehicle responds with a First Frame that includes the 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 specifics). The subsequent 17 bytes contain the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction.

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

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

This feature enhances data collection efficiency and frequency, but it also means signal encoding is specific to your request method. This makes using generic OBD2 DBC files challenging for such cases. We generally advise against using this method in practice. Below is an example trace illustrating this process:

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

Decoding such responses using generic DBC files is practically very difficult. Thus, we don’t recommend this approach for general data logging unless you’re using tools specifically designed to support it. This scenario effectively represents extended multiplexing, but with multiple instances within the payload. Your DBC file would need to account for the specific payload position of each PID, making it difficult to generalize across different vehicles with varying supported PIDs. Furthermore, managing this becomes nearly impossible with pure DBC manipulations if you send multiple multi-PID requests, as you lose a method to uniquely identify these messages.

Workarounds could involve custom scripting and recording transmit messages from your testing tool. The script could then interpret the response message in context with the request message. However, such methods are complex to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

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

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

The example below shows a request to an ECU that has 6 DTCs stored.

OBD2 Data Logging: Practical Use Cases

OBD2 data from cars and light trucks has numerous applications:

Vehicle Data Logging

OBD2 data can be used to reduce fuel consumption, improve driving habits, test prototype components, and optimize insurance costs.

Explore OBD2 loggers

Real-Time Vehicle Diagnostics

OBD2 interfaces facilitate real-time streaming of human-readable OBD2 data, ideal for diagnosing vehicle issues and monitoring performance.

Learn about OBD2 streaming

Predictive Maintenance Applications

Cars and light trucks equipped with IoT OBD2 loggers can be monitored in the cloud to predict and prevent potential breakdowns, enhancing vehicle reliability.

Discover predictive maintenance solutions

Vehicle Black Box Logging

An OBD2 logger can serve as a ‘black box’ for vehicles or equipment, providing crucial data for dispute resolution or in-depth diagnostics.

Learn about CAN bus black box applications

Do you have an OBD2 data logging application in mind? Contact us for a free consultation!

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

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy OBD2 Data Loggers Now
Contact Us for Support

Can My Car Speak OBD2? Understanding Your Vehicle’s Diagnostic Protocol