Unlock the wealth of information hidden within your vehicle’s data stream. This in-depth guide provides a practical understanding of OBD2, focusing on accessing and interpreting real-time data for diagnostics, performance analysis, and more.
Have you ever wondered what lies beneath the surface of your car’s dashboard readings? Modern vehicles are complex systems generating vast amounts of data, and OBD2 (On-Board Diagnostics II) is the key to unlocking this information. This standardized protocol allows you to tap into your car’s data stream, providing insights into everything from engine performance to emissions and potential issues. Whether you’re a seasoned mechanic or a curious car owner, understanding the OBD2 data stream is invaluable.
This guide delves into the world of OBD2, offering a comprehensive yet accessible explanation. We’ll explore the OBD2 connector, Parameter IDs (PIDs), and how it all links to the CAN bus network within your vehicle. More than just theory, this is a practical introduction. You’ll learn how to request and decode OBD2 data streams, understand key use cases for data logging, and gain practical tips to get started. Discover why this has become a go-to resource for understanding OBD2 data.
You can also watch our OBD2 intro video above – or get the PDF
Understanding OBD2: Your Car’s Diagnostic Window
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, real-time data streams through the OBD2 connector. Think of it as a universal translator for your car’s complex language.
You’ve likely already encountered OBD2 in action, perhaps without realizing it. The malfunction indicator light, often called the “check engine light,” is a direct output of the OBD2 system. When this light illuminates, it signals that your car’s self-diagnostic system has detected an issue. Mechanics rely on OBD2 scanners to interpret these signals and diagnose the problem.
To access this diagnostic information and the valuable data stream, a mechanic connects an OBD2 reader to the OBD2 16-pin connector, typically located near the steering wheel. The scanner transmits ‘OBD2 requests’ to the vehicle’s computer system. In response, the car sends back ‘OBD2 responses’ containing a wealth of information. This data stream can include parameters like speed, engine RPM, fuel level, sensor readings, and Diagnostic Trouble Codes (DTCs). This real-time data stream is what allows for efficient and accurate troubleshooting and performance monitoring.
Understanding OBD2: On-Board Diagnostics and the Malfunction Indicator Light (MIL), often diagnosed with a scan tool.
Is Your Car OBD2 Compliant? Likely, Yes.
The good news is that OBD2 compatibility is widespread. Almost all modern, non-electric cars support OBD2, and the majority operate on the CAN bus communication protocol. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 compliance. Some early systems used the same connector but didn’t fully implement the OBD2 standard. Determining your car’s compliance often comes down to its origin and manufacturing date.
A helpful guideline for determining OBD2 compliance relates to where and when the vehicle was initially sold:
OBD2 Compliance Guide: Check your vehicle’s origin and year of manufacture to determine OBD2 compatibility in EU and US markets.
A Brief History of OBD2: From Emissions to Data Access
The origins of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated OBD systems in all new vehicles starting in 1991 for emissions monitoring. This initial push was driven by environmental concerns and the need to effectively control vehicle emissions.
The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBD, recommending the OBD2 standard which included standardized Diagnostic Trouble Codes (DTCs) and a universal OBD connector (SAE J1962) across different vehicle manufacturers. This standardization was a major step forward, making vehicle diagnostics more accessible and efficient.
The OBD2 standard was progressively implemented across the automotive industry:
- 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 vehicles to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
- 2010: OBD2 was finally required in the US for heavy-duty vehicles.
This timeline demonstrates the evolution of OBD2 from a California-specific emissions control measure to a globally adopted standard for vehicle diagnostics and data access.
OBD2 History: Tracing the evolution of On-Board Diagnostics from emission control to modern data access via CAN bus.
OBD2 History Timeline: A visual overview of the standardization and adoption of On-Board Diagnostics over the years.
OBD2 Future Trends: Envisioning OBD3 and the move towards remote diagnostics, emissions testing, cloud connectivity, and IoT integration.
The Future of OBD2: Adapting to New Vehicle Technologies
OBD2 is firmly established, but its future is evolving alongside the automotive industry. Several key trends are shaping the direction of OBD and vehicle data access.
Initially legislated for emissions control and testing, OBD2’s role is being reconsidered in the context of electric vehicles (EVs). Interestingly, electric vehicles are not mandated to support OBD2 in its traditional form. This is reflected in the fact that most modern EVs do not support standard OBD2 requests. Instead, many EVs utilize OEM-specific UDS (Unified Diagnostic Services) communication protocols. This shift often makes accessing data from EVs challenging, except in cases where reverse engineering efforts have uncovered the proprietary communication rules – as seen in case studies for electric cars including Tesla, Hyundai/Kia, Nissan and VW/Skoda EVs.
Recognizing the limitations of current OBD2 implementations, particularly regarding data richness and underlying communication protocols, modern alternatives are emerging. WWH-OBD (World-Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are designed to enhance OBD communication by using the UDS protocol as a foundation. These advancements aim to streamline data access and provide richer diagnostic information. Learn more about these protocols in our introduction to UDS.
In our increasingly connected world, traditional OBD2 testing methods appear cumbersome. Manual emission control checks are time-intensive and costly. The proposed solution? OBD3 – integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder to all 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 checks. Many devices today already facilitate CAN or OBD2 data transfer over WiFi/cellular networks, such as the CANedge2 WiFi CAN logger or the CANedge3 3G/4G CAN logger. While this offers convenience and cost savings, it also raises political and privacy concerns related to surveillance.
While OBD2 was initially conceived for stationary emission controls, it’s now widely utilized by third parties to generate real-time data streams through OBD2 dongles, CAN loggers and similar devices. However, the German car industry is considering restricting this access.
Christoph Grote, SVP Electronics at BMW, 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 industry proposal is to potentially disable OBD2 functionality during driving, centralizing data collection within manufacturer-controlled servers. This would give manufacturers control over the burgeoning ‘automotive big data’ landscape. Arguments for this shift often cite security concerns, such as mitigating the risk of car hacking, although many view it as a commercially motivated move. Whether this trend gains traction remains to be seen, but it could significantly disrupt the market for third-party OBD2 services.
OBD2 Future Challenges: Electric Vehicles and potential restrictions on data access through the OBD2 connector.
Enhance Your Expertise with Our ‘Ultimate CAN Guide’
Ready to become a CAN bus expert and master vehicle data streams?
Our comprehensive 160+ page PDF guide combines 12 ‘simple intros’ into one resource:
Download now
OBD2 Standards: Defining the Language of Vehicle Data
On-board diagnostics, or OBD2, operates as a higher-layer protocol, similar to a language, while CAN (Controller Area Network) serves as the communication method, akin to a phone line. This places OBD2 in the same category as other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.
Specifically, OBD2 standards meticulously define the OBD2 connector, the lower-layer communication protocols, OBD2 Parameter IDs (PIDs), and other critical aspects of the data stream. These standards ensure interoperability and consistent data interpretation across different vehicles.
These standards can be organized using the 7-layer OSI model, which provides a framework for understanding communication protocols. The following sections will focus on the most pertinent standards within this model. Notably, both SAE (Society of Automotive Engineers) and ISO (International Organization for Standardization) standards cover several layers. This reflects the development of OBD standards in both the USA (SAE) and Europe (ISO). Many of these standards are technically equivalent, for instance, SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3, ensuring global compatibility in OBD2 data streams.
OBD2 vs. CAN Bus: Illustrating the OSI 7-Layer Model with relevant ISO and SAE standards like ISO 15765 and ISO 11898.
OBD2 Connector Pinout: Socket diagram for a female Type A Data Link Connector (DLC), detailing pin assignments.
The OBD2 Connector [SAE J1962 / ISO 15031-3]: Your Physical Access Point
The standardized 16-pin OBD2 connector, defined by SAE J1962 / ISO 15031-3, provides a straightforward physical interface to access your vehicle’s data stream. It’s the universal port for extracting diagnostic information and real-time parameters.
The illustration depicts a typical Type A OBD2 pin connector, also known as a Data Link Connector (DLC). Key features of the OBD2 connector include:
- It’s generally located near the steering wheel, though its exact location can be concealed depending on the vehicle model.
- Pin 16 provides battery power, often remaining active even when the ignition is off, allowing for continuous data logging.
- The OBD2 pinout configuration varies depending on the specific communication protocol used by the vehicle.
- CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-High) and 14 (CAN-Low) are typically connected in modern vehicles.
Understanding the OBD2 connector is the first step in accessing the rich data stream your vehicle offers.
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 passenger cars and light-duty vehicles, while Type B is more prevalent in medium and heavy-duty vehicles.
As the illustration shows, both types share similar OBD2 pinouts but differ in their power supply outputs. Type A typically provides 12V power, while Type B supplies 24V. Baud rates can also differ; cars often use 500K, whereas heavy-duty vehicles commonly use 250K (with increasing support for 500K in newer models).
Visually distinguishing between the two types is aided by the Type B OBD2 connector’s interrupted groove in the center. Consequently, a Type B OBD2 adapter cable is universally compatible with both Type A and Type B sockets, while a Type A adapter will not fit into a Type B socket.
OBD2 Connector Types A and B: Differentiating between SAE J1962 connectors for cars/vans (12V) and trucks (24V).
OBD2 vs. CAN Bus ISO15765: Illustrating the relationship between OBD2 protocol and CAN bus communication standards (ISO 15765).
OBD2 and CAN Bus [ISO 15765-4]: The Communication Foundation
Since 2008, CAN bus has become the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as specified by ISO 15765. This standard ensures a consistent and robust communication method for accessing the OBD2 data stream.
ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) is a set of specifications applied to the CAN standard (ISO 11898) to tailor it for OBD2 communication. It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers of the OSI model.
Key specifications of ISO 15765-4 include:
- CAN bus bit rates must be either 250K or 500K, ensuring compatibility across vehicles.
- CAN IDs can be either 11-bit or 29-bit, accommodating both standard and extended CAN addressing.
- Specific CAN IDs are reserved for OBD requests and responses, streamlining diagnostic communication.
- Diagnostic CAN frame data length is fixed at 8 bytes, optimizing data transmission efficiency.
- The OBD2 adapter cable is limited to a maximum length of 5 meters to maintain signal integrity.
These specifications ensure that OBD2 communication over CAN bus is reliable, consistent, and efficient, providing a solid foundation for accessing the vehicle data stream.
OBD2 CAN Identifiers (11-bit, 29-bit): Addressing the Data Stream
All OBD2 communication is based on a request-response message exchange. Understanding the CAN identifiers used for these messages is crucial for interpreting the data stream.
In most passenger vehicles, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is commonly used to broadcast a request to all OBD2-compatible ECUs (Electronic Control Units), asking if they have data to report for the requested parameter, as defined in ISO 15765-4. Conversely, CAN IDs in the range 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests, targeting specific ECUs directly, although this is less frequently used.
ECUs respond using 11-bit IDs in the range 0x7E8-0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module).
In some vehicle types, particularly vans and light, medium, and heavy-duty vehicles, OBD2 communication may utilize extended 29-bit CAN identifiers instead of the standard 11-bit IDs.
For 29-bit CAN, the ‘Functional Addressing’ CAN ID is 0x18DB33F1. Responses from the vehicle will typically use CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF, with common examples being 0x18DAF110 and 0x18DAF11E. The response ID is sometimes presented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated in the J1939-71 standard as ‘Reserved for ISO 15765-2’.
OBD2 Protocol Request/Response Frames: Illustrating the flow of OBD2 communication with PID data parameters.
OBD2 vs. Proprietary CAN Bus: Contrasting OBD2 standard data streams with OEM-specific CAN bus data protocols.
OBD2 vs. Proprietary CAN Protocols: Two Parallel Data Streams
It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) operate using OEM-specific CAN protocols, independent of OBD2. OBD2 is an additional protocol layered on top for diagnostic purposes. OEM-specific CAN protocols are proprietary to each vehicle manufacturer, brand, model, and year. Unless you are the OEM, interpreting this raw CAN data is typically impossible without significant reverse engineering efforts (CAN bus sniffing and reverse engineering).
Connecting a CAN bus data logger to your car’s OBD2 connector might capture OEM-specific CAN data, often broadcast at high rates (1000-2000 frames/second). However, in many newer vehicles, a ‘gateway’ module filters CAN data at the OBD2 port, allowing only OBD2 communication to pass through.
Think of OBD2 as a separate, standardized data stream running in parallel with the OEM’s proprietary communication network. While both may be accessible through the OBD2 connector, they represent distinct data sets with different purposes and accessibility.
Bit-Rate and ID Validation: Ensuring Correct Data Stream Access
As previously mentioned, OBD2 can utilize two bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern cars predominantly use 500K and 11-bit IDs, but external tools should systematically verify these parameters to ensure correct data stream access.
ISO 15765-4 provides recommendations for a systematic initialization sequence to determine the correct combination. This process leverages the fact that all OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (refer to the OBD2 PID section) and that transmitting data at an incorrect bit rate will generate CAN error frames.
Newer versions of ISO 15765-4 acknowledge that vehicles may support OBD communication via OBDonUDS (OBD on Unified Diagnostic Services) rather than OBDonEDS (OBD on Emission Diagnostic Service). This article primarily focuses on OBD2/OBDonEDS (defined by ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (defined by ISO 14229, ISO 27145-3/SAE J1979-2).
To differentiate between OBDonEDS and OBDonUDS protocols, a diagnostic tool 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 are required to have ECUs that respond to this DID.
In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is the prevalent protocol in most non-EV cars today, while WWH-OBD is mainly used in EU trucks and buses.
OBD2 Bit-Rate and CAN ID Validation Flowchart: Step-by-step process for validating bit-rate and CAN ID using ISO 15765-4.
OBD2 Five Lower-Layer Protocols: Illustrating the five main protocols underlying OBD2 communication, including CAN (ISO 15765), KWP2000, SAE J1850, and ISO 9141.
Five Lower-Layer OBD2 Protocols: Beyond CAN Bus
While CAN bus (ISO 15765) is the dominant lower-layer protocol for OBD2 in modern vehicles, particularly those manufactured post-2008, it’s important to be aware of the other four protocols that were previously used. Examining older vehicles (pre-2008) and their OBD2 connector pinouts can help identify which protocol might be in use.
The five lower-layer OBD2 protocols are:
- ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and currently the most widely used protocol.
- ISO 14230-4 (KWP2000): Keyword Protocol 2000, commonly used in 2003+ vehicles, particularly in Asia.
- ISO 9141-2: Used in European, Chrysler, and Asian vehicles manufactured between 2000 and 2004.
- SAE J1850 (VPW): Variable Pulse Width Modulation, primarily used in older General Motors (GM) vehicles.
- SAE J1850 (PWM): Pulse Width Modulation, mainly used in older Ford vehicles.
Understanding these historical protocols is valuable when working with older vehicles or diagnosing communication issues.
Transporting OBD2 Messages via ISO-TP [ISO 15765-2]: Handling Larger Data Payloads
OBD2 data, regardless of size, is transmitted over the CAN bus using a transport protocol called ISO-TP (ISO 15765-2). This protocol is essential because it enables the communication of data payloads exceeding the 8-byte limit of a standard CAN frame. This capability 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 provides mechanisms for segmentation (splitting large messages into smaller frames), flow control (managing data transmission rate), and reassembly (reconstructing the original message at the receiving end). For a deeper understanding of ISO-TP, refer to our introduction to UDS.
However, a significant portion of OBD2 data, especially real-time parameters, fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of ‘Single Frame’ (SF) messages. In a Single Frame, the first data byte (known as the PCI field or Protocol Control Information field) indicates the payload length (excluding any padding bytes), leaving the remaining 7 bytes for the actual OBD2 communication data.
ISO 15765-2 ISO-TP OBD2 Frame Types: Diagram illustrating different frame types in ISO-TP for OBD2 communication.
The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]: Dissecting the Data Stream
To effectively interpret the OBD2 data stream on CAN, it’s essential to understand the structure of a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message comprises a CAN identifier, a data length indicator (PCI field), and the actual data payload. The data payload itself is further structured into three key components: Mode, Parameter ID (PID), and data bytes.
OBD2 PIDs Message Structure: Breakdown of an OBD2 message structure, highlighting Mode, PID, and Data Bytes.
Example: OBD2 Request/Response for Vehicle Speed
Let’s examine a practical example of an OBD2 request and response for the ‘Vehicle Speed’ parameter to illustrate how the data stream works.
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 consists of two bytes: Mode 0x01 and PID 0x0D. This message is a request for real-time data (Mode 0x01) specifically for the Vehicle Speed parameter (PID 0x0D).
The vehicle’s ECU (typically the Engine Control Module) responds with a message using CAN ID 0x7E8. The response payload contains three bytes. The 4th byte of the CAN data frame (which is the third byte of the payload after the PCI field) holds the Vehicle Speed value, represented as 0x32 in hexadecimal. Converting 0x32 to decimal gives 50.
By consulting the OBD2 PID documentation for PID 0x0D, we find the decoding rules for Vehicle Speed. In this case, the value 50 directly corresponds to a physical value of 50 km/h. This example demonstrates the fundamental request-response mechanism and data encoding within the OBD2 data stream.
OBD2 Request and Response Example: CAN bus trace showing a request for Vehicle Speed (PID 0x0D) and the corresponding response.
OBD2 PID Example Vehicle Speed 0D: Decoding the Vehicle Speed PID (0x0D) data to obtain physical values.
OBD2 Services (Modes): Overview of the 10 standard OBD2 service modes for diagnostics and data retrieval.
The 10 OBD2 Services (Modes): Accessing Different Data Types
OBD2 defines 10 diagnostic services, also referred to as modes, each designed to access specific types of information from the vehicle. Mode 0x01, as seen in the Vehicle Speed example, is used to retrieve current real-time data parameters. Other modes are designed for accessing and clearing Diagnostic Trouble Codes (DTCs), retrieving freeze frame data (snapshots of parameters when a DTC was set), and more.
Vehicles are not required to support all 10 OBD2 modes. Manufacturers can also implement OEM-specific modes beyond the 10 standardized ones to provide access to additional diagnostic or data streams.
In OBD2 messages, the mode is indicated in the second byte of the data payload (after the PCI field in ISO-TP). In a request message, the mode is included directly (e.g., 0x01 for Mode 1). In a response message, 0x40 is added to the requested mode value (e.g., a response to Mode 0x01 will have a mode byte of 0x41).
OBD2 Parameter IDs (PIDs): Identifying Specific Data Points
Within each OBD2 mode, Parameter IDs (PIDs) are used to specify the exact data parameter being requested or reported. Mode 0x01, for example, contains approximately 200 standardized PIDs that provide real-time data on a wide range of vehicle parameters, including speed, engine RPM, coolant temperature, fuel level, and many others. However, vehicles are not obligated to support all standardized PIDs within a given mode. In practice, most vehicles support only a subset of the available PIDs.
One PID holds special significance: Mode 0x01 PID 0x00. If an emissions-related ECU supports any OBD2 services, it must support Mode 0x01 PID 0x00. When queried with this PID, the vehicle ECU responds by indicating which PIDs in the range 0x01-0x20 it supports. This makes PID 0x00 an essential tool for initial OBD2 compatibility testing and for discovering the vehicle’s supported data stream parameters. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for subsequent PID ranges within Mode 0x01.
OBD2 Protocol Request/Response Frames: Emphasizing the role of PID data parameters in OBD2 communication.
OBD2 PID Overview Tool: A tool interface displaying OBD2 PID data for service 01, aiding in data stream analysis.
Tip: Leveraging an OBD2 PID Overview Tool
The appendices of SAE J1979 and ISO 15031-5 provide crucial scaling and decoding information for standard OBD2 PIDs. This information is essential for converting the raw data bytes received in the OBD2 data stream into meaningful physical values, as discussed in our CAN bus introduction.
For quick lookups 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 the vehicle data stream.
OBD2 PID overview tool
Practical Guide: Logging and Decoding OBD2 Data Streams
This section provides a practical walkthrough on logging OBD2 data streams using the CANedge CAN bus data logger. The CANedge’s ability to transmit custom CAN frames makes it ideal for sending OBD2 requests and capturing the resulting data stream.
To begin, configure the CANedge to transmit OBD2 requests. Once configured, connecting the device to your vehicle is simple using our OBD2-DB9 adapter cable.
OBD2 PID Data Logger Request: Illustrating an OBD2 data logger sending a request (7DF) and receiving a response (7E8) for PID data.
Validating Bit Rate: Testing and validating the CAN bit-rate (e.g., 500K) for successful OBD2 communication.
Supported PIDs Validation: Reviewing responses to ‘Supported PIDs’ requests using asammdf for data stream analysis.
Step #1: Bit-Rate, ID, and Supported PID Validation
As previously discussed, ISO 15765-4 outlines the procedure for identifying the correct bit rate and CAN IDs for a specific vehicle. You can use the CANedge to perform these validation steps: (Refer to the CANedge Intro for detailed instructions).
- Bit Rate Test: Transmit a CAN frame at 500K. Check if the transmission is successful. If not, repeat the test at 250K.
- Bit Rate Confirmation: Use the successfully identified bit rate for all subsequent OBD2 communication.
- Supported PID Discovery: Send multiple ‘Supported PIDs’ requests (Mode 0x01 PID 0x00, 0x20, etc.) and analyze the responses.
- CAN ID Type Determination: Based on the response IDs (e.g., 0x7E8 range for 11-bit, 0x18DAF1xx range for 29-bit), determine whether the vehicle uses 11-bit or 29-bit CAN IDs for OBD2.
- Supported PID List: Analyze the response data to determine the specific PIDs supported by the vehicle.
We provide pre-configured CANedge configurations to simplify these validation tests. Most non-EV 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.
As illustrated in the asammdf GUI screenshot, it’s common to receive multiple responses to a single OBD request, particularly when using the functional address ID 0x7DF, which queries all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are often observed. However, for subsequent ‘Supported PIDs’ requests (e.g., for ranges 0x21-0x40, etc.), fewer ECUs typically respond. Notice that the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs. This suggests that bus load could be reduced by directing subsequent requests specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0.
Step #2: Configuring OBD2 PID Requests for Data Logging
Once you’ve identified the supported OBD2 PIDs, bit rate, and CAN IDs for your vehicle, the next step is to configure your data logger to request the PIDs you want to monitor.
Key considerations for configuring OBD2 PID requests for data logging:
- CAN ID Selection: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0 for ECM) to minimize redundant responses and bus load.
- Request Spacing: Introduce a delay of 300-500 ms between consecutive OBD2 requests. Overly rapid requests can overwhelm ECUs and lead to dropped responses.
- Power Management: Implement triggers to halt data transmission when the vehicle is inactive, preventing battery drain and unnecessary ECU wake-ups.
- Data Filtering: Configure filters to record only relevant OBD2 responses, especially if your vehicle also broadcasts OEM-specific CAN data on the same bus.
With these configurations in place, your CANedge is ready to log raw OBD2 data streams efficiently.
CANedge OBD2 Transmit List Example: Example configuration showing a list of OBD2 PID requests configured in CANedge for data logging.
OBD2 Data Decoded in asammdf: Visual plot of decoded OBD2 data in asammdf using a CAN bus DBC file for interpretation.
Step #3: DBC Decoding of Raw OBD2 Data
To analyze and visualize the logged raw OBD2 data effectively, you need to decode it into human-readable ‘physical values’ (e.g., km/h, °C, RPM). This decoding process relies on scaling and conversion formulas defined in ISO 15031-5/SAE J1979, and readily available on resources like Wikipedia.
To simplify this process, we provide a free OBD2 DBC file. This DBC file enables easy DBC decoding of raw OBD2 data within most CAN bus software tools, including asammdf.
Decoding OBD2 data is slightly more complex than decoding standard CAN signals. This is because multiple 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.
The solution is to utilize the CAN ID, OBD2 mode, and OBD2 PID in combination to identify each signal. This technique is a form of multiplexing known as ‘extended multiplexing‘. It can be effectively implemented using DBC files, which allow you to define decoding rules based on these combined identifiers.
CANedge: Your OBD2 Data Logging Solution
The CANedge provides a user-friendly solution for recording OBD2 data streams directly to an 8-32 GB SD card. Simply connect the CANedge to your vehicle’s OBD2 port to start logging. Data can then be decoded and analyzed using free software and APIs and our OBD2 DBC file.
OBD2 logger intro
CANedge
OBD2 Multi-Frame Examples [ISO-TP]: Handling Larger Diagnostic Messages
While many OBD2 data parameters fit within single CAN frames, some diagnostic requests and responses, such as those for VIN or DTCs, require multi-frame communication due to their larger data payloads. All OBD2 communication, including multi-frame exchanges, is governed by the ISO-TP (transport protocol) as defined in ISO 15765-2.
Multi-frame OBD2 communication necessitates the use of flow control frames to manage the data exchange (refer to our UDS introduction for details on flow control). 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.
Analyzing multi-frame OBD2 responses requires CAN software and API tools that support ISO-TP, such as the CANedge MF4 decoders.
OBD2 Multi-Frame Request: Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN) retrieval.
Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval
Retrieving the Vehicle Identification Number (VIN) via OBD2 is often crucial for telematics, diagnostics, and other applications (see our UDS intro for more context). To extract the VIN using OBD2 requests, you utilize mode 0x09 (Request Vehicle Information) and PID 0x02 (Request Vehicle Identification Number).
The diagnostic tool initiates the process by sending a Single Frame request with the PCI field set to 0x02 (indicating a Single Frame), the request service identifier set to 0x09 (Mode 9), and the PID set to 0x02 (VIN request).
The vehicle responds with a First Frame message. This frame contains the PCI field, the total length of the multi-frame message (0x014 = 20 bytes), the mode byte (0x49, which is 0x09 + 0x40 indicating a positive response to Mode 9), and the PID (0x02). Following the PID, the byte 0x01 indicates the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for details on NODI). The subsequent 17 bytes contain the VIN itself, encoded in hexadecimal ASCII representation. These hexadecimal values can be converted to standard ASCII characters to obtain the human-readable VIN using methods described in our UDS introduction.
Example 2: OBD2 Multi-PID Request (6x) – Advanced Data Stream Optimization
OBD2 allows diagnostic tools to request up to 6 Mode 0x01 OBD2 PIDs within a single request frame. The ECU is expected to respond with data for all supported PIDs from the request list (omitting data for unsupported PIDs). If necessary, the response can span multiple frames using ISO-TP.
This multi-PID request feature offers a way to enhance data stream acquisition frequency and efficiency. However, it also introduces complexities in data interpretation. The signal encoding in the response is tightly coupled to the specific PIDs requested, making the use of generic OBD2 DBC files challenging for this approach. We generally advise against using multi-PID requests in practical data logging scenarios unless specifically required.
Below is an example trace illustrating a multi-PID request and response:
The multi-frame response structure is similar to the VIN example, but with the added complexity that the payload includes both the requested PIDs and their corresponding data values. In the example, the PIDs in the response are ordered in the same sequence as they were requested, which is common practice but not strictly mandated by the ISO 15031-5 standard.
Decoding these multi-PID responses using standard DBC files becomes extremely difficult. Therefore, we do not recommend this approach for general data logging unless you are using specialized tools with built-in support for multi-PID requests. This scenario exemplifies extended multiplexing, but with multiple instances within a single payload. Furthermore, if you send multiple such multi-PID requests, differentiating between response messages becomes challenging, especially if relying solely on DBC file manipulations.
Workarounds might involve custom scripting and recording both request and response messages. A script could then interpret the response payload based on the corresponding request message. However, such approaches are complex to scale and manage, particularly across diverse vehicle types with varying PID support.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs) – Understanding Vehicle Faults
OBD2 Mode 0x03, ‘Show stored Diagnostic Trouble Codes’, allows you to request emissions-related DTCs. The request message for Mode 0x03 does not include a PID. The targeted ECU(s) will respond with the number of DTCs currently stored (which could be zero if no DTCs are active). Each DTC is represented by 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored, as the response payload needs to accommodate all DTC data.
The 2-byte DTC value is structured according to ISO 15031-5/ISO 15031-6. The first 2 bits define the DTC ‘category’ (e.g., Powertrain, Chassis, Body, Network), while the remaining 14 bits form a 4-digit code displayed in hexadecimal format. Decoded DTC values can be looked up using various OBD2 DTC lookup tools, such as repairpal.com.
The example below illustrates a request to an ECU that has 6 DTCs stored.
OBD2 DTC Decoding: Example of OBD2 Diagnostic Trouble Code (DTC) decoding and interpretation using a DBC file.
OBD2 Data Logging – Real-World Use Cases
OBD2 data streams from cars and light trucks have diverse applications across various industries:
Vehicle Data Logging
OBD2 data logging in cars offers benefits like fuel efficiency optimization, driving behavior improvement, prototype component testing, and insurance telematics.
obd2 logger
Real-Time Vehicle Diagnostics
OBD2 interfaces enable real-time streaming of vehicle data for immediate diagnostics and issue identification.
obd2 streaming
Predictive Maintenance
Cloud-connected IoT OBD2 loggers facilitate remote vehicle monitoring for predictive maintenance, minimizing downtime and preventing breakdowns.
predictive maintenance
Vehicle Black Box Recording
OBD2 loggers can serve as ‘black boxes’ in vehicles or equipment, providing crucial data for incident analysis, dispute resolution, and warranty validation.
can bus blackbox
Do you have an OBD2 data logging application in mind? Contact us for expert guidance and free consultation!
Contact us
Explore our guides section for more introductory resources, or download our comprehensive ‘Ultimate Guide’ PDF.
Ready to start logging and streaming OBD2 data streams?
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
