Understanding the OBD2 Diagnostic Connector: Your Car's Health Interface

Need a straightforward and practical introduction to the OBD2 system, focusing on the Obd2 Diagnostic Connector?

This guide provides a comprehensive overview of the On-Board Diagnostics 2 (OBD2) protocol, with a special emphasis on the OBD2 connector. We’ll explore its function, delve into OBD2 Parameter IDs (PIDs), and explain its connection to the CAN bus.

This is designed to be a practical guide, so you’ll also learn how to request and interpret OBD2 data through the diagnostic connector, understand key use cases for data logging, and gain valuable practical tips for working with your vehicle’s diagnostic system.

Discover why this has become a highly recommended resource for understanding the OBD2 diagnostic connector and the broader OBD2 system.

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

What is OBD2 and its Diagnostic Connector?

OBD2 is essentially your car’s internal health monitoring system. It’s a standardized protocol that allows access to diagnostic trouble codes (DTCs) and real-time vehicle data through a specific port: the OBD2 diagnostic connector.

You’ve likely already encountered OBD2 in some form. Have you ever seen the check engine light, also known as the malfunction indicator light, illuminate on your dashboard? This is your car signaling that something is amiss. When you take your car to a mechanic, they use an OBD2 scanner to pinpoint the problem.

To do this, the mechanic plugs the OBD2 scanner into the OBD2 16 pin connector, usually located near the steering wheel. This OBD2 diagnostic connector acts as the interface. The scanner sends ‘OBD2 requests’ to the car’s computer system, and the car responds with ‘OBD2 responses’. These responses can include vital information like speed, fuel level, and Diagnostic Trouble Codes (DTCs). By accessing this data through the OBD2 diagnostic connector, mechanics can efficiently troubleshoot vehicle issues.

Alt text: Malfunction Indicator Light (MIL) on a car dashboard, illustrating the OBD2 On-Board Diagnostics system and the use of a scan tool.

Is My Car Equipped with an OBD2 Diagnostic Connector?

In short: Most likely!

The vast majority of modern non-electric vehicles are equipped with OBD2 systems and predominantly utilize the CAN bus communication protocol. For older vehicles, it’s important to note that even if a 16-pin OBD2 diagnostic connector is present, it might not actually support the OBD2 protocol. Determining OBD2 compliance often depends on the vehicle’s origin and year of manufacture:

Alt text: Chart outlining OBD2 compliance by region (EU, US) and vehicle type, indicating mandatory years for OBD2 implementation.

A Brief History of OBD2 and the Diagnostic Connector

The origin of OBD2 can be traced back to California, where the California Air Resources Board (CARB) mandated the inclusion of On-Board Diagnostics (OBD) in all new vehicles starting from 1991 for emission control purposes.

The OBD2 standard, including the standardization of DTCs and the OBD connector, was developed based on recommendations from the Society of Automotive Engineers (SAE). This resulted in the SAE J1962 standard, which defined the physical OBD2 diagnostic connector across different vehicle manufacturers.

The implementation of the OBD2 standard was phased in gradually:

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 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 US heavy-duty vehicles.

Alt text: Diagram illustrating the history of OBD2, highlighting its origins in emission control and its evolution with CAN bus integration.

Alt text: Timeline infographic summarizing key milestones in OBD2 history, from its inception to wider adoption across vehicle types and regions.

Alt text: Conceptual image representing the future of OBD, including OBD3, remote diagnostics, emissions testing, cloud connectivity and IoT.

The Future of OBD2 and the Diagnostic Connector

OBD2 is expected to remain relevant, but its form and function are evolving.

Here are some important trends shaping the future of OBD2:

Originally designed for emissions control and testing, legislated OBD2 has an interesting implication: electric vehicles (EVs) are not obligated to support OBD2 in any form. In practice, most modern EVs do not support standard OBD2 requests. Instead, they often utilize OEM-specific UDS communication protocols. This generally makes it challenging to decode data from EVs, except in cases where reverse engineering has revealed the decoding rules. Examples include case studies for electric cars like Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

OBD2 implementations today vary and have limitations in data richness and lower-layer protocols. In response, modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) have emerged. These aim to improve OBD communication by using the UDS protocol as a base. Learn more about these protocols in our introduction to UDS.

In our increasingly connected world, traditional OBD2 testing methods can seem outdated. Manual emission control checks are time-consuming and costly. The proposed solution? OBD3 – integrating telematics into all vehicles.

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

Many current 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 this offers cost savings and convenience, it raises political concerns related to surveillance.

The original purpose of the OBD2 protocol was for stationary emission controls. However, today, OBD2 is widely used by third parties to generate real-time data through OBD2 dongles, CAN loggers and similar devices. However, the German car industry is considering changes:

OBD was designed for servicing 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 potentially disable OBD2 functionality while driving and instead collect data on a central server. This would effectively give manufacturers control over ‘automotive big data’. The rationale includes security concerns, such as reducing the risk of car hacking, though many perceive this as a commercial strategy https://www.navixy.com/blog/obd-trackers-what-future-awaits/. Whether this trend will materialize remains to be seen, but it could significantly disrupt the market for third-party OBD2 services.

Alt text: Graphic depicting the removal of an OBD2 connector from an electric vehicle, symbolizing the trend of EVs limiting OBD2 data access.

Get our ‘Ultimate CAN Guide’

Want to become a CAN bus expert?

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

Download now

Alt text: Cover image of the “CAN Bus – The Ultimate Guide” PDF, featuring a blue and white design with text overlay.

OBD2 Standards and the Diagnostic Connector

On-board diagnostics, OBD2, operates as a higher layer protocol (similar to a language), while CAN bus is the communication method (like a telephone line). This makes OBD2 comparable to other CAN-based higher-layer protocols like J1939, CANopen, and NMEA 2000.

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

These standards can be categorized within a 7-layer OSI model. The following sections will focus on the most crucial aspects. In the OSI model, you’ll notice that both SAE and ISO standards cover multiple layers. This generally reflects the standards defined for OBD in the USA (SAE) and EU (ISO). Many standards are technically very similar, for instance, SAE J1979 versus ISO 15031-5, and SAE J1962 versus ISO 15031-3.

Alt text: OSI 7-layer model diagram comparing OBD2 and CAN Bus standards, highlighting ISO 15765 and ISO 11898 standards.

Alt text: OBD2 Connector Pinout diagram, Socket Female Type A DLC, illustrating pin assignments and functions.

The OBD2 Connector [SAE J1962 / ISO 15031-3]

The 16-pin OBD2 connector is your gateway to accessing vehicle data. It is formally specified in the SAE J1962 standard and its ISO equivalent, ISO 15031-3.

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

Key points to remember about the OBD2 diagnostic connector:

It’s typically located near the steering wheel, though its exact location can sometimes be hidden.
Pin 16 provides battery power, often even when the ignition is off.
The OBD2 pinout configuration varies based on the communication protocol used.
CAN bus is the most prevalent lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are commonly connected.

OBD2 Connector Types: A vs. B

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

As shown in the illustration, both types share similar OBD2 pinouts but differ in their 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).

Visually distinguishing them, the Type B OBD2 connector has an interrupted groove in the center. This means 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.

Alt text: Comparison diagram of OBD2 Connector Type A and Type B, highlighting differences in voltage (12V vs 24V) and applications (car/van vs truck).

Alt text: Diagram contrasting OBD2 and CAN bus within the ISO15765 standard framework, illustrating their relationship and layers.

OBD2 Communication Over CAN Bus [ISO 15765-4]

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

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

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

CAN bus bit-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 length must not exceed 5 meters.

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

All OBD2 communication is structured around request and response messages.

In most passenger cars, 11-bit CAN IDs are used for OBD2 communication. The ‘Functional Addressing’ ID is 0x7DF, used to query all OBD2-compatible ECUs if they have data related to the requested parameter (according to ISO 15765-4). CAN IDs ranging from 0x7E0 to 0x7E7 can be used for ‘Physical Addressing’ requests to specific ECUs, although this is less common.

ECUs respond using 11-bit IDs from 0x7E8 to 0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module).

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

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). This response ID is also sometimes represented in the ‘J1939 PGN’ format, specifically PGN 0xDA00 (55808), which is designated in the J1939-71 standard as ‘Reserved for ISO 15765-2’.

Alt text: Diagram illustrating OBD2 protocol request and response frames, showing PID data parameters flow.

