Looking for a straightforward and practical guide to OBD2?
This article provides an in-depth exploration of the On-Board Diagnostics (OBD2) protocol, covering everything from the OBD2 connector and Parameter IDs (PIDs) to its connection with the CAN bus.
This is more than just an introduction. You’ll learn how to effectively request and interpret Obd2 Output data, understand key logging applications, and gain valuable practical insights.
Discover why this is considered the ultimate OBD2 resource.
You can also explore our introductory OBD2 video or download this guide in PDF format.
Article Contents
Author: Martin Falch (Updated January 2025)
Download as PDF
Understanding OBD2: Your Car’s Diagnostic Output
OBD2 is essentially your vehicle’s internal health monitoring system. It’s a standardized system that allows you to access Diagnostic Trouble Codes (DTCs) and real-time operational data through the OBD2 connector. This standardized OBD2 output is critical for modern vehicle maintenance and diagnostics.
You’ve likely already encountered OBD2 in action:
Have you ever noticed the check engine light illuminating on your dashboard?
That light is your car signaling a potential problem. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the issue.
Mechanics connect an OBD2 reader to the 16-pin OBD2 connector, usually located near the steering wheel. This tool sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’. These responses can contain a wealth of information, including speed, fuel level, and Diagnostic Trouble Codes (DTCs). This OBD2 output enables faster and more accurate troubleshooting.
OBD2 Compatibility: Does Your Car Have It?
The short answer: Almost certainly!
Nearly all modern gasoline and diesel cars, excluding electric vehicles, are equipped with OBD2 and typically operate on the CAN bus protocol. For older vehicles, even if a 16-pin OBD2 connector is present, it might not fully support OBD2. A reliable way to check OBD2 compliance is based on the car’s purchase location and year:
A Brief History of OBD2 and its Evolution
OBD2’s journey began in California, driven by the California Air Resources Board (CARB). Starting in 1991, CARB mandated OBD systems in all new vehicles sold in California to monitor and control emissions. This marked the initial push for standardized OBD2 output for environmental reasons.
The Society of Automotive Engineers (SAE) further developed the OBD2 standard, standardizing Diagnostic Trouble Codes (DTCs) and the physical OBD connector across different vehicle manufacturers (SAE J1962).
The implementation of OBD2 was phased in over time:
- 1996: OBD2 became mandatory in the USA for cars and light trucks.
- 2001: The European Union mandated OBD2 for gasoline cars.
- 2003: The EU extended the mandate to diesel cars (EOBD – European On-Board Diagnostics).
- 2005: OBD2 became required in the US for medium-duty vehicles.
- 2008: US vehicles were required to utilize ISO 15765-4 (CAN) as the foundation for OBD2 communication, standardizing the OBD2 output protocol.
- 2010: OBD2 compliance was finally mandated in the US for heavy-duty vehicles.
The Future of OBD2: Trends and Innovations
OBD2 is a foundational technology that is expected to remain relevant, though its form and function are evolving.
Here are some key future trends:
Originally designed for emissions monitoring and testing, legislated OBD2 has a notable exception: electric vehicles. Electric vehicles are not currently required to support OBD2 in any form. In fact, most modern EVs do not support standard OBD2 requests. Instead, they often use OEM-specific UDS (Unified Diagnostic Services) communication. This OEM-specific approach makes accessing OBD2 output data from EVs challenging, except in cases where reverse engineering efforts have uncovered the data decoding methods. Examples include studies for electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.
Current OBD2 implementations have limitations in data richness and underlying communication protocols. To address these, newer standards like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These protocols aim to improve OBD communication by utilizing the UDS protocol as a base, enhancing the capabilities and standardization of OBD2 output. For a deeper understanding of these protocols, refer to our introduction to UDS.
In our increasingly connected world, traditional OBD2 testing methods can seem inefficient. Manual emission checks are time-consuming and costly.
The proposed solution is OBD3: integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder (similar to those used for bridge tolls) to all cars. This would allow vehicles to transmit their vehicle identification number (VIN) and DTCs wirelessly via WiFi to a central server for automated checks.
Many current devices, like the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger, already facilitate the wireless transfer of CAN or OBD2 data.
While this offers convenience and cost savings, it also raises political and privacy concerns related to surveillance.
The original OBD2 protocol was designed for stationary emission testing.
However, today, OBD2 is widely used by third parties to access real-time vehicle data via OBD2 dongles, CAN loggers, and other devices. Interestingly, the German car industry is considering changes that could impact this trend German car industry plans to close OBD interface:
OBD was intended for vehicle servicing in repair shops. It was never designed to allow third-party entities to build a data-driven economy based on access through this interface.
– Christoph Grote, SVP Electronics, BMW (2017)
The proposal suggests disabling OBD2 functionality while driving and instead centralizing data collection with manufacturers. This would give manufacturers control over ‘automotive big data’.
The rationale is based on security concerns, such as mitigating the risk of car hacking, though some view it as a commercially motivated move Future of OBD trackers. Whether this becomes a widespread trend remains to be seen, but it could significantly disrupt the market for third-party OBD2 services and OBD2 output accessibility.
Enhance Your CAN Bus Expertise
Want to become a CAN bus expert?
Access our 12 ‘simple introductions’ in one comprehensive 160+ page PDF:
Download now
OBD2 Standards: Defining the Protocol
On-board diagnostics, specifically OBD2, is a higher-layer protocol (akin to a language). CAN (Controller Area Network) acts as the communication method (similar to a phone line). This positions OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.
OBD2 standards precisely define the OBD2 connector, lower-layer protocols, OBD2 Parameter IDs (PIDs), and other critical aspects, ensuring consistent OBD2 output.
These standards can be organized using the 7-layer OSI model. The following sections will focus on the most significant standards.
In the OSI model framework, you’ll notice that both SAE and ISO standards cover multiple layers. This reflects the development of OBD standards in the USA (SAE) and Europe (ISO). Many standards are technically very similar, for example, SAE J1979 and ISO 15031-5, as well as SAE J1962 and ISO 15031-3.
The OBD2 Connector: SAE J1962 Standard
The 16-pin OBD2 connector provides a standardized physical interface to access your car’s data, as defined by SAE J1962 / ISO 15031-3. This connector is the gateway to OBD2 output.
The illustration above shows a typical Type A OBD2 pin connector (also known as the Data Link Connector, or DLC).
Key features of the OBD2 connector:
- Usually located near the steering wheel, though it may 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, typically using pins 6 (CAN-H) and 14 (CAN-L) for communication, facilitating OBD2 output via CAN.
OBD2 Connector Types: A vs. B
In practical applications, you might encounter both Type A and Type B OBD2 connectors. Type A is commonly found in cars, while Type B is prevalent in medium and heavy-duty vehicles.
While both types share similar OBD2 pinouts, they differ in power supply output: Type A provides 12V, and Type B provides 24V. Baud rates may also vary, with cars typically using 500K and heavy-duty vehicles often using 250K (with increasing support for 500K).
Visually, Type B OBD2 connectors have a distinguishing interrupted groove in the center. This design allows a Type B OBD2 adapter cable to be compatible with both Type A and Type B sockets, whereas a Type A adapter will only fit into a Type A socket. Understanding these connector types is crucial for accessing OBD2 output correctly.
OBD2 and CAN Bus: ISO 15765-4 Integration
Since 2008, CAN bus has been mandated as the primary lower-layer protocol for OBD2 in all vehicles sold in the US, according to ISO 15765. This standardization ensures consistent OBD2 output across vehicles.
ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies a set of constraints 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 rates 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, structuring OBD2 output communication.
- Diagnostic CAN frame data length is fixed at 8 bytes.
- The OBD2 adapter cable is limited to a maximum length of 5 meters.
OBD2 CAN Identifiers: 11-bit and 29-bit
All OBD2 communication relies on request/response message exchanges.
In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, which is used to query all OBD2-compatible ECUs to check if they have data for the requested parameter (as defined in ISO 15765-4). CAN IDs ranging from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’ requests directed to specific ECUs (less common).
ECUs typically respond using 11-bit IDs in the range of 0x7E8 to 0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module). These IDs are fundamental to understanding OBD2 output message flow.
In some vehicles, particularly vans and light/medium/heavy-duty vehicles, OBD2 communication may utilize extended 29-bit CAN identifiers instead of 11-bit IDs.
Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
When a vehicle responds using 29-bit IDs, you’ll see response IDs ranging from 0x18DAF100 to 0x18DAF1FF (commonly 18DAF110 and 18DAF11E). The response ID is sometimes represented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated in the J1939-71 standard as ‘Reserved for ISO 15765-2’. These identifiers are crucial for interpreting OBD2 output in different vehicle types.
OBD2 vs. Proprietary CAN Protocols
It’s important to understand that your vehicle’s Electronic Control Units (ECUs) do not rely on OBD2 for their core operations. Instead, each Original Equipment Manufacturer (OEM) develops its own proprietary CAN protocols for internal vehicle communication. These OEM-specific CAN protocols are often unique to the vehicle brand, model, and year. Generally, this OEM-specific data is inaccessible to third parties unless it is reverse engineered.
If you connect a CAN bus data logger to your car’s OBD2 connector, you might observe OEM-specific CAN data, which is typically broadcast at high rates (1000-2000 frames per second). However, many newer vehicles employ a ‘gateway’ module that restricts access to this proprietary CAN data and only permits OBD2 communication through the OBD2 connector. This gateway limits the OBD2 output to standardized diagnostic information.
In essence, think of OBD2 as an ‘additional’ higher-layer protocol functioning alongside the OEM-specific protocol. OBD2 provides a standardized OBD2 output layer for diagnostics, separate from the OEM’s internal communication network.
Bit-rate and ID Validation for OBD2 Output
As mentioned, OBD2 can operate with two different 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 these settings.
ISO 15765-4 outlines a recommended initialization sequence to determine the correct combination. This method leverages the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (detailed in the OBD2 PID section) and that incorrect bit-rate transmissions will cause CAN error frames. Proper bit-rate and ID validation is essential for reliable OBD2 output retrieval.
Newer versions of ISO 15765-4 account for vehicles that may support OBD communication via OBDonUDS rather than OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979) compared to 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 can send additional request messages, specifically UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and Data Identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.
In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is predominantly used in non-EV cars today, while WWH-OBD is mainly used in EU trucks and buses. Understanding these protocol variations is important for correctly interpreting OBD2 output.
Five Lower-Layer OBD2 Protocols
While CAN (ISO 15765) is now the dominant lower-layer protocol for OBD2, especially in vehicles manufactured post-2008, older cars might use different protocols. Knowing these protocols and their corresponding OBD2 connector pinouts can be helpful when working with older vehicles.
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now the most widely used protocol for OBD2 output.
- ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, particularly in Asia.
- ISO 9141-2: Used in EU, Chrysler, and Asian cars between 2000-2004.
- SAE J1850 (VPW): Predominantly used in older General Motors (GM) vehicles.
- SAE J1850 (PWM): Primarily used in older Ford vehicles.
ISO-TP: Transporting OBD2 Messages Beyond 8 Bytes (ISO 15765-2)
All OBD2 data communication over CAN bus uses the ISO-TP (ISO 15765-2) transport protocol. ISO-TP enables the transmission of data payloads larger than the 8-byte limit of standard CAN frames. This capability is essential for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often exceed 8 bytes. ISO 15765-2 handles data segmentation, flow control, and reassembly for these larger OBD2 output messages. For detailed information, see our introduction to UDS.
However, much of the real-time OBD2 output 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 message, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for the actual OBD2 communication.
The OBD2 Diagnostic Message Structure (SAE J1979, ISO 15031-5)
To better understand OBD2 communication over CAN, let’s examine the structure of a raw ‘Single Frame’ OBD2 CAN message. In simple terms, an OBD2 message consists of a CAN identifier, a data length indicator (PCI field), and the data payload. The data payload is further structured into Mode, Parameter ID (PID), and data bytes, all contributing to the OBD2 output data.
Example: OBD2 Request and Response for Vehicle Speed
Let’s consider a practical example: requesting and receiving the ‘Vehicle Speed’ parameter.
In this scenario, an external diagnostic tool sends a request message to the vehicle. The CAN ID for this request is 0x7DF, and the payload contains two bytes: Mode 0x01 and PID 0x0D. This request is asking for real-time data (Mode 0x01) for the Vehicle Speed PID (0x0D).
The vehicle’s ECU responds with a message using CAN ID 0x7E8. The response payload contains three bytes. The fourth byte in the original CAN data frame (which becomes the third byte in the OBD2 payload after the PCI field) contains the Vehicle Speed value, in this case, 0x32 (decimal 50).
By consulting the OBD2 PID documentation for PID 0x0D, we find the decoding rules. Applying these rules, we determine that the value 0x32 corresponds to a physical speed of 50 km/h. This example illustrates the basic request-response mechanism for retrieving OBD2 output data.
The 10 OBD2 Services (Modes)
OBD2 defines 10 diagnostic services, also known as modes. Each mode serves a specific purpose for accessing OBD2 output. Mode 0x01, for example, is used to retrieve current real-time data, while other modes are used to access or clear Diagnostic Trouble Codes (DTCs) or retrieve freeze frame data.
Vehicles are not required to support all 10 OBD2 modes. They may also support additional OEM-specific modes beyond the 10 standardized modes.
In OBD2 messages, the mode is indicated in the second byte of the data payload. In a request message, the mode is included directly (e.g., 0x01). In a response message, 0x40 is added to the requested mode (e.g., a response to mode 0x01 will have mode 0x41 in the response).
OBD2 Parameter IDs (PIDs)
Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the particular data parameter being requested or reported in the OBD2 output.
For example, Mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on various vehicle parameters such as 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 holds special significance:
If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. When queried with PID 0x00 in Mode 0x01, the vehicle ECU responds by indicating which PIDs in the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental tool for OBD2 output compatibility testing. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for subsequent ranges of Mode 0x01 PIDs.
Tip: OBD2 PID Overview Tool
The appendices of SAE J1979 and ISO 15031-5 provide scaling and conversion information for standard OBD2 PIDs. This information is essential for decoding raw OBD2 output data into meaningful physical values, as explained in our CAN bus introduction.
For quick lookup of Mode 0x01 PIDs, our OBD2 PID overview tool is a valuable resource. This tool assists in constructing OBD2 request frames and dynamically decoding OBD2 responses, streamlining the process of accessing and interpreting OBD2 output.
OBD2 PID overview tool
Practical Guide: Logging and Decoding OBD2 Data
This section provides a step-by-step example of how to log OBD2 output data using the CANedge CAN bus data logger.
The CANedge’s flexible configuration allows you to define custom CAN frames for transmission, making it ideal for OBD2 logging.
Once configured, the CANedge can be easily connected to your vehicle’s OBD2 port using our OBD2-DB9 adapter cable.
Verifying successful CAN frame transmission at 500K bit rate.
Reviewing ‘Supported PIDs’ responses in asammdf software.
Step #1: Bit-rate, ID, and Supported PID Testing
As previously discussed, ISO 15765-4 provides guidelines for determining the correct bit-rate and CAN IDs for OBD2 communication with a specific vehicle. The CANedge can be used to systematically test these parameters. See the CANedge Introduction for detailed setup instructions.
- Bit-rate Test: Attempt to send a CAN frame at 500K bit rate. Verify successful transmission (if unsuccessful, try 250K).
- Bit-rate Confirmation: Use the successfully tested bit-rate for all subsequent OBD2 communication.
- Supported PID Discovery: Send multiple ‘Supported PIDs’ requests (Mode 0x01, PID 0x00, 0x20, 0x40, etc.) and analyze the responses.
- CAN ID Type Determination: Based on the response CAN IDs, determine whether the vehicle uses 11-bit or 29-bit CAN identifiers for OBD2 output.
- Supported PID Identification: Analyze the response data to identify the specific PIDs supported by the vehicle’s ECUs, defining the available OBD2 output parameters.
We offer plug-and-play configuration files to simplify these initial tests.
Most non-electric vehicles manufactured in 2008 or later typically support 40-80 PIDs, using a 500K bit rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol for OBD2 output.
As illustrated in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBD request, particularly when using the functional addressing request ID 0x7DF. This is because 0x7DF queries all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, multiple ECUs often respond to this PID. As you progress through subsequent ‘Supported PIDs’ requests (0x20, 0x40, etc.), fewer ECUs will typically respond. Notice that the ECM ECU (0x7E8) in the example supports all the PIDs supported by other ECUs. Therefore, to reduce bus load, you could optimize communication by directing subsequent requests specifically to the ECM ECU using the ‘Physical Addressing’ CAN ID 0x7E0.
Step #2: Configuring OBD2 PID Requests for Logging
Once you have identified the supported OBD2 PIDs for your vehicle, along with the correct bit-rate and CAN IDs, you can configure the CANedge to request and log specific PIDs of interest for OBD2 output capture.
Consider these points when configuring your PID request list:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to target specific ECUs and avoid redundant responses, optimizing OBD2 output data collection.
- Request Spacing: Introduce a delay of 300-500 ms between each OBD2 request. Overly rapid requests can overwhelm ECUs and lead to dropped responses, affecting OBD2 output reliability.
- Battery Drain Management: Utilize triggers to stop PID requests when the vehicle is inactive. This prevents unnecessary ECU ‘wake-up’ and battery drain, especially during prolonged logging sessions focused on OBD2 output.
- Data Filtering: Implement filters to record only OBD2 responses. This is particularly useful if your vehicle also broadcasts OEM-specific CAN data, allowing you to isolate relevant OBD2 output within the logged data.
With these configurations in place, your CANedge is ready to log raw OBD2 output data efficiently.
Example CANedge OBD2 PID request list configuration.
asammdf software displaying DBC decoded and visualized OBD2 data.
Step #3: DBC Decoding of Raw OBD2 Data
To effectively analyze and visualize your logged OBD2 output data, you need to decode the raw CAN data into physical values (e.g., km/h, °C). This is achieved using a DBC (CAN database) file.
The necessary decoding information is defined in ISO 15031-5/SAE J1979 and is also available in resources like Wikipedia. For convenience, we provide a free OBD2 DBC file that simplifies DBC decoding of raw OBD2 data in most CAN bus analysis software tools.
Decoding OBD2 data is more complex than decoding standard CAN signals. This is because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is insufficient to uniquely identify the signals within the payload.
To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID in combination to identify each signal. This technique is known as ‘extended multiplexing‘ and can be implemented using DBC files. Our provided OBD2 DBC file is configured to handle this extended multiplexing, enabling accurate decoding of OBD2 output.
CANedge: Your OBD2 Data Logging Solution
The CANedge provides a streamlined solution for recording OBD2 output data directly to an 8-32 GB SD card. Simply connect the CANedge to your car or truck’s OBD2 port to begin logging. Analyze and decode the logged data using free software and APIs and our OBD2 DBC file.
OBD2 logger introduction
Explore CANedge
OBD2 Multi-Frame Examples: ISO-TP in Action
All OBD2 communication utilizes the ISO-TP transport protocol (ISO 15765-2). While many examples illustrate single-frame communication, some OBD2 operations, like retrieving VIN or DTCs, require multi-frame communication for larger OBD2 output payloads. This section provides examples of multi-frame OBD2 interactions.
Multi-frame OBD2 communication necessitates flow control frames (see our UDS introduction for details). In practice, a static flow control frame can be transmitted approximately 50 ms after the initial request frame, as shown in the CANedge configuration example.
Decoding multi-frame OBD2 responses requires CAN software or API tools that support ISO-TP, such as the CANedge MF4 decoders. These tools are essential for correctly interpreting multi-frame OBD2 output.
Example 1: Retrieving the Vehicle Identification Number (VIN) via OBD2
The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and various automotive applications (see our UDS introduction for more information). To retrieve the VIN from a vehicle using OBD2, you use Mode 0x09 and PID 0x02:
The diagnostic tool initiates the VIN retrieval process by sending a Single Frame request. This request includes the PCI field (0x02), the request service identifier (0x09 for Mode 9), and the PID (0x02 for VIN request).
The vehicle responds with a multi-frame response. The first frame is a First Frame, containing the PCI field, the total length of the multi-frame message (0x014 = 20 bytes), the mode (0x49, indicating a response to Mode 9), and the PID (0x02). Following the PID is the Number Of Data Items (NODI) byte, which is 0x01 in this case, indicating one VIN is being returned (see ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes contain the VIN itself, encoded in hexadecimal ASCII. These bytes need to be converted from HEX to ASCII using methods described in our UDS introduction to obtain the human-readable VIN from the OBD2 output.
Example 2: OBD2 Multi-PID Request (Requesting 6 PIDs)
OBD2 allows diagnostic tools to request up to 6 Mode 0x01 PIDs in a single request frame. The ECU should respond with data for all supported PIDs from the request (omitting data for unsupported PIDs), potentially using multi-frame responses via ISO-TP if the data exceeds a single frame. This multi-PID request capability can enhance the efficiency of OBD2 output data acquisition.
This feature enables higher-frequency data collection but introduces complexity in signal encoding. The signal encoding becomes specific to the request method, making generic OBD2 DBC files less effective for decoding. Therefore, we generally advise against using multi-PID requests in practice unless specifically required.
Below is an example trace illustrating a multi-PID request and response exchange:
The multi-frame response structure resembles the VIN example, but with the payload containing both the requested PIDs and their corresponding data values. In this example, the PIDs in the response are ordered similarly to their order in the request, which is a common practice but not strictly mandated by the ISO 15031-5 standard.
Decoding these multi-PID responses using generic DBC files is very challenging. Therefore, we do not recommend this approach for general OBD2 output data logging unless you are using specialized tools with built-in support for multi-PID requests. Effectively, you are dealing with a more complex form of extended multiplexing where the DBC file would need to account for the specific payload position of each PID, which is difficult to generalize across vehicles with varying PID support. Furthermore, managing this complexity through DBC manipulation becomes impractical when sending multiple such multi-PID requests, as you lose a straightforward method for uniquely identifying messages.
A workaround could involve custom scripting combined with recording the transmit messages from your diagnostic tool. The script could then interpret the response message in context with the corresponding request message. However, such custom solutions are challenging to scale and maintain.
Example 3: Retrieving OBD2 Diagnostic Trouble Codes (DTCs)
OBD2 Mode 0x03, ‘Show stored Diagnostic Trouble Codes’, is used to request emissions-related DTCs. The request frame for Mode 0x03 does not include a PID. The targeted ECU(s) will respond with the number of DTCs currently stored (which may be zero if no DTCs are present). Each DTC is represented by 2 data bytes. Multi-frame responses are necessary when more than two DTCs are stored to accommodate the larger OBD2 output payload.
The 2-byte DTC value is structured according to ISO 15031-5/ISO 15031-6. The first two bits define the DTC ‘category’, and the remaining 14 bits represent a 4-digit code (displayed in hexadecimal), as shown in the diagram. Decoded DTC values can be looked up using online OBD2 DTC lookup tools, such as repairpal.com.
The example below shows a request to an ECU that has 6 DTCs stored, resulting in a multi-frame OBD2 output response.
OBD2 Data Logging Use Cases
OBD2 data logging from cars and light trucks has numerous applications across various industries:
Vehicle Data Logging for Cars
OBD2 data from passenger vehicles can be leveraged to optimize fuel efficiency, improve driving habits, test prototype components, and for insurance telematics, all leveraging valuable OBD2 output.
Explore OBD2 Loggers
Real-Time Vehicle Diagnostics
OBD2 interfaces facilitate real-time streaming of human-readable OBD2 data, enabling immediate diagnostics of vehicle issues and efficient troubleshooting using OBD2 output.
Learn about OBD2 Streaming
Predictive Maintenance Applications
Cars and light trucks equipped with IoT OBD2 loggers can be remotely monitored in the cloud. Analyzing OBD2 output data allows for predictive maintenance, anticipating potential breakdowns and enabling proactive servicing.
Discover Predictive Maintenance Solutions
Vehicle Black Box Recorders
An OBD2 logger can function as a ‘black box’ for vehicles and equipment, providing crucial data for accident analysis, dispute resolution, and comprehensive vehicle diagnostics, all derived from reliable OBD2 output.
Explore CAN Bus Black Box Loggers
Do you have a specific OBD2 data logging use case in mind? Contact us for expert consultation!
Contact us
Explore our guides section for more introductory articles, or download our comprehensive ‘Ultimate Guide’ PDF.
Need to log or stream OBD2 data?
Get your OBD2 data logger today!
Buy Now
Contact Us
Recommended Resources
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANEDGE2 – PRO CAN IoT LOGGER
CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN
