I want to know how can I access DTCs by writing a code and parsing it? I have RaspberryPi and related hardware for communication with the OBD-II of car. I will generate manual faults and then after MIL is on, I want to view the generated DTCs in readable format.

  • 1
    I guess you know that you can buy an instrument that does exactly this at the auto parts store.
    – user28910
    Dec 27, 2013 at 19:12
  • yeah the instruments are available but i am designing one. so i need help in that
    – user3098378
    Dec 27, 2013 at 19:49
  • Looking at the OBD-II spec may be a good place to start if you want to design it from scratch.
    – Dan Nixon
    Dec 27, 2013 at 21:23
  • I've designed it for accessing basic OBD-II features like RPM, SPEED< throttle. But now i want to design it for DIAGNOSTIC TROUBLE CODES purpose. Dec 28, 2013 at 12:58
  • 1
    So do you already have it connected, but need to know the diagnostic codes? These are available as a table online.
    – Rory Alsop
    Dec 28, 2013 at 18:08

2 Answers 2


This StackOverflow question and answer will guide going forward.

Is there a ELM327 / obdkey OBD2 adapter objective-c programming guide?


The 'Interpreting Trouble Codes' section (page 26) of the ELM327 Data Sheet has an example of how to fetch DTCs. You first make a mode 01 PID 01 request to determine the number of DTCs (which you'll need to decode the response in the next request). Then you make a mode 03 (no PID) request to get the actual codes. I'll try to paraphrase the example for posterity:

This should reset the interface and set the protocol search to automatic:


This should issue a mode 01 PID 01 request:

01 01

A typical response might be (in hexadecimal):

41 01 81 07 65 04

The two bytes '41 01' indicate a response to a mode 1 pid 01 request. The byte '81' (10000001 binary) is the MIL status and the number of trouble codes. The first bit is the MIL on/off bit(1 or ON in this case), the next 7 bits (0000001) are the number of trouble codes. The meaning of the remaining three bytes is buried in the SAE J1979 spec.

This should issue a mode 03 (no PID) request:


A typical response might be

43 01 33 00 00 00 00

The byte 43 indicates a response to a mode 3 request. The next three pairs of bytes are trouble codes. In this example, I think there is only one present (rest are zeroes). If there are more than 3 to report, I don't know whether the response just grows longer or is split into multiple lines. Hmmm, Wikipedia suggests multiple 'frames', not sure exactly how the elm chip would translate that. In any case, '01 33' decodes as DTC P0133. For further details, see the data sheet and the SAE J1979 spec (The spec costs money, you could reverse engineer other open source projects that support ELM327 chips if you don't want to or can't get your hands on the spec). It looks like somebody has added tons of useful info in the relevant Wikipedia articles, too.

It looks like the ELM327 supports the higher data rates that the older ELM chips didn't. That comes in handy for troubleshooting and tuning. You can get data for more sensors simultaneously or you can max out on data from one sensor to spot characteristics that might not be visible at lower data rates. I think you might need a special OBDII to RS232 cable to use those higher data rates, though.

  • here after sending request 0101 and receiving the data, you wrote that 81(10001000 binary) is the MIL status. I want to know that how you wrote it? it should be 01010001 in binary, if by-mistake. also the remaining 7 bits which indicates the count are received in binary form or decimal? Jan 1, 2014 at 14:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .