Are you looking to dive deep into vehicle diagnostics and understand the data your car is broadcasting? A crucial aspect of modern vehicle systems is the OBD2 protocol, and at its heart are Obd2 Parameters (also known as PIDs). This guide provides a practical and in-depth introduction to On-Board Diagnostics II (OBD2), focusing specifically on understanding and utilizing OBD2 parameters for effective vehicle analysis and repair.
This is more than just an introduction; it’s your pathway to mastering OBD2 data. We’ll explore everything from the OBD2 connector and parameter IDs (PIDs) to their link with the Controller Area Network (CAN bus). You’ll learn how to request and decode OBD2 data, discover key use cases for data logging, and gain practical tips for working with OBD2 systems.
Consider this your definitive resource, designed to elevate your understanding of OBD2 and its parameters to an expert level.
You can also watch our OBD2 intro video above – or get the PDF
Article Contents:
Author: Martin Falch (Updated January 2025)
Download as PDF
Decoding OBD2: What Are OBD2 Parameters?
OBD2, or On-Board Diagnostics II, is essentially your vehicle’s internal health monitoring system. It’s a standardized protocol that allows access to a wealth of diagnostic information, primarily through OBD2 parameters, and also Diagnostic Trouble Codes (DTCs), via the standardized OBD2 connector.
You’ve likely encountered OBD2 in action without even realizing it:
Ever seen the check engine light illuminate on your dashboard?
That’s your car communicating a problem through the OBD2 system. When you take your vehicle to a mechanic, they use an OBD2 scanner to pinpoint the issue. This scanner connects to the OBD2 16-pin connector, typically located near the steering wheel. The scanner sends ‘OBD2 requests’ to the vehicle, and the car responds with ‘OBD2 responses’. These responses contain valuable OBD2 parameters such as speed, engine RPM, fuel level, and also DTCs. This data allows mechanics to diagnose problems efficiently and accurately. Understanding OBD2 parameters is key to understanding your vehicle’s health.
OBD2 Compatibility: Is Your Car OBD2 Compliant?
The good news is, for most modern vehicles, the answer is yes!
Nearly all non-electric vehicles manufactured in recent decades are OBD2 compliant, and a significant portion of these utilize the CAN bus communication protocol. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 compliance. Some may have the connector but lack full OBD2 functionality. A reliable way to check for compliance is by considering the vehicle’s manufacturing origin and year of purchase:
A Brief History of OBD2 and OBD2 Parameters
The story of OBD2 begins in California, driven by the California Air Resources Board (CARB). In response to growing concerns about vehicle emissions, CARB mandated OBD systems in all new vehicles sold in California from 1991 onwards, primarily for emission control.
The Society of Automotive Engineers (SAE) then played a crucial role by recommending the OBD2 standard. This standardization included defining Diagnostic Trouble Codes (DTCs) and, importantly, the OBD connector itself, ensuring uniformity across different manufacturers (SAE J1962). This standardization was a major step forward in making OBD2 parameters universally accessible.
The OBD2 standard was progressively implemented globally:
- 1996: OBD2 became mandatory in the USA for all cars and light trucks.
- 2001: The European Union mandated OBD2 for gasoline cars.
- 2003: The EU extended the mandate to include diesel cars (EOBD – European On-Board Diagnostics).
- 2005: OBD2 was required in the US for medium-duty vehicles.
- 2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication, further standardizing the way OBD2 parameters were accessed.
- 2010: OBD2 compliance became mandatory in US heavy-duty vehicles.
The Future of OBD2 and Accessing OBD2 Parameters
OBD2 is firmly entrenched in automotive diagnostics, but its future is evolving. Here’s a look at key trends shaping OBD2 and the accessibility of OBD2 parameters:
Originally, legislated OBD2 was primarily focused on emissions control and testing. Interestingly, this has led to a situation where electric vehicles (EVs) are not obligated to support OBD2 in its traditional form. In practice, most modern EVs do not support standard OBD2 requests for OBD2 parameters. Instead, they often utilize OEM-specific UDS (Unified Diagnostic Services) communication protocols. This makes retrieving data, including OBD2 parameters or their equivalents, from EVs significantly more challenging unless the decoding rules are reverse-engineered. However, there are successful cases of reverse engineering, as seen in studies for electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.
Recognizing the limitations of current OBD2 implementations, particularly regarding data richness and lower-layer protocols, alternatives are emerging. WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are modern approaches designed to enhance OBD communication by using the UDS protocol as a base. These advancements aim to streamline access to a wider range of OBD2 parameters and diagnostic information in the future.
In our increasingly connected world, manual OBD2 emission checks seem outdated. The solution being explored 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 for wireless transmission of the car’s vehicle identification number (VIN) and DTCs via WiFi to a central server for automated emissions checks. Devices like the CANedge2 WiFi CAN logger and CANedge3 3G/4G CAN logger already facilitate CAN or OBD2 data transfer via WiFi/cellular networks. While this offers convenience and cost savings, it raises political and privacy concerns related to surveillance.
Initially designed for stationary emission controls, OBD2’s role has expanded significantly. Today, third parties widely use OBD2 to access real-time OBD2 parameters through OBD2 dongles, CAN loggers and other devices. However, the German car industry is pushing to limit this access. Manufacturers argue that OBD2 was intended for repair shop servicing, not for creating a data-driven economy based on third-party access to OBD2 parameters. Their proposal involves disabling OBD2 functionality during driving and centralizing data collection with manufacturers. This shift would give manufacturers control over ‘automotive big data’. While security concerns, like reducing the risk of car hacking, are cited, many view this as a commercial strategy. Whether this trend gains traction remains to be seen, but it could significantly disrupt the market for third-party OBD2 services and access to OBD2 parameters.
Enhance Your Knowledge with Our ‘Ultimate CAN Guide’
Ready to become a CAN bus expert and deepen your understanding of OBD2 parameters?
Our comprehensive ‘Ultimate CAN Guide’ combines 12 ‘simple intros’ into a 160+ page PDF, providing a wealth of knowledge.
Download now
OBD2 Standards: The Foundation of OBD2 Parameters
On-board diagnostics, or OBD2, functions as a higher-layer protocol – think of it as a language spoken by your car. CAN (Controller Area Network) is the communication method, akin to a phone line. This makes OBD2 comparable to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000. All these protocols, including OBD2, rely on standardized methods to transmit and interpret data, including crucial OBD2 parameters.
OBD2 standards are crucial for defining the OBD2 connector, the underlying communication protocols, and the OBD2 parameter IDs (PIDs) themselves, as well as other essential elements.
These standards can be organized using the 7-layer OSI model, and we’ll focus on the most vital aspects in the following sections. You’ll notice that both SAE (primarily US standards) and ISO (international standards) cover several layers. Many standards are technically very similar, such as SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3. Understanding these standards is key to correctly interpreting OBD2 parameters.
The OBD2 Connector [SAE J1962 / ISO 15031-3]: Your Access Point to OBD2 Parameters
The 16-pin OBD2 connector is your physical interface for accessing vehicle data and, crucially, OBD2 parameters. It’s specified by the SAE J1962 / ISO 15031-3 standards. This standard ensures that diagnostic tools can reliably interface with a wide range of vehicles to retrieve OBD2 parameters.
The illustration above shows a typical Type A OBD2 pin connector (sometimes referred to as the Data Link Connector, or DLC).
Key points to remember about the OBD2 connector:
- It’s usually located near the steering wheel, though it may be hidden from plain sight.
- Pin 16 provides battery power, often even when the ignition is off, allowing for continuous monitoring of certain OBD2 parameters in some applications.
- The OBD2 pinout configuration varies depending on the communication protocol used by the vehicle.
- CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are commonly connected for accessing OBD2 parameters.
OBD2 Connector Types: A vs. B
In practice, you might encounter both Type A and Type B OBD2 connectors. Type A is typically found in cars and light-duty vehicles, while Type B is more common in medium and heavy-duty vehicles.
As shown in the illustration, both types share similar OBD2 parameter 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).
A key physical difference is that the Type B OBD2 connector has an interrupted groove in the middle. This means a Type B OBD2 adapter cable will be compatible with both Type A and Type B sockets, while a Type A connector will only fit into a Type A socket. Choosing the correct adapter is crucial for reliable access to OBD2 parameters.
OBD2 and CAN Bus [ISO 15765-4]: Communicating OBD2 Parameters
Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all vehicles sold in the US, as defined by ISO 15765. This means that accessing OBD2 parameters in most modern vehicles involves CAN bus communication.
ISO 15765-4 (also known as Diagnostics over CAN, or DoCAN) specifies a set of constraints applied to the CAN standard (ISO 11898) for diagnostic purposes.
It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:
- The CAN bus bit rate must be either 250K or 500K.
- CAN IDs can be 11-bit or 29-bit.
- Specific CAN IDs are reserved for OBD requests and responses related to OBD2 parameters.
- Diagnostic CAN frame data length is fixed at 8 bytes.
- The OBD2 adapter cable must be a maximum of 5 meters long.
OBD2 CAN Identifiers (11-bit, 29-bit) for Requesting OBD2 Parameters
All OBD2 communication operates on a request/response principle. To retrieve OBD2 parameters, a diagnostic tool sends a request, and the vehicle responds with the requested data.
In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is used to broadcast a request to all OBD2-compatible Electronic Control Units (ECUs). This ID essentially asks all ECUs if they have data to report for the requested OBD2 parameter (as per ISO 15765-4). In contrast, CAN IDs 0x7E0-0x7E7 are used for ‘Physical Addressing’, allowing requests to be sent to specific ECUs (less commonly used for general OBD2 parameter 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 IDs are crucial for identifying responses containing requested OBD2 parameters.
In some vehicles, particularly vans and light/medium/heavy-duty vehicles, OBD2 communication may utilize extended 29-bit CAN identifiers instead of 11-bit IDs.
The ‘Functional Addressing’ CAN ID in this case is 0x18DB33F1.
Responses in 29-bit CAN ID implementations are typically found with IDs ranging from 0x18DAF100 to 0x18DAF1FF (commonly 18DAF110 and 18DAF11E). This response ID is sometimes represented 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 different CAN ID formats is essential for correctly interpreting OBD2 parameters from various vehicle types.
OBD2 vs. Proprietary CAN Protocols: Beyond Standard OBD2 Parameters
It’s important to understand that your vehicle’s Electronic Control Units (ECUs) function primarily using OEM-specific CAN protocols, not OBD2. Each Original Equipment Manufacturer (OEM) implements their own proprietary CAN protocols for core vehicle operations. These protocols can be unique to the vehicle brand, model, and year. Accessing and interpreting this proprietary data is typically not possible without OEM-specific tools or extensive reverse engineering. These proprietary protocols often contain a much richer set of parameters than standard OBD2 parameters.
When you connect a CAN bus data logger to your car’s OBD2 connector, you might observe OEM-specific CAN data being broadcast, usually at high rates (1000-2000 frames/second). However, many newer vehicles incorporate a ‘gateway’ module that restricts access to this OEM-specific CAN data through the OBD2 port, allowing only standardized OBD2 communication and OBD2 parameter access.
In essence, think of OBD2 as a standardized ‘overlay’ protocol that operates alongside the OEM-specific protocol. It provides a common interface for accessing a defined set of OBD2 parameters for diagnostics and emissions monitoring, while the OEM-specific protocol handles the vehicle’s core control and communication functions with a broader range of data.
Bit Rate and ID Validation for OBD2 Parameter Access
As mentioned, OBD2 communication can use two bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations. Modern cars most commonly use 500K and 11-bit IDs. Diagnostic tools should systematically validate these parameters to ensure correct communication and access to OBD2 parameters.
ISO 15765-4 provides a recommended initialization sequence to determine the correct combination. This method relies on the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section for details). Sending data with an incorrect bit rate will result in CAN error frames, which can be detected to identify the correct bit rate.
Newer versions of ISO 15765-4 acknowledge that vehicles may support OBD communication via OBDonUDS rather than OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).
To test for OBDonEDS vs. OBDonUDS, 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 should have ECUs that respond to this DID.
In practice, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most current non-EV cars, while WWH-OBD is primarily used in EU trucks and buses. Understanding these nuances ensures correct protocol selection for accessing OBD2 parameters.
Five Lower-Layer OBD2 Protocols: Beyond CAN for OBD2 Parameter Retrieval
While CAN (ISO 15765) is the dominant lower-layer protocol for OBD2 today, particularly in vehicles manufactured after 2008, older vehicles may utilize other protocols. If you’re working with older cars, understanding these alternative protocols is useful, and their pinouts can help identify which protocol a vehicle might be using.
The five lower-layer OBD2 protocols include:
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now the most widely used protocol for accessing OBD2 parameters.
- ISO14230-4 (KWP2000): Keyword Protocol 2000 was common in 2003+ vehicles, especially in Asia.
- ISO 9141-2: Used in EU, Chrysler, and Asian cars in the 2000-2004 period.
- SAE J1850 (VPW – Variable Pulse Width): Primarily used in older GM vehicles.
- SAE J1850 (PWM – Pulse Width Modulation): Primarily used in older Ford vehicles.
Transporting OBD2 Messages via ISO-TP [ISO 15765-2]: Handling Multi-Frame OBD2 Parameters
All OBD2 data, including OBD2 parameters, is transmitted over CAN bus using the ISO-TP (ISO 15765-2) transport protocol. ISO-TP enables communication of data payloads larger than the 8-byte limit of a standard CAN frame. This is essential in OBD2 for transmitting data like the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), which often exceed 8 bytes. ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages.
However, many OBD2 parameter values can fit within a single CAN frame. In these cases, ISO 15765-2 specifies the use of a ‘Single Frame’ (SF). The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for the OBD2 communication related to OBD2 parameters.
The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]: Structure of OBD2 Parameters
To better understand OBD2 communication on CAN, let’s examine the structure of a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message consists of a CAN identifier, a data length indicator (PCI field), and the data payload itself. The data payload is further structured into Mode, parameter ID (PID), and data bytes, which ultimately contain the OBD2 parameter value.
Example: OBD2 Request/Response for a Specific OBD2 Parameter
Consider a practical example: requesting the ‘Vehicle Speed’ OBD2 parameter.
A diagnostic tool sends a request message to the vehicle with CAN ID 0x7DF and a 2-byte payload: Mode 0x01 and PID 0x0D. The vehicle responds using CAN ID 0x7E8 with a 3-byte payload, including the Vehicle Speed value in the 4th byte of the original CAN frame (which becomes the first byte of the OBD2 payload in this response), 0x32 (50 in decimal).
By consulting the decoding rules for OBD2 PID 0x0D, we can determine that the physical value is 50 km/h. This example illustrates the fundamental request-response mechanism for accessing OBD2 parameters.
The 10 OBD2 Services (Modes) and Their Role in Accessing OBD2 Parameters
There are 10 standardized OBD2 diagnostic services, often referred to as modes. Mode 0x01 is used to retrieve current, real-time OBD2 parameters, while other modes are used for accessing and clearing Diagnostic Trouble Codes (DTCs), retrieving freeze frame data, and other diagnostic functions.
It’s important to note that vehicles are not required to support all 10 OBD2 modes. They may also implement OEM-specific modes beyond these 10 standard modes, which can provide access to additional, non-standard OBD2 parameters.
In OBD2 messages, the mode is indicated in the second byte of the payload. In a request message, the mode is included directly (e.g., 0x01). In a response message, 0x40 is added to the requested mode (e.g., a response to mode 0x01 will have mode 0x41 in the response).
OBD2 Parameter IDs (PIDs): The Key to Specific Vehicle Data
Within each OBD2 mode, there are Parameter IDs (PIDs). OBD2 parameters are identified and accessed using these PIDs.
For example, Mode 0x01 contains approximately 200 standardized PIDs that provide real-time data on various vehicle parameters, such as speed, RPM, engine temperature, and fuel level. However, a vehicle doesn’t necessarily support all PIDs within a given mode. In reality, most vehicles only support a subset of the standardized OBD2 PIDs. The specific OBD2 parameters available will vary by vehicle make, model, and year.
One PID holds a special significance: PID 0x00 in Mode 0x01.
If an emissions-related ECU supports any OBD2 services, it must support Mode 0x01 PID 0x00. When requested, this PID returns a bitmask indicating which PIDs in the range 0x01-0x20 are supported by the ECU. This makes PID 0x00 a crucial tool for determining basic OBD2 compatibility and discovering which OBD2 parameters are available. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for subsequent ranges of Mode 0x01 PIDs (0x21-0x40, 0x41-0x60, and so on).
Tip: OBD2 PID Overview Tool for Exploring OBD2 Parameters
The appendices of SAE J1979 and ISO 15031-5 contain scaling and decoding information for standard OBD2 parameters (PIDs). This information allows you to convert the raw data bytes into meaningful physical values, as explained in our CAN bus introduction.
If you need to quickly look up a Mode 0x01 PID and understand its meaning and scaling, our OBD2 PID overview tool is a valuable resource. This tool assists in constructing OBD2 request frames and dynamically decoding OBD2 responses, making it easier to work with OBD2 parameters.
OBD2 PID overview tool
Practical Guide: How to Log and Decode OBD2 Parameter Data
This section provides a practical example of logging OBD2 parameter data using the CANedge CAN bus data logger. The CANedge is configurable to transmit custom CAN frames, making it suitable for OBD2 logging and OBD2 parameter acquisition.
Once configured, the CANedge can be easily connected to your vehicle’s OBD2 port using our OBD2-DB9 adapter cable.
The responses to ‘Supported PIDs’ can be reviewed in asammdf
Step #1: Validate Bit Rate, CAN IDs, and Supported OBD2 Parameters
As discussed earlier, ISO 15765-4 outlines how to determine the correct bit rate and CAN IDs for a specific vehicle. You can use the CANedge to perform these tests as follows (refer to the CANedge Intro for detailed instructions):
- Bit Rate Test: Transmit a CAN frame at 500K. Check if the transmission is successful. If not, try 250K.
- Protocol Selection: Use the identified bit rate for all subsequent OBD2 communication.
- Supported PIDs Discovery: Send multiple ‘Supported PIDs’ requests (Mode 0x01 PID 0x00 and subsequent PID range requests) and analyze the responses.
- CAN ID Length Determination: Based on the response CAN IDs, determine whether the vehicle uses 11-bit or 29-bit CAN IDs for OBD2.
- Supported OBD2 Parameter Identification: Analyze the response data to identify the specific OBD2 parameters supported by the vehicle’s ECUs.
We provide pre-configured CANedge configurations to simplify these initial tests.
Most non-EV vehicles manufactured from 2008 onwards typically support 40-80 OBD2 parameters using a 500K bit rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.
The asammdf GUI screenshot illustrates a common scenario where multiple ECUs respond to a single OBD request. This occurs because using the 0x7DF request ID broadcasts the request to all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, multiple responses to this PID are common. As you progress to requesting ‘Supported PIDs’ for higher PID ranges, 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 ‘Physical Addressing’ with CAN ID 0x7E0).
Step #2: Configure OBD2 PID Requests for Desired OBD2 Parameters
Once you’ve identified the OBD2 parameters supported by your vehicle, along with the correct bit rate and CAN IDs, you can configure your CANedge to request the specific PIDs you are interested in logging.
Consider these factors when configuring your PID requests:
- CAN IDs for Targeted Requests: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0 for ECM) to avoid receiving multiple responses for each request and reduce 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 in your CANedge configuration to stop transmitting requests when the vehicle is inactive. This prevents unnecessary battery drain by avoiding ‘wake-up’ signals to ECUs when the vehicle is off.
- Data Filtering: Configure filters on the CANedge to record only OBD2 responses. This is particularly useful if your vehicle also broadcasts OEM-specific CAN data on the OBD2 port, allowing you to isolate and focus on OBD2 parameters.
With these configurations in place, your CANedge is ready to efficiently log raw OBD2 parameter data.
An example list of CANedge OBD2 PID requests
asammdf lets you DBC decode and visualize OBD2 data
Step #3: DBC Decoding of Raw OBD2 Parameter Data
To effectively analyze and visualize your logged OBD2 parameter data, you need to decode the raw CAN data into human-readable ‘physical values’ (e.g., km/h, °C).
The necessary decoding information is defined in ISO 15031-5/SAE J1979 and is also available on resources like Wikipedia. For convenience, we provide a free OBD2 DBC file. This DBC file simplifies the process of DBC decoding raw OBD2 data within most CAN bus software tools.
Decoding OBD2 parameters is slightly more complex than decoding standard CAN signals because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is insufficient to identify the specific signal encoded in the payload.
To overcome this, you must use a combination of the CAN ID, OBD2 mode, and OBD2 PID to uniquely identify each signal. This technique is known as ‘extended multiplexing‘. It can be implemented in DBC files and is supported by tools like asammdf.
CANedge: Your Dedicated OBD2 Parameter Data Logger
The CANedge provides a streamlined solution for recording OBD2 parameter data directly to an SD card (8-32 GB). Simply connect the CANedge to your vehicle’s OBD2 port to start logging. You can then decode and analyze the recorded data using free software and APIs, along with our OBD2 DBC file.
OBD2 logger intro CANedge
OBD2 Multi-Frame Examples [ISO-TP]: Handling Complex OBD2 Parameter Responses
All OBD2 communication, including the transmission of OBD2 parameters, relies on the ISO-TP (transport protocol) as specified in ISO 15765-2. While many examples involve single-frame communication, some OBD2 responses, particularly for requests like VIN or DTCs, require multi-frame communication.
Multi-frame OBD2 communication necessitates the use of flow control frames. In practice, a static flow control frame can be transmitted approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.
Furthermore, processing multi-frame OBD2 responses, and extracting OBD2 parameters from them, requires CAN software and API tools that support ISO-TP, such as the CANedge MF4 decoders.
Example 1: Retrieving Vehicle Identification Number (VIN) as an OBD2 Parameter
The Vehicle Identification Number (VIN) is often essential for telematics, diagnostics, and other applications. You can retrieve the VIN using OBD2 requests with Mode 0x09 and PID 0x02. While technically the VIN isn’t a real-time OBD2 parameter in the typical sense, it is accessed using the same OBD2 protocol mechanisms.
The diagnostic 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 indicating the PCI, total length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is the byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case. The subsequent 17 bytes contain the VIN, which can be converted from HEX to ASCII.
Example 2: Multi-PID Request (6x) for Efficient OBD2 Parameter Acquisition
OBD2 allows diagnostic tools to request up to 6 Mode 0x01 OBD2 parameters in a single request frame. The ECU will respond with data for the supported PIDs (omitting data for unsupported PIDs), potentially using multi-frame responses if needed (via ISO-TP).
This feature offers a more efficient way to collect OBD2 parameters at higher frequencies. However, the signal encoding becomes specific to the request method, making the use of generic OBD2 DBC files more challenging. We generally don’t recommend this method for most practical applications. Here’s an example trace:
The multi-frame response structure resembles the VIN example but includes both the requested PIDs and their corresponding data within the payload. The PIDs in the example are ordered similarly to the request order, which is common but not strictly mandated by the ISO 15031-5 standard.
Decoding these multi-PID responses using generic DBC files is complex. Therefore, we advise against this approach for general data logging unless you are using tools specifically designed for this purpose. You’d be dealing with a complex form of extended multiplexing, making it difficult to create generalized DBC files applicable across different vehicles with varying supported OBD2 parameters. Managing multiple such multi-PID requests further complicates DBC-based decoding, as uniquely identifying messages becomes challenging. Custom scripts and recording request messages alongside responses could offer workarounds, but these approaches are difficult to scale and manage.
Example 3: Diagnostic Trouble Codes (DTCs) as Diagnostic OBD2 Parameters
You can use OBD2 Mode 0x03, ‘Show stored Diagnostic Trouble Codes’, to request emissions-related DTCs. No PID is included in the request. The targeted ECU(s) will respond with the number of stored DTCs (possibly zero if no DTCs are present). Each DTC is represented by 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored. While DTCs aren’t real-time OBD2 parameters, they are a crucial part of OBD2 diagnostics.
The 2-byte DTC value is structured according to ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’, and the remaining 14 bits form a 4-digit hexadecimal code. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.
The example below shows a response from an ECU with 6 stored DTCs.
Use Cases for OBD2 Parameter Data Logging
OBD2 parameter data logging from cars and light trucks has numerous applications:
Logging Car Data and OBD2 Parameters
OBD2 data can be used for fuel efficiency analysis, driver behavior improvement, prototype part testing, and insurance telematics. Accessing OBD2 parameters provides valuable insights for these applications.
obd2 logger
Real-Time Vehicle Diagnostics Using OBD2 Parameters
OBD2 interfaces facilitate real-time streaming of OBD2 parameters in human-readable format, enabling efficient vehicle diagnostics and troubleshooting.
obd2 streaming
Predictive Maintenance Based on OBD2 Parameters
Cloud-connected IoT OBD2 loggers enable remote vehicle monitoring using OBD2 parameters to predict potential breakdowns and facilitate proactive maintenance.
predictive maintenance
Vehicle Black Box Recording of OBD2 Parameters
An OBD2 logger can function as a ‘black box’ for vehicles or equipment, recording OBD2 parameters and other data for accident analysis, dispute resolution, or diagnostic purposes.
can bus blackbox
Do you have an OBD2 data logging use case in mind? Contact us for a free consultation!
Contact us
Explore our guides section for more introductory articles, or download the ‘Ultimate Guide’ PDF for in-depth knowledge.
Need to log or stream OBD2 data and OBD2 parameters?
Get your OBD2 data logger today!
Buy now Contact us
Recommended for you
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANEDGE2 – PRO CAN IoT LOGGER
[
