OBD2 PID Overview [Lookup/Converter Tool, Table, CSV, DBC]

This OBD2 PID lookup tool lets you quickly find details for a specific OBD2 PID. The tool will display the available information, as well as how to construct the OBD2 request CAN frame. In addition, the tool provides an example of how the corresponding OBD2 response frame could look - and how the data is decoded to physical values.

OBD2 (On Board Diagnostics) is your vehicles built-in self-diagnostic system - see also our intro to OBD2. It provides a standardized connector and method for interfacing with cars, vans, trucks and other automotive vehicles. For example, it allows your mechanic to use an OBD2 scan tool to diagnose issues in your car when the Malfunction Indicator Light (MIL) indicates a problem.

An important part of OBD2 is the standard SAE J1979, which specifies a range of standard (and public) OBD2 PIDs (Parameter IDs). Basically, tools like OBD2 scanners, OBD2 interfaces, OBD2 data loggers etc. can attempt to send "OBD2 requests" into a vehicle. This is done by connecting the hardware to the vehicle's OBD2 connector (located below the steering wheel) and sending specific CAN bus frames into the vehicle's CAN bus system.

For example, you could request data for the OBD2 PID '0D' (Vehicle Speed) by sending a CAN frame with ID 7DF and the data payload 02 01 0D 55 55 55 55 55. If the vehicle supports this OBD2 parameter, you'll see an "OBD2 response" on the CAN bus with CAN ID 7E8 and a data payload of 03 41 0D XX AA AA AA AA, where 'XX' would reflect the hexadecimal value of the current vehicle speed in km/h.

In this overview, we list all the most commonly used OBD2 parameter IDs in various practical formats.

If you have an OBD2 data logging use case, feel free to contact us for sparring!

We created this OBD2 PID table overview as we found other similar tables to be less intuitive (e.g. the OBD-II PID table on Wikipedia). In particular, the table uses a syntax similar to what is used in CAN databases (DBC files). This means that we provide the bit start, bit length, offset and scale factors required for extracting the relevant data bytes from the OBD2 PID response frame.

Specifically, OBD2 uses big endian byte ordering, which means that the extracted byte(s) can be directly translated from hexadecimal to decimal form, referred to as the 'raw_value_decimal' below. The physical value can then be expressed as a linear equation as explained in our DBC intro.

For example, assume we have an OBD2 response data payload for the OBD2 PID 0C (Engine Speed) as follows:

04 41 0C 0A 0C AA AA AA

In this case, the actual signal starts from bit 31 with a length of 16, i.e. the blue bytes above. If we translate the hex string 0A0C to decimal, we get the value 2572. To convert this to Engine Speed we perform the below calculation:

physical_value = offset + scale * raw_value_decimal

       643 rpm = 0 + 0.25 * 2572

This approach can be used across all of the OBD2 PIDs that have a physical unit assigned to them. In contrast, some OBD2 PIDs are 'encoded' and require a PID specific handling - see the Wikipedia OBD2 PID overview for details. Note that the table shows OBD2 PIDs for service 01 (current data), which is the most relevant service for OBD2 data acquisition use cases.