Curious about what your car is trying to tell you? OBD2 is the key.
This guide offers a practical introduction to the On-Board Diagnostics 2 (OBD2) protocol, including the OBD2 connector, Parameter IDs (PIDs), and its connection to the CAN bus.
Dive in to discover how to access and understand OBD2 data, explore key applications, and gain practical insights into this essential automotive system.
Why is this becoming a go-to OBD2 resource? Let’s find out together.
You can also watch our OBD2 intro video above – or get the PDF
Article Contents
Author: Martin Falch (updated January 2025)
Download as PDF
Understanding OBD2: Your Car’s Diagnostic Window
OBD2 is your vehicle’s built-in diagnostic system. It’s a standardized protocol that allows you to extract diagnostic trouble codes (DTCs) and real-time data through the OBD2 connector.
You’ve likely encountered OBD2 in action already:
Ever seen the check engine light illuminate on your dashboard?
That’s your car signaling a potential problem. Mechanics use an OBD2 scanner to pinpoint these issues.
They connect the OBD2 reader to the 16-pin OBD2 connector, usually found near the steering wheel. This tool sends ‘OBD2 requests’ to the car, and the car responds with ‘OBD2 responses’. These responses contain valuable data like speed, fuel level, and Diagnostic Trouble Codes (DTCs), which helps mechanics diagnose problems efficiently.
OBD2 Compatibility: Is Your Car Equipped?
In most cases: Yes!
The vast majority of modern non-electric cars are OBD2 compliant and often operate on the CAN bus system. However, for older vehicles, even if a 16-pin OBD2 connector is present, it might not actually support OBD2. A key indicator of compliance is the car’s purchase location and year:
A Brief History of OBD2
OBD2 originated in California, driven by the California Air Resources Board (CARB) mandate for OBD in all new cars from 1991 onwards for emissions monitoring.
The Society of Automotive Engineers (SAE) recommended the OBD2 standard, which standardized DTCs and the OBD connector across all vehicle manufacturers (SAE J1962).
The OBD2 standard rollout occurred progressively:
- 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 became mandatory in the US for medium-duty vehicles.
- 2008: US cars were required to use ISO 15765-4 (CAN) as the foundation for OBD2.
- 2010: OBD2 was finally required in US heavy-duty vehicles.
The Future of OBD2
OBD2 is set to remain relevant, but its form is evolving.
Here are key trends to watch:
Originally legislated for emissions control, OBD2 requirements don’t extend to electric vehicles. Consequently, most modern EVs don’t support standard OBD2 requests, opting instead for OEM-specific UDS communication. This often makes data decoding challenging without reverse engineering efforts. However, successful reverse engineering examples exist, as shown in our case studies for electric cars, including Tesla, Hyundai/Kia, Nissan, and VW/Skoda EVs.
OBD2 implementations vary and face limitations regarding data richness and lower-layer protocols. Modern alternatives like WWH-OBD (World Wide Harmonized OBD) and OBDonUDS (OBD on UDS) are emerging to enhance OBD communication using the UDS protocol. For deeper insights, see our UDS protocol introduction.
In our connected world, manual OBD2 emission checks seem outdated.
The proposed solution? OBD3 – integrating telematics into all vehicles.
OBD3 envisions adding a small radio transponder to cars, similar to those used for bridge tolls. This would enable vehicles to wirelessly transmit their vehicle identification number (VIN) and DTCs 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 and the CANedge3 3G/4G CAN logger.
While convenient and cost-saving, OBD3 raises political challenges related to surveillance concerns.
The original purpose of OBD2 was for in-shop emission controls.
However, today, third parties widely utilize OBD2 to generate real-time data via OBD2 dongles, CAN loggers etc. The German car industry aims to change this:
OBD has been designed to service 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)
Their proposal is to disable OBD2 functionality during driving, centralizing data collection instead. This would give manufacturers control over ‘automotive big data’.
Arguments center on security (reducing car hacking risks), though many view it as a commercial strategy (https://www.navixy.com/blog/obd-trackers-what-future-awaits/). Whether this trend gains traction remains to be seen, but it could significantly disrupt the OBD2 third-party service market.
Get Our ‘Ultimate CAN Guide’
Want to become a CAN bus expert?
Access our 12 ‘simple intros’ in a comprehensive 160+ page PDF:
Download now
OBD2 Standards: A Layered Approach
On-board diagnostics, OBD2, is a higher-layer protocol (like a language), while CAN is a communication method (like a phone line). OBD2 is similar to other CAN-based higher-layer protocols such as J1939, CANopen, and NMEA 2000.
OBD2 standards define the OBD2 connector, lower-layer protocols, OBD2 Parameter IDs (PIDs), and more.
These standards can be viewed through a 7-layer OSI model. The following sections will focus on the most critical aspects.
In the OSI model, you’ll notice that SAE and ISO standards cover multiple layers. This reflects the standards defined in the USA (SAE) and EU (ISO). Many standards are technically very similar, for instance, SAE J1979 and ISO 15031-5, and SAE J1962 and ISO 15031-3.
The OBD2 Connector [SAE J1962]
The 16-pin OBD2 connector provides easy access to your car’s data and is standardized in SAE J1962 / ISO 15031-3.
The illustration shows a Type A OBD2 pin connector (also known as the Data Link Connector, or DLC).
Key points about the OBD2 connector:
- It’s usually near the steering wheel, but can be hidden.
- Pin 16 provides battery power (often even when the ignition is off).
- The OBD2 pinout varies based on the communication protocol.
- CAN bus is the most common lower-layer protocol, meaning pins 6 (CAN-H) and 14 (CAN-L) are typically connected.
OBD2 Connector Types: A vs. B
You might encounter both Type A and Type B OBD2 connectors. Type A is standard in cars, while Type B is common in medium and heavy-duty vehicles.
As shown, both types share similar pinouts but differ in power supply outputs (12V for Type A and 24V for Type B). Baud rates often differ as well, with cars typically using 500K, and heavy-duty vehicles often using 250K (though 500K support is increasing).
Type B OBD2 connectors have a central interrupted groove, distinguishing them physically. A Type B OBD2 adapter cable is compatible with both Type A and B sockets, while a Type A adapter will not fit into a Type B socket.
OBD2 and CAN Bus [ISO 15765-4]
Since 2008, CAN bus has been mandatory for OBD2 in all US cars, according to ISO 15765.
ISO 15765-4 (Diagnostics over CAN, or DoCAN) specifies restrictions on the CAN standard (ISO 11898).
It standardizes the CAN interface for test equipment, focusing on the physical, data link, and network layers:
- CAN bus bit-rate must be 250K or 500K.
- CAN IDs can be 11-bit or 29-bit.
- Specific CAN IDs are used for OBD requests/responses.
- Diagnostic CAN frame data length is 8 bytes.
- OBD2 adapter cable must be max 5 meters.
OBD2 CAN Identifiers (11-bit, 29-bit)
OBD2 communication always involves request/response messages.
Most cars use 11-bit CAN IDs for OBD2. The ‘Functional Addressing’ ID is 0x7DF, which requests data on the parameter from all OBD2-compatible ECUs (ISO 15765-4). CAN IDs 0x7E0-0x7E7 are for ‘Physical Addressing’ requests to specific ECUs (less common).
ECUs respond with 11-bit IDs 0x7E8-0x7EF. The most common response ID is 0x7E8 (ECM, Engine Control Module), followed by 0x7E9 (TCM, Transmission Control Module).
Some vehicles, like vans and medium/heavy-duty vehicles, use extended 29-bit CAN identifiers for OBD2 communication.
Here, the ‘Functional Addressing’ CAN ID is 0x18DB33F1.
Responses use CAN IDs from 0x18DAF100 to 0x18DAF1FF (typically 18DAF110 and 18DAF11E). The response ID is sometimes shown in ‘J1939 PGN’ form, specifically PGN 0xDA00 (55808), which is ‘Reserved for ISO 15765-2’ in the J1939-71 standard.
OBD2 vs. Proprietary CAN Protocols
Vehicle Electronic Control Units (ECUs) operate using OEM-proprietary CAN protocols, not OBD2. These CAN protocols are specific to vehicle brand, model, and year. Interpreting this data without OEM information is typically impossible (unless you reverse engineer it).
Connecting a CAN bus data logger to your OBD2 connector might capture OEM-specific CAN data, usually broadcast at 1000-2000 frames/second. However, many newer cars use a ‘gateway’ that blocks access, allowing only OBD2 communication via the OBD2 connector.
Think of OBD2 as a separate, higher-layer protocol 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 potential combinations. Modern cars commonly use 500K and 11-bit IDs, but tools should systematically verify this.
ISO 15765-4 recommends an initialization sequence to determine the correct combination. This method relies on the mandatory OBD2 response to a specific request (see OBD2 PID section) and the fact that incorrect bit-rates cause CAN error frames.
Newer ISO 15765-4 versions account for OBD communication via OBDonUDS instead of OBDonEDS. This article primarily focuses on OBD2/OBDonEDS (OBD on Emission Diagnostic Service as per ISO 15031-5/SAE J1979) versus WWH-OBD/OBDonUDS (OBD on Unified Diagnostic Service as per ISO 14229, ISO 27145-3/SAE J1979-2).
To test for OBDonEDS vs. OBDonUDS, tools can send UDS requests with 11-bit/29-bit functional address IDs for service 0x22 and data identifier (DID) 0xF810 (protocol identification). OBDonUDS-compliant vehicles must respond to this DID.
In practice, OBDonEDS (aka OBD2, SAE OBD, EOBD, or 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 is now dominant for OBD2 (ISO 15765), older cars (pre-2008) used four other lower-layer protocols. Pinouts can help identify the protocol used in older vehicles.
- ISO 15765 (CAN bus): Mandatory in US cars since 2008; widely used today.
- 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 used in older GM cars.
- SAE J1850 (PWM): Primarily used in older Ford cars.
ISO-TP for OBD2 Messages [ISO 15765-2]
OBD2 data is transmitted via the ISO-TP transport protocol (ISO 15765-2) over CAN bus, enabling payloads larger than 8 bytes. This is crucial for OBD2 functions like retrieving the Vehicle Identification Number (VIN) or Diagnostic Trouble Codes (DTCs). ISO 15765-2 handles segmentation, flow control, and reassembly. See our UDS introduction for details.
Often, OBD2 data fits within a single CAN frame. ISO 15765-2 specifies ‘Single Frame’ (SF) usage, where the 1st data byte (PCI field) indicates payload length (excluding padding), leaving 7 bytes for OBD2 communication.
The OBD2 Diagnostic Message [SAE J1979, ISO 15031-5]
To understand OBD2 on CAN, consider a ‘Single Frame’ OBD2 CAN message. In simple terms, it includes an identifier, data length (PCI field), and data. The data is structured into Mode, Parameter ID (PID), and data bytes.
Example: OBD2 Request/Response
Consider this request/response example for ‘Vehicle Speed’.
An external tool sends a request to the car (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 (50 decimal).
Using OBD2 PID 0x0D decoding rules, we find the physical value is 50 km/h.
Next, we’ll explore OBD2 modes and PIDs.
The 10 OBD2 Services (Modes)
OBD2 defines 10 diagnostic services (or modes). Mode 0x01 provides real-time data, while others are for displaying/clearing diagnostic trouble codes (DTCs) or showing freeze frame data.
Vehicles don’t have to support all OBD2 modes and may include OEM-specific modes beyond the 10 standard ones.
In OBD2 messages, the mode is in the 2nd byte. In requests, the mode is direct (e.g., 0x01), while responses add 0x40 to the mode (e.g., resulting in 0x41).
OBD2 Parameter IDs (PIDs)
Each OBD2 mode contains Parameter IDs (PIDs).
Mode 0x01, for example, includes ~200 standardized PIDs for real-time data like speed, RPM, and fuel level. However, vehicles don’t need to support all PIDs within a mode. Most vehicles support only a subset.
One PID is particularly important:
If an emissions-related ECU supports any OBD2 services, it must support mode 0x01 PID 0x00. Responding to PID 0x00, the ECU indicates support for PIDs 0x01-0x20. This makes PID 0x00 a fundamental ‘OBD2 compatibility test’. Similarly, PIDs 0x20, 0x40, …, 0xC0 can determine support for other mode 0x01 PIDs.
Tip: OBD2 PID Overview Tool
SAE J1979 and ISO 15031-5 appendices detail scaling information for standard OBD2 PIDs, enabling data decoding into physical values (as explained in our CAN bus intro).
For mode 0x01 PID lookups, use our OBD2 PID overview tool. It helps construct OBD2 request frames and dynamically decode responses.
OBD2 PID overview tool
Logging and Decoding OBD2 Data: A Practical Guide
This section demonstrates how to log OBD2 data using the CANedge CAN bus data logger.
The CANedge allows configuration of custom CAN frame transmissions, making it suitable for OBD2 logging.
Connect the CANedge to your vehicle using our OBD2-DB9 adapter cable.
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: Test Bit-rate, IDs & Supported PIDs
As discussed, ISO 15765-4 outlines how to determine the bit-rate and IDs used by a vehicle. Test this with CANedge as follows (see CANedge Intro for details):
- Send 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 review responses.
- Response IDs will indicate 11-bit or 29-bit IDs.
- Response data will show supported PIDs.
We offer plug-and-play configurations for these tests.
Most 2008+ non-EV cars support 40-80 PIDs via 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 when using the 0x7DF request ID, which polls all ECUs. Since all OBD2/OBDonEDS-compliant ECUs must support service 0x01 PID 0x00, there are often 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, so reducing busload can be achieved by directing subsequent requests to this ECU using ‘Physical Addressing’ CAN ID 0x7E0.
#2: Configure OBD2 PID Requests
Now that you know your vehicle’s supported OBD2 PIDs, bit-rate, and CAN IDs, configure your transmit list with desired PIDs.
Consider these points:
- CAN IDs: Switch to ‘Physical Addressing’ request IDs (e.g., 0x7E0) to avoid multiple responses per request.
- Spacing: Add 300-500 ms intervals between OBD2 requests to prevent ECU overload.
- Battery Drain: Use triggers to stop transmissions when the vehicle is inactive.
- Filters: Filter to record only OBD2 responses if OEM-specific CAN data is also present.
With configuration complete, the device is ready to log raw OBD2 data!
An example list of CANedge OBD2 PID requests
asammdf lets you DBC decode and visualize OBD2 data
#3: DBC Decode Raw OBD2 Data
To analyze and visualize logged data, decode raw OBD2 data into ‘physical values’ (e.g., km/h, °C).
Decoding information is in ISO 15031-5/SAE J1979 (and Wikipedia). We provide a free OBD2 DBC file for easy DBC decoding in CAN bus software.
Decoding OBD2 data is more complex than standard CAN signals because different OBD2 PIDs use the same CAN ID (e.g., 0x7E8). The CAN ID alone isn’t enough to identify signals in the payload.
This requires using the CAN ID, OBD2 mode, and OBD2 PID for signal identification, a form of multiplexing called ‘extended multiplexing‘, implementable in DBC files.
CANedge: OBD2 Data Logger
The CANedge simplifies OBD2 data recording to an 8-32 GB SD card. Connect it to a car/truck to start logging and decode data using free software/APIs and our OBD2 DBC.
OBD2 logger intro
CANedge
OBD2 Multi-Frame Examples [ISO-TP]
OBD2 communication uses ISO-TP (ISO 15765-2). While most examples are single-frame, multi-frame communication is also used.
Multi-frame OBD2 requires flow control frames (see UDS intro). Flow control can be implemented by sending a static flow control frame ~50 ms after the initial request, as shown in the CANedge configuration example.
Multi-frame OBD2 responses need CAN software/API tools supporting ISO-TP, like CANedge MF4 decoders.
Example 1: OBD2 Vehicle Identification Number (VIN)
The Vehicle Identification Number (VIN) is important for telematics and diagnostics (see UDS intro). To get the VIN using OBD2, use mode 0x09 and PID 0x02:
The tester tool sends a Single Frame request with PCI field (0x02), request service identifier (0x09), and PID (0x02).
The vehicle responds with a First Frame containing PCI, length (0x014 = 20 bytes), mode (0x49, i.e., 0x09 + 0x40), and PID (0x02). After the PID, byte 0x01 is the Number Of Data Items (NODI), here 1 (ISO 15031-5 / SAE J1979). The remaining 17 bytes are the VIN, convertible from HEX to ASCII as discussed in our UDS intro.
Example 2: OBD2 Multi-PID Request (6x)
External tools can request up to 6 mode 0x01 OBD2 PIDs in one request frame. The ECU responds with data for supported PIDs (omitting unsupported ones), possibly across multiple frames via ISO-TP.
This allows for higher frequency and efficiency data collection, but signal encoding becomes specific to the request method, complicating generic OBD2 DBC file use. We advise against this method practically. Below is an example trace:
The multi-frame response is similar to the VIN example, but the payload includes requested PIDs and their data. PIDs in the example are ordered like the request, common practice (but not strictly required by ISO 15031-5).
DBC decoding of this response is complex, so we don’t recommend this approach for practical data logging unless using tools with specific support. It involves extended multiplexing, complicated further if sending multiple multi-PID requests, making message identification difficult.
Workarounds might involve custom scripts and recording transmit messages to interpret responses, but these are hard to scale.
Example 3: OBD2 Diagnostic Trouble Codes (DTCs)
Use OBD2 mode 0x03 (‘Show stored Diagnostic Trouble Codes’) to request emissions-related DTCs. No PID is needed in the request. Responding ECUs indicate the number of stored DTCs (possibly 0), each DTC being 2 bytes. Multi-frame responses are needed for more than 2 DTCs.
The 2-byte DTC value is typically split (ISO 15031-5/ISO 15031-6). The first 2 bits define the ‘category,’ and the remaining 14 bits form a 4-digit hexadecimal code. Decoded DTCs can be looked up using OBD2 DTC lookup tools like repairpal.com.
Example below shows a request to an ECU with 6 DTCs stored.
OBD2 Data Logging – Use Case Examples
OBD2 data from cars and light trucks has various uses:
Logging data from cars
OBD2 data helps reduce fuel costs, improve driving, test prototype parts, and for insurance.
obd2 logger
Real-time car diagnostics
OBD2 interfaces stream human-readable data in real-time, aiding vehicle issue diagnosis.
obd2 streaming
Predictive maintenance
IoT OBD2 loggers monitor cars/light trucks in the cloud to predict and prevent breakdowns.
predictive maintenance
Vehicle blackbox logger
OBD2 loggers serve as ‘black boxes’ for vehicles/equipment, providing data for disputes or diagnostics.
can bus blackbox
Have an OBD2 data logging use case? Contact us for a free consultation!
Contact us
For more introductions, 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
CANEDGE2 – PRO CAN IoT LOGGER
[
