How to Change OBD2 Parameters: A Comprehensive Guide for Car Enthusiasts

Looking to understand and potentially “change” OBD2 parameters?

This in-depth guide provides a comprehensive overview of On-Board Diagnostics (OBD2) and how you can interact with its parameters. We’ll explore the OBD2 protocol, connector, Parameter IDs (PIDs), and delve into how you can request, interpret, and utilize this data.

Note: This is a detailed guide designed to enhance your understanding of OBD2 parameters and data interaction. We will clarify what “changing” parameters practically means in the context of OBD2.

Discover why this is considered a leading resource for understanding OBD2 parameters.

You can further enhance your knowledge by watching our OBD2 introduction video or downloading our comprehensive PDF guide on CAN bus.

Understanding OBD2: Your Car’s Diagnostic Window

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

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

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

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

This is done by connecting an OBD2 reader to the 16-pin OBD2 connector, typically located near the steering wheel. The scanner sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’. These responses can contain valuable information like speed, fuel level, and Diagnostic Trouble Codes (DTCs), enabling quicker and more accurate troubleshooting.

Understanding the OBD2 System: The Malfunction Indicator Light (MIL) alerts drivers to potential issues, which mechanics can diagnose using scan tools connected to the OBD2 port.

OBD2 Compatibility: Is Your Car Equipped?

In most cases, yes!

The vast majority of modern non-electric vehicles are OBD2 compliant, and many utilize the CAN bus communication protocol. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 support. Determining OBD2 compliance often depends on the vehicle’s origin and year of manufacture:

Regional OBD2 Compliance Timeline: This chart illustrates the mandatory implementation years for OBD2 in the US and EU, helping determine if your vehicle is likely compliant based on its origin and manufacturing date.

A Brief History of OBD2: From Emissions to Data Access

OBD2’s roots are in California, where the California Air Resources Board (CARB) mandated OBD systems in all new vehicles from 1991 onwards for emission control.

The Society of Automotive Engineers (SAE) further developed the OBD2 standard, standardizing DTCs and the OBD connector across different manufacturers (SAE J1962).

The OBD2 standard was progressively implemented worldwide:

1996: OBD2 became mandatory 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 mandate expanded to medium-duty vehicles in the US.
2008: US vehicles required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 became mandatory for heavy-duty vehicles in the US.

OBD2 Evolution Timeline: This graphic depicts the historical progression of OBD2, highlighting its origins in emission control and its evolution into a broader data access interface.

OBD2 History Timeline: A visual timeline summarizing key milestones in the development and implementation of OBD2 standards and regulations across different regions.

Future of OBD: OBD3 and Remote Diagnostics: Illustrates the potential future of OBD with OBD3, focusing on remote diagnostics, emissions testing, and cloud-based integration for connected vehicles.

The Future of OBD2: Trends and Transformations

OBD2 is expected to remain relevant, but its form and function are evolving.

Here are key trends shaping the future of OBD:

Initially designed for emission control and testing, legislative OBD2 requirements are different for electric vehicles. Interestingly, most modern EVs do not natively support standard OBD2 requests. Instead, they often utilize OEM-specific UDS communication protocols. This makes accessing data from EVs challenging unless decoding rules are reverse-engineered. However, progress is being made, as seen in case studies for electric cars including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Current OBD2 implementations have limitations in data richness and lower-layer protocols. Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging. These aim to improve OBD communication using the UDS protocol. For more information, see our introduction to UDS.

In our increasingly connected world, traditional OBD2 testing methods can be inefficient. Manual emission 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 for bridge tolls) to every car. 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 CAN or OBD2 data transfer via WiFi/cellular, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.

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

The original purpose of OBD2 was for stationary emission controls.

However, OBD2 is now widely used by third parties to generate real-time data through OBD2 dongles, CAN loggers and similar tools. The German car industry is considering changes that could impact this:

OBD was intended for vehicle servicing in repair shops, not for 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 during driving and instead collecting data on a central server, giving manufacturers control over the ‘automotive big data’.

Arguments for this change include security improvements (e.g., reducing the risk of car hacking). However, many perceive this as a commercially motivated move. The future of this proposal and its potential disruption to the OBD2 third-party service market remain to be seen.

OBD2 in EVs: Data Access Limitations: Illustrates the trend of electric vehicles potentially limiting or altering OBD2 access, impacting aftermarket data retrieval and diagnostics.

Enhance Your CAN Bus Expertise

Want to become a CAN bus expert?

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

Download now

OBD2 Standards: Defining the Protocol

