OBD2 CAN Bus Pins: Your Guide to Understanding the OBD2 Connector

Want to understand the OBD2 connector and CAN bus pins?

This guide provides a detailed look at the OBD2 protocol, focusing specifically on the OBD2 connector and CAN bus pins. We’ll explore the OBD2 pinout, the role of CAN bus in OBD2 communication, and how to access vehicle data through these pins.

This is your practical guide to understanding the Obd2 Can Bus Pins.

You can also watch our OBD2 intro video above – or get the PDF

Understanding OBD2 and its Connector

OBD2, or On-Board Diagnostics version 2, is your car’s built-in diagnostic system. It’s a standardized protocol that allows you to retrieve diagnostic trouble codes (DTCs) and access real-time vehicle data through the OBD2 connector.

You’ve likely already encountered OBD2 in action. The malfunction indicator light, often called the “check engine light,” on your dashboard is part of the OBD2 system.

When this light illuminates, it signals a problem. Mechanics use an OBD2 scanner to diagnose these issues. They connect the scanner to the OBD2 16 pin connector, usually located near the steering wheel. This tool sends ‘OBD2 requests’ to your car, and the car responds with ‘OBD2 responses’ containing information like speed, fuel level, or DTCs. This process significantly speeds up troubleshooting.

Understanding OBD2: On-Board Diagnostics and the Malfunction Indicator Light (MIL) with a scan tool connected to the OBD2 port.

OBD2 Compatibility: Does Your Car Have It?

Most likely, yes!

The vast majority of modern non-electric cars are OBD2 compliant and utilize CAN bus for communication. However, for older vehicles, the presence of a 16-pin OBD2 connector doesn’t automatically guarantee OBD2 support. Some older cars might have the connector but not the full OBD2 protocol. To confirm OBD2 compliance, consider the car’s origin and purchase date:

OBD2 Compliance Guide: Determine if your car is OBD2 compliant based on purchase location and year – EU, US, and CAN.

A Brief History of OBD2

OBD2’s story begins in California. The California Air Resources Board (CARB) mandated OBD in all new cars from 1991 onwards for emission control.

The Society of Automotive Engineers (SAE) further developed the standard, leading to standardized DTCs and the OBD connector (SAE J1962). This standardization across manufacturers was crucial.

The OBD2 standard was implemented globally in phases:

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

OBD2 History: Timeline of emission control and OBD2 implementation, linking to exhaust standards, EOBD2, EOBDII, car data, and CAN bus.

OBD2 History Timeline Overview: A visual timeline summarizing the history of On-Board Diagnostics.

OBD2 Future: Depicting OBD3 trends towards remote diagnostics, emissions testing, cloud integration, and IoT.

The Future of OBD2

OBD2 is established, but its evolution continues.

Key trends shaping its future include:

Initially, OBD2 was designed for emissions control. This has implications for electric vehicles (EVs), which are not legally obligated to support OBD2. Indeed, most modern EVs do not support standard OBD2 requests. Instead, they often use OEM-specific UDS communication protocols. This makes accessing data from EVs challenging unless decoding methods are reverse-engineered. However, progress is being made in reverse engineering, as demonstrated in case studies for EVs like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

OBD2 faces limitations in data richness and lower-layer protocols. Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging. These aim to enhance OBD communication using the UDS protocol. Learn more about these in our intro to UDS.

In our connected world, manual OBD2 emission tests are becoming inefficient. OBD3, incorporating telematics, is a potential solution.

OBD3 envisions adding a small radio transponder to vehicles, similar to those used for bridge tolls. This would allow the car’s vehicle identification number (VIN) and DTCs to be wirelessly transmitted to a central server for automated checks.

Devices like the CANedge2 WiFi CAN logger and CANedge3 3G/4G CAN logger already enable CAN/OBD2 data transfer via WiFi/cellular.

While convenient and cost-saving, OBD3 raises privacy concerns.

OBD2 was initially for in-garage emission checks. Today, it’s widely used by third parties for real-time data via OBD2 dongles, CAN loggers and more. However, the German car industry seeks to limit this:

“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“

- Christoph Grote, SVP Electronics, BMW (2017)*

The proposal is to disable OBD2 functionality during driving and centralize data collection with manufacturers. This would give manufacturers control over ‘automotive big data’ and is argued to improve security by reducing car hacking risks. However, many view this as a commercial strategy. Whether this trend will materialize and disrupt the OBD2 third-party service market remains to be seen.

OBD2 Future: Illustrating electric vehicles potentially blocking data access through the OBD2 connector.

Get our ‘Ultimate CAN Guide’

Want to become a CAN bus expert?

Get our 12 ‘simple intros’ in one 160+ page PDF:

Download now

OBD2 Standards and the OBD2 Connector Pinout

On-board diagnostics 2 (OBD2) is a higher-layer protocol (like a language). CAN (Controller Area Network) bus serves as the communication method (like a phone line). OBD2 is similar to other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

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

These standards can be organized within the 7-layer OSI model. The following sections focus on the most crucial aspects, especially the OBD2 CAN bus pins.

In the OSI model context, note that both SAE and ISO standards cover multiple layers. This reflects OBD standards defined in the US (SAE) and EU (ISO). Many standards are technically very similar, for instance, SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3.

OBD2 vs CAN Bus OSI Model: Illustrating the 7-layer OSI model with ISO 15765 and ISO 11898 standards for OBD2 and CAN Bus.

OBD2 Connector Pinout Socket Female Type A DLC: Detailed pinout diagram of a female Type A OBD2 connector, also known as Data Link Connector (DLC).

The OBD2 Connector: SAE J1962 and CAN Bus Pins

The 16-pin OBD2 connector, standardized in SAE J1962 / ISO 15031-3, provides easy access to vehicle data. Understanding the OBD2 CAN bus pins is essential for anyone working with vehicle diagnostics or data acquisition.

The illustration above shows a Type A OBD2 pin connector (sometimes called Data Link Connector, or DLC).

Key points about the OBD2 connector and its CAN bus pins:

The connector is typically near the steering wheel, but its exact location can be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The complete OBD2 pinout varies depending on the communication protocol used by the vehicle.
For vehicles using CAN bus, the OBD2 CAN bus pins are pins 6 (CAN-High) and 14 (CAN-Low). These are the crucial pins for CAN bus communication over OBD2. In most modern cars, pins 6 and 14 are connected for CAN bus functionality.

OBD2 Connector Types: A vs. B

You may encounter 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 a similar OBD2 pinout, including OBD2 CAN bus pins, but differ in power supply outputs (12V for Type A, 24V for Type B). Baud rates can also vary, with cars typically using 500K and heavy-duty vehicles often using 250K (with increasing support for 500K).

Type B OBD2 connectors have a distinguishing interrupted groove in the middle. A Type B OBD2 adapter cable is compatible with both Type A and B sockets, whereas a Type A adapter will not fit into a Type B socket. Regardless of the type, pins 6 and 14 remain the OBD2 CAN bus pins.

OBD2 Connector Type A vs B: Comparison of Type A and Type B OBD2 connectors (SAE J1962) for cars, vans, and trucks, highlighting 12V vs 24V power.

OBD2 vs CAN bus ISO15765: Diagram contrasting OBD2 and CAN bus with reference to ISO15765 standards.

OBD2 and CAN Bus: ISO 15765-4 and OBD2 CAN Bus Pins

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in US cars, as specified by ISO 15765. This means understanding OBD2 CAN bus pins is crucial for modern vehicle diagnostics.

ISO 15765-4 (Diagnostics over CAN, or DoCAN) sets specific rules for using CAN in OBD2, based on the CAN standard (ISO 11898).

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

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

Crucially, when working with CAN bus over OBD2, you will be interfacing directly with the OBD2 CAN bus pins: pin 6 (CAN-H) and pin 14 (CAN-L).

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

OBD2 communication via CAN bus always involves request and response messages. These messages are transmitted over the OBD2 CAN bus pins.

Most cars use 11-bit CAN IDs for OBD2. The ‘Functional Addressing’ ID is 0x7DF, used to query all OBD2-compatible ECUs for data on a requested parameter (ISO 15765-4). ‘Physical Addressing’ requests to specific ECUs use CAN IDs 0x7E0-0x7E7, but are less common.

ECUs respond with 11-bit IDs in the range 0x7E8-0x7EF. The most frequent response ID is 0x7E8 (Engine Control Module, ECM), followed by 0x7E9 (Transmission Control Module, TCM). All of this communication happens through the OBD2 CAN bus pins.

Some vehicles, particularly vans and medium/heavy-duty vehicles, may use extended 29-bit CAN identifiers for OBD2 instead of 11-bit IDs.

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

Responses use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is sometimes given in ‘J1939 PGN’ form, specifically PGN 0xDA00 (55808), which is ‘Reserved for ISO 15765-2’ in the J1939-71 standard. Again, all communication uses the OBD2 CAN bus pins.

OBD2 Protocol Request and Response Frames: Visualizing OBD2 protocol request and response frames, highlighting PID and data parameters.

OBD2 vs Proprietary CAN bus: Diagram comparing OBD2 and OEM-specific proprietary CAN bus data.

OBD2 vs. Proprietary CAN Protocols

It’s important to understand that your car’s ECUs don’t rely on OBD2 for their core functions. Each OEM implements proprietary CAN protocols for vehicle operation. These protocols are often unique to the vehicle brand, model, and year. Decoding this proprietary data is usually impossible without OEM documentation or reverse engineering.

Connecting a CAN bus data logger to the OBD2 connector might capture OEM-specific CAN data, typically broadcast at 1000-2000 frames/second. However, newer cars often use a ‘gateway’ to block access to this data, allowing only OBD2 communication via the OBD2 connector and OBD2 CAN bus pins.

Think of OBD2 as an ‘extra’ higher-layer protocol running alongside the OEM-specific protocol. Both protocols might be present on the same CAN bus network accessible through the OBD2 CAN bus pins.

Bit-rate and ID Validation

OBD2 over CAN can use 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, but diagnostic tools should systematically verify this. Correct communication relies on proper connection to the OBD2 CAN bus pins.

ISO 15765-4 provides initialization sequences to determine the correct combination. This process uses the fact that OBD2-compliant vehicles must respond to a mandatory OBD2 request (see the OBD2 PID section) and that incorrect bit-rates cause CAN error frames.

Newer ISO 15765-4 versions account for OBD communication via OBDonUDS versus OBDonEDS. This article mainly discusses OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979) rather than WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).

To test for OBDonEDS vs. OBDonUDS protocol, tools may send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). OBDonUDS-supporting vehicles must have ECUs that respond to this DID.

OBDonEDS (aka OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in non-EV cars today, while WWH-OBD is mainly used in EU trucks/buses. Regardless of the specific OBD protocol, CAN communication relies on the OBD2 CAN bus pins.

OBD2 bit-rate and CAN ID validation: Flowchart illustrating OBD2 bit-rate and CAN ID validation process according to ISO 15765-4.

OBD2 Standards: Visual overview of five OBD2 protocols including CAN (ISO 15765), KWP2000, SAE J1850, and ISO 9141.

Five Lower-Layer OBD2 Protocols

CAN bus (ISO 15765) is now the primary lower-layer protocol for OBD2 in most cars. Communication happens through the OBD2 CAN bus pins.

However, older (pre-2008) cars might use other protocols. Knowing these and their pinouts can be helpful:

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used today. Uses OBD2 CAN bus pins 6 and 14.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ cars, especially in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian cars around 2000-2004.
SAE J1850 (VPW): Mostly used in older GM vehicles.
SAE J1850 (PWM): Mostly used in older Ford vehicles.

ISO-TP for OBD2 Messaging: ISO 15765-2

All OBD2 data is transmitted over CAN bus using ISO-TP (ISO 15765-2), a transport protocol. This allows for messages larger than 8 bytes, necessary for OBD2 functions like retrieving the VIN or DTCs. ISO 15765-2 handles segmentation, flow control, and reassembly. For more detail, see our intro to UDS. This protocol operates over the OBD2 CAN bus pins.

Often, OBD2 data fits within a single CAN frame. ISO 15765-2 specifies ‘Single Frame’ (SF) usage, where the first data byte (PCI field) indicates payload length (excluding padding), leaving 7 bytes for OBD2 data.

ISO 15765-2 ISO-TP OBD2 frame types: Diagram of ISO-TP (ISO 15765-2) frame types used in OBD2 communication.

The OBD2 Diagnostic Message: SAE J1979, ISO 15031-5

To understand OBD2 over CAN, consider a raw ‘Single Frame’ OBD2 CAN message transmitted via the OBD2 CAN bus pins. Simplified, an OBD2 message includes an identifier, data length (PCI field), and data. The data portion is further divided into Mode, Parameter ID (PID), and data bytes.

OBD2 PIDs OBD-II Message Structure: Breakdown of an OBD2 message structure, explaining Mode, PID, ID, and data bytes.

OBD2 Request/Response Example

Let’s examine a request/response example for ‘Vehicle Speed’. Communication happens through the OBD2 CAN bus pins.

A tool sends a request to the car with CAN ID 0x7DF and 2 payload bytes: Mode 0x01 and PID 0x0D. The car responds with CAN ID 0x7E8 and 3 payload bytes, including the speed value in the 4th byte, 0x32 (50 decimal).

Consulting OBD2 PID 0x0D decoding rules reveals that 0x32 corresponds to 50 km/h.

Next, we’ll explore OBD2 modes and PIDs, which are transmitted via the OBD2 CAN bus pins.

OBD2 request 7DF response 7e8: Example of an OBD2 request (7DF) and response (7E8) sequence.

OBD2 PID example Vehicle Speed 0D: Example of OBD2 PID 0D for Vehicle Speed.

OBD2 services modes: Overview of OBD2’s 10 PID modes or diagnostic services, including current data, freeze frame, and clear DTC.

The 10 OBD2 Services (Modes)

There are 10 standard OBD2 diagnostic services or modes. Mode 0x01 provides real-time data, while others handle DTCs or freeze frame data. These modes are accessed via the OBD2 CAN bus pins.

Vehicles are not required to support all OBD2 modes and may also have OEM-specific modes beyond the standard 10.

In OBD2 messages, the mode is in the 2nd byte. In requests, the mode is directly included (e.g., 0x01). In responses, 0x40 is added to the mode value (e.g., 0x41).

OBD2 Parameter IDs (PIDs)

Each OBD2 mode contains Parameter IDs (PIDs). These PIDs are requested and returned via the OBD2 CAN bus pins.

For instance, mode 0x01 includes ~200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles typically support only a subset of these PIDs.

One PID is particularly important: mode 0x01 PID 0x00. If an emissions-related ECU supports any OBD2 services, it must support this PID. Responding to PID 0x00, the ECU indicates support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental OBD2 compatibility test. PIDs 0x20, 0x40, …, 0xC0 can be used to check support for the remaining mode 0x01 PIDs.

OBD2 Protocol Request and Response Frames: Visualizing OBD2 protocol request and response frames, highlighting PID and data parameters.

OBD2 PID overview tool service 01: Screenshot of an OBD2 PID overview tool focused on service 01.

Tip: OBD2 PID Overview Tool

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

Our OBD2 PID overview tool is helpful for looking up mode 0x01 PIDs. It assists in constructing OBD2 request frames and dynamically decoding responses received via the OBD2 CAN bus pins.

OBD2 PID overview tool

Logging and Decoding OBD2 Data

This section provides a practical example of logging OBD2 data using the CANedge CAN bus data logger. This process involves communication over the OBD2 CAN bus pins.

The CANedge allows custom CAN frame transmission, enabling OBD2 logging.

Connect the CANedge to your vehicle’s OBD2 port using our OBD2-DB9 adapter cable. This connection provides access to the OBD2 CAN bus pins.

OBD2 PID data logger request 7df 7e8: Diagram showing an OBD2 data logger requesting PID data with CAN IDs 7df and 7e8.

Validating OBD2 bit rate: Screenshot showing bit-rate validation in OBD2 testing.

OBD2 Supported PIDs Test Responses in asammdf: Screenshot of OBD2 Supported PIDs test responses viewed in asammdf.

#1: Test Bit-rate, IDs & Supported PIDs

ISO 15765-4 outlines how to determine the bit-rate and IDs for a vehicle. The CANedge can perform these tests (see the CANedge Intro):

Send a CAN frame at 500K and check for success (if unsuccessful, try 250K). This test is performed over the OBD2 CAN bus pins.
Use the identified bit-rate for further communication.
Send multiple ‘Supported PIDs’ requests and review the responses.
Determine 11-bit vs. 29-bit IDs based on response IDs.
Identify supported PIDs from the response data.

We provide plug-and-play configurations for these tests.

Most 2008+ non-EV cars support 40-80 PIDs using 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol, all communicated through the OBD2 CAN bus pins.

The asammdf GUI screenshot illustrates multiple responses to a single OBD request due to the 0x7DF request ID polling all ECUs. Because all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, many responses to this PID are common. Subsequent ‘Supported PIDs’ requests receive fewer responses. The ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, so busload can be reduced by directing subsequent requests only to the ECM using ‘Physical Addressing’ CAN ID 0x7E0. All communication occurs via the OBD2 CAN bus pins.

#2: Configure OBD2 PID Requests

Once you know the supported PIDs, bit-rate, and CAN IDs for your vehicle, configure your transmit list with desired PIDs. Remember that these requests and responses will be transmitted over the OBD2 CAN bus pins.

Consider these points:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses.
Spacing: Add 300-500 ms between OBD2 requests to prevent ECU overload.
Battery Drain: Use triggers to stop transmissions when the vehicle is inactive.
Filters: Add filters to record only OBD2 responses if OEM-specific CAN data is also present on the OBD2 CAN bus pins.

With configuration complete, the device is ready to log raw OBD2 data via the OBD2 CAN bus pins!

Example of CANedge OBD2 PID requests transmit list: Screenshot showing an example list of CANedge OBD2 PID requests.

OBD2 data decoded visual plot asammdf CAN bus DBC file: Visual plot of decoded OBD2 data using asammdf, CAN bus, and a DBC file.

#3: DBC Decode Raw OBD2 Data

To analyze and visualize logged data, decode the raw OBD2 data into ‘physical values’ (e.g., km/h, °C). Decoding relies on understanding the data transmitted over the OBD2 CAN bus pins.

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

Decoding OBD2 data is more complex than standard CAN signals because different OBD2 PIDs use the same CAN ID (e.g., 0x7E8). The CAN ID alone isn’t enough to identify the payload signals.

Signal identification requires using the CAN ID, OBD2 mode, and OBD2 PID. This is ‘extended multiplexing’, implementable in DBC files.

CANedge: OBD2 Data Logger

The CANedge easily records OBD2 data to an 8-32 GB SD card. Connect to a car or truck to start logging and decode data using free software/APIs and our OBD2 DBC. Data is transmitted and logged via the OBD2 CAN bus pins.

OBD2 logger intro CANedge

OBD2 Multi-Frame Examples: ISO-TP

OBD2 communication uses ISO-TP (ISO 15765-2) for all data, including multi-frame messages. This communication happens through the OBD2 CAN bus pins. Most examples so far were single-frame. Here are multi-frame examples.

Multi-frame OBD2 needs flow control frames (see our UDS intro). A static flow control frame can be sent ~50 ms after the initial request, as shown in the CANedge configuration example.

Multi-frame OBD2 responses require ISO-TP-supporting CAN software/API tools like CANedge MF4 decoders.

OBD2 multi-frame request message Vehicle Identification Number: Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN).

Example 1: OBD2 Vehicle Identification Number (VIN)

The VIN is important for telematics and diagnostics (see our UDS intro). Retrieve the VIN using OBD2 mode 0x09 and PID 0x02. Communication happens via the OBD2 CAN bus pins.

The tool sends a Single Frame request with PCI field (0x02), request service identifier (0x09), and PID (0x02) via the OBD2 CAN bus pins.

The vehicle responds with a First Frame containing PCI, length (0x014 = 20 bytes), mode (0x49), and PID (0x02). Byte 0x01 follows the PID, indicating Number Of Data Items (NODI) – in this case, 1 (see ISO 15031-5 / SAE J1979). The remaining 17 bytes are the VIN, convertible from HEX to ASCII.

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

Tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame via the OBD2 CAN bus pins. The ECU responds with data for supported PIDs (skipping unsupported ones), possibly using multiple frames as per ISO-TP.

This improves data collection frequency and efficiency, but signal encoding becomes request-specific, making generic OBD2 DBC files less useful. We don’t recommend this method practically. Here’s an example trace:

The multi-frame response is similar to the VIN example but includes requested PIDs and their data. PIDs are often ordered as requested, common but not strictly ISO 15031-5 compliant. Communication is over the OBD2 CAN bus pins.

Decoding these responses with generic DBC files is difficult. It’s extended multiplexing, but with multiple instances, making DBC generalization hard. DBC files would need to account for each PID’s payload position, complicating cross-vehicle generalization. Handling multiple multi-PID requests via DBC manipulation becomes very difficult.

Workarounds exist, like custom scripts combined with recording transmit messages, interpreting responses relative to requests. However, these approaches are hard to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

Use OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes’, to request emissions-related DTCs. No PID is in the request. ECUs respond with the number of stored DTCs (possibly 0), each DTC being 2 bytes, requiring multi-frame responses for more than 2 DTCs. Communication is over the OBD2 CAN bus pins.

The 2-byte DTC value is split, as per ISO 15031-5/ISO 15031-6. The first 2 bits are the ‘category’, and the remaining 14 bits form a 4-digit hexadecimal code. Decoded DTC values can be looked up using OBD2 DTC lookup tools like repairpal.com.

Example below shows a request to an ECU with 6 stored DTCs. Communication is via the OBD2 CAN bus pins.

OBD2 DTC Diagnostic Trouble Code DBC Interpretation: Example of OBD2 DTC (Diagnostic Trouble Code) DBC interpretation.

OBD2 Data Logging – Use Case Examples

OBD2 data from cars and light trucks has various applications:

Logging data from cars

OBD2 data helps reduce fuel costs, improve driving, test parts, and for insurance.

obd2 logger

Real-time car diagnostics

OBD2 interfaces stream human-readable data for diagnosing vehicle issues in real-time.

obd2 streaming

Predictive maintenance

IoT OBD2 loggers monitor cars/trucks in the cloud for predictive maintenance to avoid breakdowns.

predictive maintenance

Vehicle blackbox logger

OBD2 loggers serve as ‘black boxes’ for vehicles/equipment, providing data for disputes or diagnostics.

can bus blackbox

Have an OBD2 data logging use case? Contact us for free consultation!

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

Need to log/stream OBD2 data?

Get your OBD2 data logger today!

Buy now Contact us

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[