Unlock Your Car's Secrets: What Can You Do With OBD2?

The On-Board Diagnostics II (OBD2) system is a powerful tool built into modern vehicles, acting as your car’s self-diagnostic center. But what exactly can you do with OBD2? This guide provides a practical introduction to the world of OBD2, exploring its capabilities, from reading error codes to unlocking valuable vehicle data.

You’ve likely encountered OBD2 without even realizing it. That “check engine” light on your dashboard? That’s OBD2 at work, signaling a potential issue. Mechanics use OBD2 scanners to quickly diagnose problems by connecting to the 16-pin OBD2 connector, typically located near the steering wheel. These scanners send requests and receive responses containing crucial data like speed, fuel levels, and Diagnostic Trouble Codes (DTCs), streamlining the repair process.

Is OBD2 Available in My Car?

The good news is that OBD2 is almost certainly supported in your non-electric car if it’s a newer model. While older cars might feature a 16-pin connector, it doesn’t guarantee OBD2 compatibility. A simple rule of thumb is to consider where and when your car was initially purchased:

A Brief History of OBD2

OBD2 originated in California, driven by the California Air Resources Board (CARB) mandate for OBD systems in all new cars from 1991 onwards for emission control. The Society of Automotive Engineers (SAE) standardized the protocol, including DTCs and the OBD connector, ensuring consistency across manufacturers (SAE J1962).

The adoption of OBD2 was phased in globally:

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

The Future of OBD2 and Emerging Trends

While OBD2 remains relevant, its future is evolving. Here are key trends to consider:

Electric Vehicles (EVs) and OBD2: Interestingly, EVs are not legally obligated to support OBD2 for emission control, as it was initially intended. Consequently, many modern EVs do not support standard OBD2 requests, often using OEM-specific UDS communication instead. Accessing data from these EVs typically requires reverse engineering efforts, as seen in case studies for Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.

Advanced OBD Standards: Recognizing the limitations of current OBD2 in data richness and lower-layer protocols, alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging. These aim to enhance OBD communication by utilizing the UDS protocol as a base.

OBD3 and Telematics: The concept of OBD3 envisions integrating telematics into all vehicles. This could involve adding a radio transponder to transmit Vehicle Identification Numbers (VINs) and DTCs wirelessly to a central server for automated emission checks. While devices like the CANedge2 and CANedge3 already facilitate data transfer via WiFi/cellular, widespread OBD3 adoption faces political hurdles due to privacy concerns.

OEM Data Control: The automotive industry is considering limiting third-party access to OBD2 data, initially designed for repair shops. Proposals suggest disabling OBD2 functionality during driving and centralizing data collection with manufacturers. This shift aims to control “automotive big data” and address security concerns like car hacking, but it could significantly impact the market for third-party OBD2 services.

Become a CAN Bus Expert

Want to delve deeper into vehicle communication?

Download our comprehensive 160+ page PDF guide, “Ultimate CAN Guide,” featuring 12 simple introductions.

Download now

Understanding OBD2 Standards

OBD2 operates as a higher-layer protocol built upon communication methods like CAN bus. Think of OBD2 as a language and CAN bus as the phone line. Similar to other CAN-based protocols like J1939, CANopen, and NMEA 2000, OBD2 standards define the connector, lower-layer protocols, Parameter IDs (PIDs), and more.

These standards are structured within a 7-layer OSI model, with both SAE (US standards) and ISO (EU standards) contributing. Many standards are technically similar, such as SAE J1979 vs. ISO 15031-5 and SAE J1962 vs. ISO 15031-3.

The OBD2 Connector: Your Access Point [SAE J1962]

The 16-pin OBD2 connector, standardized under SAE J1962 / ISO 15031-3, provides easy access to your car’s data. The illustration shows a typical Type A connector (Data Link Connector, DLC).

Key points about the OBD2 connector:

It’s usually near the steering wheel, but may be concealed.
Pin 16 provides battery power, even when the ignition is off.
Pinout configuration varies depending on the communication protocol.
CAN bus, the most common lower-layer protocol, typically uses pins 6 (CAN-H) and 14 (CAN-L).

OBD2 Connector Types: A vs. B

You might 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.

While pinouts are similar, Type A provides 12V power, and Type B provides 24V. Baud rates can also differ, with cars often using 500K and heavy-duty vehicles typically using 250K (increasingly supporting 500K).

Type B connectors have a central interrupted groove, allowing Type B adapter cables to fit both Type A and B sockets, but Type A cables will only fit Type A sockets.

OBD2 and CAN Bus: The Communication Foundation [ISO 15765-4]

Since 2008, CAN bus has been the mandatory lower-layer protocol for OBD2 in US vehicles (ISO 15765).

ISO 15765-4 (Diagnostics over CAN or DoCAN) specifies CAN standard restrictions for test equipment, focusing on physical, data link, and network layers:

CAN bus bit-rate: 250K or 500K.
CAN IDs: 11-bit or 29-bit.
Specific CAN IDs for OBD requests/responses.
Diagnostic CAN frame data length: 8 bytes.
OBD2 adapter cable length limit: 5 meters.

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

OBD2 communication relies on request/response messages.

Most cars use 11-bit CAN IDs for OBD2. Functional Addressing ID 0x7DF queries all OBD2-compatible ECUs for data on a requested parameter. Physical Addressing IDs (0x7E0-0x7E7) target specific ECUs (less common).

ECUs respond with 11-bit IDs 0x7E8-0x7EF, with 0x7E8 (ECM – Engine Control Module) and 0x7E9 (TCM – Transmission Control Module) being the most frequent.

Some vehicles, like vans and heavy-duty vehicles, may use extended 29-bit CAN identifiers for OBD2. The Functional Addressing CAN ID here is 0x18DB33F1. Responses use CAN IDs 0x18DAF100 to 0x18DAF1FF (often 18DAF110 and 18DAF11E), sometimes shown as J1939 PGN 0xDA00 (55808), reserved for ISO 15765-2.

OBD2 vs. OEM-Specific CAN Protocols

Crucially, your car’s ECUs operate using OEM-proprietary CAN protocols, not OBD2. These protocols vary by vehicle brand, model, and year. Unless you are the OEM or can reverse engineer the data, interpreting this data is usually impossible.

Connecting a CAN bus data logger to the OBD2 port might capture OEM-specific CAN data (typically broadcast at 1000-2000 frames/second). However, newer cars often have a gateway that blocks access, allowing only OBD2 communication through the OBD2 connector.

Think of OBD2 as a secondary, higher-layer protocol running alongside the OEM-specific protocol.

Bit-rate and ID Validation

OBD2 can use two bit-rates (250K, 500K) and two CAN ID lengths (11-bit, 29-bit), resulting in 4 possible combinations. 500K with 11-bit IDs is most common in modern cars, but tools should systematically verify this.

ISO 15765-4 provides a flowchart for a systematic initialization sequence to determine the correct combination. This method relies on the fact that OBD2-compliant vehicles must respond to a mandatory OBD2 request and that incorrect bit-rates cause CAN error frames.

Newer ISO 15765-4 versions account for OBD communication via OBDonUDS vs. OBDonEDS. This article primarily focuses on 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, 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 (OBD2, SAE OBD, EOBD, ISO OBD) is prevalent in non-EV cars, while WWH-OBD is mainly used in EU trucks/buses.

Five Lower-Layer OBD2 Protocols

While CAN (ISO 15765) is dominant today, older cars (pre-2008) may use other lower-layer protocols. Connector pinouts can help identify these:

ISO 15765 (CAN bus): Mandatory in US cars since 2008, now widely used.
ISO14230-4 (KWP2000): Common in 2003+ cars, especially in Asia.
ISO 9141-2: Used in EU, Chrysler & Asian cars (2000-04).
SAE J1850 (VPW): Primarily in older GM vehicles.
SAE J1850 (PWM): Primarily in older Ford vehicles.

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

OBD2 data communication over CAN bus uses ISO-TP (ISO 15765-2), a transport protocol that allows for payloads exceeding 8 bytes. This is essential for OBD2 functions like retrieving VINs or DTCs. ISO 15765-2 handles segmentation, flow control, and reassembly.

For smaller OBD2 data within a single CAN frame, ISO 15765-2 uses ‘Single Frame’ (SF) format. The first data byte (PCI field) indicates payload length (excluding padding), leaving 7 bytes for OBD2 communication.

Decoding the OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]

A simplified OBD2 CAN message comprises an identifier, data length (PCI field), and data. The data section is further divided into Mode, Parameter ID (PID), and data bytes.

OBD2 Request/Response Example

Consider the example of requesting ‘Vehicle Speed’.

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

Using OBD2 PID 0x0D decoding rules, we find that 0x32 corresponds to 50 km/h.

The 10 OBD2 Services (Modes)

OBD2 defines 10 diagnostic services or modes. Mode 0x01 provides real-time data, while others handle DTCs, freeze frame data, and more.

Vehicles may not support all 10 modes and can include OEM-specific modes beyond these.

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

OBD2 Parameter IDs (PIDs)

Each OBD2 mode contains Parameter IDs (PIDs).

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

PID 0x00 in mode 0x01 is crucial. If an emissions-related ECU supports OBD2 services, it must support mode 0x01 PID 0x00. Responding to this PID indicates support for PIDs 0x01-0x20. PID 0x00 serves as a fundamental OBD2 compatibility test. Similarly, PIDs 0x20, 0x40, …, 0xC0 reveal support for subsequent mode 0x01 PIDs.

OBD2 PID Overview Tool

SAE J1979 and ISO 15031-5 appendices detail scaling information for standard OBD2 PIDs, enabling data decoding into physical values.

Our OBD2 PID overview tool can help you construct OBD2 request frames and decode responses dynamically.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 Data

Let’s explore how to log OBD2 data using the CANedge CAN bus data logger.

The CANedge allows custom CAN frame transmission, making it suitable for OBD2 logging. Connect it to your vehicle using an OBD2-DB9 adapter cable.

Review ‘Supported PIDs’ responses in asammdf

Step #1: Bit-rate, ID, and Supported PID Testing

ISO 15765-4 outlines how to determine the correct bit-rate and IDs for a vehicle. Use the CANedge to test this:

Transmit a CAN frame at 500K and check for success (if not, try 250K).
Use the identified bit-rate for further communication.
Send multiple ‘Supported PIDs’ requests and analyze the results.
Determine 11-bit vs. 29-bit IDs based on response IDs.
Identify supported PIDs from 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.

As shown in the asammdf GUI screenshot, multiple responses to a single OBD request are common due to the 0x7DF request ID polling all ECUs. ECUs compliant with OBD2/OBDonEDS must support service 0x01 PID 0x00, leading to numerous responses to this PID. Fewer ECUs respond to subsequent ‘Supported PIDs’ requests. The ECM ECU (0x7E8) often supports all PIDs supported by other ECUs, allowing for reduced busload by specifically requesting responses from this ECU using Physical Addressing CAN ID 0x7E0.

Step #2: Configuring OBD2 PID Requests

Once you know your vehicle’s supported PIDs, bit-rate, and CAN IDs, configure your transmit list with desired PIDs.

Consider these points:

CAN IDs: Use Physical Addressing request IDs (e.g., 0x7E0) to avoid multiple responses.
Spacing: Add 300-500 ms between requests to prevent ECU overload.
Battery Drain: Use triggers to stop transmission when the vehicle is inactive.
Filters: Filter for OBD2 responses if OEM-specific CAN data is also present.

With configuration complete, the device is ready to log raw OBD2 data.

Example CANedge OBD2 PID request list

Visualize DBC decoded OBD2 data in asammdf

Step #3: DBC Decoding Raw OBD2 Data

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

Decoding information is in ISO 15031-5/SAE J1979 (and online resources like Wikipedia). Our free OBD2 DBC file simplifies DBC decoding in CAN bus software tools.

Decoding OBD2 data is more complex than standard CAN signals. Different OBD2 PIDs use the same CAN ID (e.g., 0x7E8), requiring CAN ID, OBD2 mode, and PID to identify signals. This “extended multiplexing” is handled in DBC files.

CANedge: Your OBD2 Data Logger

The CANedge enables easy OBD2 data recording to an 8-32 GB SD card. Connect to your vehicle to start logging and decode data using free software/APIs and our OBD2 DBC file.

OBD2 logger intro CANedge

Multi-Frame OBD2 Examples [ISO-TP]

While most examples have been single-frame, OBD2 also utilizes multi-frame communication with ISO-TP. This requires flow control frames, often achieved by sending a static flow control frame ~50 ms after the initial request.

CAN software/API tools supporting ISO-TP, like CANedge MF4 decoders, are needed for multi-frame OBD2 responses.

Example 1: Retrieving Vehicle Identification Number (VIN)

The VIN is crucial for telematics, diagnostics, and more. Use mode 0x09 and PID 0x02 to retrieve it via OBD2:

The tool sends a Single Frame request (PCI 0x02, service 0x09, PID 0x02). The vehicle responds with a First Frame (PCI, length 0x014 = 20 bytes, mode 0x49, PID 0x02), followed by byte 0x01 (Number Of Data Items – NODI, in this case 1). The subsequent 17 bytes represent the VIN, convertible from HEX to ASCII.

Example 2: Multi-PID Request (6x)

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

This enhances data collection efficiency but complicates signal encoding, making generic OBD2 DBC files less useful. We generally advise against this method.

The multi-frame response resembles the VIN example but includes requested PIDs and their data. PID order often mirrors the request order (common but not mandatory). Decoding these responses with DBC files is complex, making it impractical for general data logging unless using tools with specific support.

Example 3: Diagnostic Trouble Codes (DTCs)

Mode 0x03 (‘Show stored Diagnostic Trouble Codes’) retrieves emissions-related DTCs. No PID is included in the request. ECUs respond with the number of stored DTCs (including 0 if none), with each DTC occupying 2 bytes. Multi-frame responses are necessary for more than 2 DTCs.

The 2-byte DTC value is split into category (first 2 bits) and a 4-digit hexadecimal code. Decoded DTCs 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.

Real-World Applications: What Can You Actually Do with OBD2?

OBD2 data from cars and light trucks has numerous practical applications:

Car Data Logging:

Fuel Efficiency: Analyze driving habits to reduce fuel consumption and costs.
Driving Improvement: Gain insights into driving behavior for safer and more efficient driving.
Prototype Testing: Validate new automotive parts and systems under real-world conditions.
Insurance Telematics: Utilize driving data for usage-based insurance models.

obd2 logger

Real-Time Car Diagnostics:

DIY Diagnostics: Stream OBD2 data in real-time for immediate vehicle issue diagnosis and troubleshooting.
Mechanic Assistance: Provide mechanics with live data for faster and more accurate repairs.

obd2 streaming

Predictive Maintenance:

Fleet Management: Monitor vehicle health remotely to predict breakdowns and schedule proactive maintenance, minimizing downtime.
Personal Vehicle Maintenance: Receive early warnings of potential issues, preventing costly repairs and ensuring vehicle longevity.

predictive maintenance

Vehicle Black Box Logging:

Accident Reconstruction: Record vehicle data during incidents for detailed analysis and dispute resolution.
Warranty Validation: Provide verifiable data logs for warranty claims and vehicle history documentation.

can bus blackbox

Have an OBD2 data logging application in mind? Contact us for expert guidance!

Explore our guides section for more introductions or download the ‘Ultimate Guide’ PDF.

Ready to unlock your car’s data?

Get your OBD2 data logger today!

Buy now Contact us

Unlock Your Car’s Secrets: What Can You Do With OBD2?