On-board diagnostics, OBD2, operates as a higher-layer protocol (like a language) on top of communication methods like CAN (similar to a phone line). OBD2 is comparable to other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

OBD2 standards specify the OBD2 connector, lower-layer communication 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.

In the OSI model representation, you’ll notice that SAE and ISO standards cover multiple layers. This reflects the standards defined for OBD in the US (SAE) and EU (ISO). Many standards are technically very similar, for example, SAE J1979 versus ISO 15031-5, and SAE J1962 versus ISO 15031-3.

OSI Model for OBD2 and CAN Bus: This diagram illustrates how OBD2 and CAN bus protocols map to the 7-layer OSI model, highlighting the standards (ISO 15765, ISO 11898) that govern each layer.

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector is your primary interface for 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 the Data Link Connector, DLC).

Key points about the OBD2 connector:

It’s usually located near the steering wheel, though it might be concealed.
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 commonly used.

OBD2 Connector Types: A vs. B

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

While both types have similar OBD2 pinouts, they 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 (with increasing support for 500K).

Visually, a Type B OBD2 connector has an interrupted groove in the middle, distinguishing it from Type A. 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 Connector Type Comparison: Illustration differentiating between Type A and Type B OBD2 connectors, highlighting voltage differences (12V vs 24V) and typical vehicle applications (cars/vans vs. trucks).

OBD2 and CAN Bus Interrelation: Depicts the relationship between OBD2 as a diagnostic protocol and CAN bus as the underlying communication network, both governed by ISO 15765 standards.

OBD2 and CAN Bus: ISO 15765-4 Standard

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

ISO 15765-4 (Diagnostics over CAN or DoCAN) specifies restrictions applied to the CAN standard (ISO 11898) for diagnostic communication.

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

OBD2 CAN Identifiers: 11-bit and 29-bit

OBD2 communication is based on request/response message exchanges.

In most cars, 11-bit CAN IDs are used for OBD2. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs for data related to a requested parameter (as defined in ISO 15765-4). ‘Physical Addressing’ requests to specific ECUs can use CAN IDs from 0x7E0 to 0x7E7 (less commonly used).

ECUs respond with 11-bit IDs from 0x7E8 to 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.

The ‘Functional Addressing’ CAN ID in this case is 0x18DB33F1.

Responses are typically seen with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (commonly 18DAF110 and 18DAF11E). The response ID is sometimes represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is reserved for ISO 15765-2 in the J1939-71 standard.

OBD2 Request-Response Frames: Diagram illustrating the structure of OBD2 communication frames, showing request and response messages with Parameter IDs (PIDs) and data parameters.

OBD2 vs. OEM CAN Data: Compares and contrasts OBD2 data with proprietary OEM-specific CAN bus data within a vehicle’s network, highlighting differences in accessibility and standardization.

OBD2 vs. OEM-Specific CAN Protocols

It’s important to understand that your vehicle’s Electronic Control Units (ECUs) operate using OEM-proprietary CAN protocols, independent of OBD2. These protocols are specific to the vehicle manufacturer, model, and year. Generally, this OEM-specific CAN data is not interpretable without OEM documentation or reverse engineering.

Connecting a CAN bus data logger to your OBD2 port might capture OEM-specific CAN data, often broadcast at 1000-2000 frames/second. However, newer vehicles often employ a ‘gateway’ that restricts access to this data, allowing only OBD2 communication via the OBD2 connector.

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

Bit-rate and ID Validation Process

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 with 11-bit IDs. Diagnostic tools should systematically verify these parameters.

ISO 15765-4 provides guidelines for an 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-rates will cause CAN error frames.

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

To differentiate between OBDonEDS and OBDonUDS, diagnostic tools may 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 vehicles today, while WWH-OBD is primarily used in EU trucks and buses.

OBD2 Protocol Validation Flow: A flowchart illustrating the process of validating OBD2 communication parameters like bit-rate and CAN ID length according to ISO 15765-4, ensuring correct diagnostic tool setup.

OBD2 Protocol Standards: Overview of the five primary lower-layer protocols used in OBD2 communication, including CAN (ISO 15765), KWP2000, ISO 9141, and SAE J1850 (VPW and PWM), and their historical context.

Five Lower-Layer OBD2 Protocols

While CAN (ISO 15765) is the dominant lower-layer protocol for OBD2 in modern vehicles, older cars (pre-2008) may use other protocols. Understanding these is helpful, especially when working with older vehicles. Pinouts can often indicate the protocol in use.

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 EU, Chrysler, and Asian vehicles around 2000-2004.
SAE J1850 (VPW): Primarily used in older GM vehicles.
SAE J1850 (PWM): Primarily used in older Ford vehicles.

ISO-TP: Transporting OBD2 Messages (ISO 15765-2)

OBD2 data communication over CAN bus utilizes ISO-TP (ISO 15765-2), a transport protocol that allows for messages larger than 8 bytes. This is crucial 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 detailed information, refer to our intro to UDS.

In many cases, OBD2 data fits within a single CAN frame. ISO 15765-2 specifies the use of ‘Single Frame’ (SF) format in such instances. The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2 communication.

ISO-TP Frame Types: Diagram illustrating the different frame types defined in ISO 15765-2 (ISO-TP) for OBD2 communication, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

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

To effectively work with OBD2 over CAN, understanding the structure of a raw ‘Single Frame’ OBD2 CAN message is essential. An OBD2 message consists of an identifier, data length (PCI field), and data. The data section is further divided into Mode, Parameter ID (PID), and data bytes.

OBD2 Message Structure: Breakdown of an OBD2 message frame, detailing the positions and roles of the PCI field, Mode byte, Parameter ID (PID), and data bytes within the CAN frame payload.

OBD2 Request/Response Example

Let’s examine a request and response example for the ‘Vehicle Speed’ parameter.

A diagnostic tool sends a request message to the car with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds with CAN ID 0x7E8 and 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 can determine that the physical value is 50 km/h.

Let’s now explore OBD2 modes and PIDs in more detail.

OBD2 Request/Response Example: Illustrates a CAN bus trace showing an OBD2 request (ID 0x7DF) for Vehicle Speed (PID 0x0D) and the corresponding response (ID 0x7E8) containing the speed data.

OBD2 PID 0x0D – Vehicle Speed: Example of OBD2 PID 0x0D (Vehicle Speed) decoding, showing how raw data bytes are converted into a physical speed value in km/h.

OBD2 Service Modes: Chart outlining the 10 standardized OBD2 service modes (or modes/services), including their functions like showing current data, freeze frame data, clearing DTCs, and more.

The 10 OBD2 Services (Modes)

OBD2 defines 10 diagnostic services, also known as modes. Mode 0x01 is used to access current real-time data, while other modes are used to retrieve 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 the standard set.

In OBD2 messages, the mode is specified 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)

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

For example, 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 mode. In practice, most vehicles support only a subset of these PIDs.

One PID is particularly significant:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the ECU indicates its support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental test for ‘OBD2 compatibility’. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to determine support for subsequent ranges of mode 0x01 PIDs.

OBD2 PID Request-Response Structure: Diagram reiterating the request and response structure in OBD2 communication, emphasizing the role of Parameter IDs (PIDs) in specifying the requested data.

OBD2 PID Lookup Tool Interface: Screenshot of an OBD2 PID lookup tool, showing the interface for service 01, used to explore and understand available Parameter IDs and their descriptions.

Tip: Using an OBD2 PID Overview Tool

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

For quick lookup of mode 0x01 PIDs, use our OBD2 PID overview tool. It helps you construct OBD2 request frames and dynamically decode OBD2 responses.

OBD2 PID overview tool

How to Log and Interpret OBD2 Data

This section provides a practical guide on logging 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, it easily connects to your vehicle via our OBD2-DB9 adapter cable.

OBD2 Data Logging Setup: Diagram showing an OBD2 data logger configured to send PID requests (ID 0x7DF) and receive responses (ID 0x7E8), illustrating the data flow for logging OBD2 parameters.

OBD2 Bit-Rate Validation: Interface showing a successful bit-rate validation test for OBD2 communication, confirming the correct communication speed for data exchange.

OBD2 Supported PIDs Validation in asammdf: Screenshot from asammdf software showing responses to ‘Supported PIDs’ requests, used to validate and identify which PIDs are supported by the vehicle.

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

As discussed, ISO 15765-4 outlines how to determine the correct bit-rate and IDs for a specific vehicle. You can use CANedge to perform these tests:

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

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

Most 2008+ non-EV cars 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 when using the 0x7DF request ID, which polls all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are often observed. Subsequent ‘Supported PIDs’ requests typically receive fewer responses as fewer ECUs support those PID ranges. Notably, the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs, suggesting that bus load could be reduced by directing subsequent requests specifically to this ECU using ‘Physical Addressing’ CAN ID 0x7E0.

#2: Configure OBD2 PID Requests

Once you know the supported OBD2 PIDs, bit-rate, and CAN IDs for your vehicle, you can configure your transmit list to request the PIDs of interest.

Consider these points when configuring your requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses per request.
Spacing: Introduce a 300-500 ms delay between OBD2 requests to prevent ECU overload.
Battery Drain: Implement triggers to stop transmissions when the vehicle is inactive to avoid unnecessary ECU wake-up and battery drain.
Filters: Apply filters to record only OBD2 responses if OEM-specific CAN data is also present.

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

CANedge OBD2 PID Request List Example: Configuration example of an OBD2 PID request list for CANedge, showing how to set up specific PIDs to request for data logging.

OBD2 Data Visualization with asammdf: Screenshot from asammdf software showing visualized OBD2 data plots, decoded using a DBC file, illustrating how raw OBD2 data is converted into meaningful graphs.

#3: DBC Decode Raw OBD2 Data

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

Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. We provide a free OBD2 DBC file to simplify 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). Therefore, the CAN ID alone is insufficient to identify the signals within the payload.

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

CANedge: Your OBD2 Data Logger

The CANedge simplifies OBD2 data recording to an 8-32 GB SD card. Connect it to your car or truck to start logging and decode the data using free software/APIs and our OBD2 DBC file.

OBD2 logger intro
CANedge product page

OBD2 Multi-Frame Examples: ISO-TP in Action

OBD2 communication relies on ISO-TP (ISO 15765-2) for all data exchange. Most examples so far have been single-frame. This section presents multi-frame communication examples.

Multi-frame OBD2 communication requires flow control frames (see our UDS intro). A common practice is to transmit a static flow control frame approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.

Analyzing multi-frame OBD2 responses requires CAN software/API tools that support ISO-TP, like CANedge MF4 decoders.

Example 1: Retrieving the Vehicle Identification Number (VIN)

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

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

The vehicle responds with a First Frame containing 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 constitute the VIN, which can be converted from HEX to ASCII as discussed in our UDS introduction.

Example 2: Multi-PID Request (6x)

Diagnostic tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU responds with data for supported PIDs (omitting unsupported ones), possibly using multiple frames via ISO-TP.

This efficient method allows for higher-frequency data collection. However, the signal encoding becomes specific to the request method, complicating the use of generic OBD2 DBC files. We generally advise against this method in practice. Below is an example trace:

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

Decoding these responses via generic DBC files is challenging. We recommend against this approach for practical data logging unless you use tools with specific built-in support. This scenario represents extended multiplexing with multiple instances throughout the payload. Your DBC file would need to account for the payload position of each PID, making generalization across vehicles difficult. Handling multiple such multi-PID requests further complicates DBC management.

Workarounds involve custom scripts and recording transmit messages, allowing scripts to interpret responses based on request messages. However, these approaches are difficult to scale.

Example 3: Diagnostic Trouble Codes (DTCs)

OBD2 allows requesting 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) respond with the number of stored DTCs (possibly 0 if none), with each DTC occupying 2 data bytes. Multi-frame responses are needed when more than 2 DTCs are stored.

The 2-byte DTC value is structured according to ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’, and the remaining 14 bits form a 4-digit hexadecimal code. 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.

OBD2 DTC Decoding Structure: Diagram explaining the structure of OBD2 Diagnostic Trouble Codes (DTCs), showing the 2-byte format and how to decode the category and code from the data bytes.

OBD2 Data Logging: Practical Applications

OBD2 data from cars and light trucks has diverse applications:

Vehicle Data Logging

OBD2 data logging can help reduce fuel costs, improve driving habits, test prototype components, and optimize insurance models.

Explore OBD2 loggers

Real-Time Vehicle Diagnostics

OBD2 interfaces enable real-time streaming of human-readable OBD2 data for immediate vehicle diagnostics and troubleshooting.

Discover OBD2 streaming

Predictive Maintenance

Cloud-connected IoT OBD2 loggers can monitor vehicle health to predict and prevent breakdowns, enhancing fleet management and vehicle longevity.

Learn about predictive maintenance

Vehicle Black Box Recording

An OBD2 logger can function as a vehicle ‘black box’, providing crucial data for incident analysis, dispute resolution, and detailed diagnostics.

Explore CAN bus black box solutions

Have an OBD2 data logging application in mind? Contact us for expert consultation!

For more educational content, visit our guides section or download the ‘Ultimate Guide’ PDF.

Ready to log or stream OBD2 data?

Get your OBD2 data logger today!

Purchase OBD2 logger
Contact us for inquiries

Recommended Resources

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN