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.
This StackOverflow question and answer will guide going forward.
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:
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.