Alt text: Table overview of OBD2 OBD CAN bus Identifiers, highlighting 7DF, 7E8, and 7E0 identifiers and their functions.

Alt text: Conceptual graphic contrasting OBD2 and proprietary CAN bus systems, indicating differences in data accessibility and standardization.

OBD2 vs. Proprietary CAN Protocols

It’s crucial to understand that your vehicle’s Electronic Control Units (ECUs) operate using proprietary CAN protocols defined by the Original Equipment Manufacturer (OEM), not OBD2. These proprietary CAN protocols are specific to the vehicle brand, model, and year. Without OEM documentation, interpreting this data is typically not possible (unless you undertake reverse engineering).

Connecting a CAN bus data logger to your car’s OBD2 connector might capture OEM-specific CAN data, usually broadcast at rates of 1000-2000 frames per second. However, many newer vehicles employ a ‘gateway’ that restricts access to this CAN data through the OBD2 connector, allowing only OBD2 communication.

In essence, think of OBD2 as a supplementary higher-layer protocol that exists alongside the OEM-specific protocol.

Bit-Rate and ID Validation

As mentioned, OBD2 can operate with two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), creating four potential combinations. Modern vehicles commonly use 500K and 11-bit IDs, but diagnostic tools should systematically verify this.

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) and that incorrect bit-rates will cause CAN error frames.

More recent versions of ISO 15765-4 consider that vehicles may support OBD communication via OBDonUDS rather than OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on emission diagnostic service per ISO 15031-5/SAE J1979) versus WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service per ISO 14229, ISO 27145-3/SAE J1979-2).

To test for OBDonEDS versus OBDonUDS, diagnostic tools 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.

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

Alt text: Flowchart detailing the OBD2 bit-rate and CAN ID validation process according to ISO 15765-4 standards.

Alt text: Diagram outlining the five lower-layer OBD2 protocols: CAN (ISO 15765), KWP2000, SAE J1850 (VPW & PWM), and ISO9141.

Five Lower-Layer OBD2 Protocols

While CAN bus is the dominant lower-layer protocol for OBD2 today (ISO 15765), particularly in vehicles manufactured post-2008, older cars may use other protocols. Understanding these can be helpful when working with older vehicles. The OBD2 connector pinout 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+ vehicles, especially in Asia.
ISO 9141-2: Used in EU, Chrysler, and Asian cars around 2000-2004.
SAE J1850 (VPW): Predominantly used in older GM vehicles.
SAE J1850 (PWM): Predominantly used in older Ford vehicles.

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

All OBD2 data communication over CAN bus relies on the ISO-TP transport protocol (ISO 15765-2). This protocol allows for transmitting data payloads exceeding the 8-byte limit of a single CAN frame. This is essential for OBD2 operations 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, refer to our introduction to UDS.

However, often, 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 available for OBD2 communication.

Alt text: Diagram illustrating ISO 15765-2 ISO-TP OBD2 frame types, including Single Frame, First Frame, Consecutive Frame, and Flow Control Frame.

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, data length (PCI field), and data. The data itself is structured into Mode, Parameter ID (PID), and data bytes.

Alt text: Breakdown of an OBD2 message structure, explaining raw mode, PID, ID, and data bytes within an OBD-II frame.

Example: OBD2 Request/Response

Consider this example request/response for ‘Vehicle Speed’ to understand how OBD2 messages work.

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 with CAN ID 0x7E8 and 3 payload bytes, including the Vehicle Speed value in the 4th byte, 0x32 (50 in decimal).

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

Let’s now delve into OBD2 modes and PIDs in more detail.

Alt text: Example of OBD2 request (7DF) and response (7E8) messages for vehicle speed, demonstrating data flow.

Alt text: OBD2 PID example for Vehicle Speed (0D), illustrating the PID code and its corresponding parameter.

Alt text: Diagram outlining the 10 OBD2 service modes, including current data, freeze frame, and clear DTC modes, representing diagnostic services.

The 10 OBD2 Services (Modes)

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

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

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

OBD2 Parameter IDs (PIDs)

Each OBD2 mode contains Parameter IDs (PIDs).

For instance, mode 0x01 includes approximately 200 standardized PIDs providing real-time data on parameters like speed, RPM, and fuel level. However, vehicles are not obligated to support all PIDs within a mode; in practice, most vehicles support only a subset.

One PID holds a special significance. If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID, the vehicle’s ECU indicates whether it supports PIDs 0x01-0x20. PID 0x00 thus serves as a fundamental ‘OBD2 compatibility test’. Additionally, PIDs 0x20, 0x40, …, 0xC0 can be used to determine support for the remaining mode 0x01 PIDs.

Alt text: Diagram of OBD2 protocol request and response frames, emphasizing PID data parameters and communication flow.

Alt text: Screenshot of an OBD2 PID overview tool, showing service 01 and available PIDs for diagnostic data retrieval.

Tip: OBD2 PID Overview Tool

The appendices of SAE J1979 and ISO 15031-5 provide scaling information for standard OBD2 PIDs, enabling you to convert raw data into physical values (as discussed in our CAN bus introduction).

For quick lookup of mode 0x01 PIDs, utilize our OBD2 PID overview tool. This tool assists in constructing OBD2 request frames and dynamically decoding OBD2 responses.

OBD2 PID overview tool

How to Log and Decode OBD2 Data Using the Diagnostic Connector

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

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

Once configured, you can easily connect the CANedge to your vehicle using our OBD2-DB9 adapter cable and the OBD2 diagnostic connector.

Alt text: Illustration of an OBD2 PID data logger requesting data (7df) and receiving a response (7e8), showcasing data logging process.

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

Alt text: Screenshot showing a bit rate validation test for OBD2, confirming successful CAN frame transmission at 500K.

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

Alt text: Screenshot of asammdf software displaying OBD2 validation PID test responses, enabling review of supported PIDs.

Alt text: Image showing the review of supported PIDs using an OBD2 lookup tool, allowing decoding of ‘Supported PIDs’ results.

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

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

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

We offer plug-and-play configurations to facilitate these tests. Most non-EV vehicles from 2008 onwards typically 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, multiple responses to a single OBD request are common. This is because using the 0x7DF request ID polls all ECUs for a response. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, numerous responses to this PID are frequent. As evident, fewer ECUs respond to subsequent ‘Supported PIDs’ requests. Note that the ECM ECU (0x7E8) supports all PIDs supported by other ECUs in this example. Busload can be reduced by specifically requesting responses only from this ECU using the ‘Physical Addressing’ CAN ID 0x7E0 for subsequent communication.

#2: Configure OBD2 PID Requests

Once you’ve identified the supported OBD2 PIDs for your vehicle, along with the correct bit-rate and CAN IDs, you can configure your transmit list with the PIDs you’re interested in.

Consider these points when configuring your requests:

CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses to each request.
Spacing: Add a delay of 300-500 ms between each OBD2 request to prevent overwhelming the ECUs and ensure responses.
Battery Drain: Implement triggers to stop transmissions when the vehicle is inactive to prevent unnecessary ECU wake-up and battery drain.
Filters: Apply filters to record only OBD2 responses if your vehicle also outputs OEM-specific CAN data, to keep logs focused.

With these configurations, your device is set to log raw OBD2 data effectively!

An example list of CANedge OBD2 PID requests

Alt text: Example CANedge OBD2 PID request list, showcasing configuration for data logging.

asammdf lets you DBC decode and visualize OBD2 data

Alt text: Visual plot of decoded OBD2 data in asammdf, using a CAN bus DBC file, showing data visualization and analysis.

#3: DBC Decode Raw OBD2 Data

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

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

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

To address this, you must use the CAN ID, OBD2 mode, and OBD2 PID to identify each signal. This multiplexing technique is referred to as ‘extended multiplexing‘ and can be implemented using DBC files.

CANedge: OBD2 Data Logger

The CANedge enables easy recording of OBD2 data onto an 8-32 GB SD card. Simply connect it to your vehicle’s OBD2 diagnostic connector to start logging and decode the data using free software/APIs and our OBD2 DBC file.

OBD2 logger intro
CANedge

OBD2 Multi-Frame Examples [ISO-TP]

OBD2 communication relies on ISO-TP (transport protocol) as per ISO 15765-2. Most examples covered so far are single-frame communications. This section provides examples of multi-frame communication scenarios.

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

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

Alt text: Example of an OBD2 multi-frame request message for Vehicle Identification Number (VIN), demonstrating multi-frame protocol.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval

The Vehicle Identification Number (VIN) is crucial for telematics, diagnostics, and more (see our UDS introduction). To retrieve the VIN from a vehicle using OBD2 requests, use mode 0x09 and PID 0x02:

Alt text: Example of VIN Vehicle Identification Number OBD2 multi-frame communication, illustrating request and response sequence.

The testing 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 containing the PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). Following the PID, byte 0x01 represents the Number Of Data Items (NODI), which is 1 in this case (refer to ISO 15031-5 / SAE J1979 for details). The remaining 17 bytes constitute the VIN, which can be converted from HEX to ASCII using methods discussed in our UDS introduction.

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

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

This efficient method allows for higher frequency OBD2 data collection. However, the signal encoding becomes specific to the request method, making generic OBD2 DBC files less useful. We generally advise against this method in practice. Below is an example trace:

Alt text: Trace example of requesting multiple PIDs in a single OBD2 request, demonstrating multi-PID request and ISO-TP trace.

The multi-frame response is similar to the VIN example, but the payload includes both the requested PIDs and their corresponding data. In this example, PIDs are ordered similarly to the request order, which is common but not strictly mandated by ISO 15031-5.

Decoding this response via generic DBC files is challenging. Unless your tool specifically supports this method, it’s not recommended for practical data logging. It involves extended multiplexing with multiple instances within the payload, making it difficult to generalize DBC files across vehicles with varying supported PIDs. Furthermore, managing this becomes complex with multiple multi-PID requests, as uniquely identifying messages becomes difficult.

Workarounds could involve custom scripts and recording transmit messages from your testing tool, allowing the script to interpret responses based on request messages. However, such approaches are hard to scale.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

You can request emissions-related Diagnostic Trouble Codes (DTCs) using OBD2 mode 0x03 (‘Show stored Diagnostic Trouble Codes’). No PID is included in the request. The target ECU(s) will respond with the number of stored DTCs (possibly 0 if none), 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 hexadecimal code, as shown in the visual. 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.

Alt text: Example of OBD2 DTC Diagnostic Trouble Code DBC interpretation, showing decoding process and structure of DTC codes.

Alt text: Example of OBD2 Diagnostic Trouble Codes DTC CAN Bus Request Response, illustrating CAN bus trace frames for DTC retrieval.

OBD2 Data Logging – Use Case Examples

OBD2 data from cars and light trucks has numerous applications:

Alt text: Image depicting an OBD2 data logger connected to a car, representing on-board diagnostics and data logging.

Logging Data from Cars

OBD2 data logging from cars can be used to reduce fuel consumption, improve driving habits, test prototype components, and for insurance purposes.

obd2 logger

Alt text: Graphic illustrating OBD2 real-time streaming diagnostics via USB, representing real-time data access for diagnostics.

Real-Time Car Diagnostics

OBD2 interfaces enable real-time streaming of human-readable OBD2 data, useful for diagnosing vehicle issues.

obd2 streaming

Alt text: Image representing OBD2 data logger for predictive maintenance, showcasing telematics and data-driven maintenance strategies.

Predictive Maintenance

Cars and light trucks can be monitored via IoT OBD2 loggers in the cloud for predictive maintenance, helping to anticipate and prevent breakdowns.

predictive maintenance

Alt text: Graphic of a black box CAN logger, illustrating its use in insurance and warranty applications for vehicle data recording.

Vehicle Blackbox Logger

An OBD2 logger can serve as a ‘black box’ for vehicles or equipment, providing valuable data for dispute resolution or diagnostics.

can bus blackbox

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

For more introductory guides, 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

Alt text: OBD2 Data Logger Dongle Car Vehicle, showcasing OBD2 data logging and conversion capabilities.

CANEDGE2 – PRO CAN IoT LOGGER

Alt text: CANedge2 – Dual CAN Bus Telematics Dongle, highlighting features of a professional CAN IoT logger.

CAN BUS INTERFACE: STREAMING OBD2 DATA WITH SAVVYCAN

Alt text: CAN Bus Interface streaming OBD2 data with SavvyCAN free software, emphasizing OBD2 data streaming with interface tools.

Understanding the OBD2 Diagnostic Connector: Your Car’s Health Interface

In this article