How to Log OBD2 Channels: A Comprehensive Guide

Looking for a straightforward and practical guide on OBD2 channel logging?

This guide provides a detailed introduction to the On-Board Diagnostics (OBD2) protocol, encompassing the OBD2 connector, OBD2 Parameter IDs (PIDs), and its connection to the CAN bus.

Note: This is designed as a practical guide to teach you how to effectively request and decode OBD2 data, highlighting key use cases for logging and offering practical tips.

Discover why this is considered a top resource for understanding OBD2 and How To Log Obd2 Channels.

You can also view our introductory OBD2 video above – or download the PDF guide.

Understanding OBD2: What is it?

OBD2 is essentially your car’s internal health monitoring system. It’s a standardized protocol that allows you to extract diagnostic trouble codes (DTCs) and access real-time data through the OBD2 connector. For those interested in vehicle performance and diagnostics, learning how to log OBD2 channels is a crucial skill.

You’ve likely already encountered OBD2 in action:

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

That’s your vehicle signaling a potential issue. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the problem.

The process involves connecting an OBD2 reader to the OBD2 16-pin connector, typically located near the steering wheel. This tool sends ‘OBD2 requests’ to the vehicle, which then responds with ‘OBD2 responses’. These responses can include vital information like speed, fuel level, and Diagnostic Trouble Codes (DTCs), making troubleshooting much more efficient. Understanding how these requests and responses work is fundamental to how to log OBD2 channels effectively.

Understanding OBD2: On-Board Diagnostics and the Malfunction Indicator Light (MIL)

OBD2 Compatibility: Does Your Car Support It?

The short answer: Almost certainly!

The vast majority of modern, non-electric vehicles are OBD2 compliant, and most operate on the CAN bus protocol. However, for older vehicles, even if a 16-pin OBD2 connector is present, it might not actually support OBD2. A reliable way to check compliance is to consider where and when the vehicle was originally purchased:

OBD2 Compliance Guide: Determine if Your Car Supports OBD2 based on Purchase Location and Year

A Brief History of OBD2

OBD2’s roots are in California. The California Air Resources Board (CARB) mandated OBD in all new vehicles from 1991 onwards to monitor and control emissions. This initial step was crucial for environmental regulation and set the stage for standardized vehicle diagnostics.

The Society of Automotive Engineers (SAE) further developed this concept by recommending the OBD2 standard. This standardization included Diagnostic Trouble Codes (DTCs) and a universal OBD connector across different manufacturers (SAE J1962). This standardization is what makes it possible to use generic tools for how to log OBD2 channels across different car brands.

The OBD2 standard was implemented gradually across different regions:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: Required in the EU for gasoline cars.
2003: Required in the EU for diesel cars as well (referred to as EOBD in Europe).
2005: OBD2 was mandated in the US for medium-duty vehicles.
2008: US vehicles were required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication.
2010: OBD2 became mandatory in the US for heavy-duty vehicles.

OBD2 Historical Timeline: From Emission Control Origins to Modern Automotive Data Standards

OBD2 History Timeline: Key Milestones in On-Board Diagnostics Development

The Future of OBD: OBD3, Remote Diagnostics, and Integration with Cloud and IoT Technologies

The Future of OBD2

OBD2 is expected to remain a key part of vehicle diagnostics for the foreseeable future, but its form and function are evolving.

Here are some significant trends to consider:

Originally, legislated OBD2 was mainly for emissions monitoring and testing. Interestingly, electric vehicles are not required to support OBD2 in the same way as combustion engine vehicles. In fact, most modern EVs do not support standard OBD2 requests. Instead, they often use OEM-specific UDS communication protocols. This makes accessing and decoding data from EVs challenging unless the decoding rules are reverse-engineered. However, progress is being made, as seen in case studies for electric cars including brands like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs. These case studies are valuable resources for those exploring how to log OBD2 channels and similar data from EVs.

Today, OBD2 implementations vary and face limitations in data richness and lower-layer protocols. To address these issues, newer alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. Both aim to improve OBD communication by using the UDS protocol as a base. For a deeper understanding of these protocols, refer to our introduction to UDS. Understanding these advancements is crucial for anyone looking to stay at the forefront of how to log OBD2 channels in modern vehicles.

In our increasingly connected world, traditional OBD2 testing methods can seem outdated. Manual emission checks are time-consuming and costly.

The proposed solution? OBD3 – integrating telematics into all vehicles.

OBD3 envisions adding a small radio transponder (similar to those used for bridge tolls) to every car. This would enable vehicles to transmit their vehicle identification number (VIN) and DTCs wirelessly via WiFi 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. These tools are essential for modern approaches to how to log OBD2 channels remotely and efficiently.

While this offers convenience and cost savings, it also raises political and privacy concerns regarding surveillance.

The original purpose of OBD2 was for stationary emission controls.

However, third parties now widely use OBD2 to generate real-time data, utilizing OBD2 dongles, CAN loggers and similar devices. Interestingly, the German car industry aims to restrict this practice:

OBD was intended for car servicing in repair shops. It was never designed to allow third parties to build a data-driven economy based on access through this interface.“

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal suggests disabling OBD2 functionality while driving and instead collecting data on a central server. This would effectively give manufacturers control over the ‘automotive big data’.

The rationale is based on security concerns, such as reducing the risk of car hacking), though many view it as a commercially motivated move. Whether this trend will prevail remains to be seen, but it could significantly impact the market for third-party OBD2 services and the methods for how to log OBD2 channels in the future.

Future OBD2 Challenges: Electric Vehicles and Potential Restrictions on Data Access

Enhance Your CAN Bus Expertise

Do you aspire to become a CAN bus expert?

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

Download now

OBD2 Standards Explained

On-board diagnostics, or OBD2, functions as a higher-layer protocol – essentially a language for vehicle communication. CAN, on the other hand, is the communication method itself, analogous to a telephone line. This makes OBD2 comparable to other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000. Understanding these layers is vital for mastering how to log OBD2 channels and interpret the data effectively.

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

These standards can be visualized using the 7-layer OSI model. In the following sections, we will 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 the standards established for OBD in the USA (SAE) and Europe (ISO). Many of these standards are technically very similar, for example, SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3. Adherence to these standards ensures compatibility and consistency in how to log OBD2 channels across different vehicles and diagnostic tools.

OBD2 and CAN Bus in the OSI Model: A 7-Layer Perspective on ISO 15765 and ISO 11898 Standards

OBD Connector Pinout: Type A Female Socket (Data Link Connector DLC) Diagram

The OBD2 Connector: SAE J1962 Standard

The 16-pin OBD2 connector provides easy access to your vehicle’s data and is standardized under SAE J1962 / ISO 15031-3. This connector is the physical interface point for anyone wanting to learn how to log OBD2 channels.

The illustration shows a typical Type A OBD2 pin connector, often referred to as the Data Link Connector (DLC).

Key points about the OBD2 connector:

It’s usually located near the steering wheel but can sometimes be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout configuration varies depending on the communication protocol used.
CAN bus is the most common lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are frequently connected. These CAN bus connections are essential for how to log OBD2 channels when using CAN-based tools.

OBD2 Connector Types: A vs. B

In practice, you might encounter both Type A and Type B OBD2 connectors. Type A is typically found in cars, while Type B is more common in medium and heavy-duty vehicles.

As shown in the illustration, both types have similar OBD2 pinouts but differ in power supply outputs (12V for Type A and 24V for Type B). Baud rates can also vary, with cars typically using 500K and heavy-duty vehicles often using 250K (though 500K support is increasing). Choosing the correct connector and understanding voltage differences are important considerations for how to log OBD2 channels safely and effectively.

A key physical difference is that the Type B OBD2 connector has an interrupted groove in the middle, which helps distinguish it from Type A. As a result, 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: Differentiating between 12V and 24V Connectors for Cars, Vans, and Trucks (SAE J1962)

OBD2 vs. CAN Bus: Understanding the Relationship under ISO 15765 Standards

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 per ISO 15765. This standardization of CAN bus is fundamental to how to log OBD2 channels in modern vehicles.

ISO 15765-4 (also known as Diagnostics over CAN or DoCAN) specifies a set of constraints applied to the CAN standard (ISO 11898).

Specifically, it standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers:

The 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 no longer than 5 meters.

OBD2 CAN Identifiers: 11-bit and 29-bit

All OBD2 communication involves a request-response message exchange. Understanding these identifiers is crucial for how to log OBD2 channels and interpret the communication.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, which is used to query all OBD2-compatible ECUs to see if they have data to report for the requested parameter (according to ISO 15765-4). In contrast, CAN IDs in the range 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests, targeting specific ECUs (less common).

ECUs can respond using 11-bit IDs in the range 0x7E8-0x7EF. The most common response ID is 0x7E8 (from the ECM, Engine Control Module), and to a lesser extent 0x7E9 (from the TCM, Transmission Control Module).

In some vehicles, particularly vans and light, medium, and heavy-duty vehicles, OBD2 communication may use extended 29-bit CAN identifiers instead of 11-bit IDs.

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

Responses from the vehicle will use CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). This response ID is sometimes represented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which in the J1939-71 standard is marked as ‘Reserved for ISO 15765-2’. Knowing these ID ranges is essential for correctly configuring tools to how to log OBD2 channels.

OBD2 Protocol Request and Response Frames: Structure of PID Data Parameters

OBD2 vs. Proprietary CAN Bus: Differentiating Standard and OEM-Specific Vehicle Data

OBD2 vs. Proprietary CAN Protocols

It is important to understand that your vehicle’s Electronic Control Units (ECUs) do not depend on OBD2 for their primary functions. Instead, each Original Equipment Manufacturer (OEM) develops their own proprietary CAN protocols for these purposes. These proprietary CAN protocols are often unique to the vehicle brand, model, and year. Unless you are the OEM, you will typically not be able to interpret this proprietary data without significant reverse engineering efforts (reverse engineer it). This distinction is key when considering how to log OBD2 channels versus accessing deeper, OEM-specific vehicle data.

If you connect a CAN bus data logger to your car’s OBD2 connector, you might observe OEM-specific CAN data, usually broadcast at a rate of 1000-2000 frames per second. However, many newer vehicles employ a ‘gateway’ that restricts access to this raw CAN data and only allows OBD2 communication through the OBD2 connector. This gateway system impacts how to log OBD2 channels and access broader vehicle network data.

In essence, think of OBD2 as an ‘additional’ higher-layer protocol that operates alongside the OEM-specific protocol. It’s a standardized layer for diagnostics and emissions data, separate from the vehicle’s core communication network.

Bit-rate and ID Validation

As previously mentioned, OBD2 can use two bit rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four possible combinations. In modern vehicles, 500K with 11-bit IDs is the most common setup. However, external diagnostic tools should systematically verify these settings. Proper validation of bit rate and ID is a foundational step in how to log OBD2 channels reliably.

ISO 15765-4 provides guidelines for a systematic initialization sequence to determine the correct combination, illustrated in the flowchart below. This method relies on the fact that OBD2-compliant vehicles must respond to a specific mandatory OBD2 request (see the OBD2 PID section for details). It also leverages the fact that transmitting data at an incorrect bit rate will cause CAN error frames. This validation process is crucial for ensuring successful communication when learning how to log OBD2 channels.

Newer versions of ISO 15765-4 acknowledge that vehicles may support OBD communication via OBDonUDS rather than OBDonEDS. While this article primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979) as opposed to WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).

To test for the ‘protocol’ of OBDonEDS versus 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 must have ECUs that respond to this DID. Understanding these protocol variations is important for advanced applications of how to log OBD2 channels.

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

OBD2 Bit-rate and CAN ID Validation Flowchart: Following ISO 15765-4 Guidelines

OBD2 Standard Protocols: Five Lower-Layer Protocols Including CAN (ISO 15765), KWP2000, SAE J1850, and ISO 9141

Five Lower-Layer OBD2 Protocols

Today, CAN (ISO 15765) serves as the primary lower-layer protocol for OBD2 in most vehicles. However, when working with older vehicles (pre-2008), it’s helpful to be aware of the other four lower-layer protocols that have been used for OBD2. The pinouts can also indicate which protocol might be in use in your vehicle. Being aware of these different protocols is helpful context when learning how to log OBD2 channels, especially in older vehicles.

ISO 15765 (CAN bus): Mandatory in US vehicles since 2008 and now widely used in most vehicles.
ISO14230-4 (KWP2000): Keyword Protocol 2000, commonly used in 2003+ vehicles, especially in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian vehicles from 2000-2004.
SAE J1850 (VPW): Mostly used in older GM vehicles.
SAE J1850 (PWM): Mostly used in older Ford vehicles.

Transporting OBD2 Messages via ISO-TP: ISO 15765-2

All OBD2 data is communicated over the CAN bus using a transport protocol known as ISO-TP (ISO 15765-2). This protocol enables the transmission of data payloads larger than 8 bytes, which is necessary in OBD2 for tasks like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. For more detailed information, see our introduction to UDS. Understanding ISO-TP is essential for advanced techniques in how to log OBD2 channels when dealing with multi-frame messages.

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). Here, the first data byte (PCI field) contains the payload length (excluding padding), leaving 7 bytes for the OBD2-related communication.

ISO 15765-2 ISO-TP Frame Types for 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. In simple terms, an OBD2 message consists of an identifier, a data length indicator (PCI field), and the data itself. The data is further broken down into Mode, Parameter ID (PID), and data bytes. Dissecting the OBD2 message structure is key to understanding how to log OBD2 channels and interpret the raw data.

OBD2 PIDs Message Structure: Breakdown of Raw Mode, PID, ID, and Data Bytes

Example: OBD2 Request and Response

Before delving into each component of the OBD2 message, consider this request-response example for the ‘Vehicle Speed’ parameter. This example provides a practical illustration of the concepts involved in how to log OBD2 channels.

In this scenario, 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 a message via CAN ID 0x7E8 and 3 payload bytes, which includes the Vehicle Speed value in the 4th byte, 0x32 (50 in decimal).

By consulting the decoding rules for OBD2 PID 0x0D, we can determine that the physical value is 50 km/h. This simple example demonstrates the fundamental process of requesting and receiving data when learning how to log OBD2 channels.

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

OBD2 Request and Response Example: CAN IDs 7DF and 7E8 for Vehicle Speed

OBD2 PID Example: Vehicle Speed Parameter ID 0D

OBD2 Service Modes: Overview of 10 Diagnostic Services Including Current Data, Freeze Frame, and DTC Clearing

The 10 OBD2 Services (Modes)

There are 10 standardized OBD2 diagnostic services, also known as 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. Understanding these modes is essential for effectively using OBD2 and how to log OBD2 channels for different diagnostic purposes.

Vehicles are not required to support all 10 OBD2 modes and may also support additional OEM-specific modes outside of these standard modes.

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

OBD2 Parameter IDs (PIDs)

Within each OBD2 mode, there are Parameter IDs (PIDs). PIDs are the specific data points you request and log when learning how to log OBD2 channels.

For example, mode 0x01 includes approximately 200 standardized PIDs that provide real-time data on parameters such as speed, RPM, and fuel level. However, a vehicle does not have to support all OBD2 PIDs within a given mode. In practice, most vehicles only support a subset of these available PIDs.

One PID is particularly important:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. When this PID is requested, the vehicle’s ECU responds with information about which PIDs from 0x01 to 0x20 it supports. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Further, PIDs 0x20, 0x40, 0x60, 0x80, 0xA0, and 0xC0 can be used to determine support for subsequent ranges of mode 0x01 PIDs. This initial PID check is a crucial first step in how to log OBD2 channels effectively, as it helps you identify what data is available.

OBD2 Protocol Request and Response Frames: Structure of PID Data Parameters

OBD2 PID Overview Tool: Service 01 Parameter ID Lookup

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs. This information is essential for decoding the raw data into meaningful physical values, as explained in our CAN bus introduction. Accurate decoding is a critical step after learning how to log OBD2 channels.

If you need to look up a mode 0x01 PID, our OBD2 PID overview tool is a helpful resource. It assists you in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

How to Log and Decode OBD2 Data: A Practical Guide

In this section, we provide a practical example of how to log OBD2 channels using the CANedge CAN bus data logger. The CANedge is an excellent tool for hands-on learning and application of OBD2 data logging.

The CANedge allows you to configure custom CAN frames for transmission, making it ideal for OBD2 logging.

Once configured, the device can be easily connected to your vehicle using our OBD2-DB9 adapter cable. This simple connection is the starting point for how to log OBD2 channels with CANedge.

OBD2 PID Data Logger Request: Example of 7DF and 7E8 CAN ID Communication

Validating Bit Rate for OBD2 Logging: Testing CAN Frame Transmission at 500K

Verifying Supported PIDs: Reviewing Responses in asammdf for OBD2 Validation

Step #1: Test Bit-rate, IDs, and Supported PIDs

As discussed earlier, ISO 15765-4 outlines how to determine the correct bit rate and IDs for a specific vehicle. You can use the CANedge to perform these tests, as described below (refer to the CANedge Intro for detailed instructions): This initial testing is a critical step in how to log OBD2 channels correctly.

Test CAN Frame Transmission at 500K: Send a CAN frame at 500K and check if it is successfully transmitted. If not, try 250K.
Use Identified Bit Rate: Use the successfully tested bit rate for all subsequent communication.
Send ‘Supported PIDs’ Requests: Transmit multiple ‘Supported PIDs’ requests and analyze the responses.
Determine 11-bit vs. 29-bit IDs: Based on the response IDs, determine whether 11-bit or 29-bit IDs are in use.
Identify Supported PIDs: Analyze the response data to see which PIDs are supported by the vehicle.

We provide ready-to-use configurations to simplify these tests. These configurations are designed to make the initial setup for how to log OBD2 channels as easy as possible.

Most non-EV cars manufactured in 2008 or later support 40-80 PIDs using a 500K bit rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol.

As shown in the asammdf GUI screenshot, it is common to receive multiple responses to a single OBD request. This is because we use the 0x7DF request ID, which is a functional address that polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, there are often numerous responses to this specific PID. As you proceed with subsequent ‘Supported PIDs’ requests, you will likely see fewer ECUs responding. Note that the ECM ECU (0x7E8) in this example supports all the PIDs supported by other ECUs. Therefore, to reduce bus load, you could specifically target only this ECU for responses in future communication by switching to the ‘Physical Addressing’ CAN ID 0x7E0. Understanding ECU addressing is key to efficient how to log OBD2 channels practices.

Step #2: Configure OBD2 PID Requests

Once you’ve identified the OBD2 PIDs supported by your vehicle and the correct bit rate and CAN IDs, you can configure your data logger to request the specific PIDs you are interested in. This configuration is the heart of how to log OBD2 channels for your specific needs.

Consider these points when configuring your PID requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid receiving multiple responses for each request, especially after identifying the primary ECU providing the data you need.
Spacing: Introduce a delay of 300-500 ms between each OBD2 request. Overly frequent requests can overwhelm ECUs and cause them to stop responding. Proper request spacing is a key technique in how to log obd2 channels reliably.
Battery Drain: Implement triggers to stop transmitting requests when the vehicle is inactive. This prevents unnecessary battery drain by avoiding ‘waking up’ ECUs when the vehicle is off. Battery management is an important practical consideration when learning how to log OBD2 channels for extended periods.
Filters: Set up filters to record only OBD2 responses, particularly if your vehicle also outputs OEM-specific CAN data. This helps keep your logs clean and focused on the OBD2 data you need. Filtering is an essential step for efficient how to log OBD2 channels in environments with mixed CAN traffic.

With these configurations in place, your device is now set up to log raw OBD2 data effectively!

CANedge OBD2 PID Request Example: Transmit List Configuration

OBD2 Data Visualization: Decoded and Plotted in asammdf using a CAN bus DBC file

Step #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). Decoding is the final, crucial step in how to log OBD2 channels and make sense of the collected data.

The necessary decoding information is available in ISO 15031-5/SAE J1979 and also on resources like Wikipedia. For convenience, we offer a free OBD2 DBC file. This DBC file simplifies DBC decoding of raw OBD2 data in most CAN bus software tools.

Decoding OBD2 data is somewhat more complex than standard CAN signal decoding. This is because different OBD2 PIDs are transmitted using the same CAN ID (e.g., 0x7E8). Therefore, the CAN ID alone is not enough to uniquely identify the signals encoded in the payload.

To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID together to identify each signal. This form of multiplexing is known as ‘extended multiplexing‘. It can be implemented using tools like DBC files. Understanding extended multiplexing is key to accurately decoding data when learning how to log OBD2 channels.

CANedge: Your OBD2 Data Logging Solution

The CANedge provides an easy way to record OBD2 data directly to an 8-32 GB SD card. Just connect it to your car or truck to start logging. You can then decode the data using free software and APIs and our OBD2 DBC file. The CANedge simplifies the entire process of how to log OBD2 channels, from setup to data analysis.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples: ISO-TP in Action

All OBD2 communication relies on the ISO-TP (transport protocol) as defined by ISO 15765-2. While most examples discussed so far involve single-frame communication, this section provides examples of multi-frame communication, which is essential for understanding more complex scenarios in how to log OBD2 channels.

Multi-frame OBD2 communication requires flow control frames (see our UDS introduction). In practice, you can often achieve this by transmitting a static flow control frame approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example. Handling flow control is a critical aspect of managing multi-frame communication when learning how to log OBD2 channels.

Furthermore, processing multi-frame OBD2 responses requires CAN software and API tools that support ISO-TP, such as the CANedge MF4 decoders.

OBD2 Multi-Frame Request Example: Message for Vehicle Identification Number (VIN)

Example 1: OBD2 Vehicle Identification Number (VIN)

The Vehicle Identification Number (VIN) is often needed for telematics, diagnostics, and more (see our introduction to UDS for more details). To retrieve the VIN from a vehicle using OBD2 requests, you use mode 0x09 and PID 0x02: Retrieving the VIN is a common application of how to log OBD2 channels for vehicle identification.

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 that includes the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID, there is the byte 0x01, which represents the Number Of Data Items (NODI), in this case, 1 (see ISO 15031-5 / SAE J1979 for details). The subsequent 17 bytes contain the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction. This example illustrates the process of handling multi-frame responses when learning how to log OBD2 channels for VIN retrieval.

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 will respond with data for the supported PIDs (omitting data for unsupported PIDs from the response), potentially using multiple frames as per ISO-TP if needed. Multi-PID requests are an advanced technique in how to log OBD2 channels for efficient data collection.

This is a powerful feature for collecting OBD2 data more frequently and efficiently. However, it also means that signal encoding is specific to your request method, making it difficult to use generic OBD2 DBC files for decoding. We generally do not recommend using this method in practice unless specifically needed. Below is an example trace of what this communication might look like:

The multi-frame response is similar to the VIN example but includes the requested PIDs and their corresponding data within the payload. Note that the PIDs in the example are ordered similarly to their request order, which is common but not strictly mandated by the ISO 15031-5 standard. Understanding the structure of multi-PID responses is essential for advanced applications of how to log OBD2 channels.

Decoding these responses using generic DBC files is challenging. Therefore, we advise against this approach for practical data logging unless you are using a tool specifically designed to support it. Effectively, you are dealing with extended multiplexing with multiple instances throughout the payload. Moreover, your DBC file would need to account for the specific payload position of each PID, making it hard to generalize across different vehicles with varying supported PIDs. This complexity highlights the challenges in efficiently decoding multi-PID responses when learning how to log OBD2 channels.

Handling this becomes even more complex if you send several such multi-PID requests, as you will lack a method to uniquely identify these messages from each other purely through DBC manipulations.

A potential workaround is to use a custom script and record the transmit messages from your testing tool. The script could then interpret the response message in conjunction with the request message. However, such methods are generally difficult to manage at scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

You can use OBD2 to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes’. No PID is included in the request. The targeted ECU(s) will respond with the number of DTCs they have stored (which could be 0 if no DTCs are present), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored. Retrieving DTCs is a fundamental diagnostic task when learning how to log OBD2 channels.

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 various OBD2 DTC lookup tools, such as repairpal.com. DTC lookup tools are invaluable resources in the diagnostic process after learning how to log OBD2 channels.

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

OBD2 DTC Decoding Example: DBC Interpretation of Diagnostic Trouble Codes

Real-World Applications of OBD2 Data Logging

OBD2 data logging from cars and light trucks has numerous practical applications: Understanding these applications can motivate your learning journey in how to log OBD2 channels.

Vehicle Data Logging

OBD2 data from passenger vehicles can be used to optimize fuel efficiency, improve driving habits, test prototype components, and for insurance telematics. These are practical examples of how how to log OBD2 channels can be applied in real-world scenarios.

obd2 logger

Real-Time Vehicle Diagnostics

OBD2 interfaces enable real-time streaming of vehicle data, which is invaluable for diagnosing vehicle issues and monitoring performance. Real-time diagnostics are a key benefit of learning how to log OBD2 channels.

obd2 streaming

Predictive Maintenance

Cars and light trucks can be monitored via IoT-connected OBD2 loggers in the cloud to predict and prevent potential breakdowns, enhancing vehicle reliability and uptime. Predictive maintenance is a sophisticated application of how to log OBD2 channels in IoT contexts.

predictive maintenance

Vehicle Black Box Recording

An OBD2 logger can serve as a ‘black box’ for vehicles or equipment, providing crucial data for incident analysis, dispute resolution, and diagnostic forensics. Black box functionality is another compelling use case for how to log OBD2 channels.

can bus blackbox

Do you have an OBD2 data logging application in mind? Reach out to us for a free consultation!

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

Ready to start logging or streaming 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