Are you looking for a straightforward and practical introduction to OBD2 and CAN bus diagnostics?
This guide provides a comprehensive overview of the On-Board Diagnostics (OBD2) protocol, including the OBD2 connector, OBD2 Parameter IDs (PIDs), and its critical link to the CAN bus network.
Designed as a hands-on introduction, this article will equip you with the knowledge to understand, request, and decode OBD2 data, explore key use cases for data logging, and offer valuable practical tips for using a Can Bus Obd2 Reader effectively.
Discover why this guide has become a leading resource for understanding OBD2 technology.
You can also watch our introductory video on OBD2 above – or download this guide in PDF format.
Article Contents:
Author: Martin Falch (Updated January 2025)
Download this guide as a PDF
What is OBD2?
OBD2, or On-Board Diagnostics version 2, is essentially your car’s internal health monitoring system. It’s a standardized protocol that allows access to diagnostic trouble codes (DTCs) and real-time vehicle data through the OBD2 connector.
You’ve likely already encountered OBD2 in action:
Have you ever seen the malfunction indicator light, often called the “check engine light,” illuminate on your dashboard?
This light is your vehicle signaling that it has detected a problem. When you take your car to a mechanic, they use a CAN bus OBD2 reader to pinpoint the issue.
To perform diagnostics, the mechanic connects the OBD2 reader to the 16-pin OBD2 connector, typically located under the dashboard near the steering wheel. This tool sends ‘OBD2 requests’ to the vehicle’s computer system, and the car responds with ‘OBD2 responses’. These responses can include a wealth of information such as vehicle speed, fuel level, and Diagnostic Trouble Codes (DTCs), enabling faster and more accurate troubleshooting.
Understanding OBD2: On-Board Diagnostics and the Malfunction Indicator Light (MIL) as seen with a scan tool.
Is My Car OBD2 Compatible?
The short answer: Almost certainly!
Nearly all modern non-electric vehicles are equipped with OBD2 systems, and the majority communicate over the CAN bus network. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 compliance. Some may have the connector but not fully support the OBD2 protocol. A key indicator of OBD2 compliance is the vehicle’s year and market of original sale:
Vehicle OBD2 Compliance: Check your vehicle’s region and year of manufacture to determine OBD2 compatibility in EU, US, and CAN markets.
A Brief History of OBD2
The origins of OBD2 trace back to California, where the California Air Resources Board (CARB) mandated OBD systems in all new vehicles starting from 1991 for emissions monitoring.
The OBD2 standard we know today was largely shaped and recommended by the Society of Automotive Engineers (SAE). They standardized Diagnostic Trouble Codes (DTCs) and the physical OBD connector across all vehicle manufacturers through the SAE J1962 standard.
From its Californian inception, the OBD2 standard was progressively implemented worldwide:
- 1996: OBD2 became mandatory in the USA for cars and light trucks.
- 2001: The European Union required OBD2 for gasoline cars.
- 2003: The EU extended the requirement to diesel cars under the EOBD (European On-Board Diagnostics) regulation.
- 2005: OBD2 became mandatory in the US for medium-duty vehicles.
- 2008: US vehicles were required to adopt ISO 15765-4 (CAN) as the foundation for OBD2 communication.
- 2010: OBD2 standardization was completed in the US with mandatory implementation in heavy-duty vehicles.
OBD2 History and Emission Control: A timeline highlighting the evolution of OBD2, EOBD2, and EOBDII in relation to car data and CAN bus integration.
OBD2 History Timeline Overview: A visual representation of the key milestones in the development and standardization of On-Board Diagnostics.
OBD2 Future Trends: Envisioning OBD3 with remote diagnostics, emissions testing, cloud connectivity, and IoT integration for advanced vehicle monitoring.
The Future of OBD2
OBD2 is firmly established in vehicle diagnostics, but its future form is evolving.
Here are key trends shaping the future of OBD2:
Initially designed for emissions control and testing, legislated OBD2 has a different trajectory for electric vehicles. Notably, electric vehicles (EVs) 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, they often use OEM-specific UDS (Unified Diagnostic Services) communication protocols. This generally makes it challenging to access data from EVs unless decoding rules are reverse-engineered. Examples of successful reverse engineering efforts include studies on Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.
The implementation of OBD2 varies, and it has limitations in data richness and lower-layer protocols. In response, modern alternatives like WWH-OBD (World-Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These aim to improve OBD communication by using the UDS protocol as a foundation. For more information on these protocols, refer to our introduction to UDS.
In today’s connected world, manual OBD2 emission tests seem outdated and inefficient.
The proposed solution is OBD3 – integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder to vehicles, similar to those used for bridge tolls. This would allow the car’s Vehicle Identification Number (VIN) and DTCs to be wirelessly transmitted to a central server for automated checks.
Many current devices already facilitate CAN or OBD2 data transfer via WiFi or cellular networks, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.
While this approach offers cost savings and convenience, it also raises political and privacy concerns related to increased surveillance.
Originally designed for stationary emission controls, OBD2 is now extensively used by third parties for real-time data generation via OBD2 dongles, CAN loggers and similar devices. However, the German car industry seeks to limit this access:
“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.”
– Christoph Grote, SVP Electronics, BMW (2017)
The proposal suggests disabling OBD2 functionality during driving, centralizing data collection with manufacturers. This would give manufacturers control over the burgeoning ‘automotive big data’.
Arguments for this change include enhanced security, such as reducing the risk of car hacking, though many view it as a commercially motivated move to control valuable data, as noted by Navixy. The future of this trend remains uncertain, but it could significantly disrupt the market for third-party OBD2 services.
OBD2 Future and Electric Vehicles: Visualizing a future where electric vehicles may restrict data access through the OBD2 connector.
Enhance Your CAN Bus Expertise
Want to become a CAN bus expert?
Access our 12 ‘simple introductions’ in one comprehensive 160+ page PDF:
Download the Ultimate CAN Bus Guide Now
OBD2 Standards
On-board diagnostics, specifically OBD2, is a higher-layer protocol, acting like a language for vehicle communication. CAN, in contrast, is the communication method, analogous to a phone line. This positions OBD2 alongside other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.
The OBD2 standards define specifications for the OBD2 connector, lower-layer protocols, OBD2 Parameter IDs (PIDs), and more.
These standards can be organized using the 7-layer OSI model. The following sections will focus on the most critical aspects of these standards.
In the OSI model framework, you’ll notice that both SAE and ISO standards cover multiple layers. This reflects the standardization of OBD in the US (SAE) and Europe (ISO). Many of these standards are technically very similar, for instance, SAE J1979 is comparable to ISO 15031-5, and SAE J1962 is similar to ISO 15031-3.
OBD2 vs CAN Bus: OSI Model Comparison highlighting ISO 15765 and ISO 11898 standards across 7 layers of communication.
OBD Connector Pinout: Detailed diagram of a Type A OBD2 female socket, also known as Data Link Connector (DLC).
The OBD2 Connector [SAE J1962]
The 16-pin OBD2 connector is the gateway to accessing your vehicle’s data and is defined by the SAE J1962 / ISO 15031-3 standards.
The illustration shows a typical Type A OBD2 pin connector, often referred to as the Data Link Connector (DLC).
Key points about the OBD2 connector:
- It’s generally located near the steering wheel, but may be hidden from immediate view.
- Pin 16 provides battery power, often active even when the ignition is off.
- The OBD2 pinout configuration depends on the communication protocol used.
- CAN bus is the most prevalent lower-layer protocol, typically utilizing pins 6 (CAN-High) and 14 (CAN-Low).
OBD2 Connector Types: A vs. B
In practice, you may encounter both Type A and Type B OBD2 connectors. Type A is standard in cars, while Type B is more common in medium and heavy-duty vehicles.
As shown in the illustration, both types share similar pinouts but differ in power supply outputs: 12V for Type A and 24V for Type B. Baud rates can also vary, with cars typically using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing).
Visually distinguishing them, the Type B OBD2 connector has a distinctive interrupted groove in the center. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, whereas a Type A adapter will not fit into a Type B socket.
OBD2 Connector Type A vs B: A comparative diagram illustrating the differences between Type A and Type B OBD2 connectors as per SAE J1962 for car, van, and truck applications, highlighting 12V and 24V power supplies.
OBD2 vs CAN bus: Diagram contrasting OBD2 and CAN bus protocols in the context of ISO 15765 standards.
OBD2 and CAN Bus [ISO 15765-4]
Since 2008, CAN bus has been mandated as the lower-layer protocol for OBD2 in all vehicles sold in the US, according to ISO 15765.
ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies a set of constraints applied to the CAN standard (ISO 11898).
Specifically, it standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:
- CAN bus bit-rates must be either 250K or 500K.
- CAN IDs can be 11-bit or 29-bit.
- Specific CAN IDs are designated for OBD requests and responses.
- Diagnostic CAN frame data length is fixed at 8 bytes.
- The OBD2 adapter cable must not exceed 5 meters in length.
OBD2 CAN Identifiers (11-bit, 29-bit)
All OBD2 communication is based on a request/response message exchange.
In most passenger vehicles, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, which is used to query all OBD2-compatible ECUs (Electronic Control Units) to check if they have data related to the requested parameter (as per ISO 15765-4). Conversely, CAN IDs ranging from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’ requests directed to specific ECUs, although this is less common.
ECUs respond using 11-bit IDs in the range of 0x7E8 to 0x7EF. The most frequently used response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module) to a lesser extent.
In some vehicles, particularly vans and light, medium, and heavy-duty vehicles, OBD2 communication may utilize extended 29-bit CAN identifiers instead of the standard 11-bit.
For 29-bit identifiers, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Responses from the vehicle will use CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF, typically 0x18DAF110 and 0x18DAF11E. The response ID is also sometimes presented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated as ‘Reserved for ISO 15765-2’ in the J1939-71 standard.
OBD2 Protocol Request and Response Frames: Diagram illustrating the structure of OBD2 request and response frames for transmitting data parameters.
OBD2 vs Proprietary CAN bus: Diagram contrasting OBD2 standard protocol with OEM-specific proprietary CAN bus protocols and data access methods.
OBD2 vs. Proprietary CAN Protocols
It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) operate primarily using OEM-specific CAN protocols, not OBD2. Each Original Equipment Manufacturer (OEM) develops its own proprietary CAN protocols for core vehicle functions. These protocols are often unique to the vehicle brand, model, and year. Typically, this OEM-specific CAN data is undecipherable to external parties unless it’s reverse-engineered.
When you connect a CAN bus data logger to your vehicle’s OBD2 port, you might observe the OEM-specific CAN data, generally broadcast at a high rate of 1000-2000 frames per second. However, many newer vehicles incorporate a ‘gateway’ that restricts access to this raw CAN data through the OBD2 port, allowing only OBD2 communication.
In essence, think of OBD2 as an additional, higher-layer protocol that operates alongside the OEM-specific protocol.
Bit-rate and ID Validation
As previously mentioned, OBD2 can operate at two bit-rates (250K, 500K) and use either 11-bit or 29-bit CAN IDs. This results in four potential combinations. Modern vehicles commonly use 500K bit-rate and 11-bit IDs, but external tools should systematically verify these settings.
ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination, as illustrated in the flowchart below. This method relies on the requirement that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (detailed in the OBD2 PID section) and the fact that incorrect bit-rate transmission will cause CAN error frames.
Newer versions of ISO 15765-4 acknowledge that vehicles may support OBD communication via OBDonUDS rather than OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979) in contrast to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).
To differentiate between OBDonEDS and OBDonUDS protocols, a diagnostic tool may 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 must have ECUs that respond to this DID.
In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is predominantly used in non-EV vehicles today, while WWH-OBD is mainly found in EU trucks and buses.
OBD2 Bit-rate and CAN ID Validation: Flowchart detailing the process for validating OBD2 bit-rate and CAN ID configurations as per ISO 15765-4.
OBD2 Standards: Diagram highlighting the five lower-layer protocols for OBD2 including CAN (ISO 15765), KWP2000, SAE J1850, and ISO 9141.
Five Lower-Layer OBD2 Protocols
Today, CAN (ISO 15765) is the predominant lower-layer protocol for OBD2 in most vehicles.
However, when working with older vehicles (pre-2008), it’s useful to be aware of the other four lower-layer protocols previously used for OBD2. The pinout configurations can also help determine which protocol your vehicle might be using.
- ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and currently the most common standard.
- ISO 14230-4 (KWP2000): Keyword Protocol 2000, frequently used in 2003+ vehicles, particularly in Asia.
- ISO 9141-2: Used in European, Chrysler, and Asian vehicles from 2000-2004.
- SAE J1850 (VPW): Predominantly used in older General Motors (GM) vehicles.
- SAE J1850 (PWM): Mostly used in older Ford vehicles.
Transporting OBD2 Messages via ISO-TP [ISO 15765-2]
All OBD2 data communication over CAN bus is managed by the ISO-TP (ISO 15765-2) transport protocol. This protocol allows for the transmission of data payloads exceeding 8 bytes, which is essential for OBD2 operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. For a deeper understanding, refer to our introduction to UDS.
In many cases, OBD2 data fits within a single CAN frame. ISO 15765-2 specifies the use of ‘Single Frame’ (SF) format for such cases. In a Single Frame, the first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-related communication.
ISO 15765-2 ISO-TP OBD2 Frame Types: Diagram illustrating the different frame types used in ISO-TP for OBD2 communication, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.
The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]
To better understand OBD2 communication over 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 itself. The data section is further structured into Mode, Parameter ID (PID), and data bytes.
OBD2 PIDs OBD-II Message Structure Breakdown: Diagram explaining the structure of an OBD2 message, breaking down into Mode, Parameter ID (PID), Identifier, and Data Bytes.
Example: OBD2 Request/Response
Before detailing each component of an OBD2 message, consider this example of a request and response for ‘Vehicle Speed’.
An external tool sends a request message to the vehicle with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds with CAN ID 0x7E8 and 3 payload bytes, including the Vehicle Speed value in the 4th byte, 0x32 (decimal 50).
By consulting the OBD2 PID decoding rules for PID 0x0D, we find that the physical value is 50 km/h.
Next, we will explore OBD2 modes and PIDs in more detail.
OBD2 Request 7DF Response 7e8: Illustration depicting an OBD2 request frame with ID 7DF and a corresponding response frame with ID 7E8 for the vehicle speed parameter.
OBD2 PID Example Vehicle Speed 0D: Diagram illustrating the OBD2 PID example for Vehicle Speed with PID 0D, and how the data is interpreted to get the speed value.
OBD2 Services Modes: Diagram outlining the 10 OBD2 service modes, including modes for accessing current data, freeze frame data, and clearing DTCs.
The 10 OBD2 Services (Modes)
There are 10 standardized OBD2 diagnostic services, also known as modes. Mode 0x01 is used to access real-time data, while others are designed to handle Diagnostic Trouble Codes (DTCs), such as displaying or clearing them, and accessing freeze frame data.
Vehicles are not required to support all 10 OBD2 modes, and manufacturers may implement additional, OEM-specific modes beyond these standard modes.
In OBD2 messages, the mode is specified in the second byte. In a request message, the mode is directly included (e.g., 0x01), while in a response, 0x40 is added to the mode value (e.g., resulting in 0x41 for a response to mode 0x01).
OBD2 Parameter IDs (PIDs)
Within each OBD2 mode, there are Parameter IDs (PIDs).
For example, mode 0x01 contains approximately 200 standardized PIDs that provide real-time data on parameters like speed, RPM, and fuel level. However, a vehicle does not necessarily support all PIDs within a mode. In practice, most vehicles support only a subset of the available PIDs.
One PID holds a special status in this context.
Specifically, if an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. When this PID is requested, the vehicle ECU responds by indicating which PIDs in the range of 0x01-0x20 it supports. This makes PID 0x00 a fundamental tool for verifying OBD2 compatibility. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining PIDs within mode 0x01.
OBD2 Protocol Request and Response Frames: Diagram detailing OBD2 protocol request and response frames for transmitting PID data parameters.
OBD2 PID Overview Tool: Screenshot of an OBD2 PID overview tool interface, highlighting parameters for service 01.
Tip: OBD2 PID Overview Tool
The appendices of SAE J1979 and ISO 15031-5 contain scaling information for standard OBD2 PIDs, which is essential for converting raw data into physical values, as explained in our CAN bus introduction.
For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is an invaluable resource. It helps you construct OBD2 request frames and dynamically decode OBD2 responses.
Access the OBD2 PID overview tool
How to Log and Decode OBD2 Data
This section provides a practical example of how to log OBD2 data using the CANedge CAN bus data logger.
The CANedge allows you to configure custom CAN frames for transmission, making it suitable for OBD2 logging.
Once configured, the device can be easily connected to your vehicle using our OBD2-DB9 adapter cable.
OBD2 PID Data Logger Request and Response: Diagram illustrating an OBD2 data logger sending a request with ID 7df and receiving a response with ID 7e8.
Validation of OBD2 bit rate test success after sending a CAN frame at 500K.
Reviewing responses to ‘Supported PIDs’ in asammdf software, a tool for MDF4/MF4 file analysis.
#1: Test Bit-rate, IDs & Supported PIDs
As discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a specific vehicle. You can perform these tests using the CANedge as described below (refer to the CANedge Introduction for detailed instructions):
- Transmit a CAN frame at 500K and verify successful transmission (if unsuccessful, try 250K).
- Use the identified bit-rate for all subsequent communication.
- Send multiple ‘Supported PIDs’ requests and analyze the responses.
- Determine whether 11-bit or 29-bit IDs are used based on response IDs.
- Identify supported PIDs based on response data.
We provide plug-and-play configurations to facilitate these tests.
Most non-EV vehicles manufactured in 2008 or later support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.
As shown in the asammdf GUI screenshot, it is common to receive multiple responses to a single OBD request. This is because the 0x7DF request ID is used, which polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are often observed. For subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. It’s also worth noting that the ECM ECU (0x7E8) in this example supports all PIDs supported by other ECUs, suggesting that busload could be reduced by directing subsequent communication specifically to this ECU using ‘Physical Addressing’ CAN ID 0x7E0.
#2: Configure OBD2 PID Requests
Once you’ve identified the OBD2 PIDs supported by your vehicle and the correct bit-rate and CAN IDs, you can configure your transmit list to request the PIDs of interest.
Consider these points when configuring your requests:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses to each request.
- Spacing: Introduce a delay of 300-500 ms between each OBD2 request to prevent overwhelming the ECUs and ensure reliable responses.
- Battery Drain: Use triggers to stop transmissions when the vehicle is inactive to avoid unnecessary ECU wake-up and battery drain.
- Filters: Implement filters to record only OBD2 responses if your vehicle also outputs OEM-specific CAN data, streamlining your data logs.
With these configurations, your device is ready to log raw OBD2 data efficiently.
OBD2 Transmit List Example: Screenshot showing an example transmit list for OBD2 PID requests configured in CANedge.
OBD2 Data Decoded Visual Plot: Screenshot from asammdf showing OBD2 data decoded and visualized as a plot using a CAN bus DBC file.
#3: DBC Decode Raw OBD2 Data
Finally, to analyze and visualize your logged data, you need to decode the raw OBD2 data into human-readable ‘physical values’ like km/h or °C.
The necessary decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, we provide a free OBD2 DBC file that simplifies DBC decoding of raw OBD2 data in most CAN bus software tools.
Decoding OBD2 data is slightly more complex than standard CAN signal decoding because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is not sufficient to determine the signals within the payload uniquely.
To address this, both the CAN ID, OBD2 mode, and OBD2 PID must be considered to identify the signal. This form of multiplexing, known as ‘extended multiplexing‘, can be implemented in DBC files.
CANedge: Your OBD2 Data Logger
The CANedge allows for easy recording of OBD2 data directly to an 8-32 GB SD card. Simply connect it to a vehicle to begin logging and then decode the data using free software/APIs and our OBD2 DBC file.
Learn more about OBD2 logging
Explore CANedge
OBD2 Multi-Frame Examples [ISO-TP]
OBD2 communication, governed by ISO-TP (ISO 15765-2), primarily utilizes single-frame messages. However, multi-frame communication is necessary for larger data sets. This section provides examples of multi-frame OBD2 communication.
Multi-frame OBD2 exchanges require 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 shown 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 Message for VIN: Screenshot illustrating an OBD2 multi-frame request message specifically for retrieving the Vehicle Identification Number (VIN).
Example 1: OBD2 Vehicle Identification Number (VIN)
The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and various other applications (see our UDS introduction for details). To retrieve the VIN using OBD2 requests, use mode 0x09 and PID 0x02:
The testing 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, representing the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for specifics). The subsequent 17 bytes constitute the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction.
Example 2: OBD2 Multi-PID Request (6x)
External diagnostic tools can request up to six mode 0x01 OBD2 PIDs in a single request frame. The ECU will respond with data for the supported PIDs, omitting data for unsupported PIDs in the response, potentially using multiple frames as per ISO-TP.
This method enhances data collection efficiency and frequency, but it also means that signal encoding is specific to the request method. This specificity can complicate the use of generic OBD2 DBC files. We generally advise against using this method in practice. Below is an example trace of such a multi-PID request:
The multi-frame response structure is similar to the VIN example, but the payload includes both the requested PIDs and their corresponding data. In practice, the PIDs in the response are often ordered as requested, though this is not strictly mandated by the ISO 15031-5 standard.
Decoding these responses via generic DBC files is challenging. Therefore, we do not recommend this approach for practical data logging unless you are using a tool specifically designed to support it. This method introduces extended multiplexing challenges, where your DBC file would need to account for the specific payload position of each PID, making it difficult to generalize across different vehicles and PID support levels. Furthermore, managing multiple multi-PID requests becomes complex, as it becomes harder to differentiate messages from each other.
Workarounds might involve custom scripts that interpret response messages in conjunction with request messages, but such approaches are difficult to scale.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs)
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. Responding ECUs will indicate the number of stored DTCs (possibly zero), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than two DTCs are stored.
The 2-byte DTC value is typically structured into two parts, as per ISO 15031-5/ISO 15031-6. The first two bits define the ‘category’, and the remaining 14 bits form a 4-digit hexadecimal code, as shown in the visual. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.
The example below shows a request to an ECU reporting 6 stored DTCs.
OBD2 DTC Diagnostic Trouble Code DBC Interpretation: Diagram illustrating how to interpret and decode OBD2 Diagnostic Trouble Codes (DTCs) using DBC files.
OBD2 Data Logging – Use Case Examples
OBD2 data logging from cars and light trucks has numerous applications:
Vehicle Data Logging
OBD2 data from vehicles can be used to optimize fuel consumption, enhance driving habits, test prototype components, and improve insurance assessments.
Explore OBD2 loggers
Real-time Vehicle Diagnostics
OBD2 interfaces enable real-time streaming of human-readable OBD2 data, facilitating immediate diagnostics of vehicle issues.
Learn about OBD2 streaming
Predictive Maintenance
Monitoring cars and light trucks via IoT-enabled OBD2 loggers in the cloud enables predictive maintenance, helping to foresee and prevent potential breakdowns.
Discover predictive maintenance solutions
Vehicle Black Box Logger
An OBD2 logger can function as a vehicle ‘black box’, providing crucial data for dispute resolution, accident analysis, and enhanced diagnostics.
Learn about CAN bus black box applications
Do you have a specific OBD2 data logging application in mind? Contact us for a free consultation!
Contact Us
For more introductory guides, visit our guides section or download the comprehensive ‘Ultimate Guide’ PDF.
Need to log or stream OBD2 data?
Get your OBD2 data logger today!
Buy Now Contact Us
Recommended Resources
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANEDGE2 – PRO CAN IoT LOGGER
CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN
