OBD2 to CAN Bus: Your Expert Guide to Vehicle Diagnostics

Looking for a clear and expert explanation of OBD2 and its relation to CAN bus?

This guide provides a comprehensive introduction to the On-Board Diagnostics (OBD2) protocol, detailing the OBD2 connector, Parameter IDs (PIDs), and its crucial link to the Controller Area Network (CAN bus).

More than just an introduction: This is your practical guide to understanding, requesting, and decoding OBD2 data. Discover key use cases for data logging and gain actionable tips for real-world applications.

Join countless readers who’ve made this the leading OBD2 resource online.

You can also explore our introductory OBD2 video above – or download the content as a PDF for offline access.

Understanding OBD2: The Basics

What exactly is OBD2? It’s your car’s inherent self-diagnostic system. OBD2 is a standardized protocol that enables the retrieval of diagnostic trouble codes (DTCs) and real-time vehicle data through the OBD2 connector.

You’ve likely already encountered OBD2 in action:

Ever seen the check engine light illuminate on your dashboard?

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

The mechanic connects the OBD2 scanner to the OBD2 16-pin connector, usually located near the steering wheel. This tool transmits ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’ containing data like speed, fuel level, or Diagnostic Trouble Codes (DTCs). This process allows for quicker and more efficient troubleshooting.

Alt text: OBD2 system overview showing malfunction indicator light and diagnostic scan tool connected to vehicle.

OBD2 Compatibility: Does Your Car Have It?

The short answer: Almost certainly!

The vast majority of modern non-electric vehicles are OBD2 compliant, and most of these utilize CAN bus for communication. For older vehicles, even if a 16-pin OBD2 connector is present, it might not actually support the OBD2 protocol. A reliable way to check compliance is based on the vehicle’s purchase location and year:

Alt text: OBD2 compliance timeline by region (USA, EU) and vehicle type, indicating mandatory implementation years.

A Look at OBD2 History

OBD2’s origins trace back to California, where the California Air Resources Board (CARB) mandated OBD in all new vehicles from 1991 onwards, primarily for emission control.

The Society of Automotive Engineers (SAE) recommended the OBD2 standard, leading to standardized DTCs and OBD connectors across different manufacturers (SAE J1962).

From its Californian inception, OBD2 adoption expanded progressively:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: OBD2 requirement extended to gasoline cars in the European Union.
2003: EU mandate included diesel cars as well (EOBD – European On-Board Diagnostics).
2005: OBD2 became compulsory for medium-duty vehicles in the US.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 mandate finally encompassed heavy-duty vehicles in the US.

Alt text: OBD2 history infographic showing key milestones related to emission control, standardization and CAN bus integration.

Alt text: OBD2 history timeline summarizing key dates and events in the development and adoption of on-board diagnostics.

Alt text: OBD3 future concept art depicting remote diagnostics, cloud connectivity, IoT, and emissions testing.

The Future of OBD2

OBD2 is firmly established, but its future evolution is worth considering.

Here are some significant trends:

Originally designed for emission control and testing, legislated OBD2 has a notable exception: electric vehicles. Electric vehicles are not mandated to support OBD2 in any form. This is reflected in the fact that most modern EVs do not support standard OBD2 requests. Instead, they often use OEM-specific UDS (Unified Diagnostic Services) communication. This OEM-specific approach generally restricts data access from EVs unless decoding rules are reverse-engineered. However, there are successful cases of reverse engineering, as demonstrated in our case studies on electric cars, including analyses for Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Current OBD2 implementations have limitations, particularly in data richness and lower-layer protocols. To address these, modern alternatives have emerged, such as WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). Both aim to improve OBD communication by utilizing the UDS protocol. For deeper insights into these protocols, refer to our introduction to UDS.

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

The proposed solution? OBD3: Integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder (similar to those used in toll systems) to every car. This would enable the car’s vehicle identification number (VIN) and DTCs to be transmitted wirelessly via WiFi to a central server for automated checks.

Many existing devices already facilitate CAN or OBD2 data transfer via WiFi/cellular networks – for example, the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.

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

The OBD2 protocol was initially designed for stationary emission control tests.

However, today, OBD2 is extensively used by third parties to generate real-time data through OBD2 dongles, CAN loggers and similar devices. The German car industry is seeking to change this landscape:

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

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal involves “disabling” OBD2 functionality during driving, instead centralizing data collection on manufacturer servers. This would effectively give manufacturers control over the ‘automotive big data’.

The rationale is often framed around security (e.g., mitigating car hacking risks), though many view it as a commercially motivated move. Whether this trend gains traction remains to be seen, but it could significantly disrupt the market for third-party OBD2 services.

Alt text: OBD2 future challenges depicted as electric vehicles potentially restricting OBD2 connector data access.

Enhance Your CAN Bus Expertise

Ready to become a CAN bus expert?

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

Download the Ultimate CAN Bus Guide Now

OBD2 Standards Explained

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

Specifically, OBD2 standards define the OBD2 connector specifications, 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 crucial aspects.

In the OSI model overview, you’ll notice that both SAE and ISO standards cover multiple layers. This generally reflects the standardization of OBD in the USA (SAE) and the EU (ISO). Many standards are technically very similar, for instance, SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3.

Alt text: OBD2 and CAN bus OSI model comparison highlighting ISO and SAE standards compliance across network layers.

Alt text: OBD2 connector pinout diagram (Type A female socket) detailing pin assignments for various communication protocols.

The OBD2 Connector: SAE J1962 Standard

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

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

Key points about the OBD2 connector:

It’s usually located near the steering wheel, but can be hidden behind panels.
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 prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically connected.

OBD2 Connector Types: A vs. B

You’ll commonly encounter both Type A and Type B OBD2 connectors. Type A is generally found in cars, while Type B is prevalent in medium and heavy-duty vehicles.

As shown, 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, while heavy-duty vehicles often use 250K (with increasing support for 500K).

To visually distinguish them, the Type B OBD2 connector has a noticeable 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.

Alt text: OBD2 connector type comparison (A vs B) illustrating voltage differences and application in cars and trucks.

Alt text: OBD2 vs CAN bus conceptual diagram highlighting ISO 15765 standards and their relationship.

OBD2 and CAN Bus: ISO 15765-4 Standard

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

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) defines a set of 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, 29-bit)

OBD2 communication relies on a request/response message structure.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID here is 0x7DF. This ID is used to query all OBD2-compatible ECUs (Electronic Control Units) to see if they have data to report for the requested parameter (as defined in ISO 15765-4). Conversely, CAN IDs in the range 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests directed to specific ECUs (less common).

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

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

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

Responses from the vehicle will use CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). This response ID is 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.

Alt text: OBD2 request-response frame structure diagram, showing PID and data parameter flow in communication.

Alt text: OBD2 vs Proprietary CAN bus data access comparison, highlighting differences in protocols and data availability.

OBD2 vs. Proprietary CAN Protocols

It’s important to understand that your vehicle’s Electronic Control Units (ECUs) operate using OEM-specific proprietary CAN protocols, not OBD2. Each Original Equipment Manufacturer (OEM) implements its own unique CAN protocols, often specific to vehicle brand, model, and year. This proprietary data is generally inaccessible to those outside the OEM unless it is reverse engineered.

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

In essence, think of OBD2 as a supplementary higher-layer protocol functioning alongside the OEM-specific protocol.

Bit-rate and ID Validation

As discussed, OBD2 can utilize two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern cars most commonly use 500K with 11-bit IDs. External tools should systematically verify these parameters.

ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination. 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 incorrect bit-rate transmissions will cause CAN error frames.

Newer versions of ISO 15765-4 consider that vehicles may support OBD communication via OBDonUDS (OBD on Unified Diagnostic Service) rather than OBDonEDS (OBD on Emission Diagnostic Service). This article primarily focuses on OBD2/OBDonEDS (as per ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (as per ISO 14229, ISO 27145-3/SAE J1979-2).

To differentiate between OBDonEDS and OBDonUDS, testing tools can 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 mainly used in EU trucks and buses.

Alt text: OBD2 bit-rate and CAN ID validation flowchart based on ISO 15765-4, outlining the process for automatic detection.

Alt text: OBD2 standards diagram displaying five protocols: CAN (ISO 15765), KWP2000, SAE J1850, ISO9141, illustrating protocol options.

Five Lower-Layer OBD2 Protocols

While CAN (ISO 15765) is now the dominant lower-layer protocol for OBD2, especially in vehicles post-2008, older cars may utilize other protocols. Understanding these protocols and their pinouts can be helpful when working with older vehicles.

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

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

All OBD2 data communication over CAN bus is managed by a transport protocol called ISO-TP (ISO 15765-2). This protocol allows for transmitting data payloads larger than 8 bytes, which is necessary for OBD2 operations 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 a detailed explanation, 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 ‘Single Frame’ (SF) messages. In a Single Frame, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-related communication.

Alt text: ISO-TP frame types diagram for OBD2 communication, illustrating Single Frame, First Frame, Consecutive Frame, and Flow Control Frame structure.

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

To better understand OBD2 communication on CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. Simplified, an OBD2 message includes an identifier, data length (PCI field), and data. The data section is further broken down into Mode, Parameter ID (PID), and data bytes.

Alt text: OBD2 message structure breakdown diagram explaining raw frame components: Mode, PID, ID, and Data Bytes.

Example: OBD2 Request and Response

Consider this request/response example for ‘Vehicle Speed’.

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

Looking up the decoding rules for OBD2 PID 0x0D reveals that the physical value is 50 km/h.

We will now delve into OBD2 modes and PIDs in more detail.

Alt text: OBD2 request-response example diagram (7DF request, 7E8 response) for vehicle speed parameter retrieval.

Alt text: OBD2 PID example for Vehicle Speed (0D), explaining data byte conversion to physical value (km/h).

Alt text: OBD2 service modes diagram illustrating 10 diagnostic services: current data, freeze frame, clear DTCs, and more.

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 to display or clear diagnostic trouble codes (DTCs) or access freeze frame data.

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

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

OBD2 Parameter IDs (PIDs)

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

For instance, mode 0x01 includes approximately 200 standardized PIDs providing real-time data on parameters like speed, RPM, and fuel level. However, vehicles are not obligated to support all PIDs within a given mode. In practice, most vehicles support only a subset of the available PIDs.

One PID is particularly significant:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. In response to this PID, the vehicle ECU communicates which PIDs within the range 0x01-0x20 are supported. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs in subsequent ranges.

Alt text: OBD2 request-response protocol diagram highlighting PID data parameters and service mode usage in communication frames.

Alt text: OBD2 PID overview tool screenshot displaying service 01 functionalities and PID data parameters for diagnostics.

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs, which is essential for converting raw data into physical values (as explained in our CAN bus introduction).

If you need to look up a mode 0x01 PID, use our OBD2 PID overview tool. It helps you construct OBD2 request frames and dynamically decode OBD2 responses.

Access the OBD2 PID overview tool here

Practical Guide: Logging and Decoding OBD2 Data

This section provides a hands-on example of how to log OBD2 data using the CANedge CAN bus data logger.

The CANedge allows you to configure custom CAN frames for transmission, making it suitable for OBD2 logging.

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

Alt text: OBD2 data logger request-response diagram (7DF request, 7E8 response) illustrating PID data logging process.

Alt text: OBD2 bit rate test validation screenshot confirming successful CAN frame transmission at 500K.

Alt text: asammdf software screenshot displaying OBD2 Supported PIDs Test results and validation responses analysis.

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

As previously discussed, ISO 15765-4 outlines how to determine the correct bit-rate and IDs for a specific vehicle. You can test this using the CANedge as follows (see the CANedge Introduction for detailed instructions):

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

We provide plug-and-play configurations to streamline these tests.

Most non-EV vehicles manufactured in 2008 or later support 40-80 PIDs using 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 using the 0x7DF request ID polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, there are often numerous responses, especially to this PID. As evident, fewer ECUs respond to subsequent ‘Supported PIDs’ requests. Notice also that the ECM ECU (0x7E8) itself supports all PIDs supported by other ECUs in this example. This means busload can be reduced by directing subsequent communication specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.

Step #2: Configure OBD2 PID Requests

Once you’ve identified the supported OBD2 PIDs for your vehicle, along with the correct bit-rate and CAN IDs, you can configure your transmit list with the PIDs you want to log.

Consider these points when configuring:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses per request.
Spacing: Introduce a delay of 300-500 ms between each OBD2 request (excessive ECU polling can lead to non-responsiveness).
Battery Drain: Use triggers to stop transmissions when the vehicle is inactive (to prevent ECU ‘wake-up’ and battery drain).
Filters: Implement filters to record only OBD2 responses, especially if your vehicle also outputs OEM-specific CAN data.

With these settings configured, your device is ready to log raw OBD2 data!

Alt text: CANedge OBD2 PID request transmit list example, showing configured PIDs for data logging.

Alt text: asammdf software visualization of decoded OBD2 data plot, showcasing CAN bus integration and DBC file usage.

Step #3: DBC Decode Raw OBD2 Data

To analyze and visualize your logged data, you need to decode the raw OBD2 data into ‘physical values’ (like km/h or °C).

The necessary decoding information is available in ISO 15031-5/SAE J1979 (and on resources like Wikipedia). For convenience, we offer 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 standard CAN signal decoding because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is not enough to uniquely 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 form of multiplexing, known as ‘extended multiplexing‘, can be implemented in formats like DBC files.

CANedge: Your OBD2 Data Logging Solution

The CANedge enables you to easily log OBD2 data to an 8-32 GB SD card. Simply connect it to your car or truck to begin logging and then decode the data using free software/APIs and our OBD2 DBC file.

Explore the OBD2 logger introduction
Learn more about CANedge

OBD2 Multi-Frame Examples: ISO-TP in Action

All OBD2 data transmission utilizes ISO-TP (transport protocol) as defined by ISO 15765-2. While many examples are single-frame communication, multi-frame communication is also important. This section provides examples of multi-frame scenarios.

Multi-frame OBD2 communication requires flow control frames (see our UDS introduction). In practice, a static flow control frame can be transmitted approximately 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.

Alt text: OBD2 multi-frame request message example screenshot for retrieving Vehicle Identification Number (VIN).

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 details). To retrieve the VIN using OBD2, you use mode 0x09 and PID 0x02:

The tester 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), in this case 1 (refer to ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes represent 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 supported PIDs (omitting unsupported ones), potentially using multi-frame responses via ISO-TP if necessary.

This efficient method enables higher frequency data collection, but the signal encoding becomes specific to your request method, making generic OBD2 DBC files less useful. We generally advise against this method. Below is an example trace:

The multi-frame response structure is similar to the VIN example, but with the added complexity of including the requested PIDs and their corresponding data in the payload. In this example, the PIDs are ordered similarly to the request order, which is common but not strictly mandated by ISO 15031-5.

Decoding such responses using generic DBC files is challenging. We do not recommend this approach for practical data logging unless you are using tools with built-in support for this specific method. It essentially involves extended multiplexing, but with multiple instances throughout the payload. Creating a DBC file to handle the payload position of each PID across different vehicles with varying supported PIDs is very difficult to generalize. Furthermore, managing this through DBC manipulations becomes nearly impossible if you send multiple multi-PID requests, as you would lack a method to uniquely identify these messages.

A workaround could involve custom scripting and recording the transmit messages from your testing tool. The script could then interpret the response message based on the corresponding request message. However, such approaches are generally complex to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

You can request emissions-related Diagnostic Trouble Codes (DTCs) using OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’. No PID is included in the request. The targeted ECU(s) will respond with the number of stored DTCs (possibly zero if none are stored), 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 divided into two parts, 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 shown visually. 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.

Alt text: OBD2 DTC decoding example, illustrating Diagnostic Trouble Code DBC interpretation, category and code breakdown.

OBD2 Data Logging: Use Case Examples

OBD2 data from cars and light trucks has numerous applications:

Alt text: OBD2 data logger icon representing on-board diagnostics in a vehicle context.

Logging Data from Cars

OBD2 data logging in cars can be used for purposes like reducing fuel consumption, improving driving habits, testing prototype components, and insurance telematics.

Explore OBD2 Loggers

Alt text: OBD2 real-time streaming diagnostics icon showing USB connection for data transfer.

Real-Time Car Diagnostics

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

Discover OBD2 Streaming Interfaces

Alt text: OBD2 data logger icon for predictive maintenance and telematics applications in vehicle health monitoring.

Predictive Maintenance

Cars and light trucks can be monitored via IoT OBD2 loggers connected to the cloud for predictive maintenance, helping to anticipate and prevent breakdowns.

Learn about Predictive Maintenance Solutions

Alt text: CAN bus data logger black box icon for vehicle event recording, insurance, and warranty applications.

Vehicle Black Box Logger

An OBD2 logger can serve as a ‘black box’ in vehicles or equipment, providing critical data for dispute resolution, accident analysis, and diagnostics.

Explore CAN Bus Black Box Loggers

Do you have an OBD2 data logging use case? We’re here to help – reach out 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

Recommended Resources

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[