In today’s automotive landscape, the ability to diagnose and monitor vehicle health is paramount. Enter Can Bus Obd2, the standardized system that empowers mechanics, car enthusiasts, and even everyday drivers to understand what’s happening under the hood. This guide provides a comprehensive yet practical introduction to On-Board Diagnostics version 2 (OBD2) and its critical integration with the Controller Area Network (CAN bus) – the backbone of modern vehicle communication.
Whether you’re deciphering a check engine light, aiming to optimize fuel efficiency, or developing advanced automotive applications, understanding CAN bus OBD2 is essential. This article will delve into the intricacies of this technology, covering everything from the OBD2 connector and Parameter IDs (PIDs) to practical data logging and interpretation techniques. Discover why this has become a go-to resource for understanding CAN bus OBD2.
You can also explore our video introduction to OBD2 or download our detailed PDF guide on CAN bus for offline reading.
Exploring CAN Bus OBD2: Your Diagnostic Gateway
What is OBD2 and its Connection to CAN Bus?
OBD2 is essentially your car’s internal health monitoring system. It’s a standardized protocol designed to access diagnostic information, trouble codes, and real-time data from your vehicle through the OBD2 connector. While OBD2 is the diagnostic language, CAN bus is the communication network that allows different parts of your car to “talk” to each other, and crucially, for your OBD2 scanner to communicate with the car’s computer.
You’ve likely encountered OBD2 in action if you’ve ever seen the malfunction indicator light (check engine light) illuminate on your dashboard. This light signals that your car has detected an issue. Mechanics use OBD2 scanners, which connect to the 16-pin OBD2 connector typically located near the steering wheel, to diagnose these problems. The scanner sends ‘OBD2 requests’ via the CAN bus network, and the car responds with ‘OBD2 responses’ containing valuable data like speed, fuel level, and Diagnostic Trouble Codes (DTCs), significantly speeding up the troubleshooting process.
Understanding OBD2: On-Board Diagnostics and the Malfunction Indicator Light (MIL).
Does Your Car Utilize CAN Bus OBD2?
The answer for most modern vehicles is a resounding yes!
Nearly all non-electric cars manufactured in recent years support OBD2, and the vast majority of these systems operate on CAN bus. For older vehicles, even if a 16-pin OBD2 connector is present, it might not fully support the OBD2 standard. To ascertain OBD2 compliance, consider the vehicle’s manufacturing origin and purchase date:
OBD2 Compliance Guide: Determining if your car is OBD2 compliant based on region and year.
The Evolution of CAN Bus OBD2: A Historical Perspective
The genesis of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated OBD systems in all new cars from 1991 onwards for emission control.
The Society of Automotive Engineers (SAE) further refined this by recommending the OBD2 standard, standardizing DTCs and the OBD connector across different manufacturers through SAE J1962.
The adoption of the CAN bus protocol as the physical layer for OBD2 was a significant step in its evolution, leading to a phased global rollout of the OBD2 standard:
- 1996: OBD2 becomes mandatory in the USA for cars and light trucks.
- 2001: Required in the EU for gasoline cars.
- 2003: Extended in the EU to include diesel cars (EOBD).
- 2005: OBD2 mandated in the US for medium-duty vehicles.
- 2008: US vehicles required to use ISO 15765-4 (CAN) as the foundation for OBD2, solidifying CAN bus OBD2.
- 2010: OBD2 becomes mandatory for heavy-duty vehicles in the US.
OBD2 History: Tracing the evolution of On-Board Diagnostics for emission control and data access.
OBD2 Timeline: A visual overview of the historical milestones in On-Board Diagnostics development.
OBD2 Future Trends: Envisioning OBD3, remote diagnostics, and cloud-based emission testing.
The Future Trajectory of CAN Bus OBD2
OBD2, particularly CAN bus OBD2, is poised to remain a crucial part of vehicle technology. However, its form and function are evolving.
Originally conceived for emissions monitoring, legislated OBD2 faces new challenges with the rise of electric vehicles. Interestingly, electric vehicles are not obligated to support OBD2 in its traditional form. Most modern EVs bypass standard OBD2 requests and utilize OEM-specific UDS communication protocols instead. This shift often complicates data retrieval from EVs, except in cases where reverse engineering has uncovered decoding methods. Examples include studies on Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs, demonstrating the evolving landscape of vehicle diagnostics.
Recognizing the limitations of current OBD2 implementations in data richness and protocol flexibility, alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging. These advanced protocols aim to enhance OBD communication by building upon the UDS protocol. Further insights into these protocols can be found in our introduction to UDS.
In the era of connected cars, traditional OBD2 testing methods can seem inefficient. Manual emission checks are time-consuming and costly, paving the way for OBD3 – the era of telematics integration in all vehicles.
OBD3 envisions embedding a small radio transponder in every car, similar to those used for bridge tolls. This technology would enable vehicles to transmit their vehicle identification number (VIN) and DTCs wirelessly to a central server for automated diagnostics.
Many current devices, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger, already facilitate CAN or OBD2 data transfer via WiFi or cellular networks.
While offering convenience and cost savings, OBD3 also raises privacy concerns related to increased vehicle surveillance.
Originally designed for stationary emission checks, OBD2’s role has expanded significantly. Today, it’s widely used by third parties to generate real-time vehicle data via OBD2 dongles, CAN loggers and similar tools. However, the German automotive industry is considering changes that could impact this ecosystem.
BMW’s SVP Electronics, Christoph Grote, stated 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 involves potentially disabling OBD2 functionality during driving and centralizing data collection within manufacturer servers. This shift would place automotive manufacturers at the helm of ‘automotive big data’.
Arguments for this change cite security improvements, such as mitigating car hacking risks. However, many perceive this as a commercially motivated move, potentially disrupting the market for third-party OBD2 services. The future of CAN bus OBD2 and third-party access remains uncertain.
Future of OBD2 in EVs: Electric vehicles may limit access to data via the traditional OBD2 connector.
Enhance Your Expertise with our ‘Ultimate CAN Guide’
Ready to become a CAN bus expert and master CAN bus OBD2?
Our comprehensive 160+ page PDF guide consolidates 12 ‘simple intros’ into one resource:
Download now
CAN Bus OBD2 Standards: Laying the Foundation
On-board diagnostics, specifically CAN bus OBD2, operates as a higher-layer protocol – essentially a language – built upon CAN, which serves as the communication method, akin to a phone line. This structure parallels other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.
The CAN bus OBD2 standards meticulously define the OBD2 connector, the lower-layer protocols, OBD2 Parameter IDs (PIDs), and other critical aspects.
These standards can be mapped against a 7-layer OSI model. Notably, both SAE and ISO standards cover multiple layers, reflecting the standardization efforts for OBD in the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.
OSI Model for CAN Bus OBD2: Mapping OBD2 and CAN Bus standards across the 7-layer OSI model.
OBD2 Connector Pinout: Pin assignments for a Type A OBD2 connector socket (female DLC).
The OBD2 Connector [SAE J1962]: Your Physical Access Point
The 16-pin OBD2 connector is the standard interface for accessing vehicle data, as specified by SAE J1962 / ISO 15031-3.
The illustration shows a Type A OBD2 pin connector, also known as a Data Link Connector (DLC).
Key features of the OBD2 connector include:
- Location: Typically found near the steering wheel, although it may be hidden.
- Pin 16: Provides battery power, often active even when the ignition is off.
- Pinout Variability: The OBD2 pinout is protocol-dependent.
- CAN Bus Dominance: CAN bus is the most prevalent lower-layer protocol, typically utilizing pins 6 (CAN-H) and 14 (CAN-L).
OBD2 Connector Types: Type A vs. Type B
In practice, you may encounter both Type A and Type B OBD2 connectors. Type A is common in cars, while Type B is more frequently used 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) and often in baud rates. Cars typically use 500K baud rate, whereas heavy-duty vehicles commonly use 250K (with increasing support for 500K).
Type B OBD2 connectors can be identified by an interrupted groove in the middle, which distinguishes them from Type A connectors. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, while a Type A adapter will not fit into a Type B socket.
OBD2 Connector Types A and B: Comparing the pinouts, voltage, and applications of Type A and Type B OBD2 connectors.
CAN Bus Integration in OBD2: Illustrating the relationship between OBD2 and CAN bus as defined by ISO 15765 standards.
CAN Bus and OBD2 Integration [ISO 15765-4]: The Protocol Foundation
Since 2008, CAN bus became the mandatory lower-layer protocol for OBD2 in all US-sold cars, as per ISO 15765. This solidified CAN bus OBD2 as the standard.
ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies a set of constraints applied to the CAN standard (ISO 11898).
It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:
- Bit-rate: CAN bus bit-rate must be 250K or 500K.
- CAN IDs: Supports both 11-bit and 29-bit CAN IDs.
- Specific CAN IDs: Defined for OBD requests and responses.
- Data Length: Diagnostic CAN frames must have a data length of 8 bytes.
- Cable Length: OBD2 adapter cable must be a maximum of 5 meters.
CAN Bus OBD2 Identifiers (11-bit, 29-bit): Addressing Communication
All CAN bus OBD2 communication is structured around request/response messages.
In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID, 0x7DF, is used to query all OBD2-compatible ECUs for data related to a requested parameter (ISO 15765-4). ‘Physical Addressing’ requests to specific ECUs can be made using CAN IDs 0x7E0-0x7E7, though this is less common.
ECUs respond with 11-bit IDs ranging from 0x7E8-0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module).
Some vehicles, especially vans and medium to heavy-duty vehicles, may utilize extended 29-bit CAN identifiers for CAN bus OBD2 communication instead of 11-bit IDs.
In 29-bit implementations, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Responses are typically seen with CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (commonly 18DAF110 and 18DAF11E). The response ID is sometimes represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is reserved for ISO 15765-2 in the J1939-71 standard.
CAN Bus OBD2 Request and Response Frames: Illustrating the structure of OBD2 communication over CAN bus.
CAN Bus OBD2 vs. Proprietary CAN Bus: Differentiating between standardized OBD2 communication and OEM-specific CAN protocols.
CAN Bus OBD2 vs. Proprietary CAN Protocols: Understanding the Difference
It’s crucial to understand that a vehicle’s Electronic Control Units (ECUs) operate primarily using OEM-specific proprietary CAN protocols, not CAN bus OBD2. Each manufacturer develops unique CAN protocols tailored to their vehicle brands, models, and years. This proprietary CAN data is typically inaccessible to third parties without reverse engineering.
When connecting a CAN bus data logger to the OBD2 connector, you might observe OEM-specific CAN data, often broadcast at high rates (1000-2000 frames/second). However, newer vehicles often employ a ‘gateway’ that restricts access to this raw CAN data, allowing only CAN bus OBD2 communication through the OBD2 port.
In essence, CAN bus OBD2 functions as an additional, higher-layer protocol operating alongside the OEM-specific protocol.
Bit-rate and ID Validation in CAN Bus OBD2
CAN bus OBD2 may utilize two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. Modern cars commonly use 500K and 11-bit IDs. External diagnostic tools should systematically validate these settings.
ISO 15765-4 outlines a systematic initialization sequence to determine the correct combination. This process leverages the mandatory support for a specific OBD2 request in compliant vehicles (see OBD2 PID section) and the fact that incorrect bit-rate transmissions will generate CAN error frames.
Newer versions of ISO 15765-4 account for vehicles supporting OBD communication via OBDonUDS instead of OBDonEDS. While this article mainly focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service per ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service per ISO 14229, ISO 27145-3/SAE J1979-2), it’s important to note the evolving standards.
To test for OBDonEDS vs. OBDonUDS, diagnostic tools may send additional 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.
Currently, OBDonEDS (also known as OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars, while WWH-OBD is primarily used in EU trucks and buses.
CAN Bus OBD2 Bit-rate and CAN ID Validation Flowchart: A systematic approach to validating CAN bus OBD2 communication parameters.
OBD2 Lower-Layer Protocols: Highlighting the five main protocols used in OBD2, including CAN (ISO 15765).
Five Lower-Layer OBD2 Protocols: Beyond CAN Bus
While CAN bus (ISO 15765) is now dominant for OBD2, especially in vehicles post-2008, older cars may use one of four other lower-layer protocols. Understanding these protocols and their pinouts can be helpful when working with older vehicles.
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used today for CAN bus OBD2.
- ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ cars, especially in Asia.
- ISO 9141-2: Used in EU, Chrysler, and Asian cars from 2000-2004.
- SAE J1850 (VPW): Predominantly used in older GM vehicles.
- SAE J1850 (PWM): Primarily used in older Ford vehicles.
ISO-TP for CAN Bus OBD2 Messaging [ISO 15765-2]
All CAN bus OBD2 data is transmitted over CAN using ISO-TP (ISO 15765-2), a transport protocol that enables the communication of payloads exceeding the 8-byte CAN frame limit. This is essential in OBD2 for operations 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. Detailed information is available in our UDS protocol introduction.
However, much of the CAN bus OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies the use of ‘Single Frame’ (SF) format. The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for OBD2-specific communication.
ISO-TP Frame Types for CAN Bus OBD2: Overview of Single Frame, First Frame, Consecutive Frame, and Flow Control frame types in ISO-TP.
Decoding CAN Bus OBD2 Messages: Structure and Examples
To effectively work with CAN bus OBD2, understanding the structure of OBD2 messages on CAN is crucial. A simplified CAN bus OBD2 message comprises an identifier, a data length (PCI field), and the data itself. The data field is further divided into Mode, Parameter ID (PID), and data bytes.
CAN Bus OBD2 Message Structure: Breakdown of a raw OBD2 CAN frame, highlighting Mode, PID, and data bytes.
Example: CAN Bus OBD2 Request and Response
Consider a request for ‘Vehicle Speed’ as an example of CAN bus OBD2 communication.
An external tool sends a request message to the car with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds via CAN ID 0x7E8 with 3 payload bytes, including the vehicle speed value in the 4th byte, 0x32 (decimal 50).
By consulting the decoding rules for OBD2 PID 0x0D, we find that the physical value corresponds to 50 km/h.
Let’s delve deeper into OBD2 modes and PIDs.
CAN Bus OBD2 Request and Response Example: Requesting Vehicle Speed (PID 0x0D) and the corresponding response.
OBD2 PID 0x0D: Decoding Vehicle Speed from a CAN Bus OBD2 response.
OBD2 Services (Modes): Overview of the 10 standardized OBD2 diagnostic services or modes.
The 10 OBD2 Services (Modes) in CAN Bus OBD2
There are 10 defined OBD2 diagnostic services, also known as modes. Mode 0x01 is used for real-time data, while others are for retrieving and clearing Diagnostic Trouble Codes (DTCs) or accessing freeze frame data.
It’s important to note that vehicles are not required to support all OBD2 modes and may also include OEM-specific modes beyond the 10 standardized ones.
In CAN bus OBD2 messages, the mode is located in the second 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., becoming 0x41).
OBD2 Parameter IDs (PIDs) within CAN Bus OBD2
Each OBD2 mode contains Parameter IDs (PIDs).
For example, mode 0x01 includes approximately 200 standardized PIDs providing real-time data on parameters like speed, RPM, and fuel level. However, vehicles typically support only a subset of the available PIDs within each mode.
One PID, in particular, is crucial for CAN bus OBD2 compatibility testing.
Specifically, if an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID, the ECU indicates its support for PIDs 0x01-0x20. PID 0x00, therefore, acts as a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.
CAN Bus OBD2 Request and Response Structure: Detailing the positions of Mode and PID within OBD2 messages.
OBD2 PID Overview Tool: A resource for exploring and understanding OBD2 Parameter IDs.
Tip: Utilizing a CAN Bus OBD2 PID Overview Tool
The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs, enabling the conversion of raw data into physical values, as detailed in our CAN bus introduction.
For quick lookup of mode 0x01 PIDs, our OBD2 PID overview tool is invaluable. It assists in constructing CAN bus OBD2 request frames and dynamically decoding OBD2 responses.
OBD2 PID overview tool
Practical Guide: Logging and Decoding CAN Bus OBD2 Data
Let’s explore a practical example of logging CAN bus OBD2 data using the CANedge CAN bus data logger.
The CANedge allows configuration of custom CAN frames for transmission, making it suitable for CAN bus OBD2 logging.
Connect the CANedge to your vehicle using our OBD2-DB9 adapter cable to begin logging.
CAN Bus OBD2 Data Logger Setup: Illustrating the connection of a CAN bus data logger for OBD2 data acquisition.
Validating CAN Bus Bit-rate: Testing CAN frame transmission at 500K to ensure successful communication.
Analyzing Supported PIDs: Reviewing responses to ‘Supported PIDs’ requests in asammdf.
Step #1: Validating Bit-rate, IDs, and Supported PIDs for CAN Bus OBD2
ISO 15765-4 details how to determine the correct bit-rate and IDs for a specific vehicle. Use CANedge to perform these tests (refer to the CANedge Intro for setup):
- Bit-rate Test: Send a CAN frame at 500K; if successful, proceed. If not, try 250K.
- Bit-rate Confirmation: Use the validated bit-rate for all subsequent communication.
- Supported PIDs Query: Send multiple ‘Supported PIDs’ requests and examine the responses.
- ID Type Determination: Response IDs indicate 11-bit or 29-bit CAN ID usage.
- PID Support Identification: Response data reveals supported PIDs.
We offer plug-and-play configurations for these tests.
Most post-2008 non-EV cars support 40-80 PIDs using 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.
As seen in the asammdf GUI screenshot, multiple responses to a single OBD request are common due to the use of the 0x7DF request ID, which polls all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are typical. Subsequent ‘Supported PIDs’ requests elicit fewer responses as fewer ECUs support those PIDs. Note that the ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, suggesting that busload can be reduced by directing requests specifically to the ECM using the ‘Physical Addressing’ CAN ID 0x7E0 for subsequent communications.
Step #2: Configuring CAN Bus OBD2 PID Requests
Once you’ve identified supported PIDs, bit-rate, and CAN IDs for your vehicle, configure your transmit list with desired PIDs.
Consider these factors:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize redundant responses.
- Spacing: Introduce 300-500 ms intervals between OBD2 requests to prevent ECU overload.
- Battery Management: Use triggers to halt transmissions when the vehicle is inactive to avoid ECU wake-up and battery drain.
- Filtering: Implement filters to record only OBD2 responses if OEM-specific CAN data is also present.
With these configurations, your device is ready for raw CAN bus OBD2 data logging!
Example CAN Bus OBD2 Transmit List: A sample configuration of OBD2 PID requests for a CANedge data logger.
Visualizing Decoded CAN Bus OBD2 Data: asammdf displaying DBC decoded and plotted OBD2 data.
Step #3: DBC Decoding of Raw CAN Bus OBD2 Data
To analyze and visualize logged data, decode the raw CAN bus OBD2 data into physical values (e.g., km/h, °C).
Decoding information is found in ISO 15031-5/SAE J1979 and online resources like Wikipedia. We provide a free OBD2 DBC file to simplify DBC decoding in most CAN bus software tools.
Decoding CAN bus OBD2 data is more complex than standard CAN signals because different OBD2 PIDs share the same CAN ID (e.g., 0x7E8). The CAN ID alone is insufficient to identify the payload signals.
To address this, utilize the CAN ID, OBD2 mode, and OBD2 PID for signal identification. This ‘extended multiplexing’ is supported in formats like DBC files.
CANedge: Your Dedicated CAN Bus OBD2 Data Logger
The CANedge provides an easy solution for recording CAN bus OBD2 data to an 8-32 GB SD card. Simply connect it to a vehicle to start logging and use free software/APIs and our OBD2 DBC for data decoding.
OBD2 logger intro
CANedge
Multi-Frame Examples in CAN Bus OBD2 [ISO-TP]
All CAN bus OBD2 communication utilizes ISO-TP as per ISO 15765-2. Most examples so far have been single-frame. This section presents multi-frame communication examples.
Multi-frame CAN bus OBD2 communication requires flow control frames (see our UDS intro). A common practice is to transmit a static flow control frame approximately 50 ms after the initial request, as shown in the CANedge configuration example.
Analyzing multi-frame CAN bus OBD2 responses requires CAN software/API tools supporting ISO-TP, such as CANedge MF4 decoders.
Multi-Frame CAN Bus OBD2 Request: Example of a multi-frame request message for Vehicle Identification Number (VIN) retrieval.
Example 1: Retrieving Vehicle Identification Number (VIN) via CAN Bus OBD2
The Vehicle Identification Number (VIN) is crucial for telematics and diagnostics. To retrieve the VIN using CAN bus OBD2 requests, 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, indicating Number Of Data Items (NODI), in this case 1. The subsequent 17 bytes represent the VIN, which can be converted from HEX to ASCII as described in our UDS introduction.
Example 2: Multi-PID Request (6x) in CAN Bus OBD2
External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame. The ECU responds with data for supported PIDs (excluding unsupported ones), possibly spanning multiple frames via ISO-TP.
This efficient method allows higher frequency data collection, but the signal encoding is specific to the request, complicating the use of generic OBD2 DBC files. We generally advise against this method. Here’s an example trace:
The multi-frame response is similar to the VIN example, but the payload includes requested PIDs and their corresponding data. PIDs are often ordered as requested, though this isn’t strictly mandated by ISO 15031-5.
Decoding these responses via generic DBC files is challenging, making this approach impractical for general data logging unless specialized tools are used. The extended multiplexing and variable payload positions make generic DBC application difficult.
Custom scripts and recording transmit messages alongside responses can help, allowing interpretation based on request-response pairs, but this approach is less scalable.
Example 3: Diagnostic Trouble Codes (DTCs) via CAN Bus OBD2
Mode 0x03, ‘Show stored Diagnostic Trouble Codes’, retrieves emissions-related DTCs. No PID is needed in the request. Responding ECUs report the number of stored DTCs (possibly zero), with each DTC occupying 2 bytes. Multi-frame responses are necessary for more than 2 DTCs.
The 2-byte DTC value is structured per ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category’, and the remaining 14 bits form a 4-digit code (hexadecimal). 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.
CAN Bus OBD2 DTC Decoding: Illustrating the interpretation of Diagnostic Trouble Codes from CAN Bus OBD2 data.
Use Cases for CAN Bus OBD2 Data Logging
CAN bus OBD2 data from cars and light trucks has diverse applications:
Car Data Logging
CAN bus OBD2 data logging aids in fuel cost reduction, driving improvement, prototype testing, and insurance applications.
obd2 logger
Real-time Car Diagnostics
CAN bus OBD2 interfaces facilitate real-time streaming of human-readable data for vehicle diagnostics.
obd2 streaming
Predictive Maintenance
IoT-enabled CAN bus OBD2 loggers allow cloud-based vehicle monitoring for predictive maintenance and breakdown prevention.
predictive maintenance
Vehicle Black Box Logger
CAN bus OBD2 loggers serve as ‘black boxes’ for vehicles, providing data for dispute resolution and diagnostics.
can bus blackbox
Do you have a CAN bus OBD2 data logging use case? Contact us for expert consultation!
Contact us
Explore our guides section for more introductions or download the ‘Ultimate Guide’ PDF.
Need to log or stream CAN bus OBD2 data?
Get your CAN bus 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
