The On-Board Diagnostics II (OBD2) system has become a cornerstone of modern automotive technology. It’s not just about diagnosing problems anymore; OBD2 is a gateway to a wealth of Data Available Over Obd2, offering unprecedented insights into your vehicle’s operation and health. Whether you’re a car enthusiast, a professional mechanic, or simply a curious owner, understanding the data available over OBD2 can empower you with knowledge and control.
This comprehensive guide provides a practical introduction to the world of OBD2 and the valuable data available over OBD2 it unlocks. We’ll explore the OBD2 protocol, the connector, Parameter IDs (PIDs), and how it all connects to the Controller Area Network (CAN) bus. More than just theory, we’ll delve into how to request and interpret data available over OBD2, highlighting key use cases and offering practical tips to get you started.
Discover why this guide is quickly becoming the go-to resource for understanding the data available over OBD2.
You can also watch our introductory video on OBD2 above – or download our comprehensive PDF guide for offline access.
Article Contents:
Author: Martin Falch (Updated January 2025)
Download as PDF
What Kind of Data is Available Over OBD2?
OBD2 is essentially your vehicle’s internal health monitoring system. It’s a standardized protocol designed to provide access to diagnostic trouble codes (DTCs) and, crucially, a wide range of real-time data available over OBD2. This data available over OBD2 is accessed through the standardized OBD2 connector.
You’ve likely encountered OBD2 in action without even realizing it. That check engine light illuminating on your dashboard? That’s your car’s OBD2 system signaling an issue. When you take your car to a mechanic, their first step is often connecting an OBD2 scanner to diagnose the problem.
This scanner plugs into the 16-pin OBD2 connector, typically located near the steering wheel. The tool sends ‘OBD2 requests’ to the vehicle, and the car responds with ‘OBD2 responses’. These responses contain valuable data available over OBD2 such as speed, engine RPM, fuel level, sensor readings, and of course, Diagnostic Trouble Codes (DTCs). This wealth of data available over OBD2 allows for faster and more accurate troubleshooting.
OBD2 Compatibility: Is Data Available Over OBD2 For Your Car?
In most cases, the answer is yes!
The vast majority of modern non-electric vehicles are OBD2 compliant, and many utilize the CAN bus communication protocol. For older vehicles, even if a 16-pin OBD2 connector is present, it might not fully support OBD2. A simple way to check OBD2 compliance is to consider the vehicle’s origin and year of purchase:
A Brief History of OBD2 and Data Availability
The story of OBD2 and the standardized data available over OBD2 begins in California. The California Air Resources Board (CARB) mandated OBD in all new vehicles starting from 1991 to monitor and control emissions.
The Society of Automotive Engineers (SAE) further developed the standard, leading to OBD2. This standardization included Diagnostic Trouble Codes (DTCs) and the physical OBD connector, ensuring interoperability across different vehicle manufacturers (SAE J1962).
The OBD2 standard, and the accessibility of data available over OBD2, was gradually implemented worldwide:
- 1996: OBD2 became mandatory in the USA for cars and light trucks.
- 2001: The European Union required OBD2 for gasoline-powered vehicles.
- 2003: OBD2 (known as EOBD in Europe) was mandated for diesel vehicles in the EU.
- 2005: OBD2 was required in the US for medium-duty vehicles.
- 2008: US vehicles were mandated to use ISO 15765-4 (CAN) as the foundation for OBD2 communication, standardizing the data interface.
- 2010: OBD2 compliance extended to heavy-duty vehicles in the US, making data available over OBD2 universally accessible across vehicle types.
The Future of OBD2 and Vehicle Data Access
OBD2 is firmly established, but its future evolution and how data available over OBD2 is accessed are subjects of ongoing development.
Initially designed for emissions monitoring, legislated OBD2 has a notable exception: electric vehicles (EVs). Interestingly, most modern EVs do not support standard OBD2 requests. Instead, they often utilize manufacturer-specific UDS communication protocols. This makes accessing data available over OBD2 from EVs challenging, except in cases where reverse engineering efforts have revealed decoding methods. We’ve explored some of these cases in our electric car case studies, including investigations into Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.
Recognizing the limitations of current OBD2 implementations in terms of data richness and underlying protocols, advancements like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These aim to improve OBD communication and expand the data available over OBD2 by utilizing the UDS protocol as a foundation. For a deeper dive into these protocols, refer to our introduction to UDS.
In our increasingly connected world, traditional OBD2 emission checks appear inefficient. Manual inspections are time-consuming and costly. The proposed solution? OBD3 – integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder to vehicles, similar to those used for electronic toll collection. This would enable the vehicle identification number (VIN) and DTCs to be wirelessly transmitted to a central server for automated monitoring.
Many existing devices already facilitate wireless transmission of CAN or OBD2 data available over OBD2 via WiFi or cellular networks. Examples include the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.
While offering cost savings and convenience, OBD3 also raises privacy concerns related to surveillance, making its widespread adoption a political challenge.
Originally intended for stationary emission testing, OBD2 has evolved into a valuable source of real-time vehicle data available over OBD2 for third-party applications. However, the German automotive industry is considering changes that could impact this access (German car industry plans to close OBD interface).
BMW’s SVP Electronics, Christoph Grote, stated in 2017: “OBD has been designed to service cars in repair shops. In no way has it been intended to allow third parties to build a form of data-driven economy on the access through this interface.“
The proposal suggests disabling OBD2 functionality during normal driving, centralizing data collection with manufacturers. This would give manufacturers greater control over ‘automotive big data’ and potentially limit the data available over OBD2 to third parties.
Security concerns, such as reducing the risk of car hacking, are cited as justification. However, many perceive this as a commercially motivated move (OBD trackers: what future awaits?). Whether this trend gains traction remains to be seen, but it could significantly disrupt the market for OBD2-based third-party services that rely on data available over OBD2.
Enhance Your CAN Bus Expertise
Want to become a CAN bus expert and better understand the foundation of data available over OBD2?
Our comprehensive ‘Ultimate CAN Guide’ consolidates 12 ‘simple intros’ into a 160+ page PDF:
Download now
OBD2 Standards and Protocols for Data Transmission
On-board diagnostics, OBD2, operates as a higher-layer protocol – essentially the language used to request and interpret data available over OBD2. CAN (Controller Area Network) bus is the communication method, like the phone line over which this language is spoken. This positions OBD2 similarly to other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.
Specifically, OBD2 standards define the OBD2 connector, lower-layer communication protocols, OBD2 Parameter IDs (PIDs), and other critical aspects for accessing data available over OBD2.
These standards can be visualized using the 7-layer OSI model. As you’ll notice, both SAE (Society of Automotive Engineers) and ISO (International Organization for Standardization) standards cover multiple layers. This reflects the development of OBD standards in the US (SAE) and Europe (ISO). Many standards are technically equivalent, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.
The OBD2 Connector: Your Access Point to Vehicle Data [SAE J1962]
The 16-pin OBD2 connector, standardized under SAE J1962 / ISO 15031-3, provides a standardized and convenient interface to access data available over OBD2.
The illustration shows a typical Type A OBD2 pin connector (also known as the Data Link Connector, or DLC). Key points to remember:
- The connector is usually located near the steering wheel but may be hidden.
- Pin 16 provides battery power, often even when the ignition is off, ensuring continuous power for accessing data available over OBD2.
- The OBD2 pinout configuration depends on the specific communication protocol used by the vehicle.
- CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are commonly connected for CAN-based data available over OBD2.
OBD2 Connector Types: A vs. B
You might encounter both Type A and Type B OBD2 connectors. Type A is predominantly used in passenger cars, while Type B is more common in medium and heavy-duty vehicles.
While both types share a similar OBD2 pinout, they differ in power supply output: Type A typically provides 12V, and Type B provides 24V. Baud rates can also vary, with cars generally using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing).
Visually, Type B OBD2 connectors have a distinguishing interrupted groove in the middle. This means a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, whereas a Type A adapter will only fit Type A sockets. Understanding these differences is crucial for correctly accessing data available over OBD2 from various vehicle types.
OBD2 and CAN Bus: The Communication Backbone for Data [ISO 15765-4]
Since 2008, CAN bus has been mandated as the lower-layer protocol for OBD2 in all vehicles sold in the US, as defined by ISO 15765. This standardization ensures consistent communication for accessing data available over OBD2.
ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies a set of constraints and guidelines for using CAN (ISO 11898) in diagnostic applications.
Specifically, it standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers to ensure reliable access to data available over OBD2:
- 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, streamlining data available over OBD2 retrieval.
- 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: Addressing Data Requests (11-bit, 29-bit)
All OBD2 communication relies on a request-response message structure. Understanding these identifiers is key to accessing data available over OBD2.
In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs (Electronic Control Units) to see if they have data available over OBD2 for the requested parameter (as per ISO 15765-4). ‘Physical Addressing’ requests, using CAN IDs 0x7E0-0x7E7, can target specific ECUs but are less frequently used.
ECUs respond with 11-bit IDs in the range 0x7E8-0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module), with 0x7E9 (TCM, Transmission Control Module) also being relatively common.
In certain vehicles, especially vans and 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.
Responses in 29-bit systems use CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is sometimes represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated as ‘Reserved for ISO 15765-2’ in the J1939-71 standard. Correctly identifying these CAN IDs is crucial for interpreting the data available over OBD2.
OBD2 vs. OEM-Specific CAN Protocols: Understanding Data Access Layers
It’s important to understand that your vehicle’s ECUs do not rely on OBD2 for their core functionality. Each Original Equipment Manufacturer (OEM) implements proprietary CAN protocols for internal vehicle communication and control. These OEM-specific CAN protocols are often unique to vehicle brand, model, and year. This data is typically not directly data available over OBD2 standards. Unless you are the OEM, interpreting this data is usually not possible without significant reverse engineering (CAN bus sniffer reverse engineering).
When you connect a CAN bus data logger to your OBD2 port, you might observe OEM-specific CAN data being broadcast, often at high rates (1000-2000 frames/second). However, many newer vehicles incorporate a ‘gateway’ that restricts access to this OEM CAN data through the OBD2 connector, primarily enabling only standardized OBD2 communication and limiting the data available over OBD2 to the standardized set.
In essence, think of OBD2 as an ‘additional’ higher-layer protocol operating alongside the OEM-specific protocol. It provides a standardized window into certain vehicle parameters, but it’s not the complete picture of all in-vehicle communication. Understanding this distinction is key to effectively utilizing data available over OBD2.
Bit-Rate and ID Validation: Ensuring Correct Data Acquisition
As discussed, OBD2 can use two bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations for accessing data available over OBD2. Modern cars commonly use 500K and 11-bit IDs, but diagnostic tools should systematically verify this.
ISO 15765-4 provides a recommended initialization sequence to determine the correct combination. This method leverages the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section for details) and detects CAN error frames caused by incorrect bit rate settings.
Newer versions of ISO 15765-4 acknowledge that vehicles 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) as opposed to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).
To test for OBDonEDS versus OBDonUDS ‘protocol’, 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, indicating a different method of accessing data available over OBD2.
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.
Five Lower-Layer OBD2 Protocols: Beyond CAN
While CAN (ISO 15765) is now the dominant lower-layer protocol for OBD2, especially in vehicles manufactured after 2008, older vehicles may utilize other protocols. Understanding these is helpful when working with legacy systems and accessing data available over OBD2 in older cars. The five lower-layer protocols used as the basis for OBD2 are:
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now the most common protocol for accessing data available over OBD2.
- ISO14230-4 (KWP2000): Keyword Protocol 2000, frequently used in 2003+ vehicles, especially in Asia.
- ISO 9141-2: Used in European, Chrysler, and Asian vehicles from 2000-2004.
- SAE J1850 (VPW): Mostly found in older General Motors (GM) vehicles.
- SAE J1850 (PWM): Primarily used in older Ford vehicles.
ISO-TP: Transporting OBD2 Messages for Larger Data Payloads [ISO 15765-2]
All OBD2 communication, and therefore all data available over OBD2, is transmitted over the CAN bus using a transport protocol called ISO-TP (ISO 15765-2). ISO-TP is essential because it enables the transmission of data payloads larger than the 8-byte limit of a standard CAN frame. This is crucial in OBD2 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, flow control, and reassembly of these larger messages, ensuring reliable transmission of all data available over OBD2. For more details on ISO-TP, see our introduction to UDS.
However, much of the time, the data available over OBD2 will fit 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 (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for the actual OBD2 communication related to the requested data available over OBD2.
Decoding the OBD2 Diagnostic Message: Unpacking Data Available Over OBD2 [SAE J1979, ISO 15031-5]
To understand how to access and interpret data available over OBD2, let’s examine the structure of a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message consists of an identifier, a data length indicator (PCI field), and the actual data payload. The data payload itself is further structured into Mode, Parameter ID (PID), and data bytes, each playing a role in defining and conveying the data available over OBD2.
Example: OBD2 Request and Response for Vehicle Speed Data
To illustrate how to request and receive data available over OBD2, consider the example of requesting ‘Vehicle Speed’.
An external tool sends a request message to the vehicle with CAN ID 0x7DF and a 2-byte payload: Mode 0x01 and PID 0x0D. The vehicle responds via CAN ID 0x7E8 with a 3-byte payload. The 4th byte of the original CAN frame (the 1st byte of the OBD2 payload after mode and PID), 0x32 (decimal 50), represents the Vehicle Speed value.
By consulting the decoding rules for OBD2 PID 0x0D, we determine that the physical value is 50 km/h. This example demonstrates the basic process of requesting and interpreting data available over OBD2.
The 10 OBD2 Services (Modes): Categorizing Data Available Over OBD2
OBD2 defines 10 diagnostic services, also referred to as modes. Each mode provides access to different categories of data available over OBD2. Mode 0x01, for instance, provides access to current real-time data parameters, while other modes are used for retrieving and clearing Diagnostic Trouble Codes (DTCs) or accessing freeze frame data.
It’s important to note that vehicles are not required to support all 10 OBD2 modes. Manufacturers may also implement OEM-specific modes beyond the 10 standardized modes, expanding the range of data available over OBD2 in proprietary ways.
In OBD2 messages, the mode is indicated in the second byte of the 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 start with 0x41). This helps distinguish requests from responses when analyzing data available over OBD2 communication.
OBD2 Parameter IDs (PIDs): Specifying Data Points
Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the exact data point being requested. PIDs are crucial for pinpointing the specific data available over OBD2 you want to access.
For example, mode 0x01 contains approximately 200 standardized PIDs that represent real-time data parameters like speed, RPM, and fuel level. However, a vehicle might not support all PIDs within a given mode. In practice, most vehicles only support a subset of the available PIDs, limiting the data available over OBD2 to a specific set of parameters.
One PID holds special significance: PID 0x00 within mode 0x01. If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. When queried with this PID, the vehicle’s ECU responds by indicating which PIDs in the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’ and a starting point for discovering the data available over OBD2 from a particular vehicle. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for subsequent ranges of mode 0x01 PIDs, allowing for a comprehensive assessment of data available over OBD2 within this mode.
Tip: OBD2 PID Overview Tool for Data Interpretation
The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs. This scaling information is essential for converting the raw data bytes received from OBD2 responses into meaningful physical values, as explained in our CAN bus introduction. This conversion is crucial for making sense of the data available over OBD2.
For quick lookup of mode 0x01 PIDs and their decoding rules, utilize our OBD2 PID overview tool. This tool assists in constructing OBD2 request frames and dynamically decoding OBD2 responses, streamlining the process of accessing and understanding data available over OBD2.
OBD2 PID overview tool
Practical Guide: Logging and Decoding Data Available Over OBD2
This section provides a practical example of how to log data available over OBD2 using the CANedge CAN bus data logger. The CANedge’s ability to transmit custom CAN frames makes it ideal for OBD2 data logging.
Once configured, the CANedge can be easily connected to your vehicle using our OBD2-DB9 adapter cable. This setup allows you to capture and analyze the valuable data available over OBD2.
You can send a CAN frame at e.g. 500K, then check if it is successfully sent
The responses to ‘Supported PIDs’ can be reviewed in asammdf
Step #1: Bit-Rate, ID, and Supported PID Validation
As previously discussed, ISO 15765-4 outlines a procedure to determine the correct bit rate and CAN IDs for a specific vehicle. You can use the CANedge to perform these tests as follows (refer to the CANedge Introduction for detailed instructions):
- Bit-rate test: Send a CAN frame at 500K. Check if transmission is successful. If not, try 250K. Successful transmission indicates the correct bit rate for accessing data available over OBD2.
- Utilize identified bit-rate: Use the validated bit-rate for all subsequent OBD2 communication.
- Send ‘Supported PIDs’ requests: Transmit multiple ‘Supported PIDs’ requests (PID 0x00 in mode 0x01) and analyze the responses.
- Determine CAN ID type: Based on the response IDs (e.g., 0x7E8 for 11-bit, 0x18DAF110 for 29-bit), identify whether the vehicle uses 11-bit or 29-bit CAN IDs for data available over OBD2.
- Identify supported PIDs: Analyze the response data to determine the specific PIDs supported by the vehicle and thus the data available over OBD2.
We provide pre-configured settings for the CANedge to simplify these tests.
Most non-electric vehicles manufactured in 2008 or later support 40-80 PIDs, using a 500K bit rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol for accessing data available over OBD2.
As shown in the asammdf GUI screenshot, you might observe multiple responses to a single OBD request. This is because using the functional address request ID 0x7DF polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, multiple responses are common for this PID. For subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. Notice that the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs. Therefore, to reduce bus load, you could target only the ECM for subsequent requests by using the ‘Physical Addressing’ CAN ID 0x7E0.
Step #2: Configuring OBD2 PID Requests for Data Logging
Once you’ve identified the PIDs supported by your vehicle and the correct communication parameters, you can configure your data logger to request specific PIDs to capture the data available over OBD2 you are interested in.
Consider these points when configuring your OBD2 PID requests:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to target specific ECUs and avoid redundant responses, optimizing data available over OBD2 acquisition.
- Request Spacing: Introduce a delay of 300-500 ms between each OBD2 request. Overly rapid requests can overwhelm ECUs and lead to dropped responses, hindering access to data available over OBD2.
- Battery Drain Management: Implement triggers to stop transmitting requests when the vehicle is inactive. This prevents unnecessary ECU wake-up and battery drain, especially during prolonged data available over OBD2 logging sessions.
- Data Filtering: Apply filters to record only OBD2 responses. This is useful if your vehicle also broadcasts OEM-specific CAN data, allowing you to focus solely on the standardized data available over OBD2.
With these configurations in place, your CANedge is ready to efficiently log raw OBD2 data, capturing the valuable data available over OBD2 from your vehicle.
An example list of CANedge OBD2 PID requests
asammdf lets you DBC decode and visualize OBD2 data
Step #3: DBC Decoding Raw OBD2 Data for Analysis
To analyze and visualize your logged data available over OBD2, you must decode the raw data bytes into physical values (e.g., km/h, °C). This decoding process is essential for transforming raw OBD2 data into understandable insights.
The necessary decoding information is defined in ISO 15031-5/SAE J1979 and is also available on resources like Wikipedia. For convenience, we provide a free OBD2 DBC file. This DBC file simplifies DBC decoding of raw OBD2 data within most CAN bus software tools, making it easier to work with data available over OBD2.
Decoding OBD2 data is slightly more complex than decoding standard CAN signals. This complexity arises 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 correctly identify the signal. This multiplexing technique, known as ‘extended multiplexing‘, is implemented in our DBC files, enabling accurate decoding of data available over OBD2.
CANedge: Your Dedicated OBD2 Data Logger
The CANedge simplifies the process of recording data available over OBD2. It allows you to easily log OBD2 data to a removable 8-32 GB SD card. Simply connect the CANedge to your vehicle’s OBD2 port to begin logging. Then, use our free software and APIs along with our OBD2 DBC file to decode and analyze the collected data available over OBD2.
OBD2 logger intro
CANedge product information
OBD2 Multi-Frame Examples: Handling Larger Data Sets with ISO-TP
While many OBD2 data requests and responses fit within single CAN frames, some, like retrieving VIN or DTCs, require multi-frame communication due to larger data payloads. All data available over OBD2, regardless of size, is transmitted using the ISO-TP (transport protocol) as specified in ISO 15765-2.
Most examples discussed so far have focused on single-frame communication. This section provides examples of multi-frame communication scenarios to illustrate how larger sets of data available over OBD2 are handled.
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 demonstrated in the CANedge configuration example.
Furthermore, processing multi-frame OBD2 responses requires CAN software and API tools that support ISO-TP, such as the CANedge MF4 decoders. These tools are essential for correctly reassembling and interpreting the complete data available over OBD2 transmitted across multiple frames.
Example 1: Retrieving Vehicle Identification Number (VIN) via OBD2
The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and various automotive applications (see our UDS introduction). OBD2 mode 0x09 PID 0x02 is used to retrieve the VIN from a vehicle, accessing this important piece of data available over OBD2.
The diagnostic tool initiates the process by sending a Single Frame request containing the PCI field (0x02), the request service identifier (0x09), and the PID (0x02).
The vehicle responds with a First Frame, which includes the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is the byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for detailed specifications). The subsequent 17 bytes constitute the VIN. These bytes can be converted from HEX to ASCII characters using methods discussed in our UDS introduction to obtain the human-readable VIN, extracting valuable identifying data available over OBD2.
Example 2: Multi-PID Request (6x) for Efficient Data Acquisition
OBD2 allows external 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 unsupported PIDs from the response), potentially using multiple frames via ISO-TP if necessary. This multi-PID request capability offers a more efficient way to collect data available over OBD2 at higher frequencies.
While powerful, this method introduces complexities in signal encoding, making generic OBD2 DBC files less suitable. 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:
The multi-frame response resembles the VIN example but includes the requested PIDs and their corresponding data within the payload. The PIDs in the example are ordered similarly to the request order, which is common but not mandated by ISO 15031-5.
Decoding these multi-PID responses using standard DBC files is challenging. Therefore, we don’t recommend this approach for general data logging unless you have tools with specific built-in support. Effectively, you’re dealing with extended multiplexing, but with multiple instances throughout the payload. Your DBC file would need to account for the specific payload position of each PID, making it difficult to generalize across vehicles with varying PID support. Furthermore, managing multiple such multi-PID requests becomes very complex using pure DBC manipulations.
Workarounds could involve custom scripts and recording the tool’s transmit messages. The script could then interpret the response message in conjunction with the request message. However, such approaches are difficult to scale. For most practical data available over OBD2 logging scenarios, simpler, single-PID requests are more manageable and robust.
Example 3: Diagnostic Trouble Codes (DTCs) for Fault Identification
OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’, is used to request emissions-related DTCs. No PID is included in the request. The targeted ECU(s) will respond with the number of stored DTCs (including zero if none are present), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than two DTCs are stored, as this exceeds the single frame payload limit for data available over OBD2.
The 2-byte DTC value is structured into two parts according to ISO 15031-5/ISO 15031-6. The first two bits define the ‘category’, and the remaining 14 bits represent a 4-digit hexadecimal code, as illustrated. Decoded DTC values can be looked up using various online OBD2 DTC lookup tools like repairpal.com. This process allows you to translate the raw DTC data available over OBD2 into human-readable fault descriptions.
The example below shows a request to an ECU with six stored DTCs.
Real-World Applications: Use Cases for Data Available Over OBD2
The data available over OBD2 from cars and light trucks has numerous practical applications across various industries:
Vehicle Data Logging for Efficiency and Analysis
OBD2 data logging in cars can be leveraged for diverse purposes, including optimizing fuel efficiency, improving driving habits, testing prototype components, and insurance telematics. Accessing data available over OBD2 provides valuable insights for these applications.
Explore OBD2 loggers
Real-Time Vehicle Diagnostics and Monitoring
OBD2 interfaces enable real-time streaming of human-readable OBD2 data. This is invaluable for diagnosing vehicle issues, monitoring performance parameters, and providing live feedback to drivers or technicians, all powered by the data available over OBD2.
Learn about OBD2 streaming
Predictive Maintenance and Fleet Management
Cars and light trucks equipped with IoT-enabled OBD2 loggers can be monitored remotely in the cloud. Analyzing the data available over OBD2 allows for predictive maintenance, anticipating potential breakdowns, optimizing maintenance schedules, and improving fleet management efficiency.
Discover predictive maintenance solutions
Vehicle Black Box Recorders for Safety and Accountability
An OBD2 logger can function as a ‘black box’ for vehicles or equipment. Recording data available over OBD2 provides crucial information for accident reconstruction, dispute resolution, warranty validation, and in-depth diagnostics in case of incidents.
Explore CAN bus black box applications
Do you have a specific use case for OBD2 data logging? Contact us for a free consultation!
Contact us today
For more introductory guides, explore our tutorials section or download our comprehensive ‘Ultimate Guide’ PDF.
Ready to start logging and streaming data available over OBD2?
Get your OBD2 data logger now!
Purchase OBD2 data loggers
Contact us for assistance
Recommended Resources:
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANEDGE2 – PRO CAN IoT LOGGER
CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN
