Decoding Your Car's Language: A Plain Language Intro to OBDII Readers

Want to understand what your car is trying to tell you without needing a mechanic?

This guide offers a straightforward and practical introduction to the On-Board Diagnostics II (OBDII) protocol. We’ll break down the OBDII connector, OBDII Parameter IDs (PIDs), and how it all links to your car’s CAN bus network.

Forget complicated jargon! This is a plain language intro designed to help you understand OBDII data, how to request and interpret it, and its key uses. We’ll also give you practical tips to get started.

Discover why this is quickly becoming the go-to OBDII guide for beginners.

You can also check out our OBDII introductory video above – or download this guide as a PDF

Inside This Article:

Author: Martin Falch (Updated January 2025)

Download as PDF

What Exactly is OBDII?

Think of OBDII as your car’s internal health monitor. It’s a standardized system built into almost all modern vehicles that allows you to access diagnostic information. This system uses a common language, the OBDII protocol, to report issues and provide real-time data through the OBDII connector.

You’ve likely already seen OBDII in action:

Ever noticed the check engine light illuminate on your dashboard?

That’s your car’s way of saying, “Hey, something needs attention!”. When you take your car to a repair shop, a mechanic uses an OBDII scanner – essentially a Plain Language Obdii Reader – to figure out what’s wrong.

To do this, they plug the OBDII reader into the OBDII 16-pin connector, usually located near the steering wheel. The reader sends “OBDII requests” to the car, and the car responds with “OBDII responses.” These responses can contain valuable information like speed, fuel level, or Diagnostic Trouble Codes (DTCs). This data helps mechanics quickly pinpoint problems and get you back on the road faster.

Is My Car OBDII Compatible?

The short answer: Almost certainly!

Most gasoline and diesel cars manufactured after the mid-1990s support OBDII. The vast majority of these systems also operate on the Controller Area Network (CAN) bus, which is the communication backbone of modern vehicles. However, for older vehicles, even if you find a 16-pin connector that looks like an OBDII port, it might not actually be OBDII compliant.

A simple way to check is to consider where and when your car was originally purchased:

A Quick Look at OBDII History

OBDII’s story begins in California. The California Air Resources Board (CARB) mandated the original OBD standard in all new cars sold in California from 1991 onwards. The primary goal was emissions control.

The OBDII standard we know today was developed and recommended by the Society of Automotive Engineers (SAE). SAE standardized Diagnostic Trouble Codes (DTCs) and the physical OBD connector across different car manufacturers with the SAE J1962 standard.

From there, OBDII adoption expanded progressively:

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

The Future of OBDII

OBDII isn’t going anywhere, but it’s definitely evolving. Here are some key trends to watch:

Initially, OBDII was created for emissions testing. Interestingly, electric vehicles (EVs) aren’t legally required to support OBDII at all. In fact, most modern EVs don’t use standard OBDII requests. Instead, they often use manufacturer-specific communication protocols like UDS (Unified Diagnostic Services). This makes accessing data from EVs challenging unless you can decode these proprietary systems. However, some progress is being made in reverse-engineering EV communication – you can see examples in our case studies for electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Current OBDII implementations have limitations, particularly in data richness and the underlying communication methods. To address this, newer standards like WWH-OBD (World-Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging. These aim to improve OBD communication by using UDS as a foundation. For a deeper dive into these protocols, check out our introduction to UDS.

In our increasingly connected world, traditional OBDII testing methods can feel outdated. Manually checking emissions is slow and costly.

The potential solution? OBD3 – bringing telematics to every car.

OBD3 envisions adding a small radio transmitter to all vehicles, similar to those used for electronic toll collection. This would allow cars to wirelessly transmit their vehicle identification number (VIN) and DTCs to a central server for automatic monitoring.

Many devices already enable data transfer over Wi-Fi or cellular networks, like the CANedge2 Wi-Fi CAN logger and the CANedge3 3G/4G CAN logger.

While this offers cost savings and convenience, it also raises privacy concerns, making it a politically sensitive topic.

OBDII was originally designed for vehicle servicing in repair shops.

However, today, third-party companies widely use OBDII to access real-time vehicle data via OBDII dongles, CAN loggers and similar devices. Interestingly, the German automotive industry is pushing for changes that could limit this access:

“OBD was intended for car maintenance in workshops. It was never meant 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 OBDII functionality while driving and instead centralizing data collection within manufacturer servers. This would effectively give automakers control over the growing field of ‘automotive big data’.

The rationale often cited is security, aiming to reduce the risk of car hacking. However, many see this as a commercially motivated move. Whether this trend gains momentum remains to be seen, but it could significantly impact the market for third-party OBDII services.

Get Our ‘Ultimate CAN Guide’

Want to become a CAN bus expert and truly understand your vehicle’s network?

Download our comprehensive 160+ page PDF guide, featuring 12 ‘simple intros’ to CAN bus technology.

Download Now

Understanding OBDII Standards

On-Board Diagnostics II (OBDII) is a higher-layer protocol – think of it like a language spoken by your car. CAN bus, on the other hand, is the communication method, similar to a phone line. OBDII is comparable to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

OBDII standards define everything from the physical OBDII connector to the lower-layer communication protocols and OBDII Parameter IDs (PIDs).

We can visualize these standards using the 7-layer OSI model, a framework for understanding network communication. In the following sections, we’ll focus on the most important aspects of these standards.

Looking at the OSI model overview, you’ll notice that both SAE (Society of Automotive Engineers) and ISO (International Organization for Standardization) standards cover several layers. This generally reflects the development of OBD standards in the US (SAE) and Europe (ISO). Many of these standards are technically very similar. For example, SAE J1979 is nearly equivalent to ISO 15031-5, and SAE J1962 is similar to ISO 15031-3.

The OBDII Connector [SAE J1962]

The 16-pin OBDII connector is your gateway to accessing your car’s data. It’s standardized by SAE J1962 / ISO 15031-3, ensuring compatibility across vehicles.

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

Here are a few important points about the OBDII connector:

It’s usually located near your steering wheel, but it can be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The specific OBDII pinout can vary depending on the communication protocol used by the vehicle.
CAN bus is the most common lower-layer protocol, so pins 6 (CAN-High) and 14 (CAN-Low) are frequently connected.

OBDII Connector: Type A vs. Type B

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

As you can see in the illustration, both types share similar pinouts but differ in their power supply outputs – 12V for Type A and 24V for Type B. The communication speed (baud rate) can also differ, with cars typically using 500 kbps, while heavy-duty vehicles often use 250 kbps (though 500 kbps is becoming more common).

To visually distinguish them, Type B connectors have a notch or interrupted groove in the middle. This means a Type B OBDII adapter cable will fit both Type A and Type B sockets, but a Type A connector will not fit into a Type B socket.

OBDII and CAN Bus [ISO 15765-4]

Since 2008, CAN bus has been the mandatory communication protocol for OBDII in all cars sold in the US, as defined by ISO 15765.

ISO 15765-4 (also known as Diagnostics over CAN, or DoCAN) specifies a set of rules and restrictions applied to the CAN standard (ISO 11898) for diagnostic communication.

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

The CAN bus speed (bit-rate) must be either 250 kbps or 500 kbps.
CAN IDs can be 11-bit (standard) or 29-bit (extended).
Specific CAN IDs are designated for OBDII requests and responses.
Diagnostic CAN frame data length is fixed at 8 bytes.
The OBDII adapter cable must be no longer than 5 meters.

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

OBDII communication always involves a request-response pattern.

In most passenger cars, 11-bit CAN IDs are used for OBDII. The ‘Functional Addressing’ ID, 0x7DF, is used to send a request to all OBDII-compatible electronic control units (ECUs), asking if they have data to report for the requested parameter (according to ISO 15765-4). In contrast, CAN IDs in the range 0x7E0-0x7E7 are used for ‘Physical Addressing’, allowing requests to be sent to specific ECUs (less common).

ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most common response ID is 0x7E8 (from the Engine Control Module, or ECM), followed by 0x7E9 (from the Transmission Control Module, or TCM).

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

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

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

OBDII vs. Proprietary CAN Protocols

It’s crucial to understand that your car’s electronic control units (ECUs) do not rely on OBDII for their normal operation. Car manufacturers (OEMs) implement their own proprietary CAN protocols for vehicle control and communication. These protocols are often unique to the vehicle brand, model, and year. Unless you are the OEM, interpreting this proprietary CAN data is usually impossible without significant reverse engineering effort (reverse engineer it).

If you connect a CAN bus data logger to your car’s OBDII port, you might see this OEM-specific CAN data, typically broadcast at a high rate of 1000-2000 frames per second. However, many newer vehicles have a ‘gateway’ module that blocks access to this proprietary CAN data through the OBDII port, allowing only OBDII communication.

In simple terms: Think of OBDII as an ‘extra’ communication layer, running alongside the manufacturer’s own internal communication system. It’s a standardized window into some of your car’s data, but not the full picture.

Bit-rate and ID Validation

As mentioned, OBDII can use two different speeds (250 kbps, 500 kbps) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern cars most commonly use 500 kbps and 11-bit IDs. However, any external tool, especially a plain language OBDII reader, should automatically detect and verify these settings to ensure proper communication.

ISO 15765-4 provides recommendations for a systematic initialization process to determine the correct combination. This process relies on the fact that OBDII-compliant vehicles must respond to a specific mandatory OBDII request (more on this in the OBDII PID section). Using an incorrect speed will result in CAN error frames, which can be detected.

Newer versions of ISO 15765-4 consider that vehicles might support OBD communication via OBDonUDS (OBD on Unified Diagnostic Services) rather than the more traditional OBDonEDS (OBD on Emission Diagnostic Service). This article primarily focuses on OBDII/OBDonEDS (defined by ISO 15031-5/SAE J1979) as it’s more widely used in non-EV cars today. WWH-OBD/OBDonUDS (defined by ISO 14229, ISO 27145-3/SAE J1979-2) is primarily found in EU trucks and buses.

To distinguish between OBDonEDS and OBDonUDS, a diagnostic tool can send additional requests, 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 the dominant standard in most non-electric vehicles today, while WWH-OBD is mainly used in European trucks and buses.

Five Lower-Layer OBDII Protocols

While CAN bus (ISO 15765) is now the standard lower-layer protocol for OBDII in most cars, especially those manufactured after 2008, older vehicles may use other protocols. If you’re working with an older car, knowing these alternatives can be helpful. The OBDII connector pinout can sometimes give clues about the protocol used.

Here are the five lower-layer protocols that have been used for OBDII:

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and the most common protocol today.
ISO 14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, particularly in Asia.
ISO 9141-2: Used in European, Chrysler, and Asian cars around 2000-2004.
SAE J1850 (VPW – Variable Pulse Width): Primarily used in older General Motors (GM) vehicles.
SAE J1850 (PWM – Pulse Width Modulation): Primarily used in older Ford vehicles.

Transporting OBDII Messages via ISO-TP [ISO 15765-2]

All OBDII data transmitted over CAN bus uses a transport protocol called ISO-TP (ISO 15765-2). This protocol allows for sending data payloads larger than the 8-byte limit of a standard CAN frame. This is necessary in OBDII for tasks like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often require more than 8 bytes of data. ISO 15765-2 handles segmentation (breaking data into smaller chunks), flow control (managing data transmission), and reassembly (putting chunks back together). For more details, see our introduction to UDS.

However, much of the time, OBDII data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF). In a Single Frame, the first data byte (called the PCI field – Protocol Control Information) indicates the payload length (excluding any padding), leaving 7 bytes for the actual OBDII communication.

The OBDII Diagnostic Message [SAE J1979, ISO 15031-5]

To better understand OBDII communication on CAN bus, let’s examine a simplified raw ‘Single Frame’ OBDII CAN message. Essentially, an OBDII message consists of a CAN identifier, a data length indicator (PCI field), and the data itself. The data portion is further structured into a Mode, a Parameter ID (PID), and data bytes.

Example: OBDII Request/Response

Before we delve into the details of each part of the OBDII message, let’s look at a practical example: requesting and receiving ‘Vehicle Speed’.

In this scenario, an external tool (like a plain language OBDII reader) sends a request message to the car. The CAN ID is 0x7DF, and the payload contains two bytes: Mode 0x01 and PID 0x0D. The car responds with a message using CAN ID 0x7E8 and a 3-byte payload. This payload includes the vehicle speed value in the 4th byte, which is 0x32 (50 in decimal).

By consulting the OBDII PID documentation for PID 0x0D, we find the decoding rules and determine that 0x32 corresponds to a physical value of 50 km/h.

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

The 10 OBDII Services (aka Modes)

There are 10 standardized OBDII diagnostic services, often referred to as modes. Mode 0x01 is used to request current, real-time data, while other modes are used to access or clear Diagnostic Trouble Codes (DTCs), retrieve freeze frame data (snapshots of data when a DTC was set), and more.

Vehicles are not required to support all 10 OBDII modes, and manufacturers can also implement additional, non-standardized modes (OEM-specific OBDII modes).

In OBDII messages, the mode is specified in the second byte of the data payload. In a request message, the mode is included directly (e.g., 0x01 for Mode 1). In a response message, 0x40 is added to the requested mode (e.g., a response to Mode 0x01 will have a mode byte of 0x41).

OBDII Parameter IDs (PIDs)

Within each OBDII mode, there are Parameter IDs (PIDs). PIDs are codes that identify specific data parameters you can request.

For example, Mode 0x01 (Show current data) includes approximately 200 standardized PIDs for real-time data like vehicle speed, engine RPM, coolant temperature, and fuel level. However, vehicles typically only support a subset of these PIDs within a given mode. A plain language OBDII reader will often help you discover which PIDs your vehicle actually supports.

One PID is particularly important:

If an emissions-related ECU supports any OBDII services at all, it must support Mode 0x01 PID 0x00. When you request PID 0x00 in Mode 0x01, the vehicle ECU responds with a bitmask indicating which PIDs in the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental ‘OBDII compatibility test’. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for subsequent ranges of Mode 0x01 PIDs (0x21-0x40, 0x41-0x60, and so on).

Tip: OBDII PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 contain detailed scaling and conversion information for standard OBDII PIDs. This information is essential for converting the raw data bytes into meaningful physical values, as we discussed in our CAN bus introduction.

If you need to look up a Mode 0x01 PID quickly, check out our free OBDII PID overview tool. This tool helps you construct OBDII request frames and dynamically decode OBDII responses, making it easier to work with OBDII data, even if you’re using a plain language OBDII reader.

OBDII PID Overview Tool

How to Log and Decode OBDII Data

Let’s walk through a practical example of logging OBDII data using the CANedge CAN bus data logger. The CANedge is a versatile tool that allows you to configure custom CAN frames for transmission, making it ideal for OBDII logging and testing.

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

Reviewing ‘Supported PIDs’ responses in asammdf software.

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

As discussed earlier, ISO 15765-4 outlines how to determine the correct bit-rate and CAN IDs for a specific vehicle. You can use the CANedge to perform these tests (see the CANedge Introduction for setup details):

Bit-rate Test: Send a CAN frame at 500 kbps. If successful, proceed. If not, try 250 kbps.
Use Identified Bit-rate: Use the successfully tested bit-rate for all subsequent communication.
‘Supported PIDs’ Requests: Send multiple ‘Supported PIDs’ requests (Mode 0x01, PIDs 0x00, 0x20, 0x40, etc.) and analyze the responses.
Determine CAN ID Type: Based on the response IDs (e.g., 0x7E8 range for 11-bit, 0x18DAF1xx for 29-bit), identify whether the vehicle uses 11-bit or 29-bit CAN IDs for OBDII.
Identify Supported PIDs: Analyze the response data to determine which specific PIDs are supported by the vehicle.

We provide pre-configured CANedge configurations to simplify these initial tests.

Most non-electric cars manufactured in 2008 or later support 40-80 PIDs using a 500 kbps bit-rate, 11-bit CAN IDs, and the OBDII/OBDonEDS protocol.

As shown in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBDII request when using the functional request ID 0x7DF. This is because 0x7DF polls all ECUs for a response. Since all OBDII/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, you’ll often see numerous responses, especially to this PID. For subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. Notice that the ECM ECU (0x7E8) in the example supports all the PIDs supported by other ECUs. This means you could reduce bus load by directing future requests only to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

#2: Configure OBDII PID Requests

Once you’ve determined the supported OBDII PIDs, bit-rate, and CAN ID type for your vehicle, you can configure your CANedge to request the PIDs you’re interested in logging.

Here are some key considerations for configuring your PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0 for the ECM) to avoid receiving multiple responses to each request, simplifying data analysis.
Request Spacing: Introduce a delay of 300-500 milliseconds between each OBDII request. Sending requests too rapidly (spamming) can overwhelm ECUs and cause them to stop responding.
Battery Drain: Use triggers in your CANedge configuration to stop transmitting OBDII requests when the vehicle is inactive (e.g., ignition off). This prevents the CANedge from ‘waking up’ ECUs unnecessarily and draining the vehicle battery.
Data Filtering: Apply filters in your CANedge configuration to record only OBDII responses (e.g., filter for CAN IDs in the 0x7E8-0x7EF range). This is helpful if your vehicle also broadcasts OEM-specific CAN data on the OBDII port, allowing you to focus specifically on the OBDII data.

With these configurations in place, your CANedge is ready to log raw OBDII data to its SD card!

Example CANedge OBDII PID request transmit list.

DBC decoding and visualization of OBDII data in asammdf.

#3: DBC Decode Raw OBDII Data

To analyze and visualize your logged OBDII data, you need to decode the raw CAN data into ‘physical values’ (like kilometers per hour or degrees Celsius).

The necessary decoding information is defined in ISO 15031-5/SAE J1979 and can also be found in online resources like Wikipedia. For convenience, we offer a free OBDII DBC file. A DBC file is a database that contains the decoding rules for CAN messages, making it easy to DBC decode raw OBDII data in most CAN bus software tools.

Decoding OBDII data is slightly more complex than decoding typical CAN signals. This is because different OBDII PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone isn’t enough to identify the specific signals within the payload.

To address this, you need to use the CAN ID, the OBDII mode, and the OBDII PID together to uniquely identify each signal. This is a form of multiplexing called ‘extended multiplexing‘. This extended multiplexing can be effectively implemented using DBC files, allowing software tools to correctly interpret OBDII data. A plain language OBDII reader often handles this decoding automatically, presenting the data in an easy-to-understand format.

CANedge: Your OBDII Data Logger

The CANedge is a user-friendly solution for recording OBDII data directly to an 8-32 GB SD card. Simply connect it to your car, truck, or other vehicle to start logging. You can then decode and analyze the data using free software and APIs and our OBDII DBC file.

OBDII Logger Intro CANedge Product Page

OBDII Multi-Frame Examples [ISO-TP]

As we’ve learned, all OBDII data communication relies on the ISO-TP (transport protocol) defined in ISO 15765-2. Most of the examples so far have involved single-frame communication. In this section, we’ll look at examples of multi-frame communication, which is necessary when the data payload exceeds 7 bytes.

Multi-frame OBDII communication requires flow control frames to manage the data exchange (see our UDS introduction for details on flow control). In practice, a simplified approach is to transmit a static flow control frame approximately 50 milliseconds after the initial request frame, as demonstrated in the CANedge configuration example below.

Analyzing multi-frame OBDII responses requires CAN software and API tools that support ISO-TP, such as the CANedge MF4 decoders, which are designed to handle segmented messages.

Example 1: OBDII Vehicle Identification Number (VIN)

The Vehicle Identification Number (VIN) is essential for various applications, including telematics and vehicle diagnostics (see our UDS intro for more on VIN and UDS). To retrieve the VIN using OBDII, you use Mode 0x09 (Request Vehicle Information) and PID 0x02 (Request Vehicle Identification Number):

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 (FF) containing the PCI, the total length of the VIN data (0x014 = 20 bytes), the mode (0x49, which is 0x09 + 0x40), and the 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 details). The remaining 17 bytes contain the VIN itself. You can convert these hexadecimal bytes to ASCII characters to get the human-readable VIN using methods described in our UDS introduction.

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

OBDII allows diagnostic tools to request up to six Mode 0x01 PIDs in a single request frame. The ECU will respond with data for the supported PIDs (omitting data for unsupported PIDs) and may use multi-frame responses via ISO-TP if necessary.

This multi-PID request feature can increase data collection efficiency and frequency. However, it also makes signal decoding more complex, as the data encoding becomes specific to the request method. This can make using generic OBDII DBC files challenging. For most practical data logging scenarios, we don’t recommend using multi-PID requests.

Here’s an example trace of a multi-PID request and response:

The multi-frame response structure is similar to the VIN example, but with the added complexity that the payload includes both the requested PIDs and the corresponding data for each. In this example, the PIDs are ordered similarly to the request order, which is common but not strictly required by ISO 15031-5.

Decoding these multi-PID responses using standard DBC files is very difficult in practice. Therefore, we advise against using this method for general data logging unless you are using a specialized tool with built-in support for multi-PID requests. Effectively, you’re dealing with a complex case of extended multiplexing, where the DBC file would need to account for the specific payload position of each PID. This becomes even more challenging to manage if you send multiple different multi-PID requests, as you’ll lack a way to uniquely identify the messages.

While you could potentially work around this with custom scripting and by also recording the request messages from your tool, allowing the script to interpret responses based on the corresponding requests, such approaches are generally difficult to scale and manage effectively.

Example 3: OBDII Diagnostic Trouble Codes (DTCs)

You can use OBDII to request emissions-related Diagnostic Trouble Codes (DTCs) using Mode 0x03, “Show stored Diagnostic Trouble Codes”. No PID is included in the request. The targeted ECU(s) will respond with the number of DTCs they have stored (which could be zero if no DTCs are present), with each DTC occupying 2 data bytes. Multi-frame responses are necessary if more than two DTCs are stored, as they won’t fit in a single CAN frame payload.

The 2-byte DTC value is structured according to ISO 15031-5/ISO 15031-6. The first two bits define the DTC ‘category’, while the remaining 14 bits form a 4-digit code (displayed in hexadecimal). You can decode and look up DTC values using various online OBDII DTC lookup tools, such as repairpal.com. Plain language OBDII readers typically decode and display DTCs in a user-friendly text format, eliminating the need for manual lookup.

The example below shows a response from an ECU with 6 DTCs stored.

OBDII Data Logging – Use Case Examples

OBDII data from cars and light trucks has a wide range of applications:

Logging Data from Cars

OBDII data can be used to optimize fuel efficiency, improve driving habits, test prototype components, and for insurance purposes. A plain language OBDII reader can provide drivers with immediate feedback to improve their driving and vehicle maintenance.

OBDII Logger Product Page

Real-time Car Diagnostics

OBDII interfaces enable real-time streaming of vehicle data, making it easier to diagnose vehicle issues and troubleshoot problems. Plain language OBDII readers excel at presenting this real-time data in an accessible format for mechanics and car owners alike.

OBDII Streaming Interface

Predictive Maintenance

Cloud-connected OBDII loggers can monitor vehicle health in real-time, enabling predictive maintenance to anticipate and prevent breakdowns in cars and light trucks. Plain language OBDII readers can be part of a broader predictive maintenance system, providing initial insights into potential issues.

Predictive Maintenance Solutions

Vehicle Black Box Logger

An OBDII logger can serve as a ‘black box’ for vehicles or equipment, recording data that can be invaluable for resolving disputes, accident analysis, and detailed diagnostics. The data from a black box OBDII logger can be reviewed with plain language OBDII reader software to understand vehicle behavior during specific events.

CAN Bus Black Box Logger

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

Explore our guides section for more introductory articles, or download our comprehensive ‘Ultimate Guide’ PDF.

Ready to start logging or streaming OBDII data?

Get your OBDII data logger today!

Buy Now Contact Us

Recommended Resources

OBDII DATA LOGGER: EASILY LOG & CONVERT OBDII DATA

CANEDGE2 – PRO CAN IoT LOGGER

[

Decoding Your Car’s Language: A Plain Language Intro to OBDII Readers