Unlocking Your Car's Secrets: What Data Can You Get From OBD2?

Ever wondered what your car is really telling you? Modern vehicles are complex machines, constantly monitoring themselves. The On-Board Diagnostics II (OBD2) system is your key to tapping into this wealth of information. This guide provides a practical introduction to OBD2 and, crucially, explores what data you can get from OBD2 to better understand your vehicle’s health and performance.

You may have already encountered OBD2 without realizing it. That “check engine light” on your dashboard? That’s OBD2 in action, signaling a potential issue. Mechanics use OBD2 scanners to diagnose problems by connecting to the 16-pin OBD2 connector, typically located near the steering wheel. These scanners send requests, and the car responds with data like speed, fuel levels, and Diagnostic Trouble Codes (DTCs), making troubleshooting faster and more accurate.

Is My Car OBD2 Compatible?

The good news is, if you drive a relatively new car, it’s almost certainly OBD2 compliant. For gasoline cars in the USA, OBD2 became mandatory in 1996, and for light trucks in the same year. The rollout continued globally, with the EU requiring it for gasoline cars in 2001 and diesel cars in 2003.

However, even if your older car has a 16-pin connector, it might not fully support OBD2. Compliance is generally linked to the vehicle’s market and manufacturing date.

A Brief History of OBD2

OBD2’s origins trace back to California, driven by the California Air Resources Board (CARB). In 1991, CARB mandated OBD in new cars for emission control. The Society of Automotive Engineers (SAE) further standardized the protocol, including DTCs and the OBD connector itself (SAE J1962).

The OBD2 standard adoption timeline:

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

The Future of OBD: OBD3 and Beyond

While OBD2 is well-established, the automotive landscape is evolving. Electric Vehicles (EVs), for instance, aren’t typically required to support OBD2, and many don’t. They often use manufacturer-specific UDS communication, making data access challenging unless reverse-engineered.

Emerging standards like WWH-OBD and OBDonUDS aim to modernize OBD communication using the UDS protocol, addressing limitations in data richness and lower-layer protocols.

The concept of OBD3 envisions adding telematics to vehicles for remote emissions testing and diagnostics. This could involve a radio transponder transmitting VIN and DTCs wirelessly. While convenient, it raises privacy concerns.

Interestingly, some automotive manufacturers are considering limiting third-party OBD2 access while driving, aiming to control automotive data and enhance security. This could potentially reshape the market for OBD2-based aftermarket services.

Deep Dive: What Data Can You Actually Get from OBD2?

This is the core question. OBD2 provides access to a standardized set of parameters related to vehicle diagnostics and performance, primarily focused on emissions. Here’s a breakdown of the types of data you can typically retrieve:

Diagnostic Trouble Codes (DTCs): These codes are the primary reason for OBD2’s existence. DTCs pinpoint specific malfunctions detected by the vehicle’s computer, often triggering the “check engine light.” You can retrieve current DTCs, pending DTCs, and clear stored DTCs using OBD2.
Emission-Related Data: OBD2’s original purpose was emission control. Therefore, you can access a range of emission-related parameters, including:
- Oxygen sensor readings: Crucial for monitoring catalytic converter efficiency and air-fuel mixture.
- Catalytic converter temperature: Indicates catalytic converter performance.
- Exhaust gas recirculation (EGR) system data: Monitors EGR flow and function.
- Fuel system status: Provides insights into fuel trim, fuel pressure, and injector performance.
Real-time Engine Performance Data (Live Data or Parameter IDs – PIDs): This is where OBD2 becomes incredibly valuable for performance monitoring and deeper diagnostics. You can access a wide array of real-time data points, including:
- Engine RPM (Revolutions Per Minute): Engine speed.
- Vehicle speed: Current speed of the vehicle.
- Engine coolant temperature: Engine operating temperature.
- Intake manifold pressure: Pressure in the intake manifold.
- Mass Air Flow (MAF) sensor readings: Airflow into the engine.
- Throttle position: Accelerator pedal position.
- Fuel level: Amount of fuel remaining in the tank (percentage).
- Battery voltage: System voltage.
- Calculated engine load: Percentage of maximum engine load.
- Ignition timing advance: Timing of the spark plugs.
- Short-term and long-term fuel trim: Adjustments made to the air-fuel mixture by the engine control unit (ECU).
Freeze Frame Data: When a DTC is set, OBD2 systems often store “freeze frame” data. This is a snapshot of the engine’s operating conditions at the moment the fault occurred. It can include parameters like RPM, engine load, coolant temperature, and fuel trim, helping diagnose the conditions that led to the problem.
Vehicle Identification Number (VIN): You can retrieve the VIN electronically via OBD2, which is useful for vehicle identification and diagnostics.
Supported PIDs: You can query the vehicle to determine exactly which PIDs (parameters) it supports. This is essential as not all vehicles support every standardized PID.

Limitations of OBD2 Data:

While OBD2 provides a wealth of information, it’s important to understand its limitations:

Emission-Focused: OBD2’s primary focus is emissions. Data outside of emission-related systems may be limited or unavailable.
Standardized Data: OBD2 provides standardized data, which is great for interoperability, but it might not offer the detailed, manufacturer-specific data available through proprietary diagnostic tools.
Not All PIDs Supported: Vehicles don’t have to support every PID. The actual data available varies by manufacturer, model, and year.
Limited Access to All Systems: OBD2 primarily focuses on powertrain-related systems (engine and transmission). Access to data from chassis, body, or infotainment systems is usually not available through standard OBD2.

Despite these limitations, OBD2 remains an incredibly powerful tool for vehicle owners, enthusiasts, and professionals to understand vehicle health, diagnose issues, and monitor performance. The data you can get from OBD2 is invaluable for preventative maintenance, performance tuning (when done responsibly and legally), and simply gaining a deeper understanding of your car’s operation.

Get Our ‘Ultimate CAN Guide’

Want to become a CAN bus expert and understand the backbone of OBD2 communication?

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

Download now

OBD2 Standards: The Foundation of Data Access

OBD2 functions as a higher-layer protocol built on communication methods like CAN bus. Think of OBD2 as the language and CAN bus as the phone line. It’s similar to other CAN-based protocols like J1939, CANopen, and NMEA 2000.

OBD2 standards define everything from the connector to communication protocols and the Parameter IDs (PIDs) that dictate what data you can get from OBD2. These standards are often represented in a 7-layer OSI model, with both SAE (US) and ISO (EU) standards contributing.

The OBD2 Connector [SAE J1962]: Your Physical Access Point

The 16-pin OBD2 connector, standardized under SAE J1962 / ISO 15031-3, is your physical interface to your car’s data. This connector is usually located near the steering wheel, though sometimes hidden. Key features include:

Pin 16 provides battery power.
Pinout varies depending on the communication protocol.
CAN bus, using pins 6 (CAN-H) and 14 (CAN-L), is the most common lower-layer protocol.

OBD2 Connector Types: A vs. B

You might encounter Type A (cars) and Type B (medium/heavy-duty vehicles) OBD2 connectors. While pinouts are similar, Type B provides 24V power (Type A is 12V) and often uses different baud rates. Type B connectors have an interrupted groove, making Type B adapters compatible with both types, while Type A adapters only fit Type A sockets.

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

Since 2008, CAN bus (ISO 15765) has been mandatory for OBD2 in US cars. ISO 15765-4 (Diagnostics over CAN or DoCAN) standardizes the CAN interface for diagnostic equipment, specifying:

Bit rates: 250K or 500K.
CAN IDs: 11-bit or 29-bit.
Specific CAN IDs for OBD requests/responses.
8-byte CAN frame data length.
Maximum OBD2 adapter cable length of 5 meters.

OBD2 CAN Identifiers

OBD2 communication uses request/response messages. 11-bit CAN IDs are common in cars, with Functional Addressing ID 0x7DF (asking all ECUs) and Physical Addressing IDs 0x7E0-0x7E7 (specific ECUs). Responses typically use 11-bit IDs 0x7E8-0x7EF, with 0x7E8 (Engine Control Module – ECM) being most frequent.

Some vehicles, especially larger ones, use 29-bit CAN identifiers. Functional Addressing ID is 0x18DB33F1, and responses range from 0x18DAF100 to 0x18DAF1FF (often 18DAF110 and 18DAF11E).

OBD2 vs. Proprietary CAN Protocols

Your car’s ECUs rely on manufacturer-specific CAN protocols for their core functions, not OBD2. OBD2 is an additional protocol for diagnostics. OEM-specific CAN data is often broadcast on the same CAN bus as OBD2, but is typically encrypted or undocumented, requiring reverse engineering to understand. Newer cars may use gateways to block access to OEM-specific data via the OBD2 port, allowing only OBD2 communication.

Bit-rate and ID Validation

OBD2 can use different bit rates (250K, 500K) and CAN ID lengths (11-bit, 29-bit), leading to four combinations. Modern cars commonly use 500K and 11-bit IDs. ISO 15765-4 outlines a process to automatically detect the correct combination by sending a mandatory OBD2 request and checking for responses and CAN errors.

Five Lower-Layer OBD2 Protocols

While CAN (ISO 15765) is dominant today, older cars might use other protocols:

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

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

OBD2 uses ISO-TP (ISO 15765-2) as a transport protocol over CAN to handle messages larger than 8 bytes, necessary for data like VIN or DTCs. ISO-TP manages segmentation, flow control, and reassembly. For smaller OBD2 requests and responses, “Single Frame” (SF) messages are used, with the first byte indicating payload length, leaving 7 bytes for OBD2 data.

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

An OBD2 message, in its simplest form, contains an identifier, data length, and data. The data is structured into Mode, Parameter ID (PID), and data bytes.

Example: OBD2 Request/Response for Vehicle Speed

For example, to request Vehicle Speed, a tool sends a request (CAN ID 0x7DF) with Mode 0x01 and PID 0x0D. The car responds (CAN ID 0x7E8) with the speed value in bytes. Decoding PID 0x0D reveals the physical value (e.g., 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, etc. Vehicles don’t have to support all modes, and OEM-specific modes can exist. In messages, the request mode is direct (e.g., 0x01), while the response mode adds 0x40 (e.g., 0x41).

OBD2 Parameter IDs (PIDs): Accessing Specific Data Points

Within each OBD2 mode are Parameter IDs (PIDs). Mode 0x01, for instance, contains ~200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles typically support only a subset of PIDs.

PID 0x00 in mode 0x01 is crucial. If an ECU supports OBD2, it must support PID 0x00. Responding to this PID indicates support for PIDs 0x01-0x20. PIDs 0x20, 0x40, etc., similarly indicate support for subsequent PID ranges within mode 0x01.

Tip: OBD2 PID Overview Tool

SAE J1979 and ISO 15031-5 appendices detail scaling information for standard OBD2 PIDs, enabling conversion to physical values. Our OBD2 PID overview tool helps construct requests and decode responses, making it easier to understand what data you can get from OBD2 in practice.

OBD2 PID overview tool

Practical Guide: Logging and Decoding OBD2 Data

Let’s walk through logging OBD2 data using a CANedge data logger as an example.

Test bit rate validation for OBD2.

Review supported PIDs via asammdf.

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

Follow ISO 15765-4 to determine the correct bit-rate and IDs for your vehicle:

Test at 500K; if successful, use it (else try 250K).
Use the identified bit-rate for communication.
Send ‘Supported PIDs’ requests and analyze responses.
Determine 11-bit or 29-bit IDs from response IDs.
Identify supported PIDs from response data.

Plug-and-play configurations are available to simplify these tests. Most post-2008 non-EV cars support 40-80 PIDs using 500K bit-rate, 11-bit CAN IDs, and OBD2/OBDonEDS. Multiple responses to PID 0x00 requests are common due to polling all ECUs.

#2: Configure OBD2 PID Requests

Once you know supported PIDs, bit-rate, and IDs, configure your data logger to request the PIDs you need. Consider these points:

CAN IDs: Use Physical Addressing (e.g., 0x7E0) to target specific ECUs and reduce response redundancy.
Spacing: Add 300-500ms delay between requests to avoid overwhelming ECUs.
Battery Drain: Use triggers to stop requests when inactive.
Filters: Filter for OBD2 responses if OEM-specific CAN data is also present.

Configure your device, and you are set to log raw OBD2 data!

Example CANedge OBD2 PID request list.

Visualize DBC decoded OBD2 data in asammdf.

#3: DBC Decode Raw OBD2 Data

To analyze logged data, decode the raw OBD2 data into physical values. ISO 15031-5/SAE J1979 and online resources like Wikipedia provide decoding information. Our free OBD2 DBC file simplifies DBC decoding in CAN bus software tools.

Decoding OBD2 is complex because different PIDs share the same CAN ID. Decoding requires using the CAN ID, OBD2 mode, and PID – a form of “extended multiplexing” handled by DBC files.

CANedge: Your OBD2 Data Logger

The CANedge recorder makes OBD2 data logging straightforward, saving data to SD cards (8-32GB). Connect to your vehicle to start logging, and use free software/APIs and our OBD2 DBC for decoding.

OBD2 logger intro CANedge

OBD2 Multi-Frame Examples [ISO-TP]

Most examples so far have been single-frame. Multi-frame communication, handled by ISO-TP, is required for larger data sets. It involves flow control frames. CANedge configurations can use static flow control frames after requests. CAN software supporting ISO-TP, like CANedge MF4 decoders, is needed for multi-frame responses.

Example 1: OBD2 Vehicle Identification Number (VIN) Retrieval

Retrieving the VIN (Vehicle Identification Number) uses mode 0x09 and PID 0x02.

The tool sends a Single Frame request (Mode 0x09, PID 0x02). The vehicle responds with a First Frame containing length, mode (0x49), PID (0x02), NODI (Number Of Data Items – 1), and the 17-byte VIN (HEX to ASCII conversion needed).

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

Requesting up to 6 mode 0x01 PIDs in a single request is possible, but complex to decode and not recommended for general use. The response structure becomes request-specific, complicating DBC file use.

Example 3: OBD2 Diagnostic Trouble Codes (DTCs)

Mode 0x03 (‘Show stored Diagnostic Trouble Codes’) retrieves DTCs. No PID is needed in the request. Responses include the number of DTCs and 2-byte DTC values. Multi-frame responses are used if more than 2 DTCs are present. DTCs are 2-byte values, categorized and coded as per ISO 15031-5/ISO 15031-6. Decoded DTCs can be looked up using online tools.

Real-World Applications: OBD2 Data Logging Use Cases

OBD2 data has diverse applications:

Car Data Logging

OBD2 data helps in fuel efficiency, driving improvement, part testing, and insurance applications.

obd2 logger

Real-time Car Diagnostics

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

obd2 streaming

Predictive Maintenance

IoT OBD2 loggers enable cloud-based vehicle monitoring for predictive maintenance.

predictive maintenance

Vehicle Black Box Logging

OBD2 loggers act as ‘black boxes’ for accident analysis and diagnostics.

can bus blackbox

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

Explore more guides in our tutorials section or download the ‘Ultimate Guide’ PDF.

Ready to log or stream OBD2 data?

Get your OBD2 data logger today!

Buy now Contact us

Unlocking Your Car’s Secrets: What Data Can You Get From OBD2?