Decoding the CAN Bus OBD2 Connector: Your Comprehensive Guide

Looking for a deep dive into the Can Bus Obd2 Connector?

This guide offers an expert exploration of the On-Board Diagnostics (OBD2) protocol, specifically focusing on the crucial CAN bus OBD2 connector. We’ll unravel the complexities of OBD2, including parameter IDs (PIDs), and its intricate relationship with the Controller Area Network (CAN) bus.

This isn’t just a basic overview – it’s a comprehensive guide designed to equip you with practical knowledge. You’ll learn how to effectively request and decode OBD2 data, understand vital logging applications, and gain actionable tips for real-world scenarios.

Discover why this article is rapidly becoming the go-to resource for understanding the CAN bus OBD2 connector.

You can also explore our introductory video on OBD2 above – or download the PDF guide for offline access.

Inside This Guide:

Author: Martin Falch (Automotive Diagnostics Specialist) – Updated January 2025

Download as PDF

Understanding OBD2 and Its Core: The CAN Bus OBD2 Connector

OBD2 serves as your vehicle’s inherent self-diagnostic system. It’s a standardized protocol that enables the extraction of diagnostic trouble codes (DTCs) and real-time vehicle data through the CAN bus OBD2 connector. This connector is the physical gateway to your vehicle’s diagnostic information.

You’ve likely encountered OBD2 in action:

Ever noticed the check engine light, officially known as the malfunction indicator light, illuminating on your dashboard?

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

This process involves connecting an OBD2 reader to the 16-pin CAN bus OBD2 connector, typically located near the steering wheel. This tool transmits ‘OBD2 requests’ to the vehicle, and the car responds with ‘OBD2 responses’. These responses can contain a wealth of information, including speed readings, fuel levels, and Diagnostic Trouble Codes (DTCs), significantly speeding up the troubleshooting and repair process.

OBD2 Compatibility: Does Your Car Have a CAN Bus OBD2 Connector?

The short answer: Almost certainly!

The vast majority of modern non-electric vehicles are OBD2 compliant, and crucially, most of these operate on the CAN bus protocol. For older vehicles, be aware that even if a 16-pin OBD2 connector is present, it might not actually support the OBD2 standard. A reliable way to confirm compliance is to consider the vehicle’s origin and purchase date:

A Look Back: The History of OBD2 and the CAN Bus OBD2 Connector

OBD2’s story begins in California, where the California Air Resources Board (CARB) mandated OBD systems in all new vehicles from 1991 onwards for emissions monitoring.

The OBD2 standard, including the standardized CAN bus OBD2 connector, was further developed and recommended by the Society of Automotive Engineers (SAE). This led to the standardization of DTCs and the OBD connector across different manufacturers (SAE J1962).

The adoption of the OBD2 standard, and consequently the CAN bus OBD2 connector, unfolded gradually:

1996: OBD2 became mandatory in the USA for cars and light trucks.
2001: Required in the EU for gasoline cars.
2003: Extended to diesel cars in the EU (EOBD).
2005: OBD2 requirement expanded to medium duty vehicles in the US.
2008: US vehicles mandated to use ISO 15765-4 (CAN) as the foundation for OBD2 communication, solidifying the role of the CAN bus OBD2 connector.
2010: OBD2 requirement extended to heavy duty vehicles in the US.

The Future of OBD2 and the Evolving CAN Bus OBD2 Connector

OBD2 is firmly established, but its future form is evolving. Let’s examine key trends impacting the CAN bus OBD2 connector and the broader OBD landscape:

Initially, OBD2 was legislated for emissions control and testing. Interestingly, electric vehicles (EVs) aren’t obligated to support OBD2 in any form. This is evident as most modern EVs largely bypass standard OBD2 requests. Instead, they often employ OEM-specific UDS communication protocols. This shift generally complicates data retrieval from EVs, except in cases where reverse engineering has revealed decoding methods – for examples, explore our case studies on electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

The current OBD2 implementation faces limitations in data richness and lower-layer protocols. In response, advanced alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. Both aim to refine OBD communication by utilizing the UDS protocol as a base. For deeper insights into these protocols, see our introduction to UDS.

In our connected world, manual OBD2 emission checks seem outdated.

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

OBD3 envisions adding a small radio transponder to every car, similar to those used for bridge tolls. 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 devices already facilitate CAN or OBD2 data transfer via WiFi/cellular, such as the CANedge2 WiFi CAN logger or the CANedge3 3G/4G CAN logger.

While cost-effective and convenient, OBD3 raises political and privacy concerns due to potential surveillance implications.

Originally designed for stationary emission tests, OBD2 is now widely used by third parties to generate real-time data via OBD2 dongles, CAN loggers and similar devices. However, the German car industry is advocating for changes:

OBD was intended for car servicing in repair shops. It was never meant to enable 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 during driving, centralizing data collection on manufacturer servers. This would give manufacturers control over the burgeoning ‘automotive big data’.

The rationale is security, citing the reduction of car hacking risks. However, many perceive this as a commercially motivated move. The future of this proposal and its impact on the third-party OBD2 service market remains uncertain.

Enhance Your CAN Bus Expertise with Our ‘Ultimate CAN Guide’

Ready to become a CAN bus expert?

Access our 12 ‘simple introductions’ compiled into a comprehensive 160+ page PDF:

Download now

OBD2 Standards and the CAN Bus OBD2 Connector

On-board diagnostics, OBD2, is a higher layer protocol – akin to a language. CAN bus is the communication method – like a phone line. This positions OBD2 alongside other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

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

These standards can be mapped to a 7-layer OSI model. The following sections 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 for OBD defined in the US (SAE) and EU (ISO). Many standards are technically very similar, such as SAE J1979 and ISO 15031-5, or SAE J1962 and ISO 15031-3, particularly concerning the CAN bus OBD2 connector.

Delving into the CAN Bus OBD2 Connector [SAE J1962]

The 16-pin CAN bus OBD2 connector is your primary interface for accessing vehicle data. It’s standardized under SAE J1962 / ISO 15031-3.

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

Key points to note about the CAN bus OBD2 connector:

It’s usually near the steering wheel, but can be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout varies depending on the communication protocol in use.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically connected on the CAN bus OBD2 connector.

CAN Bus OBD2 Connector: Type A vs. Type B

You might encounter both Type A and Type B CAN bus OBD2 connectors. Type A is common in cars, while Type B is often found in medium and heavy-duty vehicles.

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 differ, with cars typically using 500K and heavy-duty vehicles often using 250K (with increasing support for 500K).

Visually, the Type B CAN bus OBD2 connector has an interrupted groove in the middle, distinguishing it from Type A. Consequently, a Type B OBD2 adapter cable is compatible with both Type A and B sockets, whereas a Type A adapter will not fit into a Type B socket.

OBD2 and CAN Bus Protocol [ISO 15765-4]

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in all US-sold vehicles, as per ISO 15765. This reinforces the critical role of the CAN bus OBD2 connector.

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

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

CAN bus bit-rate must be either 250K or 500K.
CAN IDs can be 11-bit or 29-bit.
Specific CAN IDs are used for OBD requests and responses via the CAN bus OBD2 connector.
Diagnostic CAN frame data length is fixed at 8 bytes.
The OBD2 adapter cable, connecting to the CAN bus OBD2 connector, must be max 5 meters.

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

All OBD2 communication, through the CAN bus OBD2 connector, involves request/response message exchanges.

In most cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, which broadcasts a request to all OBD2 compatible ECUs to check if they have data on the requested parameter (ISO 15765-4). CAN IDs 0x7E0-0x7E7 can be used for ‘Physical Addressing’ requests to specific ECUs (less common).

ECUs respond with 11-bit IDs in the range 0x7E8-0x7EF. The most frequent response ID is 0x7E8 (ECM, Engine Control Module), and to a lesser extent 0x7E9 (TCM, Transmission Control Module), all communicated via the CAN bus OBD2 connector.

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

Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.

Responses from the vehicle will use CAN IDs ranging from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is sometimes presented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated in the J1939-71 standard as ‘Reserved for ISO 15765-2’.

OBD2 vs. Proprietary CAN Protocols: Understanding the CAN Bus OBD2 Connector Data

It’s crucial to understand that your vehicle’s electronic control units (ECUs) operate using OEM-specific proprietary CAN protocols, not OBD2. OBD2 is an additional protocol. These OEM protocols are often unique to the vehicle brand, model, and year. Interpreting this proprietary data is generally not possible for non-OEM parties without reverse engineering.

Connecting a CAN bus data logger to your vehicle’s CAN bus OBD2 connector may reveal OEM-specific CAN data, typically broadcast at high rates (1000-2000 frames/second). However, many newer vehicles employ a ‘gateway’ that restricts access to this OEM CAN data through the CAN bus OBD2 connector, enabling only OBD2 communication.

In essence, OBD2 is an ‘extra’ higher-layer protocol that operates alongside the OEM-specific protocol. Both are accessible through the CAN bus OBD2 connector, but they serve different purposes and contain different data.

Bit-rate and ID Validation for the CAN Bus OBD2 Connector

As mentioned, OBD2 can utilize two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations for communication via the CAN bus OBD2 connector. Modern cars commonly use 500K and 11-bit IDs, but external tools should systematically verify this.

ISO 15765-4 provides recommendations for an initialization sequence to determine the correct combination. This process leverages the fact that OBD2 compliant vehicles must respond to a specific mandatory OBD2 request and that incorrect bit-rates will cause CAN error frames.

Newer versions of ISO 15765-4 account for vehicles supporting OBD communication via OBDonUDS instead of OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on emission diagnostic service as per ISO 15031-5/SAE J1979) versus WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).

To differentiate between OBDonEDS and OBDonUDS protocols, testing tools can send 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 through the CAN bus OBD2 connector.

In practice, OBDonEDS (aka OBD2, SAE OBD, EOBD, or ISO OBD) is predominant in non-EV cars, while WWH-OBD is mainly used in EU trucks/buses.

Five Lower-Layer OBD2 Protocols: Beyond the CAN Bus OBD2 Connector

While CAN bus (ISO 15765) is now the dominant lower-layer protocol for OBD2, especially via the CAN bus OBD2 connector, older vehicles (pre-2008) might use other protocols. Understanding these can be helpful, especially when diagnosing older cars. The pinouts of the CAN bus OBD2 connector can sometimes indicate the protocol in use.

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

Transporting OBD2 Messages via ISO-TP [ISO 15765-2] over the CAN Bus OBD2 Connector

All OBD2 data exchanged through the CAN bus OBD2 connector is transported over CAN bus using ISO-TP (ISO 15765-2), a transport protocol. This allows for payloads exceeding the 8-byte CAN frame limit, necessary for OBD2 functions 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 details, consult our UDS introduction.

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

The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5] and the CAN Bus OBD2 Connector

To understand OBD2 communication via the CAN bus OBD2 connector and CAN, let’s examine a raw ‘Single Frame’ OBD2 CAN message. In simplified terms, an OBD2 message comprises an identifier, data length (PCI field), and data. The data section is further broken down into Mode, parameter ID (PID), and data bytes.

Example: OBD2 Request/Response via the CAN Bus OBD2 Connector

Consider this example request/response for ‘Vehicle Speed’ communicated through the CAN bus OBD2 connector.

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

By consulting the OBD2 PID 0x0D decoding rules, we determine that the physical value is 50 km/h.

Next, we will explore OBD2 modes and PIDs in more detail, all accessed through the CAN bus OBD2 connector.

The 10 OBD2 Services (Modes) via the CAN Bus OBD2 Connector

There are 10 standardized OBD2 diagnostic services, or modes, accessible through the CAN bus OBD2 connector. Mode 0x01 provides current real-time data, while others are used for displaying/clearing diagnostic trouble codes (DTCs) or showing freeze frame data.

Vehicles are not required to support all 10 OBD2 modes and may also implement OEM-specific modes beyond these standards.

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

OBD2 Parameter IDs (PIDs) Accessed via the CAN Bus OBD2 Connector

Each OBD2 mode contains Parameter IDs (PIDs). These PIDs, accessed via the CAN bus OBD2 connector, specify the data being requested or reported.

For example, mode 0x01 includes approximately 200 standardized PIDs providing real-time data on parameters like speed, RPM, and fuel level. However, vehicles don’t have to support all PIDs within a mode, and in practice, most vehicles support only a subset.

One PID is particularly important:

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. In response to this PID, the vehicle ECU indicates whether it supports PIDs 0x01-0x20. This makes PID 0x00 a crucial ‘OBD2 compatibility test’ when connecting via the CAN bus OBD2 connector. Further, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.

Tip: OBD2 PID Overview Tool for CAN Bus OBD2 Connector Data

The appendices of SAE J1979 and ISO 15031-5 contain scaling information for standard OBD2 PIDs. This information is vital for decoding the raw data received through the CAN bus OBD2 connector into physical values, as explained in our CAN bus introduction.

If you need to look up a mode 0x01 PID, our OBD2 PID overview tool is a valuable resource. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses obtained via the CAN bus OBD2 connector.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 Data from the CAN Bus OBD2 Connector

This section provides a practical example of logging OBD2 data using the CANedge CAN bus data logger connected to the CAN bus OBD2 connector.

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

Once configured, the CANedge easily connects to your vehicle using our OBD2-DB9 adapter cable, plugging directly into the CAN bus OBD2 connector.

Test CAN frame transmission at 500K to validate bit-rate via the CAN bus OBD2 Connector

Review responses to ‘Supported PIDs’ in asammdf after querying the CAN bus OBD2 connector

Step #1: Bit-rate, ID & Supported PID Validation via the CAN Bus OBD2 Connector

As previously discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a specific vehicle when communicating through the CAN bus OBD2 connector. You can perform these tests with the CANedge as follows (refer to the CANedge Intro for detailed instructions):

Send a CAN frame at 500K and verify successful transmission (if unsuccessful, try 250K) via the CAN bus OBD2 connector.
Use the validated bit-rate for all subsequent communication through the CAN bus OBD2 connector.
Send multiple ‘Supported PIDs’ requests and analyze the responses received via the CAN bus OBD2 connector.
Determine 11-bit vs. 29-bit CAN IDs based on response IDs from the CAN bus OBD2 connector.
Identify supported PIDs based on the response data obtained through the CAN bus OBD2 connector.

We provide ready-to-use configurations to streamline these tests when working with the CAN bus OBD2 connector.

Most post-2008 non-EV vehicles support 40-80 PIDs using a 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol when accessed via the CAN bus OBD2 connector.

As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common. This is because the 0x7DF request ID polls all ECUs for responses via the CAN bus OBD2 connector. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses, especially to this PID, are often observed. Note that the ECM ECU (0x7E8) in this example supports all PIDs supported by other ECUs, suggesting that busload can be reduced by directing subsequent requests only to this ECU using the ‘Physical Addressing’ CAN ID 0x7E0 for communication through the CAN bus OBD2 connector.

Step #2: Configuring OBD2 PID Requests for the CAN Bus OBD2 Connector

Having identified the supported OBD2 PIDs for your vehicle, and the correct bit-rate and CAN IDs for communication via the CAN bus OBD2 connector, you can now configure your transmit list with the PIDs you wish to log.

Consider these points when configuring OBD2 PID requests for the CAN bus OBD2 connector:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses per request when communicating via the CAN bus OBD2 connector.
Spacing: Introduce a 300-500 ms delay between OBD2 requests (excessive ECU polling may lead to non-responsiveness) via the CAN bus OBD2 connector.
Battery Drain: Implement triggers to halt transmission when the vehicle is inactive (to prevent ECU ‘wake-up’) through the CAN bus OBD2 connector.
Filters: Apply filters to record only OBD2 responses (especially if your vehicle also outputs OEM-specific CAN data) obtained via the CAN bus OBD2 connector.

Once configured, your device is ready to log raw OBD2 data from the CAN bus OBD2 connector!

Example CANedge OBD2 PID request list for CAN bus OBD2 Connector data logging

Visualize DBC decoded OBD2 data from the CAN bus OBD2 Connector in asammdf

Step #3: DBC Decoding of Raw OBD2 Data from the CAN Bus OBD2 Connector

To effectively analyze and visualize logged data from the CAN bus OBD2 connector, you need to decode the raw OBD2 data into ‘physical values’ (e.g., km/h or °C).

Decoding information is available in ISO 15031-5/SAE J1979 and online resources like Wikipedia. We offer a free OBD2 DBC file to facilitate DBC decoding of raw OBD2 data in most CAN bus software tools after capture from the CAN bus OBD2 connector.

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

To resolve this, you must use the CAN ID, OBD2 mode, and OBD2 PID to uniquely identify signals. This is a form of multiplexing known as ‘extended multiplexing‘, which can be implemented in DBC files for data obtained from the CAN bus OBD2 connector.

CANedge: Your OBD2 Data Logger for CAN Bus OBD2 Connector Analysis

The CANedge simplifies recording OBD2 data onto an 8-32 GB SD card directly from the CAN bus OBD2 connector. Simply connect it to a vehicle to begin logging and decode the data using free software/APIs and our OBD2 DBC.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples [ISO-TP] via the CAN Bus OBD2 Connector

All OBD2 data communication, including multi-frame messages, via the CAN bus OBD2 connector utilizes the ISO-TP (transport protocol) as defined in ISO 15765-2. While previous examples focused on single-frame communication, this section presents multi-frame examples.

Multi-frame OBD2 communication requires flow control frames (see our UDS intro). In practice, a static flow control frame can be transmitted approximately 50 ms after the initial request frame, as demonstrated in the CANedge configuration example.

Moreover, multi-frame OBD2 responses necessitate CAN software/API tools that support ISO-TP, such as the CANedge MF4 decoders, for proper handling of data received from the CAN bus OBD2 connector.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval via the CAN Bus OBD2 Connector

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more (see our UDS intro for details). To retrieve the VIN from a vehicle using OBD2 requests through the CAN bus OBD2 connector, 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) via the CAN bus OBD2 connector.

The vehicle responds with a First Frame containing the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02), all transmitted back through the CAN bus OBD2 connector. 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 remaining 17 bytes constitute the VIN, which can be converted from HEX to ASCII using methods described in our UDS introduction.

Example 2: OBD2 Multi-PID Request (6x) via the CAN Bus OBD2 Connector

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

This efficient method allows for higher frequency OBD2 data collection, but it also means the signal encoding is specific to your request method. This can complicate the use of generic OBD2 DBC files. We generally advise against this method for standard logging. Below is an example trace:

The multi-frame response, received via the CAN bus OBD2 connector, is similar to the VIN example, but the payload includes both the requested PIDs and their corresponding data. The PIDs in the example are typically ordered as requested, though this is not strictly mandated by ISO 15031-5.

Decoding this response using generic DBC files is very challenging. Therefore, we don’t recommend this approach for practical data logging unless using tools specifically designed for it. This scenario represents extended multiplexing with multiple instances throughout the payload. Your DBC file would need to account for each PID’s specific payload position, making generalization across vehicles with varying supported PIDs difficult. Handling this via DBC manipulation becomes nearly impossible when sending multiple multi-PID requests, as uniquely identifying messages becomes problematic.

Workarounds might involve custom scripts and recording transmit messages from your testing tool. The script could then interpret response messages based on the corresponding request message. However, such approaches are generally difficult to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) via the CAN Bus OBD2 Connector

OBD2 can be used to request emissions-related Diagnostic Trouble Codes (DTCs) using mode 0x03, ‘Show stored Diagnostic Trouble Codes,’ accessed through the CAN bus OBD2 connector. No PID is included in the request. The target ECU(s) will respond with the number of stored DTCs (potentially zero), with each DTC occupying 2 data bytes. Multi-frame responses are necessary when more than 2 DTCs are stored.

The 2-byte DTC value is typically 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 code (hexadecimal), as shown visually. 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, all communicated via the CAN bus OBD2 connector.

OBD2 Data Logging Use Cases via the CAN Bus OBD2 Connector

OBD2 data logged from cars and light trucks via the CAN bus OBD2 connector has numerous applications:

Car Data Logging via the CAN Bus OBD2 Connector

OBD2 data from cars, accessed through the CAN bus OBD2 connector, can be used to reduce fuel consumption, improve driving habits, test prototype components, and for insurance purposes.

obd2 logger

Real-time Car Diagnostics via the CAN Bus OBD2 Connector

OBD2 interfaces, connected to the CAN bus OBD2 connector, can stream human-readable OBD2 data in real-time, facilitating vehicle diagnostics and issue identification.

obd2 streaming

Predictive Maintenance via OBD2 Data from the CAN Bus OBD2 Connector

Cars and light trucks can be monitored via IoT OBD2 loggers, utilizing the CAN bus OBD2 connector for data, to predict and prevent breakdowns, improving vehicle uptime and reducing maintenance costs.

predictive maintenance

Vehicle Black Box Logging via the CAN Bus OBD2 Connector

An OBD2 logger connected to the CAN bus OBD2 connector can act as a ‘black box’ for vehicles or equipment, providing valuable data for dispute resolution, accident analysis, and in-depth diagnostics.

can bus blackbox

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

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

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy now
Contact us

Recommended Resources:

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN