Looking for a straightforward and practical guide to understanding OBD2 output data?
This guide provides a deep dive into the On-Board Diagnostics (OBD2) protocol, encompassing the OBD2 connector, OBD2 Parameter IDs (PIDs), and its connection to the CAN bus.
Note: This is designed to be a comprehensive yet accessible guide, equipping you with the knowledge to request and interpret OBD2 data, explore key data logging applications, and benefit from practical insights.
Discover why this is becoming a leading resource for mastering OBD2 output data.
You can also watch our introductory video on OBD2 or download this guide as a PDF
Article Contents
Author: Martin Falch (Updated January 2025)
PDF icon
Download as PDF
Understanding OBD2: Unveiling Vehicle Diagnostics
OBD2 is essentially your vehicle’s internal health monitoring system. It’s a standardized protocol designed to extract diagnostic trouble codes (DTCs) and provide real-time data streams via the OBD2 connector, giving you crucial insights into your vehicle’s operation and health through OBD2 output data.
You’ve likely already encountered OBD2 in action:
Ever seen the check engine light illuminate on your dashboard?
That’s your car signaling an issue. When you take your vehicle to a mechanic, they use an OBD2 scanner to pinpoint the problem. This process relies heavily on interpreting OBD2 output data.
Mechanics connect an OBD2 reader to the 16-pin OBD2 connector, usually located near the steering wheel. The scanner sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses.’ These responses, the OBD2 output data, can include vital information such as speed, fuel level, and Diagnostic Trouble Codes (DTCs), enabling faster and more efficient troubleshooting.
OBD2 system overview highlighting the malfunction indicator light and scan tool usage for diagnostics.
OBD2 Compatibility: Does Your Car Speak the Language?
The short answer is: Most likely, yes!
Nearly all modern non-electric vehicles are equipped with OBD2 support, and most operate on the CAN bus network. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t guarantee OBD2 compliance. Some may not fully support the protocol. To verify, consider the vehicle’s purchase location and year:
Does My Car Have OBD2?
Infographic illustrating OBD2 compliance by region and vehicle type, helping determine if a car supports OBD2.
A Look Back: The History of OBD2
The origins of OBD2 trace back to California, where the California Air Resources Board (CARB) mandated OBD in all new vehicles starting from 1991 for emissions monitoring.
The OBD2 standard was refined and recommended by the Society of Automotive Engineers (SAE), leading to standardized DTCs and a universal OBD connector (SAE J1962). This standardization was crucial for consistent OBD2 output data interpretation across different manufacturers.
The OBD2 standard adoption unfolded progressively:
- 1996: OBD2 became mandatory in the USA for cars and light trucks.
- 2001: Required in the EU for gasoline cars.
- 2003: Extended to diesel cars in the EU (EOBD).
- 2005: OBD2 was mandated in the US for medium-duty vehicles.
- 2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2, standardizing OBD2 output data communication protocols.
- 2010: OBD2 compliance became mandatory for heavy-duty vehicles in the US.
Graphical timeline depicting the evolution of OBD2 standards in relation to emission control and data communication.
Timeline overview illustrating the historical progression of OBD2 from inception to widespread adoption.
Conceptual illustration of OBD3 advancements, focusing on remote diagnostics and cloud integration for emissions testing and data management.
The Future Trajectory of OBD2
OBD2 is firmly established, but its evolution continues. What’s on the horizon?
Key trends shaping the future of OBD2 include:
Initially designed for emissions regulation and testing, legislated OBD2 standards present a unique scenario with electric vehicles. Interestingly, electric vehicles are not compelled to support OBD2 in any form. This is reflected in the limited support for standard OBD2 requests in most modern EVs. Instead, many employ OEM-specific UDS communication protocols. This OEM-specific approach generally restricts access to OBD2 output data from electric vehicles unless decoding methods are reverse-engineered. However, progress is being made as shown in our case studies for electric cars, including analyses for Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.
OBD2’s current implementations face limitations in data richness and lower-layer protocol flexibility. To address these, advanced alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These protocols aim to refine OBD communication by using the UDS protocol as a foundation, promising richer and more standardized OBD2 output data. For a deeper understanding of these protocols, refer to our introduction to UDS.
In our increasingly connected world, traditional OBD2 testing methods can seem outdated. Manual emission checks are slow and costly.
The answer? OBD3 – integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder, similar to those used for bridge tolls, to every car. This would enable vehicles to transmit their vehicle identification number (VIN) and DTCs wirelessly via WiFi to a central server for automated diagnostics. This shift would revolutionize how OBD2 output data is accessed and utilized.
Many current devices 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 offering cost savings and convenience, OBD3 also raises political concerns related to surveillance and data privacy.
The original purpose of OBD2 was for stationary emission controls.
However, today, OBD2 is widely used by third parties to generate real-time data through OBD2 dongles, CAN loggers and similar tools. This widespread access to OBD2 output data is now being reconsidered by the German car industry, as highlighted in this report:
OBD was intended for vehicle servicing 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.”
– Christoph Grote, SVP Electronics, BMW (2017)
The proposal suggests disabling OBD2 functionality while driving, centralizing data collection through manufacturer-controlled servers. This move would give manufacturers control over the burgeoning ‘automotive big data’ market, and fundamentally alter access to OBD2 output data.
The rationale is rooted in security concerns, such as mitigating the risk of car hacking. However, many perceive this as a commercially motivated strategy. Whether this trend gains traction remains to be seen, but it could significantly disrupt the market for third-party OBD2 services and access to OBD2 output data.
Illustration depicting the potential future trend of electric vehicles limiting or blocking access to OBD2 data through connector modifications.
Enhance Your CAN Bus Expertise
Eager to become a CAN bus expert?
Access our 12 ‘simple intros’ compiled into a comprehensive 160+ page PDF guide:
Download now
CAN Bus – The Ultimate Guide Tutorial PDF
Decoding OBD2 Standards
On-board diagnostics, OBD2, operates as a higher-layer protocol, similar to a language, while CAN functions as the communication method, akin to a phone line. This places OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000. Understanding these standards is key to correctly interpreting OBD2 output data.
Specifically, OBD2 standards define the OBD2 connector, lower-layer protocols, OBD2 Parameter IDs (PIDs), and other critical aspects essential for standardized OBD2 output data.
These standards can be organized using a 7-layer OSI model. The following sections will focus on the most crucial standards for understanding OBD2 output data.
In the OSI model framework, you’ll notice that both SAE and ISO standards cover multiple layers. This generally reflects the standards established for OBD in the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, for example, SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3. Adherence to these standards ensures consistency in OBD2 output data across different regions and manufacturers.
OSI model diagram contrasting OBD2 and CAN Bus protocols, emphasizing ISO 15765 and ISO 11898 standards across different layers.
Detailed pinout diagram of a Type A OBD2 connector, essential for hardware interfacing and data retrieval.
The OBD2 Connector: SAE J1962 Standard
The 16-pin OBD2 connector is your gateway to accessing vehicle data, standardized under SAE J1962 / ISO 15031-3. This connector is critical for retrieving OBD2 output data.
The illustration shows a typical Type A OBD2 pin connector, also known as the Data Link Connector (DLC).
Key points about the OBD2 connector include:
- It’s usually located near the steering wheel, but can be hidden.
- Pin 16 provides battery power, often active even when the ignition is off, ensuring continuous power for diagnostics.
- The OBD2 pinout configuration varies depending on the communication protocol used by the vehicle.
- CAN bus is the most prevalent lower-layer protocol, typically utilizing pins 6 (CAN-H) and 14 (CAN-L), which are essential for CAN-based OBD2 output data systems.
OBD2 Connector Types: A vs. B
In practice, you might encounter both Type A and Type B OBD2 connectors. Type A is commonly found in cars, while Type B is more prevalent in medium and heavy-duty vehicles. These connector types influence the physical interface and power supply for OBD2 output data systems.
As shown in the illustration, Type A and Type B connectors share similar pinouts but differ in power supply outputs: 12V for Type A and 24V for Type B. Baud rates often vary as well, with cars typically using 500K, and heavy-duty vehicles commonly using 250K (though 500K support is increasing). These differences are important when configuring devices to read OBD2 output data.
Type B OBD2 connectors have a distinguishing interrupted groove in the middle. This design means a Type B OBD2 adapter cable is compatible with both Type A and B sockets, while a Type A adapter will not fit into a Type B socket. This physical incompatibility is a key consideration for hardware selection when working with OBD2 output data.
Comparison diagram of OBD2 Connector Types A and B, highlighting differences in voltage, application, and physical characteristics as per SAE J1962.
Diagram illustrating the relationship between OBD2 and CAN bus within the context of ISO 15765 standards for automotive diagnostics.
OBD2 and CAN Bus: ISO 15765-4 Integration
Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as mandated by ISO 15765. This standardization ensures consistent communication and interpretation of OBD2 output data.
ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies a set of constraints applied to the CAN standard (ISO 11898). These constraints are crucial for reliable OBD2 output data transmission.
Specifically, it standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:
- CAN bus bit-rate must be either 250K or 500K, ensuring compatibility across different vehicle systems.
- CAN IDs can be 11-bit or 29-bit, accommodating standard and extended identifiers.
- Specific CAN IDs are designated for OBD requests and responses, streamlining diagnostic communication.
- Diagnostic CAN frame data length is fixed at 8 bytes, optimizing data packet size.
- The OBD2 adapter cable is limited to a maximum length of 5 meters to maintain signal integrity and reliability of OBD2 output data.
OBD2 CAN Identifiers: 11-bit and 29-bit
All OBD2 communication is structured around request/response message exchanges. These messages are fundamental to obtaining OBD2 output data.
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 to see if they have data for the requested parameter (as per ISO 15765-4). Conversely, CAN IDs 0x7E0-0x7E7 enable ‘Physical Addressing’ requests to specific ECUs, although this is less commonly used in standard OBD2 output data requests.
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). These response IDs are essential for parsing OBD2 output data.
In some vehicles, especially vans and medium to heavy-duty vehicles, OBD2 communication may use extended 29-bit CAN identifiers instead of 11-bit IDs. This is important to note when configuring systems to capture OBD2 output data.
For 29-bit identifiers, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Responses in 29-bit systems are sent with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF, typically 0x18DAF110 and 0x18DAF11E. The response ID is sometimes presented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated as ‘Reserved for ISO 15765-2’ in the J1939-71 standard. Understanding these identifiers is crucial for correctly interpreting OBD2 output data in various vehicle types.
Diagram illustrating the request-response frame structure in OBD2 protocol, essential for understanding data flow.
OBD2 OBD CAN bus Identifiers 7DF 7E8 7E0
Visual comparison of OBD2 and proprietary CAN bus data, highlighting differences in accessibility and standardization.
OBD2 vs. Proprietary CAN Protocols
It’s important to understand that your vehicle’s Electronic Control Units (ECUs) function independently of OBD2. Each Original Equipment Manufacturer (OEM) implements their own proprietary CAN protocols for core vehicle operations. These proprietary protocols are often specific to vehicle brand, model, and year. Access to and interpretation of this data is typically restricted unless you can reverse engineer it. This distinction is crucial when analyzing OBD2 output data in the context of broader vehicle communication.
When you connect a CAN bus data logger to your car’s OBD2 connector, you may observe OEM-specific CAN data, usually broadcast at high rates (1000-2000 frames/second). However, many newer vehicles use a ‘gateway’ to block access to this proprietary CAN data, limiting the OBD2 connector to OBD2 communication only. This gateway system significantly affects the availability of OBD2 output data and OEM-specific data.
In essence, OBD2 should be viewed as an ‘additional’ higher-layer protocol working alongside the OEM-specific protocol. This layered architecture affects how OBD2 output data is accessed and its relation to overall vehicle data.
Bit-Rate and ID Validation
As previously mentioned, OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern vehicles commonly use 500K with 11-bit IDs, but external tools should systematically verify these settings. Accurate validation ensures reliable capture of OBD2 output data.
ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination. This method relies on the fact that OBD2-compliant vehicles must respond to a mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit-rate transmissions will cause CAN error frames. Proper validation is essential for accurate OBD2 output data retrieval.
Newer versions of ISO 15765-4 account for vehicles that may support OBD communication via OBDonUDS rather than OBDonEDS. While this article primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979), understanding the distinction is important. WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2) represents an evolving standard.
To test for OBDonEDS vs. OBDonUDS protocol, diagnostic tools may send additional UDS requests using 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS must have ECUs that respond to this DID. These tests help determine the protocol and ensure correct interpretation of OBD2 output data.
Currently, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars, while WWH-OBD is mainly used in EU trucks and buses. This protocol landscape influences the methods and tools needed for effective OBD2 output data analysis.
Flowchart illustrating the OBD2 bit-rate and CAN ID validation process as per ISO 15765-4, crucial for establishing correct communication parameters.
Diagram showing the five lower-layer OBD2 protocols including CAN (ISO 15765), KWP2000, SAE J1850, and ISO 9141, highlighting protocol diversity in OBD2 systems.
Five Lower-Layer OBD2 Protocols
While CAN is now the dominant lower-layer protocol for OBD2 under ISO 15765, older vehicles (pre-2008) may use other protocols. Knowing these protocols and their corresponding pinouts is useful for diagnosing older systems and understanding the evolution of OBD2 output data standards.
The five lower-layer OBD2 protocols include:
- ISO 15765 (CAN bus): Mandatory in US cars since 2008, now widely used in most vehicles for OBD2 output data.
- ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ cars, especially in Asia.
- ISO 9141-2: Used in EU, Chrysler, and Asian cars from 2000-2004.
- SAE J1850 (VPW): Predominantly used in older GM vehicles.
- SAE J1850 (PWM): Mainly used in older Ford vehicles.
ISO-TP: Transporting OBD2 Messages – ISO 15765-2
All OBD2 data communication over CAN bus relies on the ISO-TP (ISO 15765-2) transport protocol. This protocol is essential for handling payloads larger than 8 bytes, which is necessary for transmitting Vehicle Identification Numbers (VINs) or Diagnostic Trouble Codes (DTCs) within OBD2 output data. ISO 15765-2 manages segmentation, flow control, and reassembly of these larger data packets. For an in-depth understanding, refer to our introduction to UDS.
However, much of the OBD2 output data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF) format. The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-related communication. This efficient use of single frames is common for many real-time OBD2 output data parameters.
Diagram illustrating ISO-TP frame types used in OBD2 communication as per ISO 15765-2, showing Single Frame, First Frame, Consecutive Frame, and Flow Control Frame structures.
Decoding the OBD2 Diagnostic Message – SAE J1979, ISO 15031-5
To effectively understand OBD2 communication on CAN, let’s examine 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 data payload. The data is further structured into Mode, Parameter ID (PID), and data bytes. Understanding this structure is fundamental to interpreting OBD2 output data.
Breakdown of an OBD2 message structure, detailing the arrangement of Mode, PID, and Data Bytes within a CAN frame for diagnostic communication.
Example: OBD2 Request and Response
Consider this example of requesting and receiving the ‘Vehicle Speed’ parameter to illustrate OBD2 output data in action.
An external tool sends a request message to the vehicle with CAN ID 0x7DF, containing two payload bytes: Mode 0x01 and PID 0x0D. This request is specifically for vehicle speed data. The vehicle responds via CAN ID 0x7E8 with three payload bytes, including the vehicle speed value in the fourth byte, 0x32 (50 in decimal). This response contains the OBD2 output data we are interested in.
By consulting the decoding rules for OBD2 PID 0x0D, we determine that the physical value is 50 km/h. This process of request, response, and decoding is central to working with OBD2 output data.
In the following sections, we’ll delve deeper into OBD2 modes and PIDs to provide a comprehensive understanding of OBD2 output data interpretation.
Example of OBD2 request and response messages for vehicle speed, showing CAN IDs and payload data flow.
Detailed example of OBD2 PID 0D (Vehicle Speed), illustrating the data bytes and their conversion to physical units.
Overview of the 10 OBD2 service modes, including descriptions of current data, freeze frame, and DTC clearing functionalities.
The 10 OBD2 Services (Modes)
There are 10 standardized OBD2 diagnostic services, often referred to as modes. Mode 0x01 is used to access current real-time data, while other modes are designed to display or clear diagnostic trouble codes (DTCs) or show freeze frame data. Each mode provides a different type of OBD2 output data.
Vehicles are not required to support all 10 OBD2 modes and may also implement modes beyond these standardized ones, which are known as OEM-specific OBD2 modes. The level of mode support impacts the breadth of OBD2 output data available from a vehicle.
In OBD2 messages, the mode is specified in the second byte of the data payload. In a request message, the mode is included directly (e.g., 0x01). In a response message, 0x40 is added to the requested mode (resulting in 0x41 for a response to mode 0x01). This mode encoding is important for distinguishing requests from responses in OBD2 output data streams.
OBD2 Parameter IDs (PIDs)
Within each OBD2 mode, Parameter IDs (PIDs) are used to specify particular data points. PIDs are crucial for accessing specific OBD2 output data.
For example, mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on parameters such as speed, RPM, and fuel level. However, vehicles are not obligated to support all PIDs within a mode. In practice, most vehicles support only a subset of the available PIDs. Therefore, understanding supported PIDs is essential for effective OBD2 output data retrieval.
One PID holds special significance.
Specifically, if an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the vehicle ECU indicates its support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Furthermore, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for subsequent ranges of mode 0x01 PIDs. Using PID 0x00 is a primary step in discovering the range of OBD2 output data a vehicle can provide.
Diagram reiterating the request-response framework of OBD2 protocol, emphasizing the role of PIDs in data parameter requests and responses.
OBD2 PID overview tool
Screenshot of an OBD2 PID overview tool, showcasing its interface for browsing and selecting PIDs within service 01.
Tip: OBD2 PID Overview Tool
The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs, which is necessary to decode the raw data into physical values, as explained in our CAN bus introduction. This scaling information is vital for accurately interpreting OBD2 output data.
For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is invaluable. It helps you construct OBD2 request frames and dynamically decode OBD2 responses, streamlining the process of working with OBD2 output data.
OBD2 PID overview tool
Practical Guide: Logging and Decoding OBD2 Data
This section provides a hands-on example of how to log OBD2 output data using the CANedge CAN bus data logger.
The CANedge allows configuration of custom CAN frames for transmission, making it suitable for OBD2 logging. This capability is essential for effectively capturing OBD2 output data.
Once configured, the CANedge can be easily connected to your vehicle using our OBD2-DB9 adapter cable. This setup simplifies the process of logging OBD2 output data.
Diagram illustrating the use of an OBD2 data logger to request and capture PID data, showcasing the data flow between vehicle and logger.
OBD2 bit rate test
Screenshot demonstrating a bit-rate validation test for OBD2 communication, ensuring proper setup for data logging.
OBD2 Supported PIDs Test
Screenshot from asammdf software showing OBD2 validation PID test responses, used to verify supported PIDs in a vehicle.
Review supported PIDs via OBD2 lookup tool
Step #1: Bit-rate, ID, and Supported PID Validation
As previously discussed, ISO 15765-4 outlines how to determine the correct bit-rate and IDs for a specific vehicle. The CANedge can be used to perform these tests as follows (see the CANedge Intro for detailed instructions): These steps are crucial for ensuring successful OBD2 output data logging.
- Bit-rate Test: Send a CAN frame at 500K and check for successful transmission. If unsuccessful, try 250K.
- Bit-rate Configuration: Use the validated bit-rate for all subsequent communication.
- Supported PID Requests: Send multiple ‘Supported PIDs’ requests and analyze the responses.
- ID Type Determination: Based on response IDs, determine whether 11-bit or 29-bit IDs are in use.
- Supported PID Identification: Based on the response data, identify the PIDs supported by the vehicle.
We provide plug-and-play configurations to simplify these tests, making it easier to start logging OBD2 output data.
Most 2008+ non-EV vehicles 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, multiple responses to a single OBD request are common. This is because using the 0x7DF request ID polls all ECUs for responses. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, many responses are often received for this PID. For subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. Notably, the ECM ECU (0x7E8) supports all PIDs supported by other ECUs in this example. This means busload can be reduced by directing subsequent communication specifically to the ECM using ‘Physical Addressing’ CAN ID 0x7E0. This optimization technique can improve the efficiency of OBD2 output data collection.
Step #2: Configuring OBD2 PID Requests
Once you’ve identified the PIDs supported by your vehicle and the correct bit-rate and CAN IDs, you can configure your transmit list with the PIDs you want to log. Proper configuration is key to efficient OBD2 output data logging.
Consider these points when configuring PID requests:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid redundant responses and streamline OBD2 output data.
- Request Spacing: Introduce a 300-500 ms delay between each OBD2 request. Overly frequent requests can overwhelm ECUs and prevent responses, affecting OBD2 output data reliability.
- Battery Drain Management: Use triggers to halt transmissions when the vehicle is inactive to prevent battery drain by ‘waking up’ ECUs unnecessarily, especially important during long-term OBD2 output data logging.
- Data Filtering: Implement filters to record only OBD2 responses, particularly if your vehicle also broadcasts OEM-specific CAN data, ensuring clean and focused OBD2 output data logs.
With these configurations, your CANedge is ready to log raw OBD2 output data effectively!
obd2-transmit-list-example-canedge
Example of a CANedge OBD2 PID request transmit list configuration, showing setup for specific PIDs and request parameters.
OBD2 data decoded visual plot asammdf CAN bus DBC file
Screenshot from asammdf software displaying decoded and visualized OBD2 data, demonstrating data analysis and interpretation capabilities.
Step #3: DBC Decoding of Raw OBD2 Data
To analyze and visualize your logged data, you need to decode the raw OBD2 output data into ‘physical values’ such as km/h or °C. Decoding is essential for making sense of the raw data logs.
The decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, we offer a free OBD2 DBC file that simplifies DBC decoding of raw OBD2 data in most CAN bus software tools. Using a DBC file significantly streamlines OBD2 output data analysis.
Decoding OBD2 output data is more complex than standard CAN signal decoding. This is because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is insufficient to identify the signals within the payload.
To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID to uniquely identify each signal. This technique, known as ‘extended multiplexing‘, can be implemented in DBC files. Properly using DBC files with extended multiplexing is key to accurate OBD2 output data interpretation.
CANedge: Your OBD2 Data Logging Solution
The CANedge facilitates easy recording of OBD2 output data onto an 8-32 GB SD card. Simply connect it to a vehicle to begin logging. Data can be decoded using free software/APIs and our OBD2 DBC. The CANedge provides a robust and user-friendly solution for OBD2 output data logging.
OBD2 logger intro
CANedge product details
Multi-Frame OBD2 Examples – ISO-TP in Action
All OBD2 data transmission uses the ISO-TP (transport protocol) as per ISO 15765-2. While most examples so far have shown single-frame communication, multi-frame communication is essential for larger datasets. This section illustrates multi-frame communication with examples of OBD2 output data.
Multi-frame OBD2 communication requires flow control frames (see our UDS introduction). 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. Handling flow control is crucial for successful multi-frame OBD2 output data retrieval.
Furthermore, multi-frame OBD2 responses necessitate CAN software and API tools that support ISO-TP, such as the CANedge MF4 decoders. These tools are designed to correctly process multi-frame OBD2 output data.
OBD2-multi-frame-request-message-vehicle-identification-number
Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN), illustrating the structure of multi-frame requests.
Example 1: Retrieving the Vehicle Identification Number (VIN) via OBD2
The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more (see our UDS introduction for details). To retrieve the VIN using OBD2 requests, you use mode 0x09 and PID 0x02. This process demonstrates multi-frame OBD2 output data retrieval.
VIN Vehicle Identification Number OBD2 Example multi-frame
The tester tool sends a Single Frame request containing the PCI field (0x02), request service identifier (0x09), and PID (0x02).
The vehicle responds with a First Frame that includes the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is byte 0x01, indicating the Number Of Data Items (NODI), which is 1 in this case (see ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes represent the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction. This example clearly illustrates multi-frame OBD2 output data for VIN retrieval.
Example 2: OBD2 Multi-PID Request (6x)
External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU will respond with data for supported PIDs (omitting unsupported PIDs from the response), using multiple frames via ISO-TP if necessary. This capability increases the efficiency of OBD2 output data collection.
This efficient method allows for higher frequency data collection but results in signal encoding specific to the request method. This specificity can complicate the use of generic OBD2 DBC files. Therefore, we generally advise against this method in practice. Below is an example trace of a multi-PID request scenario:
Requesting multiple PIDs in one request
The multi-frame response is similar to the VIN example but includes the requested PIDs and their corresponding data. In this example, the PIDs in the response are ordered similarly to the request, which is common but not strictly mandated by ISO 15031-5. While efficient, this method complicates OBD2 output data decoding and standardization.
Decoding this response using generic DBC files is challenging. Hence, we do not recommend this approach for practical data logging unless you are using a tool with built-in support for multi-PID requests. This scenario represents extended multiplexing with added complexity, as DBC files would need to account for the specific payload position of each PID. Generalizing DBC files across vehicles with varying PID support becomes very difficult. Furthermore, managing multiple multi-PID requests via pure DBC manipulations becomes nearly impossible due to the lack of a method to uniquely identify these messages from each other. The complexity of decoding multi-PID OBD2 output data makes it less practical for general use.
Workarounds could involve custom scripts and recording transmit messages from your testing tool. The script could then interpret response messages based on the corresponding request message. However, such approaches are hard to scale and manage. The complexity in handling multi-PID requests emphasizes the challenges in efficiently processing OBD2 output data in such configurations.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval
OBD2 can be used to request 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) will respond with the number of stored DTCs (possibly zero if none are stored), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored. This mode is crucial for accessing fault-related OBD2 output data.
The 2-byte DTC value is typically split into two parts, as defined in ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category,’ and the remaining 14 bits form a 4-digit code (in hexadecimal), as shown in the diagram. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com. Understanding DTCs is key to interpreting diagnostic OBD2 output data.
The example below shows a request to an ECU that has 6 DTCs stored.
Diagram explaining OBD2 DTC decoding and interpretation, illustrating the bit allocation for category and code within a DTC byte.
OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response Example
Use Cases for OBD2 Data Logging
OBD2 data from cars and light trucks has diverse applications across various sectors. The versatility of OBD2 output data makes it valuable for numerous use cases.
Icon representing OBD2 data logging in automotive diagnostics, highlighting data logger applications in vehicle health monitoring.
Vehicle Data Logging for Cars
OBD2 data logging in cars can be used to optimize fuel efficiency, enhance driving habits, test prototype components, and improve insurance risk assessments. Analyzing OBD2 output data provides actionable insights for these applications.
OBD2 data logger details
Icon for real-time OBD2 streaming diagnostics, showcasing applications in live vehicle monitoring and issue detection.
Real-Time Car Diagnostics
OBD2 interfaces enable real-time streaming of human-readable OBD2 data, which is essential for diagnosing vehicle issues promptly and efficiently. Real-time OBD2 output data is crucial for immediate diagnostic feedback.
OBD2 streaming interface details
Icon for OBD2 data logger in predictive maintenance, highlighting the use of logged data for anticipating and preventing vehicle breakdowns.
Predictive Maintenance
Cars and light trucks can be monitored via IoT-enabled OBD2 loggers connected to the cloud to predict and prevent potential breakdowns. This predictive approach leverages OBD2 output data for proactive vehicle maintenance.
Predictive maintenance solutions
Icon for black box CAN logger applications in insurance and warranty, illustrating data logging for event recording and analysis.
Vehicle Black Box Recorders
An OBD2 logger can serve as a ‘black box’ for vehicles or equipment, providing critical data for dispute resolution and in-depth diagnostics. This application of OBD2 output data is invaluable for accident analysis and vehicle monitoring.
CAN bus black box logger details
Do you have a specific OBD2 data logging application in mind? Contact us for expert consultation and support!
Contact us
For further reading, explore our guides section or download the comprehensive ‘Ultimate Guide’ PDF.
Ready to log or stream OBD2 data?
Get your OBD2 data logger today!
Purchase now
Contact us for inquiries
Recommended Resources
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANedge2 – Dual CAN Bus Telematics Dongle
CANEDGE2 – PRO CAN IoT LOGGER
CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN
