Understanding CAN OBD2: A Comprehensive Guide to On-Board Diagnostics over CAN Bus

Looking for a clear and practical introduction to CAN OBD2?

This guide provides an in-depth look at the On-Board Diagnostics (OBD2) protocol, focusing on its integration with the Controller Area Network (CAN) bus. We’ll cover everything from the OBD2 connector and OBD2 Parameter IDs (PIDs) to the crucial link with CAN bus technology.

This is designed as a comprehensive yet accessible guide, so you’ll learn how to effectively request and interpret OBD2 data, explore key applications for data logging, and gain valuable practical insights.

Discover why this is considered a top resource for understanding CAN OBD2.

You can also check out our introductory video on OBD2 and CAN or download this guide as a PDF for offline reading.

Exploring CAN OBD2: In This Article

Author: Martin Falch (Updated January 2025)

Download this guide as PDF

What is CAN OBD2?

CAN OBD2 represents the integration of the OBD2 diagnostic protocol with the CAN bus communication standard. OBD2, in itself, is your vehicle’s built-in self-diagnostic system. It’s a standardized protocol that allows access to diagnostic trouble codes (DTCs) and real-time vehicle data through the OBD2 connector. The “CAN” part signifies that this communication often occurs over the CAN bus, a robust network widely used in modern vehicles.

You’re likely already familiar with OBD2:

Have you ever seen the check engine light illuminate on your dashboard?

That light is your car signaling a potential issue. When you take your vehicle to a mechanic, they use an OBD2 scanner to diagnose the problem.

This process involves connecting an OBD2 reader to the 16-pin OBD2 connector, usually located near the steering wheel. The scanner sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’. These responses can include valuable data like speed, fuel level, and Diagnostic Trouble Codes (DTCs), which are essential for efficient troubleshooting.

Understanding OBD2: The Malfunction Indicator Light (MIL) signals issues, diagnosed with an OBD2 scan tool.

Is My Car Equipped with CAN OBD2?

The answer is: Most likely, yes!

The vast majority of contemporary non-electric vehicles are CAN OBD2 compliant, utilizing the CAN bus for communication. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t guarantee CAN OBD2 support. Some may not fully adhere to the OBD2 standard. To ascertain CAN OBD2 compliance, consider the vehicle’s origin and year of manufacture:

Vehicle CAN OBD2 Compliance Guide: Check your vehicle’s region and manufacturing year for OBD2 compatibility.

The Evolution of CAN OBD2

The origins of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated OBD for all new vehicles from 1991 onwards, primarily for emission control.

The Society of Automotive Engineers (SAE) further refined this by recommending the OBD2 standard. They standardized DTCs and the OBD connector across different vehicle manufacturers with the SAE J1962 standard.

The adoption of the CAN OBD2 standard was a phased process:

1996: CAN OBD2 became mandatory in the USA for cars and light trucks.
2001: The EU mandated CAN OBD2 for gasoline cars.
2003: EU extended the mandate to diesel cars as well (EOBD).
2005: CAN 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 CAN OBD2 communication.
2010: CAN OBD2 became mandatory for heavy-duty vehicles in the US.

CAN OBD2 History: From emission control origins to widespread adoption in vehicles.

Timeline of OBD2 Evolution: Key milestones in the standardization and implementation of On-Board Diagnostics.

The Future of OBD: Envisioning OBD3 with remote diagnostics, cloud connectivity, and IoT integration for enhanced vehicle monitoring.

The Future Trajectory of CAN OBD2

CAN OBD2 is firmly established, but its evolution continues.

Key future trends include:

Initially, legislated OBD2, including CAN OBD2, was developed for emission control and testing. Consequently, electric vehicles (EVs) aren’t mandated to support CAN OBD2 in any form. This is reflected in the fact that most modern EVs do not support standard CAN OBD2 requests. Instead, they often use OEM-specific UDS communication protocols. This shift often complicates data retrieval from EVs, except in cases where reverse engineering efforts have decoded the communication rules. Examples include studies on electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Currently, CAN OBD2 implementations vary, and it faces limitations in data richness and lower-layer protocols. To address these issues, newer protocols like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These advancements aim to enhance and streamline OBD communication by utilizing the UDS protocol as a base. Further details on these protocols are available in our introduction to UDS.

