Anyone fooled around with interfacing to the OBD II port on vehicles?

[sean-h]

I went on a steep learning curve with the ODBII stuff a couple of years ago, as I wanted to get the MUT protocol going and log on my Evo 6.

The Mut protocol is different to the ODBII but the same interface can be used and I did detail stuff I found over at my old forums.

They are no longer active as I do not have time, but the material is left up online for reference purposes.
http://www.myrollingroad.com

For the ODBII the ISO 9141-2 protocol is used.

Once you got the Init sorted then the rest is easy going.

Pin7 on the ODBII connector is the K line

If you take a Pin HIGH this means you are applying 12Volts to it.
If you take the Pin LOW you are applying 0V

The first thing that you need to do is to initialise the ECU so it knows you want to communicate.

This is done with the following routine:

'Slow Init
Take K Line High
Pause 300ms

'Send 0x33 (00110011) at rate of 5 baud (LSB) with a Start Bit and a Stop bit

'Send Startbit
Set K line low (0)
Pause 200ms

'Now to send out 0x33
'Send out bit0
Set K line high (1)
pause 200ms
'Send out bit1
Set K line low (1)
pause 200ms
'Send out bit2
Set K line low (0)
pause 200ms
'Send out bit3
Set K line low (0)
pause 200ms
'Send out bit4
Set K line low (1)
pause 200ms
'Send out bit5
Set K line low (1)
pause 200ms
'Send out bit6
Set K line low (0)
pause 200ms
'Send out bit7
Set K line low (0)
pause 200ms

'Send Stopbit
Set K line high (1)
Pause 200ms

'Extra pause as per spec sheet
pause 50ms

Switch to 10400 baud
Now wait for reply of 55 08 08
Then Send out 0xF7
Wait for 0xCC to come back.
Now initialised!

As you can see the first routine I listed it is what we call Bit Bang mode as it is at a slow Baud Rate of 5.
After this we can switch the embedded controller into using it's standard Serial Port setting to achieve the 10400 Baud Rate.

Next to come , sending PID's and getting the information we need!

Right now the ECU is Initialised and talking to us, it is time to send some Packets to it, and hopefully they will reply with stuff we requested.

ISO Packet format

The data packet specification that the ISO bus uses is referenced in J1979 standard. The packet is made up of a three byte header followed by up to 7 data bytes and single byte checksum as shown below.



The three Header bytes are basically the ISO Scantool Request.

Data Byte 1
The next bytes are the data and the first byte in the stream is the mode number. There are 9 modes for diagnostic requests, so this first byte is from 1 to 9.

MODE 1:
This mode is used to obtain current diagnostic data, and is probably the most useful: Number of Trouble codes set, status of on-board tests,vehicle data such as engine RPM, temperatures, ignition advance, speed, air flow rates, whether or not the fuel system is in closed loop operation.

MODE 2:
This mode is very similar to mode one, except it pertains to freeze frame data. This is basically the same data as in mode 1, but it was captured and stored at some point in time when a malfunction occurred and a trouble code was set. Many of the PIDs for mode one are not implemented in this mode.

MODE 3:
This mode has no associated PIDs. It simply requests all diagnostic trouble codes from the vehicle. There may be more than one response message if there are more trouble codes than will fit in the data bytes of the response message, or if there are more than one ECU computer responding.

MODE4:
Mode 4 is also a very simple mode, with no PID bytes. It simply instructs the vehicle to clear all diagnostic trouble codes that may be set.

MODE 5:
This is an optional mode which requests results of oxygen sensor test results. There are a number of Test IDs (similar in function to PIDs) which may be used to obtain the results of various tests. Some vehicles do not use this mode, but report the data under mode 6.

MODE 6:
This mode is for obtaining test results for non continuously monitored systems. This data is optional, and it is defined by a given vehicle maker if its used.

MODE 7:
This mode is an optional mode. If implemented, it is similar to mode 3, which returns trouble codes, but these are codes which may be set after a single driving cycle (also known as "pending" trouble codes). They can be useful for checking the results after repair work.

MODE 8:
This mode can be used to request control of an on board system, and is manufacturer defined.

MODE 9:
This optional mode is used to report vehicle information such as the VIN number, and possibly calibration information stored in the vehicle ECU.

Check this link for the standard modes and pids: http://en.wikipedia.org/wiki/OBD-II_PIDs

Data Byte 2

This second byte is the PID you want to send.
Again look at the link above for a list of PIDS.
So for example if we wanted to know our Speed we would send the byte 0D

Data Byte 3-7

The remaining data bytes, if used, are for further specification of what data is requested, or if it is a response message, they are the actual data returned from the vehicle. The latter is the usual case.

Check Data Byte

This is a checksum byte. You basically calculate it on the value of all the other bytes.
I personaly hate writing Checksum routines when sending data, but found this bit of code, written in basic that I can convert for my Pic Chip to use.

'*******************************************
' Calculates the checksum and crc (as defined by SAE)
' for a string of numbers

CLS
DIM buf%(12)
begin:
INPUT "Number of bytes"; nbytes%
FOR i% = 1 TO nbytes%
PRINT "Enter number"; i%; " ";
INPUT buf%(i%)
NEXT i%

GOSUB ErrByte
PRINT "CRC= "; HEX$(CRC%); " hex "; CRC%; "dec"
PRINT "Checksum= "; HEX$(checksum%); " hex "; checksum%; "dec"
PRINT
GOTO begin

ErrByte:
checksum% = 0
CrcReg% = 255
FOR i% = 1 TO nbytes%
BitPoint% = 128
Byte% = buf%(i%)

FOR j% = 0 TO 7
IF BitPoint% AND Byte% THEN
IF CrcReg% AND 128 THEN Poly% = 1 ELSE Poly% = 28
CrcReg% = (((CrcReg% * 2) OR 1) XOR Poly%) AND 255
ELSE
IF (CrcReg% AND 128) THEN Poly% = 29 ELSE Poly% = 0
CrcReg% = ((CrcReg% * 2) XOR Poly%) AND 255
END IF
BitPoint% = BitPoint% \ 2
NEXT j%
checksum% = (checksum% + Byte%) AND 255
NEXT i%
CRC% = (NOT CrcReg%) AND 255
RETURN

'*******************************************

You now send your Packet to the ECU and you get a Value returned that represents that Data you wanna know about.

AND BASICALLY THAT IS IT !!!!!

Simple huh!. You just get the Init right so the ECU is communicating with you, then send a PID over to the ECU which will then reply with the values you want.
In my case I want to output the results to a LCD and looking to mainly get results from the Fault Codes that are stored in the ECU.

This would first be sending a MODE1 request of PID01 to get the amount of DTC's (Diagnostic Trouble Codes)
Then send a Mode3 request with no PID, but still the header to get the codes out.
Inside the Pic Chip it will already have a table to compare the codes against and will display it on the LCD.

This would be MODE 3



Hope this helps

Cheers

Sean.

[tekart]

Thanks a lot Sean and retepsnikrep! Lots of useful info there - probably more than I need. For now all I want to do is read MPH and display it - I hate analog gauges on vehicles!

In looking at the Scantool.net site, I think I can just get the ElmScan 5 Compact Scan Tool and use the serial port on a PIC to connect to it. Saves hacking the ELM chip.

[ardhuru]

Slightly tangential approach to the subject, but there are bluetooth OBDII dongles available on ebay for as low as 20 USD. And there is great software that runs on an android to complement these dongles.

Regards,

Anand