Need a uncomplicated, applied intro to OBD2?

In this guide we introduce the On Board Diagnostic (OBD2) protocol incl. the OBD2 connector, OBD2 parameter IDs (PID) and the link to CAN jitney.

Note: This is a applied intro then y'all will also acquire how to request and decode OBD2 data, key logging use cases and practical tips.

See below why this has become the #1 OBD2 tutorial.

You tin can too cheque out our OBD2 intro video higher up (150K+ views on YouTube)

What is OBD2?

In brusk, OBD2 is your vehicle's built-in self-diagnostic system.

You've probably encountered OBD2 already:

Ever noticed the malfunction indicator light on your dashboard?

That is your car telling y'all there is an issue. If you visit a mechanic, he will use an OBD2 scanner to diagnose the outcome.

To do so, he will connect the OBD2 reader to the OBD2 sixteen pivot connector about the steering wheel.

This lets him read OBD2 codes aka Diagnostic Trouble Codes (DTCs) to review and troubleshoot the consequence.

What is OBD2 On Board Diagnostics Malfunction Indicator Light MIL

OBD Connector Pinout Socket Female Type A DLC

The OBD2 connector

The OBD2 connector lets you access information from your car easily. The standard SAE J1962 specifies 2 female OBD2 sixteen-pivot connector types (A & B).

In the illustration is an example of a Type A OBD2 pivot connector (also sometimes referred to as the Information Link Connector, DLC).

A few things to note:

  • The OBD2 connector is near your steering wheel, but may be hidden behind covers/panels
  • Pivot 16 supplies bombardment ability (ofttimes while the ignition is off)
  • The OBD2 pinout depends on the advice protocol
  • The most common protocol is Tin can (via ISO 15765), significant that pins 6 (Tin-H) and 14 (Tin can-L) will typically be connected

OBD2 connector - type A vs. B

In practice, yous may encounter both the type A and type B OBD2 connector. Typically, blazon A will be institute in cars, while type B is mutual in medium and heavy duty vehicles.

As evident from the analogy, the two types share similar OBD2 pinouts, but provide 2 different power supply outputs (12V for type A and 24V for type B). Ofttimes the baud rate will differ as well, with cars typically using 500K, while most heavy duty vehicles utilise 250K (more recently with support for 500K).

To help physically distinguish betwixt the 2 types of OBD2 sockets, note that the type B OBD2 connector has an interrupted groove in the middle. Equally a result, a type B OBD2 adapter cablevision volition be compatible with both types A and B, while a type A will non fit into a type B socket.

OBD2 Connector Type A vs B SAE J1962 Car Van Truck

Does my car have OBD2?

In short: Probably!

Almost all newer cars back up OBD2 and most run on Tin (ISO 15765). For older cars, be aware that even if a 16 pin OBD2 connector is present, it may yet non support OBD2. One style to determine compliance is to identify where & when it was bought new:

Does My Car Have OBD2?

Link between OBD2 and Tin can bus

On board diagnostics, OBD2, is a 'higher layer protocol' (similar a linguistic communication). CAN is a method for advice (similar a phone).

In particular, the OBD2 standard specifies the OBD2 connector, incl. a ready of five protocols that it can run on (see below). Further, since 2008, Tin can coach (ISO 15765) has been the mandatory protocol for OBD2 in all cars sold in the US.

OBD2 vs CAN bus ISO15765

OBD2 vs CAN Bus ISO 11765 ISO 11898 OSI Layer

What is the ISO 15765 standard?

ISO 15765 refers to a set up of restrictions applied to the CAN standard (which is itself defined in ISO 11898). Ane might say that ISO 15765 is like "CAN for cars".

In item, ISO 15765-4 describes the physical, data link layer and network layers, seeking to standardize the CAN omnibus interface for external test equipment. ISO 15765-2 in turn describes the transport layer (ISO TP) for sending Tin frames with payloads that exceed 8 bytes. This sub standard is besides sometimes referred to as Diagnostic Advice over CAN (or DoCAN). Run across too the 7 layer OSI model analogy.

OBD2 can also be compared to other college layer protocols (e.g. J1939, CANopen).

The five OBD2 protocols

As explained above, Tin autobus today serves as the basis for OBD2 advice in the vast bulk of cars through ISO 15765.

All the same, if you're inspecting an older car (pre 2008), it is useful to know the other four protocols that have been used as footing for OBD2. Note also the pinouts, which can be used to decide which protocol may be used in your car.

  • ISO 15765 (Tin can bus): Mandatory in US cars since 2008 and is today used in the vast majority of cars
  • ISO14230-four (KWP2000): The Keyword Protocol 2000 was a common protocol for 2003+ cars in e.g. Asia
  • ISO9141-2: Used in EU, Chrysler & Asian cars in 2000-04
  • SAE J1850 (VPW): Used mostly in older GM cars
  • SAE J1850 (PWM): Used mostly in older Ford cars

OBD2 Standards KWP2000 SAE J1850 ISO9141 ISO 15765


Below we list some of the nearly relevant SAE/ISO standards related to OBD2:

SAE J1962: This standard defindes the physical connector used for the OBD2 interfacing, i.e. the OBD2 connector. The standard describes both the vehicle OBD2 connector and the connector used by the external exam equipment (e.g. an OBD2 scanner or OBD2 data logger). In particular, the standard dictates the location and admission to the OBD2 connector.

SAE J1979: The SAE J1979 standard describes the methods for requesting diagnostic information via the OBD2 protocol. Information technology too includes a list of standardized public OBD2 parameter IDs (OBD2 PIDs) that automotive OEMs may implement in cars (though they are not required to do so). Vehicle OEMs may also decide to implement boosted proprietary OBD2 PIDs beyond those outlined by the SAE J1979 standard.

SAE J1939: The J1939 standard describes the data protocol used for heavy-duty vehicle communication. While OBD2 PID information is just bachelor on-request past OBD2 test equipment, the J1939 protocol is used in most heavy-duty vehicles equally the basic means for communicating CAN traffic - meaning data is broadcast continuously.

ISO 11898: This standard describes the Tin can motorbus data link layer and concrete layer, serving as the basis for OBD2 communication in nearly cars today

ISO 15765-ii: The ISO-TP standard describes the 'Transport Layer', i.e. how to send data packets exceeding eight bytes via Tin bus. This standard is important every bit it forms the ground for Unified Diagnostic Services (UDS) communication, which relies on sending multiframe CAN data packets.

ISO 14229: This describes UDS communication in detail


OBD2 history

OBD2 originates from California where the California Air Resources Board (CARB) required OBD in all new cars from 1991+ for emission control purposes.

The OBD2 standard was recommended by the Society of Automotive Engineers (SAE) and standardized DTCs and the OBD connector across manufacturers (SAE J1962).

From there, the OBD2 standard was rolled out pace-by-step:

  • 1996: OBD2 made mandatory in U.s. for cars/lite trucks
  • 2001: Required in Eu for gasoline cars
  • 2003: Required in European union besides for diesel fuel cars (EOBD)
  • 2005: OBD2 was required in The states for medium duty vehicles
  • 2008: US cars must utilize ISO 15765-4 (Can) as OBD2 basis
  • 2010: Finally, OBD2 was required in Usa heavy duty vehicles

OBD2 History Emission Control Exhaust EOBD2 EOBDII

OBD2 History Timeline Overview

OBD2 Future OBD3 remote diagnostics emissions testing cloud IoT

OBD2 futurity

OBD2 is here to stay - just in what form?

Two potential routes may radically change OBD2:


In today'due south world of connected cars, OBD2 tests can seem cumbersome: Manually doing emission command checks is fourth dimension-consuming and expensive.

The solution? OBD3 - adding telematics to all cars.

Basically, OBD3 adds a small radio transponder (as in e.g. bridge tolls) to all cars. Using this, the car vehicle identification number (VIN) and DTCs can be sent via WiFi to a key server for checks.

Many devices today already facilitate transfer of CAN or OBD2 data via WiFi/cellular - e.g. the CANedge2 WiFi CAN logger.

This saves toll and is user-friendly, but it is also politically a challenge due to surveillance concerns.

The OBD2 protocol was originally designed for stationary emission controls.

Even so, today OBD2 is used extensively for generating existent-fourth dimension data by 3rd parties - via OBD2 dongles, CAN loggers etc. However, the German automobile manufacture is looking to change this:

OBD has been designed to service cars in repair shops. In no way has it been intended to allow 3rd parties to build a grade of data-driven economy on the admission through this interface"

- Christoph Grote, SVP Electronics, BMW (2017)

The proposal is to "turn off" the OBD2 functionality while driving - and instead collect the data in a cardinal server. This would effectively put the manufacturers in control of the automotive 'big data'.

The argumentation is based in security (e.g. removing the risk of car hacking), though many see it as a commercial move. Whether this becomes a existent tendency is to exist seen - merely it may truly disrupt the market for OBD2 3rd party services.

OBD2 Future Electric Vehicles Block Access to data


OBD2 parameter IDs (PID)

Why should you lot intendance about OBD2 data?

Mechanics obviously intendance near OBD2 DTCs (perchance you practise besides), while regulatory entities demand OBD2 to control emission.

But the OBD2 protocol as well supports a broad range of standard parameter IDs (PIDs) that can exist logged beyond most cars.

This means that you tin easily become human-readable OBD2 data from your car on speed, RPM, throttle position and more.

In other words, OBD2 lets you analyze data from yous car easily - in contrast to the OEM specific proprietary raw Can data.

In principle it is simple to log the raw Can frames from your car. If you e.g. connect a CAN logger to the OBD2 connector, you'll offset logging broadcasted CAN bus data out-the-box. However, the raw CAN letters need to be decoded via a database of conversion rules (DBC) and a suitable Tin software that supports DBC decoding (like due east.k. asammdf). The claiming is that these CAN DBC files are typically proprietary, making the raw Tin can data unreadable unless you're the automotive OEM.

Motorcar hackers may try to reverse engineer the rules, though this can be hard. Tin is, withal, still the merely method to get "full access" to your car data - while OBD2 just provides access to a limited subset of data.


OBD2 protocol request respond frames

OBD2 PID data logger request 7df 7e8

How to log OBD2 data?

OBD2 data logging works as follows:

  • You connect an OBD2 logger to the OBD2 connector
  • Using the tool, y'all send 'request frames' via Tin
  • The relevant ECUs send 'response frames' via CAN
  • Decode the raw OBD2 responses via e.g. an OBD2 DBC

In other words, a Can logger that is able to transmit custom Can frames can also be used equally an OBD2 logger.

Note that cars differ by model/year in what OBD2 PIDs they support. For details, see our OBD2 data logger guide.

CANedge OBD2 data logger

The CANedge lets you easily log OBD2 information to an 8-32 GB SD card. Only specify what OBD2 PIDs you wish to request, then connect it to your auto via an OBD2 adapter to start logging. Process the data via costless software/APIs and our OBD2 DBC.

larn more

Raw OBD2 frame details

To get started recording OBD2 information, information technology is helpful to sympathize the basics of the raw OBD2 message structure. In simplified terms, an OBD2 message is comprised of an identifier and information. Further, the data is divide in Way, PID and data bytes (A, B, C, D) every bit below.

OBD2 PIDs OBD-ii Message Structure Breakdown Explained

Identifier: For OBD2 messages, the identifier is standard 11-fleck and used to distinguish betwixt "request messages" (ID 7DF) and "response messages" (ID 7E8 to 7EF). Note that 7E8 volition typically exist where the main engine or ECU responds at.

Length: This simply reflects the length in number of bytes of the remaining data (03 to 06). For the Vehicle Speed example, it is 02 for the asking (since only 01 and 0D follow), while for the response it is 03 as both 41, 0D and 32 follow.

Mode: For requests, this will exist between 01-0A. For responses the 0 is replaced by four (i.e. 41, 42, … , 4A). There are 10 modes every bit described in the SAE J1979 OBD2 standard. Mode one shows Current Data and is e.m. used for looking at real-fourth dimension vehicle speed, RPM etc. Other modes are used to e.one thousand. bear witness or clear stored diagnostic trouble codes and show freeze frame information.

PID: For each mode, a list of standard OBD2 PIDs be - east.g. in Mode 01, PID 0D is Vehicle Speed. For the full list, bank check out our OBD2 PID overview. Each PID has a description and some have a specified min/max and conversion formula.

The formula for speed is east.one thousand. simply A, significant that the A data byte (which is in HEX) is converted to decimal to get the km/h converted value (i.eastward. 32 becomes l km/h in a higher place). For e.g. RPM (PID 0C), the formula is (256*A + B) / 4.

A, B, C, D: These are the information bytes in HEX, which demand to exist converted to decimal form earlier they are used in the PID formula calculations. Note that the final information byte (subsequently Dh) is non used.

OBD2 request/response example

An instance of a asking/response CAN message for the PID 'Vehicle Speed' with a value of 50 km/h can exist seen in the illustration.

Note in detail how the formula for the OBD2 PID 0D (Vehicle Speed) simply involves taking the 4th byte (0x32) and converting it to decimal form (50).


In some vehicles (eastward.thousand. vans and light/medium/heavy duty vehicles), you may find that the raw Tin can data uses extended 29-chip CAN identifiers instead of xi-flake Tin can identifiers.

In this case, yous will typically need to modify the OBD2 PID requests to use the CAN ID 18DB33F1 instead of 7DF. The data payload construction is kept identical to the examples for 11-bit Can IDs.

If the vehicle responds to the requests, you'll typically see responses with CAN IDs 18DAF100 to 18DAF1FF (in practice, typically 18DAF110 and 18DAF11E). The response identifier is likewise sometimes shown in the 'J1939 PGN' form, specifically the PGN 0xDA00 (55808), which in the J1939-71 standard is marked equally 'Reserved for ISO 15765-2'.

Nosotros provide an OBD2 DBC file for both the 11-bit and 29-flake responses, enabling simple decoding of the data in virtually Tin can software tools.

OBD2 request 7DF response 7e8 OBD2 PID example Vehicle Speed 0D

OBD2 services modes current data freeze frame clear dtc

The 10 OBD2 services (aka modes)

In that location are 10 OBD2 diagnostic services (or modes) equally described in the SAE J1979 OBD2 standard. Mode i shows Electric current Data and is used for looking at real-time parameters like vehicle speed, RPM, throttle position etc. Other modes are e.g. used to show/clear diagnostic problem codes (DTCs) and testify freeze frame data.

Manufacturers exercise not take to support all diagnostic services - and they may support modes outside these ten services (i.due east. manufacturer specific OBD2 services).



OBD2 data logging - utilise case examples

OBD2 information from cars and light trucks can exist used in diverse employ cases:

OBD2 data logger on board diagnostics

Logging data from cars

OBD2 data from cars can e.g. be used to reduce fuel costs, meliorate driving, exam image parts and insurance

Larn more

OBD2 real-time streaming diagnostics

Real-fourth dimension car diagnostics

OBD2 interfaces tin can exist used to stream human-readable OBD2 information in existent-time, due east.1000. for diagnosing vehicle bug

Learn more

OBD2 data logger preventive maintenance

Predictive maintenance

Cars and light trucks tin can be monitored via IoT OBD2 loggers in the cloud to predict and avoid breakdowns

Learn more

Black box CAN logger insurance warranty

Vehicle blackbox logger

An OBD2 logger can serve every bit a 'blackbox' for vehicles or equipment, providing data for e.1000. disputes or diagnostics

Larn more than

Exercise you have an OBD2 data logging use instance? Achieve out for free sparring!

Contact usa


Below we outline the most common OBD2 analyzer categories:

OBD2 scanners: Used equally car diagnostic tools in static reading/clearing of DTCs by e.g. mechanics. An OBD2 scan tool is typically used in diagnosing vehicle issues e.g. indicated by an activated MIL. Various types exist and some private persons utilise low cost variants as simple motorcar code readers for cocky-diagnosing their car health.

Bluetooth OBD2 dongles: Many OBD2 bluetooth dongles be, which let you view car data directly on your smartphone via an app. Typically OBDII bluetooth dongles are depression cost and piece of cake-to-use, though also limited in terms of their usability outside the bluetooth-to-app visualization purpose. The purpose of an OBD2 bluetooth dongle is typically to monitor personal driving beliefs and vehicle health.

OBD2 interfaces: Provide real-fourth dimension OBD2 data to a PC via USB streaming. OBD2 interfaces are typically used in advanced car diagnostics and OEM vehicle development. Further, Can interfaces that back up OBD2 requests can be useful every bit role of reverse engineering proprietary CAN jitney parameters.

OBD2 loggers: Used to log OBD2 data from a car to an SD card - ideal for e.k. blackbox apply cases or prototype field tests by automotive OEMs. Every bit an example, the CANedge1 lets you log Tin bus information, too as request OBD2 data by sending custom frame requests to the Tin jitney.

WiFi OBD2 logger: WiFi OBD2 loggers and WiFi OBD2 dongles enable the automatic transfer of OBD2 data via WiFi (incl. 3G/4G) to a server/cloud. WiFi OBD2 loggers are typically used for OBD2 telematics use cases, where motorcar fleet data needs to exist nerveless automatically and visualized via OBD2 data dashboards. For example, the CANedge2 lets you log Tin/OBD2 data and motorcar-button it via a WiFi accces point to your own server. The information tin be processed in free software tools and e.g. visualized in Grafana dashboards.

CANedge2 Telematics OBD2 Logger

The CANedge2 makes it easy to log OBD2 data to an SD card - and upload it via WiFi to your own server.

Need to log/stream OBD2 data?

Get your OBD2 data logger today!


Recommended for you