In our increasingly connected world, traditional CAN OBD2 testing methods can seem inefficient. Manual emission checks are both 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 bridge tolls) to all cars. 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 existing devices already facilitate CAN or CAN OBD2 data transfer via WiFi/cellular, such as the CANedge2 WiFi CAN logger and the CANedge3 3G/4G CAN logger.

While this offers convenience and cost savings, it also raises political challenges related to surveillance and data privacy.

Originally, the CAN OBD2 protocol was designed for stationary emission controls.

However, today, CAN OBD2 is extensively utilized by third parties to generate real-time data using CAN OBD2 dongles, CAN loggers and similar devices. However, the German automotive industry is seeking to change this landscape:

“CAN OBD2 has been designed to service cars in repair shops. It was never intended to allow third parties to build a data-driven economy based on access through this interface.“

Christoph Grote, SVP Electronics, BMW (2017)

The proposition is to deactivate CAN OBD2 functionality during normal driving and instead centralize data collection on manufacturer servers. This would effectively place automotive manufacturers in control of the burgeoning ‘automotive big data’.

The rationale often cited is security, such as mitigating the risk of car hacking. However, many perceive this as a commercially motivated move. The future of this proposal remains uncertain, but it has the potential to significantly disrupt the market for third-party CAN OBD2 services.

Future of CAN OBD2 Data Access: Electric Vehicles and potential shifts in data accessibility and control.

Enhance Your CAN Bus Expertise

Want to master CAN bus technology?

Access our comprehensive collection of 12 ‘simple introductions’ in a single, 160+ page PDF:

Download the Ultimate CAN Guide Now

CAN OBD2 Standards

On-board diagnostics, specifically CAN OBD2, operates as a higher-layer protocol, essentially a language built upon a communication method. CAN bus provides the communication method, similar to a telephone line. This analogy positions CAN OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

CAN OBD2 standards define the OBD2 connector, lower-layer protocols, OBD2 Parameter IDs (PIDs), and more.

These standards can be categorized using the 7-layer OSI model. The following sections will concentrate on the most critical aspects.

In the OSI model framework, it’s important to note that SAE and ISO standards cover several layers. This reflects the standardization efforts for OBD in the USA (SAE) and Europe (ISO). Many standards are technically very similar, such as SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.

CAN OBD2 within the OSI Model: Illustrating the layered standards of CAN OBD2 and CAN Bus according to the 7-layer OSI model.

OBD2 Connector Pinout: Type A female socket pin configuration for Data Link Connector (DLC).

The OBD2 Connector [SAE J1962]

The 16-pin OBD2 connector facilitates easy access to vehicle data and is specified by the SAE J1962 / ISO 15031-3 standards. This connector is crucial for CAN OBD2 communication.

The illustration shows a typical Type A OBD2 pin connector, also known as a Data Link Connector (DLC).

Key features of the OBD2 connector:

It’s usually located near the steering wheel but can be sometimes hidden.
Pin 16 provides battery power, often even when the ignition is off.
The 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 commonly active in CAN OBD2 implementations.

OBD2 Connector Types: A vs. B

In practical applications, you may encounter both Type A and Type B OBD2 connectors. Type A is standard in cars, while Type B is more common in medium and heavy-duty vehicles.

Both types share similar OBD2 pinouts but differ in power supply outputs: Type A typically provides 12V, and Type B provides 24V. Baud rates can also vary, with cars generally using 500K, while heavy-duty vehicles often use 250K (with increasing support for 500K in newer models).

Visually distinguishing them, the Type B OBD2 connector has a distinctive 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.

OBD2 Connector Types A and B: Comparison of pin configurations, voltage, and applications in cars and trucks as per SAE J1962.

CAN OBD2 Standard ISO 15765: The relationship between OBD2 and CAN bus protocols within the ISO 15765 framework.

CAN OBD2 and CAN Bus [ISO 15765-4]

Since 2008, CAN bus has been the mandated lower-layer protocol for OBD2 in all vehicles sold in the US, as specified by ISO 15765. This standard is fundamental to CAN OBD2.

ISO 15765-4, also known as Diagnostics over CAN (DoCAN), outlines specific 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:

CAN bus bit rates must be either 250K or 500K.
CAN IDs can be 11-bit or 29-bit.
Specific CAN IDs are designated for CAN OBD2 requests and responses.
Diagnostic CAN frame data length is fixed at 8 bytes.
The CAN OBD2 adapter cable must not exceed 5 meters in length.

CAN OBD2 Identifiers (11-bit, 29-bit)

All CAN OBD2 communication is structured around request/response message exchanges.

In most passenger vehicles, 11-bit CAN IDs are used for CAN OBD2 communication. The ‘Functional Addressing’ ID here is 0x7DF, used to query all CAN OBD2-compatible ECUs to check if they have data for the requested parameter (refer to ISO 15765-4). Conversely, CAN IDs ranging from 0x7E0 to 0x7E7 are used for ‘Physical Addressing’ requests directed to specific ECUs, though this is less common.

ECUs respond using 11-bit IDs in the range of 0x7E8 to 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 light, medium, and heavy-duty vehicles, CAN OBD2 communication may utilize extended 29-bit CAN identifiers instead of 11-bit IDs.

For 29-bit identifiers, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses in 29-bit CAN OBD2 typically use CAN IDs from 0x18DAF100 to 0x18DAF1FF, commonly 18DAF110 and 18DAF11E. The response ID is sometimes represented in ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is marked in the J1939-71 standard as ‘Reserved for ISO 15765-2’.

CAN OBD2 Request and Response Frames: Illustrating the structure of request and response frames in CAN OBD2 protocol.

CAN OBD2 vs. Proprietary CAN Bus: Differentiating between standardized CAN OBD2 and OEM-specific CAN bus data protocols.

CAN OBD2 vs. Proprietary CAN Protocols

It’s important to understand that your vehicle’s Electronic Control Units (ECUs) operate using proprietary CAN protocols developed by the Original Equipment Manufacturer (OEM), not CAN OBD2. These OEM-specific CAN protocols are essential for vehicle functionality and can vary by brand, model, and year. Accessing and interpreting this proprietary data is typically restricted unless you can reverse engineer it.

Connecting a CAN bus data logger to your car’s OBD2 port might capture OEM-specific CAN data, often broadcast at high rates (1000-2000 frames/second). However, many newer vehicles employ a ‘gateway’ system that blocks access to this OEM CAN data via the OBD2 port, allowing only CAN OBD2 communication.

In essence, consider CAN OBD2 as an additional, higher-layer protocol that operates alongside the OEM-specific protocol.

Bit-Rate and ID Validation in CAN OBD2

As discussed, CAN OBD2 can utilize two bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), creating four possible combinations. Modern vehicles commonly use 500K with 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. This method leverages the fact that CAN OBD2-compliant vehicles must respond to a mandatory CAN OBD2 request (see the CAN OBD2 PID section) and that incorrect bit rate transmissions will cause CAN error frames.

Newer versions of ISO 15765-4 account for vehicles that may support CAN OBD2 communication via OBDonUDS rather than OBDonEDS. This article primarily focuses on CAN 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 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.

Currently, OBDonEDS (also known as CAN OBD2, SAE OBD, EOBD, or ISO OBD) is predominant in non-EV cars, while WWH-OBD is mainly used in EU trucks and buses.

CAN OBD2 Bit-Rate and CAN ID Validation Flowchart: ISO 15765-4 compliant process for validating bit-rate and CAN ID in CAN OBD2 systems.

Five Lower-Layer OBD2 Protocols: CAN (ISO 15765), KWP2000 (ISO 14230-4), ISO 9141-2, SAE J1850 VPW, and SAE J1850 PWM standards.

Five Lower-Layer CAN OBD2 Protocols

While CAN is now the primary lower-layer protocol for CAN OBD2 according to ISO 15765, especially in vehicles manufactured post-2008, it’s useful to be aware of four other protocols used in older vehicles. The OBD2 connector pinouts can sometimes indicate which protocol is in use.

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and currently the most widely used CAN OBD2 protocol.
ISO 14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ vehicles, particularly in Asia.
ISO 9141-2: Used in European, Chrysler, and Asian vehicles from 2000-2004.
SAE J1850 (VPW): Predominantly used in older General Motors vehicles.
SAE J1850 (PWM): Mostly found in older Ford vehicles.

Transporting CAN OBD2 Messages via ISO-TP [ISO 15765-2]

All CAN OBD2 data communication over CAN bus relies on the ISO-TP (ISO 15765-2) transport protocol. This protocol allows for transmitting data payloads exceeding the 8-byte limit of a standard CAN frame. ISO-TP is essential in CAN OBD2 for operations like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). It manages segmentation, flow control, and reassembly of larger messages. More details are available in our introduction to UDS.

However, much of CAN OBD2 data fits within a single CAN frame. In these cases, ISO 15765-2 specifies using a ‘Single Frame’ (SF) format. The first data byte (PCI field) indicates the payload length (excluding padding), leaving 7 bytes for CAN OBD2-related communication.

ISO-TP Frame Types in CAN OBD2: Single Frame (SF), First Frame (FF), Consecutive Frame (CF), and Flow Control (FC) types as per ISO 15765-2.

The CAN OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]

To better understand CAN OBD2 communication over CAN, let’s examine a raw ‘Single Frame’ CAN OBD2 message. Simplified, a CAN OBD2 message includes an identifier, a data length indicator (PCI field), and the data itself. The data is further structured into Mode, Parameter ID (PID), and data bytes.

CAN OBD2 Message Structure: Breakdown of a CAN OBD2 message frame including Mode, PID, Identifier, and Data Bytes.

Example: CAN OBD2 Request and Response

Before detailing each component of a CAN OBD2 message, consider this example of a request and response for ‘Vehicle Speed’.

An external tool sends a request message to the vehicle with CAN ID 0x7DF, containing 2 payload bytes: Mode 0x01 and PID 0x0D. The vehicle responds using CAN ID 0x7E8 with 3 payload bytes, including the vehicle speed value in the 4th byte, represented as 0x32 (50 in decimal).

By consulting the decoding specifications for CAN OBD2 PID 0x0D, we find that the physical value corresponds to 50 km/h.

Next, we will explore CAN OBD2 modes and PIDs in more detail.

CAN OBD2 Request and Response Example: Request frame 7DF and response frame 7E8 for Vehicle Speed PID.
Vehicle Speed PID 0D in CAN OBD2: Example of PID 0D for vehicle speed parameter in CAN OBD2.

10 CAN OBD2 Service Modes: Overview of diagnostic services including current data, freeze frame, and DTC clearing modes.

The 10 CAN OBD2 Services (Modes)

There are 10 standardized CAN OBD2 diagnostic services, also referred to as modes. Mode 0x01 is used to retrieve current real-time data, while others are for displaying or clearing diagnostic trouble codes (DTCs) or accessing freeze frame data.

Vehicles are not required to support all 10 CAN OBD2 modes and may also implement non-standard, OEM-specific modes.

In CAN OBD2 messages, the mode is indicated in the second byte. In a request, the mode is directly specified (e.g., 0x01), while in a response, 0x40 is added to the mode value (e.g., resulting in 0x41).

CAN OBD2 Parameter IDs (PIDs)

Within each CAN OBD2 mode, there are Parameter IDs (PIDs).

For instance, mode 0x01 includes approximately 200 standardized PIDs for real-time data such as speed, RPM, and fuel level. However, vehicles typically support only a subset of the available CAN OBD2 PIDs within a given mode.

One PID is particularly significant:

If an emissions-related ECU supports any CAN 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 fundamental tool for verifying CAN OBD2 compatibility. Similarly, PIDs 0x20, 0x40, …, 0xC0 are used to determine support for subsequent mode 0x01 PIDs.

CAN OBD2 Request and Response PID Parameters: Illustrating PID parameters within CAN OBD2 request and response frames.

CAN OBD2 PID Overview Tool: A tool for exploring and understanding CAN OBD2 Parameter IDs within service mode 01.

Tip: CAN OBD2 PID Overview Tool

SAE J1979 and ISO 15031-5 appendices provide scaling information for standard CAN OBD2 PIDs, enabling the conversion of raw data into physical values, as explained in our CAN bus introduction.

For quick lookups of mode 0x01 PIDs, our CAN OBD2 PID overview tool is invaluable. It aids in constructing CAN OBD2 request frames and dynamically decoding CAN OBD2 responses.

Access the CAN OBD2 PID Overview Tool

How to Log and Decode CAN OBD2 Data

This section provides a practical guide on logging CAN OBD2 data using the CANedge CAN bus data logger.

The CANedge allows configuration of custom CAN frames for transmission, making it suitable for CAN OBD2 logging.

Once configured, the CANedge can be easily connected to your vehicle using our CAN OBD2-DB9 adapter cable.

CAN OBD2 Data Logger Setup: Illustrating CAN OBD2 data logging with request frames 7DF and response frames 7E8.

CAN OBD2 Bit Rate Validation: Testing CAN frame transmission at 500K to validate bit rate for CAN OBD2.
Supported PIDs Test Responses in asammdf: Reviewing responses to ‘Supported PIDs’ requests using asammdf software.

#1: Bit-Rate, ID & Supported PID Testing

As previously mentioned, ISO 15765-4 outlines how to identify the bit rate and IDs used by a specific vehicle. The CANedge can perform these tests as follows (see the CANedge Intro for detailed instructions):

Transmit a CAN frame at 500K and verify successful transmission (if unsuccessful, try 250K).
Use the verified bit rate for all subsequent communication.
Send multiple ‘Supported PIDs’ requests and analyze the responses.
Determine between 11-bit and 29-bit IDs based on response IDs.
Identify supported PIDs based on response data.

We offer plug-and-play configurations to facilitate these tests.

Most non-EV vehicles manufactured from 2008 onwards support 40-80 PIDs using a 500K bit rate, 11-bit CAN IDs, and the CAN OBD2/OBDonEDS protocol.

As shown in the asammdf GUI screenshot, multiple responses to a single CAN OBD2 request are common when using the 0x7DF request ID, as it polls all ECUs for responses. Since all CAN OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are typical. For subsequent ‘Supported PIDs’ requests, fewer ECUs generally respond. Notice that the ECM ECU (0x7E8) in the example supports all PIDs supported by other ECUs. This suggests that bus load could be reduced by directing subsequent requests only to this ECU using the ‘Physical Addressing’ CAN ID 0x7E0.

#2: Configuring CAN OBD2 PID Requests

After determining the PIDs supported by your vehicle and the correct bit rate and CAN IDs, configure your transmit list with the PIDs of interest.

Consider these points:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses per request.
Spacing: Introduce a 300-500 ms delay between each CAN OBD2 request to prevent ECU overload, which can lead to non-responsiveness.
Battery Drain: Use triggers to halt transmissions when the vehicle is inactive to avoid unnecessary ECU wake-up and battery drain.
Filters: Implement filters to record only CAN OBD2 responses, especially if your vehicle also outputs OEM-specific CAN data.

Once these configurations are set, the device is ready to log raw CAN OBD2 data.

CANedge CAN OBD2 PID Request Example: A sample transmit list of CAN OBD2 PID requests configured for CANedge.

Decoded CAN OBD2 Data in asammdf: Visual plot of decoded CAN OBD2 data using asammdf software and a CAN bus DBC file.

#3: DBC Decoding of Raw CAN OBD2 Data

To effectively analyze and visualize logged data, you need to decode the raw CAN OBD2 data into ‘physical values’ like km/h or °C.

Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. We provide a free CAN OBD2 DBC file to simplify DBC decoding of raw CAN OBD2 data in most CAN bus software tools.

Decoding CAN OBD2 data is more complex than standard CAN signal decoding because different CAN OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone isn’t sufficient to identify the signals within the payload.

This is resolved by using both the CAN ID, CAN OBD2 mode, and CAN OBD2 PID to uniquely identify signals. This multiplexing technique, known as ‘extended multiplexing‘, can be implemented in DBC files.

