Need a simple, practical introduction to OBD2?
In this guide, we’ll explore the On-Board Diagnostics, specifically OBD2, a crucial protocol in modern vehicles. We’ll cover everything from the OBD2 connector and OBD2 parameter IDs (PIDs) to its link with the CAN bus system.
This is designed as a practical introduction, so you’ll learn how to request and understand OBD2 data, discover key applications for data logging, and get useful tips for working with OBD2.
Discover why this has become a leading OBD2 resource.
You can also watch our OBD2 introductory video above – or download the PDF guide
Understanding OBD2: On-Board Diagnostic System
OBD2 is essentially your car’s built-in health monitor. It’s a standardized system that allows access to valuable information, including diagnostic trouble codes (DTCs) and real-time vehicle data, all through the OBD2 connector.
You’ve likely already encountered OBD2 in action:
Have you ever seen the check engine light illuminate on your dashboard?
That light is your vehicle signaling a potential problem. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the issue.
To do this, the mechanic connects an OBD2 reader to the OBD2 16-pin connector, typically located near the steering wheel. This tool sends ‘OBD2 requests’ to the car’s computer, and the car responds with ‘OBD2 responses’. These responses can include data like speed, fuel level, and Diagnostic Trouble Codes (DTCs). This system makes troubleshooting car problems much faster and more efficient.
Understanding the Malfunction Indicator Light (MIL) on your dashboard, a key component of the OBD2 system.
OBD2 Compatibility: Does Your Car Have It?
In most cases, yes!
The vast majority of modern, non-electric cars are equipped with OBD2 systems, and many utilize the CAN bus communication protocol. For older vehicles, even if you spot a 16-pin OBD2 connector, it might not actually support the OBD2 standard. A reliable way to check compliance is based on where and when your car was originally purchased:
A visual guide to determine OBD2 compliance based on vehicle purchase location and year.
A Look at OBD2 History
The story of OBD2 begins in California. The California Air Resources Board (CARB) mandated OBD systems in all new cars starting from 1991 to monitor and control vehicle emissions.
The Society of Automotive Engineers (SAE) then recommended the OBD2 standard, which standardized DTCs and the OBD connector across all vehicle manufacturers (SAE J1962).
From there, OBD2 adoption grew progressively:
- 1996: OBD2 became mandatory in the USA for cars and light trucks.
- 2001: Required in the EU for gasoline cars.
- 2003: Required in the EU for diesel cars as well (known as EOBD in Europe).
- 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.
- 2010: Finally, OBD2 became mandatory for heavy-duty vehicles in the US.
The historical progression of OBD2, highlighting its origins in emission control and expansion across vehicle types.
A timeline visually summarizing the key milestones in OBD2 history and its global adoption.
A forward-looking view of OBD3 and the potential for remote diagnostics, emissions testing, and cloud integration.
The Future of OBD2
OBD2 is firmly established, but its future is evolving.
Here are some significant trends to consider:
Initially designed for emissions monitoring and testing, legislated OBD2 has a specific focus. Consequently, electric vehicles (EVs) are not obligated to support OBD2 in any form. In fact, most modern EVs do not support standard OBD2 requests. Instead, they often use manufacturer-specific UDS communication protocols. This typically makes accessing data from EVs challenging, except when decoding methods have been reverse-engineered. See our case studies for electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs for examples.
OBD2 implementations vary and have limitations regarding data richness and underlying communication protocols. To address these, newer standards 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. Learn more about these protocols in our introduction to UDS.
In today’s connected world, traditional OBD2 testing can seem outdated. Manual emission checks are time-consuming and costly.
The proposed solution? OBD3 – integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder (similar to those used for toll roads) to every car. This would allow the car’s vehicle identification number (VIN) and DTCs to be transmitted wirelessly via WiFi to a central server for automated checks.
Many current devices already enable CAN or OBD2 data transfer over WiFi/cellular networks. Examples include the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.
While this offers cost savings and convenience, it also raises political and privacy concerns related to surveillance.
The OBD2 protocol was originally intended for use during stationary emission control checks.
However, today OBD2 is widely used by third parties to access real-time vehicle data through OBD2 dongles, CAN loggers and similar devices. Interestingly, the German car industry is looking to restrict this access:
OBD was designed for car 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 and instead centralizing data collection on manufacturer servers. This would give manufacturers control over the valuable ‘automotive big data’.
The justification often cites security concerns, such as reducing the risk of car hacking, although many perceive this as a commercially motivated strategy. Whether this trend gains traction remains to be seen, but it has the potential to significantly disrupt the market for third-party OBD2 services.
The potential future where electric vehicles and manufacturers may limit or control access to vehicle data through the OBD2 port.
Enhance Your CAN Bus Knowledge
Want to become a CAN bus expert?
Get our 12 ‘simple introductions’ compiled into one comprehensive 160+ page PDF guide:
Download now
OBD2 Standards Explained
On-board diagnostics, OBD2, operates as a higher-layer protocol, much like a language, while CAN bus serves as the communication method, similar to a telephone line. This places OBD2 in the same category as other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.
Specifically, OBD2 standards define the OBD2 connector, the underlying communication protocols, OBD2 parameter IDs (PIDs), and more.
These standards can be visualized using a 7-layer OSI model. In the following sections, we will focus on the most important standards.
Looking at the OSI model, you’ll notice that several layers are addressed by both SAE and ISO standards. This reflects the development of OBD standards 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.
An OSI model diagram comparing OBD2 and CAN bus standards, highlighting relevant ISO and SAE specifications.
Pinout diagram for a Type A OBD2 connector socket (female), also known as a Data Link Connector (DLC).
The OBD2 Connector: SAE J1962 Standard
The 16-pin OBD2 connector is your gateway to accessing vehicle data. It is standardized under SAE J1962 / ISO 15031-3.
The illustration shows a Type A OBD2 pin connector (sometimes called a Data Link Connector, or DLC).
Key points to remember about the OBD2 connector:
- It’s generally located near your steering wheel, but can sometimes be hidden.
- Pin 16 provides battery power, often even when the ignition is off.
- The OBD2 pinout varies depending on the communication protocol used.
- CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically connected.
OBD2 Connector Types: A vs. B
You might encounter both Type A and Type B OBD2 connectors. Type A is typically found in cars, while Type B is more common in medium and heavy-duty vehicles.
As shown in the illustration, both types have similar OBD2 pinouts but differ in power supply outputs (12V for Type A and 24V for Type B). Baud rates can also differ; cars usually use 500K, while heavy-duty vehicles often use 250K (with increasing support for 500K).
To visually differentiate them, Type B OBD2 connectors have an 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.
Comparison of OBD2 Connector Type A and Type B, highlighting differences in voltage and application.
Diagram illustrating the relationship between OBD2 and CAN bus within the ISO15765 framework.
OBD2 and CAN Bus: ISO 15765-4 Standard
Since 2008, CAN bus has been the mandatory 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 or DoCAN) specifies a set of constraints on the CAN standard (ISO 11898).
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.
- CAN IDs can be 11-bit or 29-bit.
- Specific CAN IDs are designated for OBD requests and responses.
- Diagnostic CAN frame data length must be 8 bytes.
- The OBD2 adapter cable must be no longer than 5 meters.
OBD2 CAN Identifiers: 11-bit and 29-bit
All OBD2 communication involves a request-response message exchange.
Most cars use 11-bit CAN IDs for OBD2 communication. The ‘Functional Addressing’ ID here is 0x7DF, used to query all OBD2-compatible ECUs to see if they have data for the requested parameter (as per ISO 15765-4). In contrast, CAN IDs 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests to specific ECUs, although this is less common.
ECUs can respond using 11-bit IDs ranging from 0x7E8 to 0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module), and to some extent 0x7E9 (TCM, Transmission Control Module).
In some vehicles, particularly vans and light, medium, and heavy-duty vehicles, OBD2 communication may use extended 29-bit CAN identifiers instead of 11-bit IDs.
Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Vehicle responses will use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is sometimes also presented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is marked as ‘Reserved for ISO 15765-2’ in the J1939-71 standard.
Illustration of OBD2 protocol request and response frames, showing the structure of data parameters and PIDs.
Diagram contrasting OBD2 standard CAN bus communication with proprietary OEM-specific CAN protocols.
OBD2 vs. Proprietary CAN Protocols
It’s important to understand that your car’s electronic control units (ECUs) do not depend on OBD2 for their core functions. Instead, each Original Equipment Manufacturer (OEM) implements their own proprietary CAN protocols for vehicle operation. These proprietary CAN protocols can be unique to a vehicle brand, model, and year. Unless you are the OEM, interpreting this proprietary data is usually not possible, unless you can reverse engineer it.
If you connect a CAN bus data logger to your vehicle’s OBD2 connector, you might observe the OEM-specific CAN data, typically broadcast at a rate of 1000-2000 frames per second. However, many newer vehicles use a ‘gateway’ that blocks access to this raw CAN data through the OBD2 port, only allowing OBD2 communication.
In essence, think of OBD2 as an ‘additional’ higher-layer protocol that runs alongside the OEM-specific protocol.
Bit-rate and ID Validation
As mentioned, OBD2 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, but diagnostic tools should systematically verify this.
ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination. This process relies on the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section for details) and that using an incorrect bit-rate will cause CAN error frames.
Newer versions of ISO 15765-4 acknowledge that vehicles 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), as opposed to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2), it’s important to be aware of these distinctions.
To differentiate between OBDonEDS and 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 predominantly used in non-EV cars today, while WWH-OBD is primarily used in EU trucks and buses.
Flowchart illustrating the process of OBD2 bit-rate and CAN ID validation according to ISO 15765-4.
Overview of the five lower-layer protocols used in OBD2, including CAN, KWP2000, SAE J1850, and ISO9141.
Five Lower-Layer OBD2 Protocols
While CAN bus is now the dominant lower-layer protocol for OBD2 as per ISO 15765, especially in cars manufactured since 2008, older vehicles might utilize other protocols. Knowing these protocols and their corresponding pinouts can be helpful when working with older cars.
The five main lower-layer OBD2 protocols include:
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and now the most common protocol.
- ISO14230-4 (KWP2000): Keyword Protocol 2000, frequently used in cars from 2003 onwards, particularly in Asia.
- ISO 9141-2: Used in European, Chrysler, and Asian cars in the early 2000s (2000-2004).
- SAE J1850 (VPW): Primarily used in older General Motors (GM) vehicles.
- SAE J1850 (PWM): Primarily used in older Ford vehicles.
Transporting OBD2 Messages with ISO-TP: ISO 15765-2
All OBD2 data transmitted over CAN bus uses a transport protocol called ISO-TP (ISO 15765-2). This protocol enables the transmission of data payloads larger than the 8-byte limit of a standard CAN frame. This is essential in OBD2 for tasks like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 provides mechanisms for segmentation, flow control, and reassembly of these larger messages. For more details, refer to our introduction to UDS.
However, much of the time, OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of ‘Single Frame’ (SF) messages. In a Single Frame, the first data byte (known as the PCI field) indicates the payload length (excluding padding), leaving 7 bytes available for OBD2-related communication.
Diagram illustrating different ISO-TP frame types used for OBD2 communication, including Single Frame and Multi-Frame messages.
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 simple terms, an OBD2 message includes an identifier, a data length indicator (PCI field), and the actual data. The data itself is structured into a Mode, a parameter ID (PID), and data bytes.
Breakdown of an OBD2 message structure, showing the arrangement of Mode, PID, Identifier, and Data Bytes within a CAN frame.
Example: OBD2 Request and Response
Before diving into the details of each part of the OBD2 message, consider this example request and response for the ‘Vehicle Speed’ parameter.
An external diagnostic tool sends a request message to the car with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds with a message via CAN ID 0x7E8 and 3 payload bytes, including the Vehicle Speed value in the 4th byte, 0x32 (which is 50 in decimal).
By consulting the decoding rules for OBD2 PID 0x0D, we can determine that the physical value is 50 km/h.
Next, we’ll explore OBD2 modes and PIDs in more detail.
Example of an OBD2 request (ID 7DF) and response (ID 7E8) for vehicle speed, illustrating the data exchange process.
Detailed example of OBD2 PID 0x0D (Vehicle Speed), showing the request, response, and data interpretation.
Overview of the 10 OBD2 diagnostic services (modes), including current data, freeze frame, and DTC clearing.
The 10 OBD2 Services (Modes)
There are 10 standardized OBD2 diagnostic services, also referred to as modes. Mode 0x01 is used to access current real-time data, while other modes are used to retrieve and clear diagnostic trouble codes (DTCs) or access freeze frame data.
Vehicles are not required to support all 10 OBD2 modes, and manufacturers may also implement additional, non-standardized modes (OEM-specific OBD2 modes).
In OBD2 messages, the mode is indicated 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 (e.g., a response to mode 0x01 will start with 0x41).
OBD2 Parameter IDs (PIDs)
Within each OBD2 mode, there are Parameter IDs (PIDs).
For instance, mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on parameters such as speed, RPM, and fuel level. However, a vehicle doesn’t have to support every PID within a mode. In practice, most vehicles only support a limited subset of available PIDs.
One PID is particularly important:
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 0x01-0x20 it supports. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for subsequent ranges of mode 0x01 PIDs.
(Repeated image) Illustration of OBD2 protocol request and response frames, highlighting PID and data parameters.
Screenshot of an OBD2 PID overview tool, showcasing service 01 and available parameters.
Tip: OBD2 PID Overview Tool
The appendices of SAE J1979 and ISO 15031-5 contain scaling information for standard OBD2 PIDs, which is crucial for converting raw data into meaningful physical values (as explained in our CAN bus introduction).
If you need to look up details for a mode 0x01 PID, our OBD2 PID overview tool is a valuable resource. It can help you construct OBD2 request frames and dynamically decode OBD2 responses.
OBD2 PID overview tool
How to Log and Decode OBD2 Data
This section provides a practical guide on 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.
Diagram illustrating OBD2 PID data logging with request and response CAN IDs 7DF and 7E8.
Screenshot showing bit-rate validation in an OBD2 setup.
Screenshot from asammdf software showing OBD2 supported PIDs test responses.
#1: Test Bit-rate, IDs & Supported PIDs
As discussed, ISO 15765-4 outlines how to determine the correct bit-rate and IDs for a specific vehicle. You can use the CANedge to perform these tests (see the CANedge Introduction for detailed instructions):
- Send a CAN frame at 500K and check for 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 the response IDs.
- Identify supported PIDs based on the response data.
We offer plug-and-play configurations to facilitate these tests.
Most non-EV cars 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’s common to receive multiple responses to a single OBD request. This is because we use the 0x7DF request ID, which broadcasts the request to all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, there are often numerous responses to this particular PID. As you can see, subsequent ‘Supported PIDs’ requests receive fewer responses, as fewer ECUs support those PID ranges. Note that the ECM ECU (0x7E8) in this example supports all the PIDs supported by other ECUs. Therefore, you could reduce bus load by directing subsequent requests only to this ECU using ‘Physical Addressing’ CAN ID 0x7E0.
#2: Configure OBD2 PID Requests
Now that you know which OBD2 PIDs your vehicle supports and the correct bit-rate and CAN IDs to use, you can configure your transmit list with the PIDs you want to log.
Consider these points when configuring your PID requests:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses to each request.
- Spacing: Add a delay of 300-500 ms between each OBD2 request. Sending requests too rapidly may cause ECUs to stop responding.
- Battery Drain: Use triggers to stop transmissions when the vehicle is inactive to prevent unnecessary battery drain by ‘waking up’ ECUs.
- Filters: Apply filters to record only OBD2 responses if your vehicle also outputs OEM-specific CAN data, to keep your logs clean and focused.
Once configured, your device is ready to log raw OBD2 data!
Example of a CANedge OBD2 PID request transmit list configuration.
Visualization of decoded OBD2 data in asammdf, 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 ‘physical values’ (e.g., km/h or °C).
The necessary decoding information can be found 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 somewhat more complex than decoding regular CAN signals because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is not enough to uniquely identify the signals within the payload.
To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID together to identify each signal. This form of multiplexing is known as ‘extended multiplexing‘, and it can be implemented in formats like DBC files.
CANedge: Your OBD2 Data Logger
The CANedge makes it easy to record OBD2 data directly to an 8-32 GB SD card. Simply connect it to your car or truck to start logging. You can then decode the data using free software and APIs and our OBD2 DBC file.
OBD2 logger intro
CANedge product details
OBD2 Multi-Frame Examples: ISO-TP in Action
All OBD2 data communication relies on the ISO-TP (transport protocol) as defined by ISO 15765-2. While many examples discussed so far involve single-frame communication, this section provides examples of multi-frame communication scenarios.
Multi-frame OBD2 communication requires flow control frames (see our UDS introduction for more details). In practice, you can often achieve this by transmitting a static flow control frame approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.
Analyzing multi-frame OBD2 responses requires CAN software or API tools that support ISO-TP, such as the CANedge MF4 decoders.
Example of an OBD2 multi-frame request message for retrieving the Vehicle Identification Number (VIN).
Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval
The Vehicle Identification Number (VIN) is often essential for telematics, diagnostics, and other applications (see our introduction to UDS for more information). To retrieve the VIN from a vehicle using OBD2 requests, you use mode 0x09 and PID 0x02:
The diagnostic tool sends a Single Frame request with 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 the byte 0x01, representing the Number Of Data Items (NODI), which is 1 in this case (see ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes contain the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction.
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 should respond with data for all supported PIDs (omitting data for unsupported PIDs) and use multi-frame responses if necessary, as per ISO-TP.
This feature allows for more efficient and higher-frequency data collection. However, it also means that the signal encoding is specific to your request method, which can make using generic OBD2 DBC files challenging for such use cases. We generally do not recommend using this method in practice due to these complexities. Below is an example trace of what this communication might look like:
The multi-frame response is similar to the VIN example, but with the added complexity that the payload includes the requested PIDs themselves, as well as the data for each PID. Note that in this example, the PIDs are ordered in the response similarly to their order in the request, which is common but not strictly mandated by the ISO 15031-5 standard.
Decoding such responses using generic DBC files is very difficult. Therefore, we generally advise against this approach for practical data logging, unless you are using a tool specifically designed to handle multi-PID requests. Effectively, you are dealing with extended multiplexing, but with multiple instances of it throughout the payload. Furthermore, your DBC file would need to account for the specific payload position of each PID, making it very hard to create a generalized DBC that works across different vehicles with varying supported PIDs. This becomes even more challenging if you send multiple multi-PID requests, as you will lack a method to uniquely identify these messages from each other.
Possible workarounds include using custom scripts and also recording the transmit messages from your testing tool. The script could then interpret the response message in relation to the corresponding request message. However, such approaches are generally complex to manage at scale.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs)
You can use OBD2 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 DTCs currently stored (which could be zero if there are no DTCs), with each DTC occupying 2 data bytes. Consequently, multi-frame responses are necessary when more than two DTCs are stored.
The 2-byte DTC value is typically structured into two parts, as defined by ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’ of the DTC, and the remaining 14 bits represent a 4-digit code (displayed in hexadecimal), as shown in the visual. Decoded DTC values can be looked up using various OBD2 DTC lookup tools, such as repairpal.com.
The example below shows a request to an ECU that has 6 DTCs stored.
Example of OBD2 DTC decoding and interpretation, showing the structure of the 2-byte DTC code.
OBD2 Data Logging: Use Case Examples
OBD2 data from cars and light trucks has numerous applications:
Logging Car Data
OBD2 data logging in cars can be used for various purposes, such as reducing fuel consumption, improving driving habits, testing prototype components, and insurance-related applications.
OBD2 logger product
Real-Time Car Diagnostics
OBD2 interfaces enable real-time streaming of human-readable vehicle data, useful for diagnosing vehicle issues as they occur.
OBD2 streaming solution
Predictive Maintenance
Monitoring cars and light trucks via IoT-connected OBD2 loggers in the cloud allows for predictive maintenance, helping to prevent breakdowns before they happen.
Predictive maintenance applications
Vehicle Black Box Logger
An OBD2 logger can function as a ‘black box’ for vehicles or equipment, providing valuable data for dispute resolution, warranty claims, and detailed diagnostics after incidents.
CAN bus black box logger
Do you have an OBD2 data logging use case? Contact us for a free consultation!
Contact us
For more introductory guides, visit our tutorials section – or download our comprehensive ‘Ultimate Guide’ PDF.
Need to log or stream OBD2 data?
Get your OBD2 data logger today!
Buy now
Contact us for inquiries
Recommended for you
OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA
CANEDGE2 – PRO CAN IoT LOGGER
CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN
