Ever wondered what that mysterious port in your car is for? Or what that “check engine” light really means? The answer lies in OBD2, your vehicle’s onboard diagnostic system. But What Can Obd2 Do, exactly?
This comprehensive guide will delve into the powerful capabilities of OBD2, explaining everything from reading error codes to monitoring real-time performance data. We’ll break down the technical jargon and show you how OBD2 can empower you to understand your car like never before.
You can also watch our OBD2 intro video above – or get the PDF
Understanding the Power of OBD2: Your Car’s Diagnostic Center
OBD2, short for On-Board Diagnostics version 2, is a standardized system built into virtually all modern vehicles. Think of it as your car’s internal health monitor and communication interface. It allows you, mechanics, and diagnostic tools to access a wealth of information about your vehicle’s engine, emissions, and overall system health through a universal OBD2 connector.
You’ve likely already encountered OBD2 in action, perhaps indirectly:
That illuminated malfunction indicator light (MIL), commonly known as the “check engine light,” is triggered by the OBD2 system when it detects an issue. When you take your car to a mechanic, they use an OBD2 scanner to plug into the standardized 16-pin OBD2 port, typically located under the dashboard near the steering wheel. This scanner sends “OBD2 requests” to the car’s computer, and the car responds with “OBD2 responses” containing valuable data. This data can include everything from engine speed and coolant temperature to fuel levels and, crucially, Diagnostic Trouble Codes (DTCs). These DTCs pinpoint problems, making troubleshooting and repairs much faster and more efficient.
Image showing a malfunction indicator light (MIL) or “check engine light” illuminated on a car dashboard, illustrating OBD2’s role in flagging vehicle issues.
Does Your Car Have OBD2? Compatibility Across Vehicles
The question “what can OBD2 do” is only relevant if your car actually supports it. The good news is: almost certainly, yes!
Nearly all gasoline and diesel cars manufactured after 1996 in the US, 2001 in Europe for gasoline, and 2004 in Europe for diesel are OBD2 compliant. While older vehicles might have a 16-pin connector that looks like OBD2, it may not actually be fully compliant. A simple guideline to check OBD2 compatibility is based on the car’s origin and year of purchase:
Infographic illustrating OBD2 compliance timelines for vehicles based on region (US, EU) and fuel type (gasoline, diesel).
A Brief History of OBD2: From Emissions to Data Access
To truly understand “what can OBD2 do,” it’s helpful to know its origins. OBD2’s story begins in California. The California Air Resources Board (CARB) mandated OBD in all new cars from 1991 onwards, primarily for emission control. The goal was to ensure vehicles were running cleanly and efficiently to reduce air pollution.
The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBD2, defining Diagnostic Trouble Codes (DTCs) and the physical OBD connector itself (SAE J1962) to ensure consistency across different car manufacturers.
The OBD2 standard was then progressively adopted globally:
- 1996: OBD2 became mandatory in the USA for all cars and light trucks.
- 2001: The European Union required OBD2 for gasoline cars.
- 2003: The EU extended the requirement to diesel cars as well (known as EOBD in Europe).
- 2005: OBD2 was mandated in the US for medium-duty vehicles.
- 2008: US regulations required cars to use ISO 15765-4 (CAN bus) as the foundation for OBD2 communication.
- 2010: OBD2 became mandatory for heavy-duty vehicles in the US.
Diagram illustrating the historical development of OBD2, highlighting its emission control focus and evolution over time.
Timeline graphic visually summarizing key milestones in OBD2 history and its global adoption.
Conceptual image representing the future of OBD with OBD3, suggesting trends like remote diagnostics, cloud connectivity, and IoT integration.
The Future of OBD2: OBD3 and Beyond
OBD2’s core function – emissions monitoring and diagnostics – remains relevant, but the automotive landscape is changing rapidly. So, what will OBD2 do in the future?
While OBD2 is firmly established, its future evolution is being shaped by several key trends:
Originally designed for emissions testing, legislated OBD2 has limitations, particularly with the rise of electric vehicles (EVs). Interestingly, EVs are generally not required to support OBD2 in its standard form. Most modern EVs bypass standard OBD2 requests and instead use manufacturer-specific UDS communication protocols. This makes accessing data from EVs more challenging, requiring reverse engineering efforts to decode data, as seen in case studies for brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda.
Recognizing OBD2’s limitations in data richness and communication protocols, modern alternatives are emerging. WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are designed to enhance OBD communication by utilizing the UDS protocol as a foundation. These advancements aim to streamline diagnostics and data access. For a deeper dive, explore our introduction to UDS.
In our increasingly connected world, traditional OBD2 testing methods are becoming less efficient. Manual emission checks are time-consuming and costly. The proposed solution? OBD3 – integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder to cars, similar to those used for bridge tolls. This would enable vehicles to wirelessly transmit their Vehicle Identification Number (VIN) and DTCs via WiFi to a central server for automated monitoring and diagnostics. Many existing devices, like the CANedge2 WiFi CAN logger and CANedge3 3G/4G CAN logger, already facilitate data transfer via WiFi or cellular networks.
While offering convenience and cost savings, OBD3 raises privacy concerns related to vehicle surveillance, creating political and societal challenges.
Originally intended for stationary emission controls, OBD2 is now widely used by third parties to access real-time vehicle data through OBD2 dongles, CAN loggers and similar devices. However, the German car industry is seeking to restrict this access. Automakers argue that OBD2 was designed for repair shop servicing, not for creating a “data-driven economy” for third-party services.
A proposed approach is to potentially “disable” OBD2 functionality during normal driving, centralizing data collection within manufacturer-controlled servers. This would give automakers control over “automotive big data.” While security concerns, such as car hacking risks, are cited as justification, many perceive this as a commercial strategy. Whether this trend gains traction remains to be seen, but it could significantly disrupt the market for third-party OBD2 services.
Illustration depicting the trend of electric vehicles potentially limiting access to vehicle data through OBD2 ports.
Get Our ‘Ultimate CAN Guide’
Want to become a CAN bus expert and further understand what underlies OBD2?
Our 160+ page PDF ‘Ultimate CAN Guide’ offers 12 simple introductions to the world of CAN bus and related technologies:
Download now
OBD2 Standards: The Foundation for Communication
To understand “what can OBD2 do” on a technical level, it’s important to grasp the underlying standards. On-Board Diagnostics, OBD2, operates as a higher-layer protocol, similar to a language, while CAN (Controller Area Network) acts as the communication method, like a phone line. This places OBD2 in the same category as other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.
OBD2 standards define the OBD2 connector, the lower-layer communication protocols, OBD2 Parameter IDs (PIDs), and much more, ensuring interoperability across different vehicles and diagnostic tools.
These standards can be visualized using the 7-layer OSI model, a framework for understanding network communication. Interestingly, both SAE (Society of Automotive Engineers – primarily US standards) and ISO (International Organization for Standardization – global standards, often adopted in the EU) contribute to defining different layers of the OBD2 protocol stack. Many SAE and ISO standards are technically equivalent, for instance, SAE J1979 and ISO 15031-5 (defining diagnostic services), and SAE J1962 and ISO 15031-3 (specifying the OBD connector).
Diagram illustrating the OSI 7-layer model in the context of OBD2 and CAN bus, showing the relationship between different standards (ISO, SAE) at various layers.
Detailed pinout diagram of a Type A OBD2 connector socket, highlighting pin assignments for various functions.
The OBD2 Connector [SAE J1962 / ISO 15031-3]: Your Access Point
The 16-pin OBD2 connector, standardized under SAE J1962 / ISO 15031-3, is the physical interface that allows you to tap into your car’s data. It’s often referred to as the Data Link Connector (DLC).
Key features and points about the OBD2 connector:
- It’s typically located near the steering wheel, but its exact placement can vary and may sometimes be hidden behind a panel.
- Pin 16 provides battery power, often even when the ignition is switched off, allowing for diagnostics without the car running.
- The specific OBD2 pinout configuration depends on the 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 in modern vehicles.
OBD2 Connector Types: A vs. B
While Type A is most common in passenger cars, Type B OBD2 connectors are often found in medium and heavy-duty vehicles. Both types share similar pin assignments, but there are important differences:
- Power Supply: Type A provides 12V power, while Type B delivers 24V, reflecting the different electrical systems in cars versus larger vehicles.
- Baud Rate: Cars (Type A) typically use a CAN bus baud rate of 500 Kbps, while heavy-duty vehicles (Type B) often use 250 Kbps (though 500 Kbps support is increasing).
Visually, you can distinguish a Type B OBD2 connector by an interrupted groove in the middle of the connector face. A Type B OBD2 adapter cable is designed to be compatible with both Type A and Type B sockets, while a Type A adapter will only fit into Type A sockets.
Diagram comparing Type A and Type B OBD2 connectors, highlighting differences in power supply, typical vehicle applications, and visual distinguishing features.
Visual representation of the relationship between OBD2 and CAN bus, emphasizing ISO 15765 as the standard for OBD2 over CAN.
OBD2 and CAN Bus [ISO 15765-4]: Communication Foundation
Since 2008, CAN bus has become the mandatory lower-layer protocol for OBD2 in all cars sold in the US, as defined by ISO 15765. This means that when you ask “what can OBD2 do,” the answer often involves CAN bus communication behind the scenes.
ISO 15765-4, also known as Diagnostics over CAN (DoCAN), is a set of specifications that refines the CAN standard (ISO 11898) specifically for OBD2 diagnostics. It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:
- CAN bus bit-rate: Must be either 250 Kbps or 500 Kbps.
- CAN IDs: Can be either 11-bit or 29-bit.
- Specific CAN IDs: Are designated for OBD requests and responses.
- Diagnostic CAN frame data length: Limited to 8 bytes.
- OBD2 adapter cable length: Maximum of 5 meters.
OBD2 CAN Identifiers (11-bit, 29-bit): Addressing Communication
All OBD2 communication follows a request-response model. Understanding CAN identifiers is key to understanding “what can OBD2 do” in terms of data exchange.
11-bit CAN IDs: Predominate in most passenger cars for OBD2 communication.
- Functional Addressing ID: 0x7DF is used for “functional requests,” broadcasting a request to all OBD2-compatible Electronic Control Units (ECUs) to see if they have the requested data (as per ISO 15765-4).
- Physical Addressing IDs: 0x7E0-0x7E7 are available for “physical requests,” allowing tools to target specific ECUs (less frequently used).
- Response IDs: ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF.
- 0x7E8: Most common response ID, typically from the ECM (Engine Control Module).
- 0x7E9: Another common response ID, often from the TCM (Transmission Control Module).
29-bit CAN Identifiers: Used in some vehicles, particularly vans and light, medium, and heavy-duty vehicles.
- Functional Addressing CAN ID: 0x18DB33F1.
- Response IDs: 0x18DAF100 to 0x18DAF1FF (common examples are 18DAF110 and 18DAF11E).
- J1939 PGN (Parameter Group Number): The response ID is sometimes represented as PGN 0xDA00 (55808), which in the J1939-71 standard is reserved for ISO 15765-2.
Diagram illustrating the OBD2 request-response communication flow, highlighting the roles of request and response frames and Parameter IDs (PIDs).
Conceptual image contrasting OBD2 CAN bus communication with proprietary OEM-specific CAN bus protocols, highlighting their distinct purposes and data access levels.
OBD2 vs. Proprietary CAN Protocols: Two Worlds of Data
It’s crucial to understand that your car’s ECUs rely on OEM-specific proprietary CAN protocols for their core functions, not OBD2. Each car manufacturer develops its own communication language for its vehicle systems. These proprietary protocols are often unique to the brand, model, and year. Unless you are the OEM, decoding this proprietary data is usually impossible without significant reverse engineering efforts (CAN bus reverse engineering).
When you connect a CAN bus data logger to your OBD2 port, you might see this OEM-specific CAN data, often broadcast at high rates (1000-2000 frames/second). However, many newer vehicles incorporate a “gateway” that restricts access to this proprietary CAN data through the OBD2 port, allowing only standardized OBD2 communication.
Think of OBD2 as an “add-on” higher-layer protocol that operates alongside the OEM’s primary communication system. It’s a standardized window into certain aspects of your car’s operation, primarily emissions-related and some basic vehicle parameters.
Bit-rate and ID Validation: Ensuring Correct Communication
OBD2 over CAN can use two bit rates (250 Kbps, 500 Kbps) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern cars commonly use 500 Kbps and 11-bit IDs, but diagnostic tools should systematically verify the correct combination for reliable communication.
ISO 15765-4 outlines a systematic initialization sequence to determine the appropriate combination. This process leverages the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit rates will cause CAN error frames.
Newer versions of ISO 15765-4 also account for vehicles that might support OBD communication via OBDonUDS (OBD on Unified Diagnostic Services) instead of OBDonEDS (OBD on Emission Diagnostic Service). While this article primarily focuses on OBD2/OBDonEDS (as defined in ISO 15031-5/SAE J1979), WWH-OBD/OBDonUDS (ISO 14229, ISO 27145-3/SAE J1979-2) is relevant for EU trucks and buses.
To test for OBDonEDS vs. OBDonUDS, diagnostic tools can send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and Data Identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should respond to this DID.
In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-electric vehicles today, while WWH-OBD is mainly used in EU trucks and buses.
Flowchart illustrating the process of OBD2 bit-rate and CAN ID validation as per ISO 15765-4, used by diagnostic tools to establish correct communication parameters.
Diagram outlining the five lower-layer OBD2 protocols, including CAN (ISO 15765) and older protocols like KWP2000, SAE J1850, and ISO 9141.
Five Lower-Layer OBD2 Protocols: Beyond CAN
While CAN (ISO 15765) is dominant today, especially in vehicles from 2008 onwards, older cars might utilize one of four other lower-layer protocols for OBD2 communication. Knowing these protocols and their associated OBD2 connector pinouts can be helpful when working with older vehicles:
- ISO 15765 (CAN bus): Mandatory in US cars since 2008; the most common protocol today.
- ISO 14230-4 (KWP2000): Keyword Protocol 2000; common in 2003+ cars, particularly in Asia.
- ISO 9141-2: Used in European, Chrysler, and Asian cars in the 2000-2004 era.
- SAE J1850 (VPW – Variable Pulse Width Modulation): Primarily found in older General Motors (GM) vehicles.
- SAE J1850 (PWM – Pulse Width Modulation): Mostly used in older Ford vehicles.
Transporting OBD2 Messages via ISO-TP [ISO 15765-2]: Handling Larger Data
All OBD2 data transmitted over CAN bus uses the ISO-TP (ISO 15765-2) transport protocol. This protocol is crucial because it allows for sending data payloads larger than the 8-byte limit of a single CAN frame. This is essential for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often require more than 8 bytes of data. ISO 15765-2 provides mechanisms for segmentation (splitting large messages), flow control (managing data transmission rate), and reassembly (putting fragmented messages back together). For detailed information, refer to our introduction to UDS.
However, much OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a “Single Frame” (SF) format. The first byte of the data payload (the PCI field – Protocol Control Information) indicates the payload length (excluding padding), leaving 7 bytes available for OBD2-specific communication.
Diagram illustrating different ISO-TP frame types used in OBD2 communication, including Single Frame (SF) and multi-frame types, showing how data payloads are structured.
The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]: Decoding the Data
To truly answer “what can OBD2 do,” we need to understand the structure of the diagnostic messages themselves. Let’s examine a simplified “Single Frame” OBD2 CAN message. Essentially, an OBD2 message consists of a CAN identifier, a data length indicator (PCI field), and the actual data payload. The payload is further broken down into: Mode, Parameter ID (PID), and data bytes.
Breakdown of the OBD2 message structure, showing the components like CAN ID, PCI field, Mode, PID, and data bytes within a raw CAN frame.
Example: OBD2 Request/Response in Action
Let’s illustrate with a practical example: requesting “Vehicle Speed”.
A diagnostic tool sends a request message to the car with CAN ID 0x7DF and a 2-byte payload: Mode 0x01 and PID 0x0D. The car responds with a CAN ID 0x7E8 message and a 3-byte payload. The 4th byte of the response contains the vehicle speed value, in this case, 0x32 (which is 50 in decimal).
By consulting the OBD2 PID documentation for PID 0x0D, we find the decoding rules. In this instance, 0x32 translates to a physical value of 50 km/h.
Let’s delve deeper into OBD2 modes and PIDs.
Example of an OBD2 request-response sequence for vehicle speed, showing the CAN IDs (7DF request, 7E8 response) and data payloads (Mode 0x01, PID 0x0D).
Detailed illustration of OBD2 PID 0x0D (Vehicle Speed) example, showing the request and response data bytes and how to decode the speed value.
Infographic listing the 10 standardized OBD2 service modes (modes 0x01 to 0x0A), briefly describing the function of each mode (e.g., current data, freeze frame data, clear DTCs).
The 10 OBD2 Services (Modes): What You Can Ask Your Car
OBD2 defines 10 diagnostic services, also referred to as modes. Each mode serves a specific purpose:
- Mode 0x01 (Show current data): Provides access to real-time sensor data and vehicle parameters.
- Mode 0x02 (Show freeze frame data): Displays data captured when a DTC was set.
- Mode 0x03 (Show stored DTCs): Retrieves currently active Diagnostic Trouble Codes.
- Mode 0x04 (Clear DTCs and stored values): Resets DTCs and clears related stored data (like the “check engine light”).
- Mode 0x05 (Oxygen sensor monitoring test results): Accesses results from oxygen sensor tests.
- Mode 0x06 (On-board monitoring test results for non-continuously monitored systems): Provides test results for specific systems not continuously monitored.
- Mode 0x07 (Show pending DTCs): Displays DTCs that are detected but not yet confirmed as permanent faults.
- Mode 0x08 (Control operation of on-board component/system): Allows for bi-directional control of certain vehicle components (less commonly implemented in aftermarket tools).
- Mode 0x09 (Request vehicle information): Used to retrieve vehicle-specific information like VIN and calibration IDs.
- Mode 0x0A (Show permanent DTCs): Displays DTCs that cannot be cleared by normal means.
Important: Vehicles are not required to support all OBD2 modes, and manufacturers may also implement OEM-specific modes beyond these 10 standardized ones.
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 for Mode 1). In a response message, 0x40 is added to the mode value (e.g., a response to Mode 0x01 will have a mode byte of 0x41).
OBD2 Parameter IDs (PIDs): Accessing Specific Data Points
Within each OBD2 mode, Parameter IDs (PIDs) are used to request specific data items.
For example, Mode 0x01 (Show current data) contains approximately 200 standardized PIDs. These PIDs represent real-time data points such as vehicle speed, engine RPM, coolant temperature, fuel level, and many more. However, vehicles typically only support a subset of these available PIDs.
One PID stands out as particularly important for basic OBD2 functionality:
Mode 0x01 PID 0x00 (Supported PIDs [01-20]): If an emissions-related ECU supports any OBD2 services, it must support this PID. When requested, the ECU responds indicating which PIDs in the range 0x01-0x20 it supports. This makes PID 0x00 a fundamental “OBD2 compatibility test.” Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 are used to determine support for subsequent PID ranges (0x21-0x40, 0x41-0x60, and so on) within Mode 0x01.
(Re-used image from earlier section)
Screenshot of an OBD2 PID overview tool, showing a table of PIDs within service 0x01 and their descriptions.
Tip: OBD2 PID Overview Tool – Your Decoding Guide
The appendices of SAE J1979 and ISO 15031-5 contain detailed scaling and encoding information for standard OBD2 PIDs. This information is essential for converting raw OBD2 data bytes into meaningful physical values.
For quick lookups and PID exploration, our OBD2 PID overview tool is a valuable resource. It helps you construct OBD2 request frames and dynamically decode OBD2 responses, streamlining the process of understanding “what can OBD2 do” in terms of data retrieval.
OBD2 PID overview tool
How to Log and Decode OBD2 Data: A Practical Example
Now that we’ve explored the theory, let’s look at a practical example of logging OBD2 data using a CANedge CAN bus data logger. This demonstrates “what can OBD2 do” in a real-world scenario.
The CANedge is configurable to transmit custom CAN frames, making it suitable for sending OBD2 requests and logging the responses. Connecting it to your vehicle is easy using our OBD2-DB9 adapter cable.
Diagram showing an OBD2 data logger connected to a vehicle, illustrating the request (7DF) and response (7E8) CAN ID communication for PID data.
Screenshot illustrating a bit-rate validation test for OBD2 communication, confirming successful CAN frame transmission at a specific bit-rate.
Screenshot from asammdf software showing responses to “Supported PIDs” requests, allowing users to identify which PIDs are supported by the vehicle.
#1: Test Bit-rate, IDs & Supported PIDs – Establishing Communication
As discussed earlier, ISO 15765-4 provides a method to determine the correct bit-rate and CAN IDs for OBD2 communication with a specific vehicle. You can use the CANedge to perform these tests:
- Bit-rate Test: Send a CAN frame at 500 Kbps. If successful (no errors), use 500 Kbps; otherwise, try 250 Kbps.
- Bit-rate Confirmation: Use the identified bit-rate for all subsequent communication.
- Supported PIDs 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 if the vehicle uses 11-bit or 29-bit IDs for OBD2.
- Supported PID List: Analyze the response data to identify the specific PIDs supported by the vehicle.
We provide plug-and-play CANedge configuration files to simplify these initial tests.
Most non-EV cars manufactured after 2008 typically support 40-80 PIDs using a 500 Kbps bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.
The asammdf GUI screenshot demonstrates that multiple ECUs may respond to a single OBD request when using the functional addressing ID (0x7DF). This is because the 0x7DF request polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, you often see numerous responses to this PID. As you request subsequent “Supported PIDs” ranges, fewer ECUs typically respond. Notice that the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs. To reduce bus load, you could switch to “Physical Addressing” (using CAN ID 0x7E0) to specifically request data only from the ECM for subsequent requests.
#2: Configure OBD2 PID Requests – Selecting Your Data
Once you know the supported PIDs, bit-rate, and CAN IDs, you can configure your CANedge to request the specific PIDs you are interested in logging.
Key considerations for configuring OBD2 PID requests:
- CAN IDs: Switch to “Physical Addressing” request IDs (e.g., 0x7E0) to target a specific ECU and avoid multiple responses to each request, simplifying data analysis.
- Request Spacing: Introduce a delay of 300-500 ms between consecutive OBD2 requests. Overly rapid requests (“spamming”) can cause ECUs to stop responding reliably.
- Battery Drain Management: Implement triggers in your CANedge configuration to stop transmitting requests when the vehicle is inactive (ignition off) to prevent unnecessary battery drain by “waking up” ECUs.
- Data Filtering: Configure CANedge filters to record only OBD2 response messages. This is helpful if your vehicle also broadcasts OEM-specific CAN data on the OBD2 port, allowing you to isolate the OBD2 data stream.
With these configurations in place, your CANedge is ready to log raw OBD2 data efficiently.
Example CANedge configuration showing a list of OBD2 PID requests to be transmitted by the logger.
Screenshot from asammdf software showing decoded and visualized OBD2 data, plotted as graphs over time, demonstrating data analysis capabilities using DBC files.
#3: DBC Decode Raw OBD2 Data – Making Sense of the Logs
To analyze and visualize your logged OBD2 data, you need to decode the raw data bytes into “physical values” (like km/h, °C, RPM).
The necessary decoding information (scaling, units, etc.) is detailed in ISO 15031-5/SAE J1979 and is also often available on online resources like Wikipedia. To simplify decoding, we provide a free OBD2 DBC file. This DBC file allows you to easily DBC decode raw OBD2 data within most CAN bus software tools.
Decoding OBD2 data is slightly 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 not sufficient to identify the specific signal within the payload.
To correctly decode OBD2 data, you must consider the CAN ID, the OBD2 mode, and the OBD2 PID together. This is a form of multiplexing called “extended multiplexing,” and it can be effectively handled using DBC files. Our provided OBD2 DBC file is designed to handle this extended multiplexing for common OBD2 PIDs.
CANedge: Your Dedicated OBD2 Data Logger
The CANedge offers a straightforward solution for recording OBD2 data. It logs data to an 8-32GB SD card, making it easy to capture data simply by connecting it to a car or truck. You can then decode and analyze the logged data using free software and APIs and our OBD2 DBC file.
OBD2 logger intro CANedge product page
OBD2 Multi-Frame Examples [ISO-TP]: Handling Larger Responses
We’ve primarily focused on single-frame OBD2 communication. However, as we discussed, OBD2 uses ISO-TP to handle data larger than 8 bytes, requiring multi-frame communication. Here are examples of “what can OBD2 do” with multi-frame requests and responses.
Multi-frame OBD2 communication involves flow control frames (explained in our UDS intro). A common practical approach is to transmit a static flow control frame approximately 50 ms after the initial request frame, as illustrated in the CANedge configuration examples.
Analyzing multi-frame OBD2 responses requires CAN software and API tools that support ISO-TP, such as the CANedge MF4 decoders.
Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN), showing the structure of a multi-frame request for larger data retrieval.
Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval
The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and vehicle identification. OBD2 allows you to retrieve the VIN using Mode 0x09 (Request vehicle information) and PID 0x02 (Request VIN):
Request: The diagnostic tool sends a Single Frame request with PCI field (0x02), service identifier (0x09), and PID (0x02).
Response: The vehicle responds with a First Frame containing the PCI, total length (0x014 = 20 bytes), mode (0x49 – response to mode 0x09), and PID (0x02). Following the PID is byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case (see ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes contain the VIN itself, encoded in hexadecimal, which can be converted to ASCII characters as discussed in our UDS introduction.
Example 2: OBD2 Multi-PID Request (Requesting Up to 6 PIDs)
OBD2 tools can 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, using multi-frame responses if needed (ISO-TP).
This technique can increase data acquisition efficiency, but it also complicates signal encoding and decoding. Generic OBD2 DBC files become less useful because the signal encoding is dependent on the specific PIDs requested and their order. We generally do not recommend using multi-PID requests for practical data logging due to the complexity it adds to data processing and the reduced compatibility with standard tools.
Below is an example trace of a multi-PID request and response:
The multi-frame response structure is similar to the VIN example, but the payload includes both the requested PIDs and their corresponding data values. In the example trace, the PIDs in the response are ordered similarly to their order in the request, which is common but not strictly mandated by ISO 15031-5.
Decoding these multi-PID responses using generic DBC files is very challenging. Unless you are using specialized tools with built-in support for this specific multi-PID request method, it’s generally not practical for data logging and analysis. It introduces a complex form of extended multiplexing, where the payload structure and signal positions depend on the specific request. While custom scripts and recording request messages alongside responses could potentially address this, scaling such solutions across different vehicles and PID combinations becomes very complex.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval
OBD2 allows you to retrieve 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 (potentially zero if no DTCs are active). Each DTC is represented by 2 data bytes. Multi-frame responses are necessary if more than 2 DTCs are stored.
The 2-byte DTC value is structured as defined in ISO 15031-5/ISO 15031-6. The first 2 bits indicate the “category” of the DTC (e.g., Powertrain, Chassis, Body, Network), and the remaining 14 bits form a 4-digit code (displayed in hexadecimal). Decoded DTC values can be looked up using online OBD2 DTC lookup tools like repairpal.com to understand the specific fault indicated by the code.
The example below shows a response from an ECU reporting 6 stored DTCs.
Diagram explaining how to decode a 2-byte DTC value, breaking down the category bits and the 4-digit DTC code, and illustrating the process of looking up DTC definitions.
OBD2 Data Logging – Real-World Use Case Examples
“What can OBD2 do” translates into a wide range of practical applications. OBD2 data logging from cars and light trucks is valuable in various scenarios:
Logging Data from Cars: Performance, Efficiency, and More
OBD2 data from passenger cars can be used for diverse purposes, such as:
- Fuel Efficiency Improvement: Analyze fuel consumption parameters to optimize driving habits and reduce fuel costs.
- Driving Behavior Analysis: Monitor driving patterns for driver training, insurance risk assessment, or fleet management.
- Prototype Testing: Evaluate the performance of prototype automotive parts and systems under real-world driving conditions.
- Insurance Telematics: Collect driving data for usage-based insurance programs.
OBD2 logger product link
Real-time Car Diagnostics: On-the-Spot Troubleshooting
OBD2 interfaces enable real-time streaming of human-readable OBD2 data. This is invaluable for:
- Vehicle Diagnostics: Mechanics and DIYers can use real-time data to diagnose vehicle issues, monitor sensor readings, and pinpoint problems quickly.
OBD2 streaming interface link
Predictive Maintenance: Preventing Breakdowns
Combining OBD2 data with IoT (Internet of Things) connectivity allows for:
- Remote Vehicle Monitoring: Cars and light trucks can be monitored remotely via cloud-connected OBD2 loggers.
- Predictive Maintenance: Analyze historical and real-time OBD2 data to predict potential component failures and schedule preventative maintenance, minimizing downtime and repair costs.
Predictive maintenance solution link
Vehicle “Black Box” Logging: Accident Reconstruction and Warranty
An OBD2 logger can function as a “black box” for vehicles or equipment, providing valuable data for:
- Accident Investigation: Record pre- and post-accident data to aid in accident reconstruction and liability determination.
- Warranty Validation: Document vehicle operation for warranty claims and dispute resolution.
- Equipment Monitoring: Track usage and performance of vehicles or machinery in various applications.
CAN bus blackbox logger link
Do you have an OBD2 data logging use case in mind? Contact us for free expert advice and solutions!
Explore our guides section for more introductory articles and tutorials, or download our comprehensive ‘Ultimate Guide’ PDF for in-depth CAN bus knowledge.
Ready to unlock the power of OBD2 and start logging or streaming your vehicle data?
Get your OBD2 data logger today!
Buy now Contact us
Recommended for You: Further Explore OBD2 and CAN Bus Solutions
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANEDGE2 – PRO CAN IoT LOGGER
[
