Understanding OBD2 Terminals: A Comprehensive Guide for Automotive Diagnostics

Need a practical guide to understanding Obd2 Terminals?

This guide provides a detailed introduction to OBD2 (On-Board Diagnostics II) terminals, focusing on the connector, pinouts, and their role in automotive diagnostics. We’ll explore the OBD2 connector terminals, their functions, and how they facilitate communication for retrieving diagnostic data and troubleshooting vehicle issues.

Note: This is a comprehensive guide designed to enhance your understanding of OBD2 terminals and their practical applications in vehicle repair and diagnostics.

Discover why this has become a leading resource for understanding OBD2 terminals and diagnostics.

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

What are OBD2 Terminals?

OBD2 terminals are the physical interface points within your vehicle’s OBD2 connector. This connector is a crucial component of your car’s self-diagnostic system, providing standardized access to diagnostic trouble codes (DTCs) and real-time vehicle data. The OBD2 connector terminals are designed to comply with international standards, ensuring compatibility across different scan tools and vehicles.

You’ve likely encountered the impact of OBD2 terminals indirectly:

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

This light signals a problem detected by your car’s onboard diagnostics system. When a mechanic diagnoses this issue, they use an OBD2 scanner which connects directly to the OBD2 terminals within the 16-pin connector.

By connecting an OBD2 reader to the OBD2 16 pin connector, typically found near the steering wheel, technicians can access a wealth of information. The diagnostic tool transmits ‘OBD2 requests’ through specific OBD2 terminals, and the car responds with ‘OBD2 responses’. These responses can include vital data such as speed, fuel level, and Diagnostic Trouble Codes (DTCs), all communicated via the OBD2 terminals, significantly speeding up the troubleshooting and repair process.

OBD2 Compatibility: Does Your Car Have the Right Terminals?

In short: Almost certainly!

Most modern gasoline and diesel vehicles are equipped with OBD2 and utilize CAN bus for communication through their OBD2 terminals. However, in older vehicles, the presence of a 16-pin OBD2 connector does not guarantee OBD2 compliance. Some may have the connector but lack the necessary internal circuitry and OBD2 terminals to support the protocol fully. To confirm compatibility, consider the vehicle’s origin and manufacturing date:

A Brief History of OBD2 and Connector Terminal Standardization

OBD2’s origins are in California, driven by the California Air Resources Board (CARB) mandate for OBD in all new vehicles starting from 1991 to monitor and control emissions.

The Society of Automotive Engineers (SAE) played a crucial role in standardizing OBD2, including the standardization of DTCs and, importantly, the OBD connector terminals through SAE J1962. This standard ensured that all manufacturers used a uniform set of OBD2 terminals, facilitating easier diagnostics across different makes and models.

The OBD2 standard, with its standardized OBD2 terminals, was progressively implemented:

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 (EOBD).
2005: OBD2 mandated in the US for medium-duty vehicles.
2008: US vehicles required to use ISO 15765-4 (CAN) as the foundation for OBD2 communication, impacting the active OBD2 terminals used.
2010: OBD2 requirement extended to heavy-duty vehicles in the US.

The Future of OBD2 and Diagnostic Connector Terminals

OBD2 is set to remain a key technology in vehicle diagnostics, though its form and function are evolving.

Key trends shaping the future of OBD2 and its terminals include:

Originally designed for emissions monitoring, legislated OBD2 is not mandated for electric vehicles. Consequently, most modern EVs do not support standard OBD2 requests via the traditional OBD2 terminals. Instead, they often employ OEM-specific UDS communication protocols, making data retrieval challenging without specialized knowledge or reverse engineering – as seen in our case studies for electric cars including Tesla, Hyundai/Kia, Nissan and VW/Skoda EVs.

Limitations in data richness and lower-layer protocols in traditional OBD2 have spurred the development of alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS). These advancements aim to improve OBD communication by using the UDS protocol as a base, potentially affecting how data is accessed through OBD2 terminals in the future. For more on these protocols, see our intro to UDS.

In the era of connected vehicles, manual emission checks via OBD2 terminals are becoming less efficient.

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

OBD3 envisions adding a small radio transponder to vehicles, enabling wireless transmission of the vehicle identification number (VIN) and DTCs to a central server for automated checks. This could reduce the reliance on physical access to OBD2 terminals for emission testing.

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

While convenient and cost-saving, OBD3 raises privacy concerns due to potential surveillance.

Initially designed for in-garage emission testing, OBD2 is now widely used by third parties for real-time data generation via OBD2 dongles, CAN loggers and similar tools that connect to OBD2 terminals. However, the German car industry is considering restricting this access:

OBD was intended for vehicle servicing in repair shops, not for third parties to build data-driven economies via OBD2 terminal access.

– Christoph Grote, SVP Electronics, BMW (2017)

The proposal involves disabling OBD2 functionality during driving, centralizing data collection with manufacturers. This would give manufacturers control over automotive data and potentially disrupt the market for third-party OBD2 services that rely on accessing data through OBD2 terminals.

Arguments for this shift include security improvements (reducing car hacking risks), though many view it as a commercial strategy. The impact on the future of OBD2 terminals and third-party access remains to be seen.

Get our ‘Ultimate CAN Guide’

Want to master CAN bus technology?

Our 160+ page PDF compiles 12 ‘simple intros’ into one comprehensive resource:

Download now

OBD2 Standards and the Role of Connector Terminals

On-board diagnostics, OBD2, is a higher-layer protocol, similar to a language, while CAN is the communication method, like a phone line. This parallels other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.

Specifically, OBD2 standards define the OBD2 connector, including the specifications for OBD2 terminals, lower-layer protocols, OBD2 parameter IDs (PIDs), and more.

These standards can be organized using a 7-layer OSI model. In the following sections, we will focus on the most critical aspects related to OBD2 terminals and communication.

The OSI model highlights that both SAE and ISO standards cover multiple layers. This reflects the standardization efforts in the USA (SAE) and EU (ISO) for OBD. Many standards are technically similar, such as SAE J1979 versus ISO 15031-5, and SAE J1962 versus ISO 15031-3, especially concerning the OBD2 connector terminals.

The OBD2 Connector and Terminal Pinout [SAE J1962]

The 16-pin OBD2 connector, with its defined OBD2 terminal layout, allows for easy access to vehicle data and is detailed in SAE J1962 / ISO 15031-3.

The illustration shows a Type A OBD2 pin connector (Data Link Connector, DLC), outlining the specific OBD2 terminals.

Key aspects of the OBD2 connector and its terminals include:

The connector is typically located near the steering wheel, but its exact location can vary and may be hidden.
Pin 16 of the OBD2 terminals provides battery power, often even when the ignition is off, ensuring constant power for diagnostic tools.
The OBD2 terminal pinout configuration depends on the communication protocol used by the vehicle.
CAN bus, the most prevalent lower-layer protocol, typically utilizes pins 6 (CAN-High) and 14 (CAN-Low) as its designated OBD2 terminals.

OBD2 Connector Types: A vs. B and Terminal Variations

You might 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. The distinction lies primarily in their OBD2 terminals and power delivery.

Both types share a similar OBD2 terminal pinout but differ in power supply outputs: 12V for Type A and 24V for Type B. Baud rates can also vary, with cars commonly using 500K and heavy-duty vehicles often using 250K (with increasing support for 500K).

Visually, Type B OBD2 connectors have a distinguishing interrupted groove in the middle, unlike Type A. This mechanical difference means a Type B OBD2 adapter cable is compatible with both Type A and Type B sockets, but a Type A adapter will not fit into a Type B socket due to the OBD2 terminal arrangement and connector shape.

OBD2 Communication over CAN bus [ISO 15765-4] and Terminal Usage

Since 2008, CAN bus has been mandated as the lower-layer protocol for OBD2 in all US vehicles, as per ISO 15765. This standard dictates how OBD2 terminals are used for communication.

ISO 15765-4, also known as Diagnostics over CAN (DoCAN), specifies constraints on the CAN standard (ISO 11898) specifically for diagnostic purposes via OBD2 terminals.

It standardizes the CAN interface for diagnostic equipment, focusing on the physical, data link, and network layers relevant to OBD2 terminal communication:

CAN bus bit-rate must be 250K or 500K for OBD2 terminal communication.
CAN IDs can be 11-bit or 29-bit, transmitted through OBD2 terminals.
Specific CAN IDs are reserved for OBD requests and responses via OBD2 terminals.
Diagnostic CAN frame data length is fixed at 8 bytes, transmitted and received through OBD2 terminals.
The OBD2 adapter cable connecting to the OBD2 terminals must be a maximum of 5 meters long.

OBD2 CAN Identifiers (11-bit, 29-bit) and Terminal Communication

OBD2 communication is based on request/response message pairs transmitted through the OBD2 terminals.

In most cars, 11-bit CAN IDs are used for OBD2 communication via the OBD2 terminals. The ‘Functional Addressing’ ID is 0x7DF, which queries all OBD2-compatible ECUs for data on the requested parameter (ISO 15765-4). ‘Physical Addressing’ requests to specific ECUs, less common, use CAN IDs 0x7E0-0x7E7 via OBD2 terminals.

ECUs respond using 11-bit IDs 0x7E8-0x7EF through the OBD2 terminals. The most common response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module). These IDs are crucial for interpreting data received through OBD2 terminals.

Some vehicles, especially vans and medium to heavy-duty vehicles, may use extended 29-bit CAN identifiers for OBD2 communication via their OBD2 terminals.

The ‘Functional Addressing’ CAN ID in these cases is 0x18DB33F1.

Responses use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is also sometimes presented in ‘J1939 PGN’ format as PGN 0xDA00 (55808), which is reserved for ISO 15765-2 in the J1939-71 standard, indicating the standardization of communication through OBD2 terminals.

OBD2 vs. Proprietary CAN Protocols and OBD2 Terminals

Vehicle ECUs operate using proprietary CAN protocols defined by the OEM, independent of OBD2. These protocols are specific to vehicle brand, model, and year. Interpreting this proprietary data is generally not possible without OEM-specific tools or reverse engineering, unlike standardized OBD2 data accessed through OBD2 terminals.

Connecting a CAN bus data logger to the OBD2 connector might capture OEM-specific CAN data, typically broadcast at high rates. However, newer vehicles often use a ‘gateway’ that restricts access to this OEM data via the OBD2 connector and OBD2 terminals, allowing only OBD2 communication.

OBD2 should be seen as an additional higher-layer protocol running alongside the OEM-specific protocol. Both utilize the same physical OBD2 terminals but serve different diagnostic and data access purposes.

Bit-rate and ID Validation for OBD2 Terminal Communication

OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in four potential combinations for communication via OBD2 terminals. Modern cars commonly use 500K and 11-bit IDs, but diagnostic tools should systematically verify these parameters to ensure correct OBD2 terminal communication.

ISO 15765-4 recommends a systematic initialization sequence to determine the correct combination. This process relies on the mandatory OBD2 response to a specific request (see OBD2 PID section) and the detection of CAN error frames caused by incorrect bit-rate settings.

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

To differentiate between OBDonEDS and OBDonUDS protocols, diagnostic tools may send additional UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). Vehicles supporting OBDonUDS must have ECUs that respond to this DID via the OBD2 terminals.

OBDonEDS (aka OBD2, SAE OBD, EOBD, or ISO OBD) is prevalent in most non-EV cars, while WWH-OBD is mainly used in EU trucks/buses, both communicating through standardized OBD2 terminals.

Five Lower-Layer OBD2 Protocols and Terminal Pinouts

While CAN (ISO 15765) is now the dominant lower-layer protocol for OBD2, older vehicles (pre-2008) may use one of four other protocols. Understanding these protocols and their corresponding OBD2 terminal pinouts is useful for diagnosing older vehicles.

ISO 15765 (CAN bus): Mandatory in US cars since 2008 and widely used today, utilizing specific OBD2 terminals for CAN communication.
ISO14230-4 (KWP2000): Keyword Protocol 2000, common in 2003+ Asian cars, using different OBD2 terminals than CAN.
ISO 9141-2: Used in EU, Chrysler & Asian cars (2000-04), with its unique OBD2 terminal assignments.
SAE J1850 (VPW): Mostly in older GM cars, employing specific OBD2 terminals for VPW communication.
SAE J1850 (PWM): Primarily in older Ford cars, also with distinct OBD2 terminal usage.

ISO-TP for OBD2 Message Transport [ISO 15765-2] and OBD2 Terminals

OBD2 data communication over the CAN bus relies on ISO-TP (ISO 15765-2), a transport protocol that manages data payloads exceeding 8 bytes. This is essential for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs), all transmitted through OBD2 terminals. ISO 15765-2 handles segmentation, flow control, and reassembly of these larger messages. Further details are available in our intro to UDS.

However, much 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, leaving 7 bytes for OBD2-related communication via OBD2 terminals.

The OBD2 Diagnostic Message Structure [SAE J1979, ISO 15031-5] and Terminal Data

To better understand OBD2 communication via CAN and OBD2 terminals, let’s examine a raw ‘Single Frame’ OBD2 CAN message. Simplified, an OBD2 message consists of an identifier, data length (PCI field), and data. The data section is further divided into Mode, parameter ID (PID), and data bytes, all transmitted and interpreted through the OBD2 terminals.

Example: OBD2 Request/Response via Terminals

Consider a request/response example for ‘Vehicle Speed’.

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

Using OBD2 PID 0x0D decoding rules, the physical value is determined as 50 km/h, illustrating how data is transmitted and interpreted via OBD2 terminals.

Next, we’ll detail OBD2 modes and PIDs, which are fundamental to understanding data exchanged through OBD2 terminals.

The 10 OBD2 Services (Modes) and Terminal Communication

There are 10 standardized OBD2 diagnostic services, or modes, each accessible via OBD2 terminals. Mode 0x01 provides real-time data, while others are used to manage diagnostic trouble codes (DTCs) or access freeze frame data, all communicated through the OBD2 terminals.

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

In OBD2 messages transmitted via OBD2 terminals, the mode is in the 2nd byte. In a request, the mode is directly included (e.g., 0x01), whereas in a response, 0x40 is added to the mode (e.g., resulting in 0x41), indicating a response to a specific mode request via the OBD2 terminals.

OBD2 Parameter IDs (PIDs) and Terminal Data

Each OBD2 mode contains parameter IDs (PIDs), which define the specific data being requested or provided through the OBD2 terminals.

For example, 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 these PIDs within a mode, limiting the data accessible through OBD2 terminals.

One PID, however, is universally significant.

If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID, the vehicle ECU indicates its support for PIDs 0x01-0x20. PID 0x00 thus serves as a fundamental ‘OBD2 compatibility test’ for the OBD2 terminal interface. Similarly, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs, confirming the extent of diagnostic capabilities available through the OBD2 terminals.

Tip: OBD2 PID Overview Tool for Terminal Data Analysis

SAE J1979 and ISO 15031-5 appendices provide scaling information for standard OBD2 PIDs, enabling the conversion of raw data into physical values, as explained in our CAN bus intro. This conversion is essential for interpreting data received via OBD2 terminals.

For quick lookup of mode 0x01 PIDs, use our OBD2 PID overview tool. It assists in constructing OBD2 request frames and dynamically decoding OBD2 responses, facilitating efficient analysis of data from OBD2 terminals.

OBD2 PID overview tool

How to Log and Decode OBD2 Data from Terminals

This section provides a practical guide on logging OBD2 data using the CANedge CAN bus data logger, demonstrating how to effectively utilize OBD2 terminals for data acquisition.

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

Connecting the CANedge to your vehicle via our OBD2-DB9 adapter cable provides a straightforward setup for logging data from OBD2 terminals.

You can send a CAN frame at e.g. 500K, then check if it is successfully sent

The responses to ‘Supported PIDs’ can be reviewed in asammdf

#1: Testing Bit-rate, IDs, and Supported PIDs via OBD2 Terminals

ISO 15765-4 outlines how to determine the bit-rate and IDs used by a vehicle. You can test this using CANedge as follows (see CANedge Intro):

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

We offer plug-and-play configurations to facilitate these tests, streamlining the process of verifying OBD2 terminal communication parameters.

Most post-2008 non-EV cars support 40-80 PIDs via 500K bit-rate, 11-bit CAN IDs, and the OBD2/OBDonEDS protocol, all accessible through OBD2 terminals.

As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common due to the use of the 0x7DF request ID, which polls all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses are typically received for this PID. Subsequent ‘Supported PIDs’ requests usually yield fewer responses as fewer ECUs support those specific PIDs. The ECM ECU (0x7E8) often supports all PIDs supported by other ECUs in this example. Therefore, busload can be reduced by directing subsequent requests specifically to the ECM ECU using the ‘Physical Addressing’ CAN ID 0x7E0, optimizing communication via OBD2 terminals.

#2: Configuring OBD2 PID Requests for Terminal Data

Once you’ve identified the OBD2 PIDs supported by your vehicle and the communication parameters (bit-rate, CAN IDs), you can configure your transmit list with desired PIDs for data logging via OBD2 terminals.

Consider these points when configuring PID requests for OBD2 terminal data:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to minimize multiple responses for each request, focusing communication through specific OBD2 terminals.
Spacing: Add 300-500 ms intervals between OBD2 requests to prevent overwhelming ECUs and ensure reliable responses via OBD2 terminals.
Battery Drain: Use triggers to stop transmissions when the vehicle is inactive, preventing unnecessary ECU wake-up and battery drain when accessing data through OBD2 terminals.
Filters: Implement filters to record only OBD2 responses, especially if the vehicle outputs OEM-specific CAN data alongside OBD2 data on the OBD2 terminals.

With these configurations, your device is ready to log raw OBD2 data efficiently from the OBD2 terminals.

An example list of CANedge OBD2 PID requests

asammdf lets you DBC decode and visualize OBD2 data

#3: DBC Decoding of Raw OBD2 Terminal Data

To analyze and visualize logged data, decode the raw OBD2 data into ‘physical values’ (e.g., km/h, °C).

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

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

Therefore, signal identification requires both the CAN ID, OBD2 mode, and OBD2 PID. This ‘extended multiplexing’ method is supported in DBC files and is essential for accurately interpreting data logged from OBD2 terminals.

CANedge: OBD2 Data Logger for Terminal Data Acquisition

The CANedge simplifies OBD2 data recording to an 8-32 GB SD card. Connect it to a vehicle to start logging and use free software/APIs and our OBD2 DBC for data decoding. CANedge is designed for easy and efficient OBD2 terminal data logging.

OBD2 logger intro

CANedge

OBD2 Multi-Frame Examples [ISO-TP] and OBD2 Terminals

OBD2 communication uses ISO-TP (ISO 15765-2) for all data transmission via OBD2 terminals, with examples so far primarily showing single-frame communication. This section provides examples of multi-frame communication, crucial for understanding complex data exchanges through OBD2 terminals.

Multi-frame OBD2 communication requires flow control frames (see our UDS intro). A static flow control frame transmitted ~50 ms after the initial request frame can manage this, as shown in the CANedge configuration example.

Analyzing multi-frame OBD2 responses necessitates CAN software/API tools that support ISO-TP, such as CANedge MF4 decoders, to properly interpret data from OBD2 terminals.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval via Terminals

The Vehicle Identification Number (VIN) is important for telematics and diagnostics. Retrieve it using OBD2 mode 0x09 and PID 0x02 via OBD2 terminals.

The tester tool sends a Single Frame request via OBD2 terminals with PCI field (0x02), request service identifier (0x09), and PID (0x02).

The vehicle responds through OBD2 terminals with a First Frame containing PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID is byte 0x01, the Number Of Data Items (NODI), in this case 1 (ISO 15031-5 / SAE J1979). The subsequent 17 bytes represent the VIN, convertible from HEX to ASCII as described in our UDS intro, demonstrating full data exchange via OBD2 terminals.

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

External tools can request up to 6 mode 0x01 OBD2 PIDs in a single request frame via OBD2 terminals. The ECU responds with data for supported PIDs (excluding unsupported ones) potentially across multiple frames via ISO-TP.

This method enhances data collection efficiency, but signal encoding becomes specific to the request, complicating generic OBD2 DBC file use. We advise against this method practically. Below is a sample trace:

The multi-frame response is similar to the VIN example, but the payload includes requested PIDs and their data. PIDs are typically ordered as requested, common in practice but not strictly required by ISO 15031-5. Decoding such responses via generic DBC files is challenging; thus, this method is not recommended for standard data logging unless using tools specifically designed for it. Effectively, it’s extended multiplexing with multiple instances throughout the payload. Creating a DBC file to manage payload position for each PID across vehicles is complex. If sending multiple multi-PID requests, distinguishing messages becomes difficult.

Workarounds include custom scripts and recording transmit messages to interpret responses based on requests. However, these approaches are hard to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs) via Terminals

OBD2 mode 0x03, ‘Show stored Diagnostic Trouble Codes,’ allows requesting emissions-related DTCs via OBD2 terminals. No PID is included in the request. Responding ECUs indicate the number of stored DTCs (possibly zero), with each DTC using 2 data bytes. Multi-frame responses are necessary for more than 2 DTCs.

The 2-byte DTC value is structured per ISO 15031-5/ISO 15031-6. The first 2 bits define the ‘category,’ and the remaining 14 bits form a 4-digit hexadecimal code, as visualized. 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, all communicated through OBD2 terminals.

OBD2 Data Logging Use Cases via Terminals

OBD2 data from cars and light trucks, accessed via OBD2 terminals, has diverse applications:

Logging Data from Cars via OBD2 Terminals

OBD2 data logging, accessed through OBD2 terminals, can reduce fuel costs, improve driving habits, test prototype parts, and inform insurance policies.

obd2 logger

Real-Time Car Diagnostics via OBD2 Terminals

OBD2 interfaces facilitate real-time streaming of human-readable OBD2 data, aiding in diagnosing vehicle issues directly through OBD2 terminals.

obd2 streaming

Predictive Maintenance via OBD2 Terminal Data

Cars and light trucks can be monitored via IoT OBD2 loggers in the cloud to predict and prevent breakdowns, utilizing data accessed through OBD2 terminals.

predictive maintenance

Vehicle Black Box Logger via OBD2 Terminals

An OBD2 logger can function as a vehicle ‘black box,’ recording data for disputes or diagnostics, all accessed through the vehicle’s OBD2 terminals.

can bus blackbox

Do you have an OBD2 data logging use case? Contact us for free consultation!

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

Need to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy now

Recommended for you

OBD2 DATA LOGGER: EASILY LOG & CONVERT OBD2 DATA

CANEDGE2 – PRO CAN IoT LOGGER

[