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

I'm thinking about building a device that would need to access vehicle data from the OBDII data port (required in all vehicles in the US since 1996). Has anyone successfully interfaced with the port? Want to share what you learned? It would seem that you first need to determine what type of interface is present; serial, CAN, PWM...

I have done a bit. It is CAN bus on newer cars.

If you have a BMW, you are really in good shape.

http://autos.groups.yahoo.com/group/HackTheIBus/

What prompted my interest in this is the Scan Gauge II that I use. It is impressive in that it will work with ANY vehicle - so presumably the code can detect which of several possible interfaces are in use for the vehicle. Pretty darned clever device: http://www.scangauge.com
I'd like to explore some applications for vehicles that the SG goes not cover... So solving only for the CAN bus on a BMW would only solve part of the problem.

However I'm open to ideas...

I just poked around the forum looking for CAN bus info and found the ELM327 chip that would seem to solve the whole interface dilemma. It does OBD to serial and the data sheet explains the whole OBD protocol quite nicely. Neat chip!
http://elmelectronics.com/DSheets/ELM327DS.pdf

Yes, the chip does all the translation. Where the forums help is how to do unusual things, like - how to make your car windows go up and sunroof automatically close when you lock your car.

I bought a couple of the ELM chips intending to do something clever with them but i haven't yet LOL. I'm interested in ODBII on honda vehicles from 1999-2005 which is basic stuff. I also have a scangauge and looked at putting the elm inbetween it and the car and capturing the signals to work out how it did what it does. There are some good ODBII sites on interwebulator.

My particular interest is IMA ODBII codes for the early Honda Hybrids in particular the Mk1 Insight. These codes don't show on the scangauge and need the proprietory £3000 honda scan tools to acess them. I need to borrow one, capture the signals with the elm chip then make something clever with a pic and the elm.

http://www.thinkythings.org/obdii/
http://www.pureenergysystems.com/sto...TestStatus.htm
http://www.obd2crazy.com/tech.html#eint

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.

http://www.myrollingroad.com/isopacket.jpg

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.

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.

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