Take the 2-minute tour ×
Motor Vehicle Maintenance & Repair Stack Exchange is a question and answer site for mechanics and DIY enthusiast owners of cars, trucks, and motorcycles. It's 100% free, no registration required.

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.

share|improve this question
1  
I guess you know that you can buy an instrument that does exactly this at the auto parts store. –  user28910 Dec 27 '13 at 19:12
    
yeah the instruments are available but i am designing one. so i need help in that –  user3098378 Dec 27 '13 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 '13 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. –  user3098378 Dec 28 '13 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 '13 at 18:08
show 4 more comments

migrated from electronics.stackexchange.com Dec 28 '13 at 5:41

This question came from our site for electronics and electrical engineering professionals, students, and enthusiasts.

2 Answers

up vote 2 down vote accepted

This StackOverflow question and answer will guide going forward.

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

share|improve this answer
add comment

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:

ATZ
ATSP0

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:

03

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.

share|improve this answer
    
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? –  user3098378 Jan 1 at 14:19
    
@user3098378 Yes, it should have been 01010001 binary, fixed. The mode 1 response is hexadecimal encoded. Note that the DTCs in the mode 3 response are Binary Coded Decimal. The WikiPedia article has more details. –  Mark Johnson Jan 2 at 6:54
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.