Need a straightforward, practical introduction to the Can Bus Obd2 Connector?
This guide provides a comprehensive overview of the CAN bus OBD2 connector, a critical interface for modern vehicle diagnostics. We’ll explore the OBD2 protocol, its connector, Parameter IDs (PIDs), and delve into its intricate link with the Controller Area Network (CAN bus).
This is designed as a hands-on introduction, so you’ll learn not just the theory but also how to request and interpret OBD2 data, understand key applications, and gain practical tips for using the CAN bus OBD2 connector effectively.
Discover why this is quickly becoming a go-to resource for understanding the CAN bus OBD2 connector.
You can also watch our introductory video on OBD2 above – or download our comprehensive PDF guide on CAN bus
Understanding the CAN Bus OBD2 Connector
The CAN bus OBD2 connector is your gateway to your vehicle’s internal diagnostic system. OBD2 (On-Board Diagnostics II) is a standardized protocol that enables access to diagnostic trouble codes (DTCs) and real-time vehicle data through a universal connector. This connector is the physical interface through which diagnostic tools communicate with your car’s computer system, often utilizing the robust CAN bus network.
You’ve likely encountered the OBD2 system without realizing it. Remember the “check engine” light on your dashboard?
That light is your car signaling a problem. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the issue.
This process begins by connecting the OBD2 reader to the 16-pin OBD2 connector, usually located near the steering wheel. This connector, often referred to as the CAN bus OBD2 connector due to its common use of CAN bus for communication, allows the diagnostic tool to send ‘OBD2 requests’ to the vehicle. The car, in turn, responds with ‘OBD2 responses’, which can include vital data such as speed, fuel levels, and Diagnostic Trouble Codes (DTCs). This streamlined communication via the CAN bus OBD2 connector is crucial for efficient troubleshooting and repair.
Understanding the Malfunction Indicator Light (MIL) and OBD2 diagnostics.
Is My Car Equipped with a CAN Bus OBD2 Connector?
The answer is likely yes!
The vast majority of modern non-electric vehicles are equipped with OBD2 systems, and many of these utilize the CAN bus for communication. However, with older vehicles, even if you find a 16-pin OBD2 connector, it might not necessarily support the OBD2 protocol. To confirm OBD2 compliance, especially concerning the CAN bus OBD2 connector, consider the vehicle’s origin and purchase date:
Compliance timeline for OBD2 implementation in vehicles across different regions.
A Brief History of OBD2 and the CAN Bus Connector
OBD2’s journey began in California, driven by the California Air Resources Board (CARB). In 1991, CARB mandated OBD systems in all new vehicles sold in California to monitor and control emissions.
The Society of Automotive Engineers (SAE) played a pivotal role in standardizing OBD2. They recommended the protocol and standardized both DTCs and the OBD connector itself through SAE J1962, ensuring uniformity across different vehicle manufacturers. This standardization was crucial for the widespread adoption and effectiveness of the CAN bus OBD2 connector system.
The OBD2 standard, and consequently the CAN bus OBD2 connector, was implemented gradually:
- 1996: OBD2 became mandatory in the USA for cars and light trucks.
- 2001: The EU mandated OBD2 for gasoline cars.
- 2003: The EU extended the mandate to diesel cars (EOBD).
- 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, solidifying the CAN bus OBD2 connector’s role.
- 2010: OBD2 became mandatory for heavy-duty vehicles in the US.
Historical progression of OBD2 implementation for emission control and diagnostics.
Timeline illustrating the evolution of OBD2 and on-board diagnostics.
Future trends in OBD, including remote diagnostics and integration with IoT.
The Future of OBD2 and the CAN Bus OBD2 Connector
OBD2 is firmly established, but its future form is evolving.
Here are key trends shaping the future of OBD2 and the CAN bus OBD2 connector:
Originally designed for emissions control and testing, legislated OBD2 has limitations, especially with electric vehicles. Interestingly, electric vehicles aren’t mandated to support OBD2 in any form. Most modern EVs do not support standard OBD2 requests and instead use OEM-specific UDS communication. This makes accessing data from EVs challenging, except when decoding rules are reverse-engineered. Our case studies on electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs, provide more insights.
Today, OBD2 implementations vary, facing limitations in data richness and lower-layer protocols. Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging to enhance OBD communication using the UDS protocol. Learn more in our introduction to UDS.
In our connected world, manual OBD2 emission checks 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/cellular, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.
While convenient and cost-saving, OBD3 raises political challenges due to surveillance concerns.
Originally intended for stationary emission controls, OBD2 is now widely used by third parties for real-time data generation via OBD2 dongles and CAN loggers. However, the German car industry aims to restrict this, as highlighted by Christoph Grote, SVP Electronics at BMW in 2017:
“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.”
The proposal suggests disabling OBD2 functionality during driving, centralizing data collection with manufacturers, effectively giving them control over ‘automotive big data’.
Arguments for this shift include security improvements, such as reducing the risk of car hacking, though many view it as a commercial strategy. Whether this trend will materialize and disrupt the OBD2 third-party service market remains to be seen.
The evolving landscape of OBD2 in electric vehicles and data access.
Enhance Your CAN Bus Expertise
Looking to master CAN bus technology?
Our comprehensive ‘Ultimate CAN Guide’ delivers 12 accessible introductions in a detailed 160+ page PDF:
Download now
OBD2 Standards and the CAN Bus OBD2 Connector
On-board diagnostics, OBD2, operates as a higher-layer protocol, much like a language. CAN bus is the communication method, analogous to a telephone line. This places OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.
Specifically, OBD2 standards define the CAN bus OBD2 connector, lower-layer protocols, OBD2 Parameter IDs (PIDs), and more.
These standards can be visualized using a 7-layer OSI model. Notably, both SAE and ISO standards cover multiple layers, reflecting OBD standards in the USA (SAE) and EU (ISO). Many standards are technically very similar, for instance, SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.
OSI model illustrating the relationship between OBD2 and CAN Bus standards.
Pinout diagram for a Type A OBD2 connector socket.
SAE J1962: The OBD2 Connector Standard
The 16-pin OBD2 connector, standardized under SAE J1962 and ISO 15031-3, is your primary interface for accessing vehicle data. This CAN bus OBD2 connector simplifies data retrieval from your vehicle.
The illustration shows a Type A OBD2 pin connector, also known as the Data Link Connector (DLC).
Key features of the CAN bus OBD2 connector include:
- Location near the steering wheel, though it may sometimes be concealed.
- Pin 16 provides battery power, often even when the ignition is off.
- OBD2 pinout configuration varies based 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 for CAN communication via the OBD2 connector.
OBD2 Connector Types: A vs. B
You may encounter both Type A and Type B OBD2 connectors. Type A is commonly found in cars, while Type B is typical in medium and heavy-duty vehicles.
While both types share similar OBD2 pinouts, they differ in power supply outputs (12V for Type A and 24V for Type B). Baud rates can also vary, with cars usually using 500K and heavy-duty vehicles often using 250K (with increasing support for 500K).
Visually, a Type B OBD2 connector has an interrupted groove in the middle, distinguishing it from Type A. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and B sockets, whereas a Type A adapter will not fit into a Type B socket.
Comparison of Type A and Type B OBD2 connectors, highlighting voltage and application differences.
Illustrating the relationship between OBD2 and CAN bus according to ISO15765 standards.
OBD2 and CAN Bus Integration: ISO 15765-4
Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US-sold vehicles, as per ISO 15765. This standard ensures seamless communication via the CAN bus OBD2 connector.
ISO 15765-4, also known as Diagnostics over CAN (DoCAN), outlines restrictions applied to 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 is fixed at 8 bytes.
- The OBD2 adapter cable must be max 5 meters long.
CAN Identifiers for CAN Bus OBD2 Communication (11-bit, 29-bit)
OBD2 communication over CAN bus relies on request/response message exchanges through the CAN bus OBD2 connector.
In most cars, 11-bit CAN IDs are used. The ‘Functional Addressing’ ID, 0x7DF, broadcasts requests to all OBD2-compatible ECUs, asking if they have data for the requested parameter (ISO 15765-4). CAN IDs 0x7E0-0x7E7 are used for ‘Physical Addressing’ requests to specific ECUs, though less commonly used.
ECUs respond with 11-bit IDs in the range 0x7E8-0x7EF. The most frequent response ID is 0x7E8 (ECM, Engine Control Module), and to a lesser extent 0x7E9 (TCM, Transmission Control Module).
Some vehicles, particularly vans and medium to heavy-duty vehicles, may use extended 29-bit CAN identifiers for OBD2 communication instead of 11-bit IDs.
Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Responses use CAN IDs from 0x18DAF100 to 0x18DAF1FF, typically 18DAF110 and 18DAF11E. The response ID is also sometimes represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which in the J1939-71 standard is marked ‘Reserved for ISO 15765-2’.
Illustrative frames for OBD2 protocol request and response processes.
Comparison between OBD2 and proprietary CAN bus data protocols in vehicles.
OBD2 vs. Proprietary CAN Protocols
It’s important to understand that your vehicle’s electronic control units (ECUs) operate primarily on OEM-specific proprietary CAN protocols, not OBD2. Each OEM develops unique CAN protocols tailored to their vehicle brands, models, and years. This OEM-specific data is generally inaccessible unless reverse-engineered.
When you connect a CAN bus data logger to your CAN bus OBD2 connector, you might observe OEM-specific CAN data, typically broadcast at high rates (1000-2000 frames/second). However, newer vehicles often have a ‘gateway’ that restricts access to this CAN data, allowing only OBD2 communication through the CAN bus OBD2 connector.
In essence, OBD2 is an additional higher-layer protocol running in parallel with the OEM-specific protocol. The CAN bus OBD2 connector serves as the access point for both, but with limitations on accessing proprietary data.
Bit-rate and ID Validation for CAN Bus OBD2 Connector
As mentioned, OBD2 over CAN bus can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in 4 potential combinations. Modern vehicles commonly use 500K and 11-bit IDs, but external tools should systematically verify this.
ISO 15765-4 recommends an initialization sequence to determine the correct combination. This method relies on the fact that OBD2-compliant vehicles must respond to a mandatory OBD2 request (see OBD2 PID section) and that incorrect bit-rates will cause CAN error frames.
Newer ISO 15765-4 versions account for OBD communication via OBDonUDS as well as OBDonEDS. This article mainly focuses on OBD2/OBDonEDS (OBD on emission diagnostic service per ISO 15031-5/SAE J1979) rather than WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service per ISO 14229, ISO 27145-3/SAE J1979-2).
To differentiate between OBDonEDS and OBDonUDS protocols, testing tools may send additional UDS requests using 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS should have ECUs that respond to this DID.
In practice, OBDonEDS (aka OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars today, whereas WWH-OBD is primarily used in EU trucks and buses.
Flowchart illustrating the process for OBD2 bit-rate and CAN ID validation.
Overview of the five lower-layer OBD2 protocols 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, older vehicles (pre-2008) may use other protocols. Understanding these can be helpful, particularly when diagnosing older systems via the OBD2 connector. Pinouts can also indicate the protocol in use.
The five lower-layer OBD2 protocols are:
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used today.
- ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ cars, especially in Asia.
- ISO 9141-2: Used in EU, Chrysler, and Asian cars in 2000-2004.
- SAE J1850 (VPW): Primarily used in older GM vehicles.
- SAE J1850 (PWM): Primarily used in older Ford vehicles.
ISO 15765-2: Transporting OBD2 Messages via ISO-TP
All OBD2 data transmitted over CAN bus through the CAN bus OBD2 connector uses ISO-TP (ISO 15765-2), a transport protocol that enables payloads larger than 8 bytes. This is essential for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly. More details can be found in our UDS protocol introduction.
However, often OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies ‘Single Frame’ (SF) usage, where the first data byte (PCI field) indicates payload length (excluding padding), leaving 7 bytes for OBD2 communication.
Frame types defined by ISO-TP (ISO 15765-2) for OBD2 communication.
SAE J1979, ISO 15031-5: The OBD2 Diagnostic Message
To better grasp OBD2 communication over CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message transmitted via the CAN bus OBD2 connector. In simplified terms, an OBD2 message comprises an identifier, data length (PCI field), and data, which is further divided into Mode, Parameter ID (PID), and data bytes.
Breakdown of the OBD2 message structure, showing PIDs, mode, and data bytes.
OBD2 Request/Response Example
Consider this request/response example for ‘Vehicle Speed’ to illustrate data exchange via the CAN bus OBD2 connector.
An external tool sends a request message to the car using CAN ID 0x7DF with 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 (50 in decimal).
Looking up the decoding rules for OBD2 PID 0x0D, we find the physical value is 50 km/h.
We’ll now delve into OBD2 modes and PIDs used in communication through the CAN bus OBD2 connector.
Example of an OBD2 request (7DF) and response (7E8) for vehicle speed.
Detailed example of OBD2 PID 0D, representing vehicle speed.
Overview of the 10 OBD2 service modes, including current data, freeze frame, and DTC clearing.
The 10 OBD2 Services (Modes)
OBD2 includes 10 diagnostic services, or modes. Mode 0x01 provides current real-time data, while others are used for displaying or clearing diagnostic trouble codes (DTCs) and accessing freeze frame data. These services are accessed through the CAN bus OBD2 connector.
Vehicles are not required to support all 10 OBD2 modes and may also include OEM-specific modes beyond these standard ones.
In OBD2 messages, the mode is the 2nd byte. In a request, the mode is directly included (e.g., 0x01), while in the response, 0x40 is added to the mode value (e.g., resulting in 0x41).
OBD2 Parameter IDs (PIDs)
Each OBD2 mode contains Parameter IDs (PIDs).
For example, mode 0x01 has approximately 200 standardized PIDs that provide real-time data on parameters like speed, RPM, and fuel level, all accessible via the CAN bus OBD2 connector. However, vehicles typically support only a subset of the available PIDs within each mode.
One PID stands out:
If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the vehicle ECU indicates its support for PIDs 0x01-0x20. This makes PID 0x00 a crucial test for basic ‘OBD2 compatibility’ via the CAN bus OBD2 connector. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.
Diagram illustrating OBD2 protocol request and response frames with PID data.
Screenshot of an OBD2 PID overview tool for service 01.
OBD2 PID Overview Tool
SAE J1979 and ISO 15031-5 appendices provide scaling information for standard OBD2 PIDs, which is essential for converting raw data into physical values, as explained in our CAN bus introduction. This decoding process is crucial when working with data obtained through the CAN bus OBD2 connector.
For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is invaluable. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses received via the CAN bus OBD2 connector.
OBD2 PID overview tool
Practical Guide: Logging and Decoding OBD2 Data
This section provides a practical example of logging OBD2 data using the CANedge CAN bus data logger, connected through the CAN bus OBD2 connector.
The CANedge allows configuration of custom CAN frames for transmission, enabling its use for OBD2 logging.
Once configured, the CANedge can be easily connected to your vehicle using our OBD2-DB9 adapter cable, plugging directly into the CAN bus OBD2 connector.
Diagram showing an OBD2 data logger requesting PID data (7df) and receiving responses (7e8).
Screenshot of a bit-rate validation test for OBD2 communication.
Screenshot showing responses to ‘Supported PIDs’ test in asammdf software.
Step #1: Bit-rate, ID, and Supported PID Testing
As previously discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a vehicle’s CAN bus OBD2 connector. You can test this using CANedge as follows (refer to the CANedge Intro 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 11-bit vs. 29-bit IDs based on response IDs.
- Identify supported PIDs based on response data.
We offer plug-and-play configurations to simplify these tests.
Most non-EV vehicles from 2008 onwards typically support 40-80 PIDs via a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol, all accessible through the CAN bus OBD2 connector.
The asammdf GUI screenshot illustrates common responses to a single OBD request. Using the 0x7DF request ID polls all ECUs for responses. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are common. For subsequent ‘Supported PIDs’ requests, fewer ECUs typically respond. Note that the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, potentially reducing busload by directing subsequent requests specifically to this ECU using ‘Physical Addressing’ CAN ID 0x7E0.
Step #2: Configuring OBD2 PID Requests
Once you’ve identified the supported OBD2 PIDs, bit-rate, and CAN IDs for your vehicle’s CAN bus OBD2 connector, configure your transmit list with the PIDs of interest.
Consider these points for effective configuration:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses per request.
- Spacing: Add 300-500 ms intervals between OBD2 requests to prevent ECU overload.
- Battery Drain: Use triggers to halt transmissions when the vehicle is inactive to avoid unnecessary ECU activation.
- Filters: Implement filters to record only OBD2 responses, especially if OEM-specific CAN data is also present.
With these configurations, your device is set to log raw OBD2 data from the CAN bus OBD2 connector!
Example transmit list of CANedge OBD2 PID requests.
Visual plot of decoded OBD2 data in asammdf, using a CAN bus DBC file.
Step #3: DBC Decoding of Raw OBD2 Data
To effectively analyze and visualize logged data, you need to decode the raw OBD2 data into ‘physical values’ (e.g., km/h, °C). This decoding is essential for interpreting data obtained through the CAN bus OBD2 connector.
Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. For convenience, we provide a free OBD2 DBC file to facilitate DBC decoding of raw OBD2 data in most CAN bus software tools.
Decoding OBD2 data is more complex than standard CAN signal decoding because different OBD2 PIDs can be transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone isn’t sufficient to identify the signals within the payload.
To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID to uniquely identify each signal. This multiplexing method, known as ‘extended multiplexing‘, can be implemented in DBC files.
CANedge: Your OBD2 Data Logger
The CANedge simplifies recording OBD2 data directly to an 8-32 GB SD card via the CAN bus OBD2 connector. Just connect it to a vehicle to start logging and use our free software/APIs and OBD2 DBC for data decoding.
OBD2 logger intro
CANedge
ISO-TP and OBD2 Multi-Frame Examples
OBD2 communication, including multi-frame exchanges, is managed by ISO-TP as per ISO 15765-2. Most examples discussed so far involve single-frame communication. This section provides examples of multi-frame communication through the CAN bus OBD2 connector.
Multi-frame OBD2 communication necessitates flow control frames (see our UDS intro). 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, multi-frame OBD2 responses require CAN software/API tools that support ISO-TP, such as CANedge MF4 decoders.
Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN).
Example 1: Retrieving Vehicle Identification Number (VIN) via OBD2
The Vehicle Identification Number (VIN) is crucial for telematics and diagnostics. To retrieve the VIN using OBD2 requests through the CAN bus OBD2 connector, use mode 0x09 and PID 0x02:
The tester tool sends a Single Frame request with PCI field (0x02), request service identifier (0x09), and PID (0x02).
The vehicle responds with a First Frame containing 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 (see ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes constitute the VIN, which can be converted from HEX to ASCII as detailed 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 via the CAN bus OBD2 connector. The ECU will respond with data for supported PIDs (excluding unsupported ones), potentially across multiple frames as per ISO-TP.
This efficient method allows higher-frequency data collection, but signal encoding becomes specific to the request method, complicating the use of generic OBD2 DBC files. We generally advise against this method for practical applications. Below is an example trace:
The multi-frame response is similar to the VIN example, but the payload includes both the requested PIDs and their corresponding data. The PIDs in the example are ordered similarly to the request order, which is common but not strictly mandated by ISO 15031-5.
Decoding such responses via DBC files is challenging. We recommend avoiding this approach for practical data logging unless your tool specifically supports it. This method results in a complex form of extended multiplexing, making it difficult to generalize DBC files across vehicles with varying PID support. Handling multiple multi-PID requests further complicates DBC management, making unique message identification difficult.
Workarounds might involve custom scripts that interpret response messages in conjunction with request messages, but these are hard to scale.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs) Retrieval
OBD2 can be used to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03 (‘Show stored Diagnostic Trouble Codes’) via the CAN bus OBD2 connector. No PID is included in the request. The targeted ECU(s) will respond with the number of stored DTCs (possibly 0), 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 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 request to an ECU with 6 stored DTCs.
Example of OBD2 DTC decoding and DBC interpretation.
Use Cases for OBD2 Data Logging via the CAN Bus OBD2 Connector
OBD2 data, accessed through the CAN bus OBD2 connector, from cars and light trucks has diverse applications:
Car Data Logging
OBD2 data from cars can be used to reduce fuel costs, improve driving habits, test prototype parts, and for insurance purposes.
obd2 logger
Real-Time Car Diagnostics
OBD2 interfaces enable real-time streaming of human-readable OBD2 data, useful for diagnosing vehicle issues.
obd2 streaming
Predictive Maintenance
Cars and light trucks can be monitored via IoT OBD2 loggers in the cloud to predict and prevent breakdowns.
predictive maintenance
Vehicle Black Box Logging
An OBD2 logger can serve as a ‘black box’ for vehicles or equipment, providing critical data for disputes or diagnostics.
can bus blackbox
Do you have an OBD2 data logging application in mind? Contact us for a free consultation!
Contact us
Explore our guides section for more introductions, or download the ‘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
