What To Do With OBD2: Practical Guide for Car Diagnostics & More

Need a straightforward, hands-on guide to OBD2?

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

This is a practical guide, so you’ll discover how to request and interpret OBD2 data, learn about essential logging applications, and get valuable practical advice.

Discover why this is considered a top OBD2 resource.

You can also watch our OBD2 introduction video above – or download the PDF guide.

Understanding OBD2 and What You Can Do With It

OBD2 is essentially your car’s built-in health monitoring system. It’s a standardized system that gives you access to diagnostic trouble codes (DTCs) and live vehicle data through the OBD2 port.

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

Ever seen the check engine light illuminate on your dashboard?

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

Mechanics connect an OBD2 reader to the OBD2 16-pin connector, usually found near the steering wheel. This tool sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’. These responses can contain valuable information such as speed, fuel level, or Diagnostic Trouble Codes (DTCs), which significantly speeds up the troubleshooting process.

Is Your Car OBD2 Compatible?

Most likely, yes!

Almost all modern non-electric vehicles are equipped with OBD2, and many operate on the CAN bus network. For older vehicles, even if a 16-pin OBD2 connector is present, it might not fully support OBD2. A key indicator of OBD2 compliance is the vehicle’s purchase location and year:

A Brief History of OBD2

OBD2 has its roots in California, where the California Air Resources Board (CARB) mandated OBD systems in all new vehicles starting from 1991 for emissions monitoring.

The Society of Automotive Engineers (SAE) recommended the OBD2 standard, which standardized DTCs and the OBD connector across different car manufacturers (SAE J1962).

The adoption of the OBD2 standard progressed in stages:

1996: OBD2 became compulsory in the USA for cars and light trucks.
2001: Required in the EU for gasoline vehicles.
2003: Extended to diesel vehicles in the EU (EOBD).
2005: OBD2 became mandatory in the US for medium-duty vehicles.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2.
2010: OBD2 requirement extended to heavy-duty vehicles in the US.

The Future of OBD2

OBD2 is set to remain relevant, but its form is evolving. Here are key trends to consider:

Originally designed for emissions control and testing, legislated OBD2 has a notable exception: electric vehicles. Electric vehicles are generally not required to support OBD2 in its traditional form. This is evident as most modern EVs do not support standard OBD2 requests. Instead, they often use OEM-specific UDS communication protocols. This typically makes accessing data from electric vehicles challenging, except when decoding methods are reverse-engineered. Examples include case studies for electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Today, OBD2 implementations vary and face limitations in data richness and underlying communication protocols. To address these, advanced alternatives are emerging, such as WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). These aim to improve OBD communication by using the UDS protocol as a base. For a deeper dive into these protocols, refer to 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 is OBD3 – integrating telematics into all vehicles.

OBD3 concept involves adding a small radio transponder (similar to those used for bridge tolls) to all cars. This would allow the car’s vehicle identification number (VIN) and DTCs to be transmitted wirelessly via WiFi to a central server for automated checks.

Many current devices already facilitate transferring CAN or OBD2 data over WiFi or cellular networks, such as the CANedge2 WiFi CAN logger or the CANedge3 3G/4G CAN logger.

While this offers cost savings and convenience, it also raises political and privacy concerns regarding surveillance.

The original purpose of OBD2 was for in-garage emission controls.

However, today, OBD2 is widely used by third parties to generate real-time vehicle data through OBD2 dongles, CAN loggers and similar devices. Interestingly, the German automotive industry is considering changes that could impact this:

OBD was designed for car servicing in repair shops, not to enable third parties to build a data-driven economy using this interface.“

– Christoph Grote, SVP Electronics, BMW (2017)

The suggestion is to deactivate OBD2 functionality while driving and instead centralize data collection through manufacturers’ servers. This would effectively give manufacturers control over ‘automotive big data’ and vehicle telematics.

The rationale includes security improvements, such as mitigating the risk of car hacking, although many view this as a commercially motivated move. Whether this trend gains traction remains to be seen, but it could significantly alter the landscape for third-party OBD2 services.

Enhance Your CAN Bus Expertise

Want to become a CAN bus expert?

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

Download now

OBD2 Standards Explained

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

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

These standards can be visualized using a 7-layer OSI model. In the following sections, we’ll focus on the most critical aspects.

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 Europe (ISO). Many of these standards are technically very similar, for example, SAE J1979 versus ISO 15031-5, and SAE J1962 versus ISO 15031-3.

The OBD2 Connector [SAE J1962 Standard]

The 16-pin OBD2 connector is your gateway to accessing vehicle data, standardized under SAE J1962 / ISO 15031-3.

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

Key points about the OBD2 connector:

It’s typically located near the steering wheel, but can 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 usually connected.

OBD2 Connector Types: A vs. B

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

As shown, both types have similar OBD2 pinouts but differ in power supply output: 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).

To visually differentiate them, Type B OBD2 connectors have an interrupted groove in the middle. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and B sockets, whereas a Type A adapter will not fit into a Type B socket.

OBD2 and CAN Bus [ISO 15765-4 Standard]

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US-sold vehicles, as per ISO 15765.

ISO 15765-4, also known as Diagnostics over CAN or DoCAN, is a set of specifications applied to the CAN standard (ISO 11898).

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 set to 8 bytes.
The OBD2 adapter cable should not exceed 5 meters.

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

OBD2 communication always involves request/response message pairs.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, which broadcasts a request to all OBD2-compatible ECUs to check if they have the requested parameter data (defined in ISO 15765-4). CAN IDs from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’ requests, targeting specific ECUs (less common).

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).

Some vehicles, particularly vans and medium to heavy-duty vehicles, may use extended 29-bit CAN identifiers for OBD2 communication instead of 11-bit IDs.

Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

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

OBD2 vs. OEM Proprietary CAN Protocols

It’s crucial to understand that your car’s Electronic Control Units (ECUs) operate using OEM-specific CAN protocols, not OBD2. Each vehicle manufacturer implements their own proprietary CAN protocols, often unique to the vehicle brand, model, and year. Unless you are the OEM, interpreting this data is usually not possible without reverse engineering.

Connecting a CAN bus data logger to your car’s OBD2 port might reveal OEM-specific CAN data, typically broadcast at 1000-2000 frames/second. However, many newer vehicles use a ‘gateway’ to restrict access to this CAN data, allowing only OBD2 communication through the OBD2 connector.

In essence, think of OBD2 as an additional, higher-level protocol that runs alongside the OEM-specific protocol.

Bit-rate and ID Validation

As mentioned, OBD2 can use two bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern cars commonly use 500K and 11-bit IDs, but diagnostic tools should systematically verify this.

ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination. This process relies on the fact that OBD2-compliant vehicles must respond to a mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit rate transmissions will cause CAN error frames.

Newer ISO 15765-4 versions consider that vehicles may support OBD communication via OBDonUDS rather than OBDonEDS. While this article mainly discusses OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979), WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2) is also relevant.

To test for OBDonEDS versus OBDonUDS, diagnostic tools might send additional 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 prevalent in most non-EV cars today, while WWH-OBD is primarily used in EU trucks and buses.

Five Lower-Layer OBD2 Protocols

While CAN is now the dominant lower-layer protocol for OBD2 as per ISO 15765, older vehicles (pre-2008) might use one of four other protocols. Understanding these and their pinouts can help determine which protocol your car might be using:

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

Transporting OBD2 Messages via ISO-TP [ISO 15765-2 Standard]

All OBD2 data communication over CAN bus relies on the ISO-TP (ISO 15765-2) transport protocol. This protocol enables the transmission 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, see our introduction 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 OBD2 communication.

Decoding the OBD2 Diagnostic Message [SAE J1979, ISO 15031-5 Standards]

To better grasp OBD2 communication on CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simple terms, an OBD2 message consists of an identifier, a data length indicator (PCI field), and the data itself. The data is structured into Mode, Parameter ID (PID), and data bytes.

Example: OBD2 Request and Response

Consider this example of requesting and receiving ‘Vehicle Speed’ data.

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

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

Next, we’ll explore OBD2 modes and PIDs in more detail.

The 10 OBD2 Diagnostic Services (Modes)

OBD2 includes 10 diagnostic services, or modes. Mode 0x01 provides real-time data, while others are used to display and clear diagnostic trouble codes (DTCs) or access freeze frame data.

Vehicles are not required to support all 10 OBD2 modes and may also implement OEM-specific modes beyond these standardized ones.

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

OBD2 Parameter IDs (PIDs)

Each OBD2 mode contains Parameter IDs (PIDs).

For example, Mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on parameters like speed, RPM, and fuel level. However, vehicles don’t have to support every PID within a mode, and most vehicles only support a subset.

One PID is particularly important:

If an emissions-related ECU supports any OBD2 services, it must support Mode 0x01 PID 0x00. Responding to PID 0x00, the vehicle’s ECU indicates whether it supports PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, and up to 0xC0 can be used to determine support for the remaining Mode 0x01 PIDs.

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 contain scaling information for standard OBD2 PIDs, which allows you to decode data into physical values (as explained in our CAN bus introduction).

For quick lookups of Mode 0x01 PIDs, our OBD2 PID overview tool is invaluable. It helps you construct OBD2 request frames and dynamically decode OBD2 responses.

OBD2 PID overview tool

Practical Guide: How to Log and Decode OBD2 Data

This section provides a practical example of logging OBD2 data using the CANedge CAN bus data logger.

The CANedge allows you to configure custom CAN frame transmissions, making it ideal for OBD2 logging.

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

You can send a CAN frame at 500K to test if transmission is successful.

Review responses to ‘Supported PIDs’ in asammdf.

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

As previously discussed, ISO 15765-4 outlines how to determine the bit rate and IDs used by a specific vehicle. You can use the CANedge to perform these tests (see the CANedge Introduction for detailed instructions):

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

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

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

As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common. This is because we use the 0x7DF request ID, which queries all ECUs for responses. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, there are often numerous responses, especially to this PID. As you can see, fewer ECUs respond to subsequent ‘Supported PIDs’ requests. Notice also that the ECM ECU (0x7E8) supports all PIDs supported by other ECUs in this example. To reduce bus load, you can specifically target this ECU for requests by using the ‘Physical Addressing’ CAN ID 0x7E0 for future communication.

Step #2: Configure OBD2 PID Requests

Now that you know your vehicle’s supported OBD2 PIDs and the correct bit rate and CAN IDs to use, you can configure your transmit list with the PIDs you’re interested in logging.

Consider these points when configuring your requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses for each request.
Spacing: Add a delay of 300-500 ms between each OBD2 request. Overly frequent requests may cause ECUs to stop responding.
Battery Drain: Use triggers to stop transmissions when the vehicle is inactive to prevent ‘waking up’ ECUs and draining the battery.
Filters: Set up 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!

Example of a CANedge OBD2 PID request list.

Visualize DBC decoded OBD2 data in asammdf.

Step #3: DBC Decode 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 °C).

Decoding information is available in ISO 15031-5/SAE J1979 and online resources 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 more complex than standard CAN signals because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). The CAN ID alone is not enough to identify the signals within the payload.

To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID to correctly identify each signal. This multiplexing technique, known as ‘extended multiplexing,’ can be implemented using DBC files.

CANedge: Your OBD2 Data Logger

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

OBD2 logger intro

CANedge

OBD2 Multi-Frame Examples [ISO-TP]

OBD2 communication uses ISO-TP (transport protocol) as per ISO 15765-2. While many examples are single-frame, multi-frame communication is also important. Here are some examples.

Multi-frame OBD2 communication requires flow control frames (see our UDS introduction). In practice, you can transmit a static flow control frame about 50 ms after the initial request frame, as shown in the CANedge configuration example.

Analyzing multi-frame OBD2 responses requires 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). To retrieve the VIN using OBD2, 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 containing 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 details). The subsequent 17 bytes contain the VIN, which can be converted from HEX to ASCII as described in our UDS introduction.

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

External tools can request up to 6 Mode 0x01 OBD2 PIDs in a single request frame. The ECU will respond with data for supported PIDs (excluding unsupported ones) and may use multiple frames as per ISO-TP if necessary.

This efficient method allows for higher-frequency data collection. However, the signal encoding becomes specific to your request method, making generic OBD2 DBC files less useful. We generally advise against this method in practice. Here’s an example trace:

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

Decoding this response using generic DBC files is challenging. Therefore, we don’t recommend this approach for practical data logging unless you are using a tool with built-in support for this specific method. It involves extended multiplexing with payload positions dependent on the requested PIDs. Creating a generalized DBC file for various vehicles and PID combinations becomes very difficult. Furthermore, managing multiple such multi-PID requests via DBC manipulation becomes almost impossible, lacking a clear method to differentiate messages.

Workarounds could involve custom scripts and recording transmit messages to interpret responses based on requests. However, such methods are hard 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 the request. The ECU(s) will respond with the number of stored DTCs (potentially zero if none are stored), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored.

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

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

Use Cases for OBD2 Data Logging

OBD2 data from cars and light trucks has numerous applications:

Logging Car Data

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

OBD2 logger

Real-Time Vehicle Diagnostics

OBD2 interfaces enable real-time streaming of vehicle data, useful for diagnosing car issues and monitoring performance.

OBD2 streaming

Predictive Maintenance

Monitoring cars and light trucks via IoT OBD2 loggers in the cloud allows for predictive maintenance, helping to prevent breakdowns.

Predictive maintenance

Vehicle Black Box Logging

An OBD2 logger can act as a ‘black box’ for vehicles or equipment, providing crucial data for incident analysis or diagnostics.

CAN bus blackbox

Do you have an OBD2 data logging use case? Contact us for a free consultation!

Explore more introductory guides in our tutorials section or download our ‘Ultimate Guide’ PDF.

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy now

Recommended for You

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN