Integrating OBD2 (On-board diagnostics)

1. Introduction

On-board diagnostics (OBD) is an automotive term referring to a vehicle’s self-diagnostic and reporting capability. OBD systems give the vehicle owner or repair technician access to the status of the various vehicle subsystems.

OBD-II PIDs (On-board diagnostics Parameter IDs) are codes used to request data from a vehicle, used as a diagnostic tool.

2. Steps at a Glance

2.1. Initialize OBD2 device to request data from a vehicle.

2.2. Send a code to request data from the vehicle.

2.2. Handle response.

3. Implementation

Before we get into implementation, we have to understand that OBD devices can handle only one command at a time. In other words, you should send a command until the previous command execution has been completed. Successful execution of the command send is indicated by the response followed by ‘>’ character. If this not followed then you might get wrong responses like STOPPED, SEARCHING etc.

3.1. Device initialization

a) For initializing the device, send initialization codes “at”, “atsp0”, “ate1” synchronously to a device. Commands that are intended for the device internal use will begin with characters ‘AT’. All codes (including internal codes) are case insensitive. The device also ignores space characters and all control characters (tab, etc).

b) AT Z is reset command for setting internal circuit.

c) AT E0, E1 for Echo off, or on. If the echo is on, the response will have value for the code send preceded by the code you sent.

d) When an incomplete code is sent and no data return appears. In this case, an internal timer will automatically abort the incomplete message after about 20 seconds, and will print a single question mark (‘?’) to show that the input was not understood (and was not acted upon).

e) Messages that are not understood by the device will always be signalled by a single question mark.

f) Each Code response will be many bytes.

g) Each code response will have three parameters Code, Data and “>” symbol.

h) The ‘>’ character is the prompt character. It indicates that the device is in an idle state, ready to receive codes. After getting “>” character in response, then only you should send another Code.

3.2. Requesting Data

a) Send a code to device, to request data from vehicle

Example: Intake air temperature (Code: 010f)

3.3. Handling response

a) Each response starts with the code you have sent and ends with “>” symbol, in between these you will get

the Data.

b) The first four bytes of Data is static, the first two bytes will differ based on the first two bytes of Code and

next two bytes is next two bytes of Code. The actual value is four bytes in Data

Example: Code: 010f

response,

010f      

                              41 0F FF  

                              >        

                              010f – Code, 41 0F FF – Data, > – End symbol

In the above example, “41” will defer based on first two bytes of Code (010f) and 0F is Code (010f)

(refer: http://elmelectronics.com/DSheets/ELM327DS.pdf)

c) Response data will be in hexadecimal format. Take two bytes as one value, convert into decimal format to

use.

Example:

1) Intake air temperature, Code: 010f

response,

                                010f      

                                41 0F FF  

                                >

Formula: A-40

So, here A is FF

                                FF, in decimal 255

                                => 255-40 = 215.

                                Intake air temperature = 215 °C

2) Distance travelled, Code: 0131

response,

0131

                               SEARCHING…

                               41 31 37 65

                               >

Formula: (A*256)+B

So, here A is 37, B is 65

                               37, in decimal 55

                               65, in decimal 101

                               => (55*256)+101 = 14181

                               Distance travelled = 14181 km

(For units & formulae, refer: https://en.wikipedia.org/wiki/OBD-II_PIDs)

Interpreting Trouble Codes:

– For obtaining current Diagnostic Trouble Codes.

– This requires that a mode 03 request be made to request the actual trouble codes.

> 03

A response to this could be:

43 01 33 00 00 00 00

– The ’43’ in the above response simply indicates that this is a response to a mode 03 request.

– The remaining 6 bytes in the response have to be read in pairs to show the trouble codes (the above would be interpreted as 0133, 0000, and 0000).

– 0000’s do not represent actual trouble codes.

– When requesting the number of stored codes, the most significant bits of each trouble code also contain additional information. It is easiest to use the following table to interpret the extra bits in the first digit as follows:

– Taking the example trouble code (0133), the first digit (0) would then be replaced with P0, and the 0133 reported would become P0133.

– If the received code was D016, you would replace the D with U1, and the resulting trouble code would be U1016. Similarly, 1131 received would actually be for the code P1131.

4. Project Details

This project had an implementation of CarIO app on android and iOS. The communication between the OBD device and the app was through BLE (BLE communication details not included here).

Cumulations built the iOS OBD library, Android OBD library and iOS App.