CANedge: CAN OBD2 Data Logger

The CANedge offers an easy way to record CAN OBD2 data onto 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 CAN OBD2 DBC file.

Explore the CAN OBD2 Logger Intro Learn more about CANedge

CAN OBD2 Multi-Frame Examples [ISO-TP]

All CAN OBD2 communication adheres to the ISO-TP (transport protocol) as per ISO 15765-2. While many examples are single-frame, multi-frame communication is also crucial.

Multi-frame CAN OBD2 communication requires flow control frames (see our UDS intro). 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, processing multi-frame CAN OBD2 responses necessitates CAN software or API tools that support ISO-TP, such as CANedge MF4 decoders.

CAN OBD2 Multi-Frame Request: Example of a multi-frame request message for Vehicle Identification Number (VIN) in CAN OBD2.

Example 1: CAN OBD2 Vehicle Identification Number (VIN) Retrieval

The Vehicle Identification Number (VIN) is essential for telematics, diagnostics, and more (see our UDS introduction for details). To retrieve the VIN using CAN 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, including the 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 (refer to ISO 15031-5 / SAE J1979 for specifics). The subsequent 17 bytes constitute the VIN, convertible from HEX to ASCII as discussed in our UDS introduction.

Example 2: CAN OBD2 Multi-PID Request (6x)

External tools can request up to 6 mode 0x01 CAN OBD2 PIDs in a single request frame. The ECU will respond with data for supported PIDs (omitting unsupported ones), potentially across multiple frames as per ISO-TP.

This efficient method allows for higher frequency CAN OBD2 data collection. However, it also means signal encoding is specific to your request method, complicating the use of generic CAN OBD2 DBC files. We generally advise against this method for practical use. 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 mandated by ISO 15031-5.

Decoding such responses via DBC files is challenging, making this approach impractical for general data logging unless you use tools specifically designed for it. The complexity arises from extended multiplexing, where the DBC file would need to account for the payload position of each PID, making it difficult to generalize across vehicles with varying supported PIDs. Managing multiple such multi-PID requests further complicates DBC handling.

Workarounds could involve custom scripts and recording transmit messages, enabling the script to interpret response messages in conjunction with request messages. However, these approaches are generally complex to scale.

Example 3: CAN OBD2 Diagnostic Trouble Codes (DTCs)

CAN OBD2 can be used 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 stored DTCs (possibly 0 if none), 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 structured 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, as visualized. Decoded DTC values can be looked up using CAN OBD2 DTC lookup tools like repairpal.com.

The example below shows a request to an ECU with 6 stored DTCs.

CAN OBD2 DTC Decoding Example: DBC interpretation of Diagnostic Trouble Codes in CAN OBD2.

CAN OBD2 Data Logging: Use Case Examples

CAN OBD2 data from cars and light trucks has diverse applications:

Car Data Logging

CAN OBD2 data logging in cars can be used for reducing fuel consumption, improving driving habits, testing prototype components, and insurance telematics.

Explore CAN OBD2 Loggers

Real-Time Car Diagnostics

CAN OBD2 interfaces enable real-time streaming of human-readable CAN OBD2 data for immediate vehicle diagnostics and issue identification.

Learn about CAN OBD2 Streaming

Predictive Maintenance

Monitoring cars and light trucks via IoT CAN OBD2 loggers in the cloud facilitates predictive maintenance, helping to anticipate and prevent breakdowns.

Discover Predictive Maintenance Solutions

Vehicle Black Box Logging

A CAN OBD2 logger can serve as a ‘black box’ for vehicles or equipment, providing critical data for dispute resolution or in-depth diagnostics.

Explore CAN Bus Black Box Loggers

Do you have a CAN OBD2 data logging application? Contact us for a free consultation!

For more introductory guides, see our tutorials section or download the ‘Ultimate Guide’ PDF.

Need to log or stream CAN OBD2 data?

Get your CAN OBD2 data logger today!

Purchase Now Contact Us for Support

Recommended Resources

CAN OBD2 DATA LOGGER: EASILY LOG & CONVERT CAN OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[