Looking for a straightforward and practical introduction to OBD2?
This tutorial provides a comprehensive yet simple explanation of the On-Board Diagnostics (OBD2) protocol. We’ll cover everything from the OBD2 connector and OBD2 Parameter IDs (PIDs) to its connection with the CAN bus system.
This is a hands-on tutorial, designed to teach you how to request and interpret OBD2 data. We’ll also explore key use cases for data logging and offer practical tips to get you started.
Discover why this guide is rapidly becoming the go-to OBD2 tutorial for beginners and experts alike.
You can also watch our introductory OBD2 video above – or download this guide as a PDF.
Article Contents
Author: Martin Falch (Updated January 2025)
Download as PDF
Understanding OBD2: What is it?
OBD2, or On-Board Diagnostics version 2, is essentially your vehicle’s internal health monitoring system. It’s a standardized protocol that enables the extraction of diagnostic trouble codes (DTCs) and real-time vehicle data through the OBD2 port.
Chances are, you’ve already encountered OBD2 in action:
Ever seen the check engine light illuminate on your dashboard?
That’s your car signaling a potential problem. When you take your vehicle to a mechanic, they use an OBD2 scanner to pinpoint the issue.
Mechanics connect an OBD2 reader to the OBD2 16-pin connector, usually located near the steering wheel. This tool sends ‘OBD2 requests’ to your car, and the car responds with ‘OBD2 responses’ containing information like speed, fuel level, or Diagnostic Trouble Codes (DTCs). This process significantly speeds up troubleshooting and repair.
Image alt text: OBD2 system diagram showing malfunction indicator light (MIL) and mechanic using a scan tool for on-board diagnostics.
OBD2 Compatibility: Does Your Car Have It?
Likely, yes!
The vast majority of modern non-electric vehicles are OBD2 compliant and typically operate on the CAN bus network. However, for older vehicles, even if a 16-pin OBD2 connector is present, it might not actually support the OBD2 protocol. A key indicator of OBD2 compliance is the vehicle’s purchase location and year:
Image alt text: Table illustrating OBD2 compliance timelines for US and EU vehicles based on gasoline and diesel models.
A Look at OBD2 History
OBD2’s roots are in California, where the California Air Resources Board (CARB) mandated OBD in all new vehicles starting from 1991 for emissions monitoring.
The Society of Automotive Engineers (SAE) further developed the OBD2 standard, standardizing DTCs and the OBD connector across different manufacturers (SAE J1962).
The OBD2 standard was progressively implemented:
- 1996: OBD2 becomes mandatory in the USA for cars and light trucks.
- 2001: Required in the EU for gasoline vehicles.
- 2003: Mandated in the EU for diesel vehicles as well (EOBD).
- 2005: OBD2 becomes a requirement in the US for medium-duty vehicles.
- 2008: US vehicles are required to use ISO 15765-4 (CAN) as the foundation for OBD2.
- 2010: OBD2 is finally required in US heavy-duty vehicles.
Image alt text: OBD2 history infographic highlighting key milestones in emission control and the evolution of On-Board Diagnostics.
Image alt text: Timeline graphic showing the historical progression of OBD2 standards and adoption in the automotive industry.
Image alt text: Illustration depicting OBD3 future trends including remote diagnostics, emissions testing, cloud connectivity, and IoT integration.
The Future of OBD2
OBD2 is set to remain relevant, but its future form is evolving.
Here are some significant trends to consider:
Originally designed for emissions control and testing, legislated OBD2 has a notable exception: electric vehicles. EVs are not obligated to support OBD2 in any form, and in practice, most modern EVs do not adhere to standard OBD2 requests. Instead, they often utilize OEM-specific UDS communication protocols. This typically makes it challenging to decode data from electric vehicles unless decoding rules have been reverse-engineered. For examples, explore our case studies on electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.
Current OBD2 implementations have limitations in data richness and lower-layer protocols. To address these, 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 deeper insights into these protocols, refer to our introduction to UDS.
In today’s connected automotive landscape, traditional OBD2 testing can seem outdated. Manual emission control checks are both time-consuming and costly.
The proposed solution? OBD3 – integrating telematics into all vehicles.
OBD3 concept involves adding a small radio transponder (similar to those used for bridge tolls) to all cars. This would allow the car’s vehicle identification number (VIN) and DTCs to be wirelessly transmitted via WiFi to a central server for automated checks.
Many current devices already facilitate CAN or OBD2 data transfer via WiFi/cellular, like the CANedge2 WiFi CAN logger or the CANedge3 3G/4G CAN logger.
While this offers convenience and cost savings, it raises political and privacy concerns related to potential surveillance.
Originally designed for stationary emission controls, OBD2 is now widely used by third parties to generate real-time data through OBD2 dongles, CAN loggers and similar devices. However, the German car industry is pushing for changes:
OBD was intended for servicing 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,” according to Christoph Grote, SVP Electronics at BMW (2017).
The proposal suggests disabling OBD2 functionality during driving and instead centralizing data collection on manufacturer servers. This would give manufacturers control over ‘automotive big data’.
Arguments for this change often cite security benefits (e.g., reducing the risk of car hacking), though many perceive it as a commercially motivated move https://www.navixy.com/blog/obd-trackers-what-future-awaits/. Whether this trend will materialize and disrupt the market for third-party OBD2 services remains to be seen.
Image alt text: Graphic depicting the removal of an OBD2 connector from an electric vehicle, representing the challenge of data access in EVs.
Enhance Your CAN Bus Knowledge
Want to become a CAN bus expert?
Access our 12 ‘simple introductions’ in one comprehensive 160+ page PDF:
Download Now
OBD2 Standards Explained
On-board diagnostics, or OBD2, is a higher-layer protocol (like a language), while CAN is a communication method (like a phone line). This makes OBD2 similar to other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.
Specifically, OBD2 standards define the OBD2 connector, lower-layer protocols, OBD2 Parameter IDs (PIDs), and more.
These standards can be viewed in a 7-layer OSI model. In the following sections, we’ll focus on the most critical aspects.
In the OSI model overview, you’ll notice that both SAE and ISO standards cover multiple layers. This generally reflects OBD standards developed in the USA (SAE) and EU (ISO). Several standards are technically very similar, for instance, SAE J1979 versus ISO 15031-5, and SAE J1962 versus ISO 15031-3.
Image alt text: OSI 7-layer model diagram comparing OBD2 and CAN Bus protocols, highlighting ISO 15765 and ISO 11898 standards.
Image alt text: OBD2 connector pinout diagram for a Type A socket, detailing pin assignments for a female Data Link Connector (DLC).
The OBD2 Connector [SAE J1962]
The 16-pin OBD2 connector provides easy access to your vehicle’s data and is defined by the SAE J1962 / ISO 15031-3 standard.
The illustration shows a Type A OBD2 pin connector (also known as a Data Link Connector, or DLC).
Key points to remember:
- The connector is usually near your steering wheel but might be hidden.
- Pin 16 provides battery power, often even when the ignition is off.
- The OBD2 pinout varies depending on the communication protocol.
- CAN bus is the most common lower-layer protocol, so pins 6 (CAN-H) and 14 (CAN-L) are typically connected.
OBD2 Connector Types: A vs. B
In practice, you may encounter both Type A and Type B OBD2 connectors. Type A is generally found in cars, while Type B is 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 vary, with cars typically using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing).
Type B OBD2 connectors are distinguished by an interrupted groove in the middle. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and B sockets, but a Type A adapter will not fit into a Type B socket.
Image alt text: OBD2 Connector Type A vs B diagram comparing SAE J1962 standards for car, van, and truck applications with 12V and 24V power differences.
Image alt text: Diagram illustrating the relationship between OBD2 and CAN bus protocols under the ISO15765 standard.
OBD2 and CAN Bus [ISO 15765-4]
Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US-sold vehicles, according to ISO 15765.
ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies restrictions applied to the CAN standard (ISO 11898).
It standardizes the CAN interface for test 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/responses.
- Diagnostic CAN frame data length is fixed at 8 bytes.
- OBD2 adapter cable length must not exceed 5 meters.
OBD2 CAN Identifiers (11-bit, 29-bit)
OBD2 communication always involves request/response message pairs.
Most cars use 11-bit CAN IDs for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, which broadcasts a request to all OBD2-compatible ECUs to report data for the requested parameter (as per ISO 15765-4). CAN IDs 0x7E0-0x7E7, in contrast, are used for ‘Physical Addressing’ requests to specific ECUs (less common).
ECUs can respond with 11-bit IDs in the range 0x7E8-0x7EF. The most frequent response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module).
In some vehicles, particularly vans and medium/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 represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is marked as ‘Reserved for ISO 15765-2’ in the J1939-71 standard.
Image alt text: OBD2 protocol request and response frames diagram illustrating PID data parameters exchange.
Image alt text: OBD2 vs proprietary CAN bus diagram illustrating differences in data access and standardization.
OBD2 vs. Proprietary CAN Protocols
It’s important to note that your vehicle’s electronic control units (ECUs) do not rely on OBD2 for their primary functions. Instead, each Original Equipment Manufacturer (OEM) implements its own proprietary CAN protocols for vehicle operation. These protocols are often unique to the vehicle brand, model, and year. Unless you are the OEM, interpreting this proprietary CAN data is typically not possible without reverse engineering.
Connecting a CAN bus data logger to your car’s OBD2 port may allow you to see OEM-specific CAN data, usually broadcast at 1000-2000 frames/second. However, many newer vehicles use a ‘gateway’ that restricts access to this CAN data, enabling only OBD2 communication through the OBD2 connector.
In essence, think of OBD2 as an ‘additional’ higher-layer protocol operating alongside the OEM-specific protocol.
Bit-rate and ID Validation
As discussed, OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in 4 potential combinations. Modern cars commonly use 500K and 11-bit IDs, but external tools should systematically verify this.
ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination, illustrated in the flowchart. This method uses the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section for details) and that incorrect bit-rate transmissions will cause CAN error frames.
Newer versions of ISO 15765-4 consider that vehicles might 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 protocol, a test 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 currently used in most non-EV cars, while WWH-OBD is mainly used in EU trucks and buses.
Image alt text: OBD2 bit-rate and CAN ID validation flowchart based on ISO 15765-4 standards.
Image alt text: OBD2 standards diagram illustrating five protocols: CAN (ISO 15765), KWP 2000, SAE J1850, and ISO 9141.
Five Lower-Layer OBD2 Protocols
While CAN bus (ISO 15765) is now the dominant lower-layer protocol for OBD2 in most vehicles, especially post-2008, older cars may use different protocols. Understanding these can be helpful, particularly when working with pre-2008 models. The pinouts can often indicate which protocol your car might be using.
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used in modern vehicles.
- ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, especially in Asia.
- ISO 9141-2: Used in EU, Chrysler, and Asian vehicles around 2000-2004.
- SAE J1850 (VPW): Predominantly used in older GM vehicles.
- SAE J1850 (PWM): Primarily used in older Ford vehicles.
Transporting OBD2 Messages via ISO-TP [ISO 15765-2]
All OBD2 data communication over CAN bus uses a transport protocol called ISO-TP (ISO 15765-2). This protocol allows for transmitting payloads larger than 8 bytes, which is necessary for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 manages segmentation, flow control, and reassembly of these larger messages. For a more detailed explanation, see our introduction to UDS.
However, much of the OBD2 data fits 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 OBD2-related communication.
Image alt text: ISO 15765-2 ISO-TP frame types diagram used in OBD2 communication.
The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]
To better understand OBD2 communication on CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. Simplified, an OBD2 message consists of an identifier, a data length indicator (PCI field), and the actual data. The data is further broken down into Mode, Parameter ID (PID), and data bytes.
Image alt text: OBD2 PIDs message structure breakdown diagram explaining raw mode, PID, and data bytes.
Example: OBD2 Request/Response
Consider this example of requesting and receiving ‘Vehicle Speed’ data.
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 (which is 50 in decimal).
By consulting the OBD2 PID decoding rules for PID 0x0D, we can determine that the physical value is 50 km/h.
Next, we will delve into OBD2 modes and PIDs in more detail.
Image alt text: OBD2 request response diagram showing 7DF request and 7E8 response for vehicle speed retrieval.
Image alt text: OBD2 PID example diagram specifically for Vehicle Speed, PID 0D.
Image alt text: OBD2 services modes diagram illustrating 10 PID modes for diagnostic services like current data, freeze frame, and clearing DTCs.
The 10 OBD2 Services (aka Modes)
OBD2 includes 10 diagnostic services or modes. Mode 0x01 is used to access current real-time data, while other modes are used to display or clear diagnostic trouble codes (DTCs) or show freeze frame data.
Vehicles are not required to support all OBD2 modes and may also support non-standard, OEM-specific OBD2 modes.
In OBD2 messages, the mode is located in the second byte. In a request, the mode is included directly (e.g., 0x01), while in the response, 0x40 is added to the mode value (e.g., resulting in 0x41).
OBD2 Parameter IDs (PIDs)
Within each OBD2 mode 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 need to support all PIDs within a mode. In practice, most vehicles only support a subset of these.
One PID is particularly important:
If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID, the vehicle ECU indicates whether it supports PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.
Image alt text: OBD2 protocol request and response frames diagram, focusing on PID data parameters exchange.
Image alt text: Screenshot of an OBD2 PID overview tool interface showing service 01 functionalities.
Tip: OBD2 PID Overview Tool
The appendices of SAE J1979 and ISO 15031-5 contain scaling information for standard OBD2 PIDs, allowing you to convert the raw data into physical values (as explained in our CAN bus introduction).
If you need to look up a mode 0x01 PID, our OBD2 PID overview tool is a valuable resource. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.
OBD2 PID overview tool
How to Log and Decode OBD2 Data
This section provides a practical example of logging OBD2 data using the CANedge CAN bus data logger.
The CANedge allows configuration of 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.
Image alt text: OBD2 data logger request diagram showing PID 7df 7e8 communication flow.
Image alt text: Screenshot showing successful bit rate validation for OBD2 testing.
Image alt text: Screenshot from asammdf showing OBD validation PID test responses for supported PIDs.
#1: Test Bit-rate, IDs & Supported PIDs
As previously discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a specific vehicle. You can test this using the CANedge as described below (refer to the CANedge Intro for detailed instructions):
- Send a CAN frame at 500K and verify successful transmission (if unsuccessful, try 250K).
- Use the identified bit-rate for subsequent communication.
- Send multiple ‘Supported PIDs’ requests and review the responses.
- Determine 11-bit vs. 29-bit IDs based on response IDs.
- Identify supported PIDs based on response data.
We offer plug-and-play configurations to perform 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, multiple responses to a single OBD request are common. This is because we use the 0x7DF request ID, which polls all ECUs for responses. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses are often received for this PID in particular. As demonstrated, subsequent ‘Supported PIDs’ requests receive fewer ECU responses. Note that the ECM ECU (0x7E8) supports all PIDs supported by other ECUs in this example. This means busload can be reduced by specifically requesting responses only from this ECU by switching to the ‘Physical Addressing’ CAN ID 0x7E0 for future communication.
#2: Configure OBD2 PID Requests
Having identified the OBD2 PIDs supported by your vehicle and the correct bit-rate and CAN IDs, you can now configure your transmit list with the PIDs of interest.
Consider these points:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses per request.
- Spacing: Add 300-500 ms intervals between OBD2 requests. Overly frequent requests may cause ECUs to stop responding.
- Battery Drain: Use triggers to stop transmissions when the vehicle is inactive to prevent ‘waking up’ ECUs and draining the battery.
- Filters: Apply filters to record only OBD2 responses, especially if your vehicle also outputs OEM-specific CAN data.
Once configured, your device is ready to log raw OBD2 data.
Image alt text: Screenshot illustrating an example transmit list of CANedge OBD2 PID requests.
Image alt text: Screenshot from asammdf showing DBC decoded and visualized OBD2 data plotted on a graph.
#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’ (like km/h or °C).
The necessary decoding information is available in ISO 15031-5/SAE J1979 and 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 decoding regular 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 signals within the payload uniquely.
To solve this, you must use the CAN ID, OBD2 mode, and OBD2 PID to identify the signal. This form of multiplexing is known as ‘extended multiplexing,’ which can be implemented in formats like DBC files.
CANedge: OBD2 Data Logger
The CANedge makes it easy to record OBD2 data to an 8-32 GB SD card. Simply connect it to a vehicle to start logging and decode the data using free software/APIs and our OBD2 DBC file.
OBD2 logger intro
CANedge product page
OBD2 Multi-Frame Examples [ISO-TP]
All OBD2 data communication utilizes the ISO-TP (transport protocol) as per ISO 15765-2. While many examples so far have shown single-frame communication, multi-frame communication is also important. This section provides examples of multi-frame scenarios.
Multi-frame OBD2 communication requires flow control frames (see our UDS introduction). In practice, this can be achieved by transmitting a static flow control frame approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.
Furthermore, multi-frame OBD2 responses necessitate CAN software/API tools that support ISO-TP, such as the CANedge MF4 decoders.
Image alt text: Screenshot illustrating an OBD2 multi-frame request message 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 more (refer to our UDS introduction for more details). To retrieve the VIN from a vehicle using OBD2 requests, use mode 0x09 and PID 0x02:
The tester 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 containing the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is the byte 0x01, which is the Number Of Data Items (NODI), in this case 1 (consult 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.
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 supported PIDs (omitting unsupported ones), potentially across multiple frames as per ISO-TP.
This feature allows for higher frequency and efficiency in data collection. However, it also means that signal encoding is specific to your request method, making the use of generic OBD2 DBC files challenging for such applications. We generally advise against this method in practice. Below is an example trace of what this might look like:
Image alt text: Screenshot of an example trace illustrating multiple PID requests in one OBD2 request.
The multi-frame response is similar to the VIN example, but the payload includes both the requested PIDs and their corresponding data. In this example, the PIDs are ordered similarly to the request, which is common but not strictly mandated by the ISO 15031-5 standard.
Decoding this response using generic DBC files is very difficult. Therefore, we do not recommend using this approach for practical data logging unless you are using a tool with built-in support for this specific method. This scenario represents extended multiplexing with multiple instances throughout the payload. Your DBC file would need to account for the specific payload position of each PID, making it difficult to generalize across vehicles with varying supported PIDs. Handling this via DBC manipulation becomes nearly impossible if sending multiple multi-PID requests, as you would lack a method to uniquely identify these messages from each other.
Workarounds could involve custom scripts and recording transmit messages from your testing tool. The script could then interpret the response message in conjunction with the request message. However, such approaches are generally difficult to 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 target ECU(s) will respond with the number of stored DTCs (possibly zero), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored.
The 2-byte DTC value is typically divided into two parts, as per ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category,’ and the remaining 14 bits define a 4-digit code (displayed in hexadecimal), 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 with 6 stored DTCs.
Image alt text: OBD2 DTC Diagnostic Trouble Code DBC interpretation example diagram.
OBD2 Data Logging – Use Case Examples
OBD2 data from cars and light trucks has numerous applications:
Logging Data from Cars
OBD2 data logging in cars can be used for fuel efficiency improvement, driving behavior analysis, prototype component testing, and insurance telematics.
OBD2 logger product link
Real-time Car Diagnostics
OBD2 interfaces enable real-time streaming of human-readable OBD2 data, useful for diagnosing vehicle issues in real-time.
OBD2 streaming interface link
Predictive Maintenance
Cars and light trucks can be monitored via IoT OBD2 loggers in the cloud to predict and prevent breakdowns through predictive maintenance.
Predictive maintenance solution link
Vehicle Blackbox Logger
An OBD2 logger can function as a ‘black box’ for vehicles or equipment, providing crucial data for dispute resolution or in-depth diagnostics.
CAN bus blackbox logger link
Do you have an OBD2 data logging use case? Contact us for a free consultation!
Contact Us
For more introductory guides, visit our guides section or download the ‘Ultimate Guide’ PDF.
Need to log or stream OBD2 data?
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
CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN
