Harrison R&D

1/12/2003

OBDScan Protocol Converter Interface

Preliminary The OBDScan Protocol Converter interfaces to the vehicle OBD-II bus on one side utilizes an RS-232 interface to communicate with a host computer on the other. The host can be a Windows computer, a Palm compatible handheld or anything with a RS232 interface. The RS-232 interface is fixed at 19200 baud, no parity, 8 data bits and 1 stop bit. It uses the Transmit, Receive and Ground only, no hardware handshaking is required or allowed. The OBDScan is an OBD-II interface and as such is a specialized interface for ISO-9141, J1850 PWM and VPW, and KWP2000. The OBD-II specification SAE-J1979 defines several modes of operation modes of operation for the retrieval of data. All of the implemented J1979 Modes work the same on all OBD-II interface types. The protocol converter automatically tests for all interface types and begins communication with which ever is present, relieving the user from needing to know the interface type up front. Initialization On power up, the protocol converter begins testing for the four interface types and outputs a string of PIPIPIPIP which indicate that initialization is being attempted. The sequence starts with a P transmitted at the beginning of a search pass, the I is transmitted when the ISO interface test times out, the VPW and PWM interfaces are tested then the KWP2000 is tested. If no interface is found the the cycle starts all over. When an interface responds to the initialization request the protocol converter starts sending a string of SSSSSSSSSSSSSSSSSS, with each S being transmitted approximately every 40ms. Once the string of SSSSSSs occurs, the user can begin communicating with the protocol converter. Protocol Converter Communication The S characters are used to synchronize the computer with the protocol converter. This is really only necessary for the ISO-9141 and KWP2000 protocol because the protocol converter must periodically issue a keep alive command or the ECU will stop communicating and the protocol converter would have to reinitialize the interface, which can take over one second. In order to keep the computer from issuing an OBD-II data request at the same time the protocol converter is issuing a keep alive command, the S character guarantees a 25ms window. The user needs to insure that each communication from the computer to the protocol converter will occur within 25ms of receipt of the S character. The protocol converter expects to receive 6 ASCII characters, which represent 3 bytes in hexadecimal format. As an example, the byte value 3E would be transmitted as an ASCII 3 and an ASCII E. Below you will find the definition and format of the 6 character strings sent to the protocol converter. Once a valid 6-character string is transmitted, the protocol converter will return a V character followed by the ECU response. The ECU response will be formatted as all ASCII characters and will look similar to 486A1001AABBCCDD, where AA is byte 1, BB is byte 2, CC is byte 3 and DD is byte four. A four-byte response is the longest allowed, if the response were only one data byte, as in the case of Throttle Position, then the AA would be the only data byte. Dont

www.ghg.net/dharrison

1 of 12

Harrison R&D

1/12/2003

forget that when parsing the response string, the string starts with the V character and the response message follows. Vehicle Communication The OBDScan protocol converter is designed to communicate with the vehicle using the protocl as described in SAE-J1979. This document described several Modes of operation to read data, read trouble codes and clear trouble codes. The OBDSCan protocol converter will communicate to the vehicle using Mode 1,2,3 and 4. This communication is described below. Mode 1 Mode 1 - Read OBD-II data, format MODE-PP-BC PP=Parameter Identification (PID), BC=byte count to be received by protocol converter. Remember that the received byte count is actually double the value because each byte is transmitted as two ASCII characters. PID 00 - return supported PIDs - send string 010009 You would read 19 bytes, the V and the 18 ASCII characters which represent the 9 bytes response message. PID 00 returns four data bytes, 32 bits, where each bit represents a PID starting with PID 01, a 1 indicates a supported PID and a 0 represents a non-supported PID. Bytes 12-13 represent hex byte 1, 14-15 represent hex byte 2, 16-17 represent hex byte 3 and 18-19 represent hex byte 4. PID 01 - returns MIL status, send 010109 This PID returns two bytes of ODB test status receive 19 ASCII bytes

Byte 1 MIL Status

-------x

Byte 2 Misfire support -------x Fuel support ------xComponent support -----x-Reserved ----0--Misfire status ---x---Fuel status --x----Component status -x-----Reserved status 0------Byte 3 and 4 Catalyst monitoring support -------x Heated Cat. Monitor Supp. ------xEvap. System Monitor Supp. -----x-Sec. Air System Monitor Supp. ----x--A/C Refrig. Monitoring Supp. ---x----

www.ghg.net/dharrison

2 of 12

Harrison R&D

1/12/2003

O2 sensor monitor support --x----O2 sensor heater monitor support -x-----EGR System monitor support x------Byte 3 is used to determine which test is supported and the corresponding bit of byte 4 is used to determine if the supported test is complete ( bit=0) or not (bit=1) See code example at end of document for more details. PID 02 - Get trouble codes used by Mode2 only PID 03 - Get Fuel System status, send 010307 receive 15 bytes from this command returns two bytes, each bit is defined as follows: Byte 1 -- Fuel System 1 open loop 1------closed loop -1-----open loop driving --1----open loop fault ---1---closed loop fault ----1--Byte 2 -- Fuel System 2 open loop 1------closed loop -1-----open loop driving --1----open loop fault ---1---closed loop fault ----1--Fuel System 1 will be received as bytes 12-13 and Fuel system 2 as bytes 14-15 of the received data stream. PID 04 - Get Calculated Load - send string 010406 Receive 13 bytes Returns one byte response in location 12-13 of received data Calculated load% = b/255*100 PID 05 - Get Coolant Temp.- send string 010506 Receive 13 bytes Returns one byte response in location 12-13 of received data coolant temp.C = b-40 coolant temp.F= (b-40)*1.8+32 PID 06 - Short term fuel trim bank 1 -send string 010606 Receive 13 bytes Returns one byte response in location 12-13 of received data short fuel trim bank1 = b/128*100-100 % PID 07 - Long term fuel trim bank 1 -send string 010706 Receive 13 bytes

www.ghg.net/dharrison

3 of 12

Harrison R&D Returns one byte response in location 12-13 of received data long fuel trim bank1 = b/128*100-100 % PID 08 - Short term fuel trim bank 2 send string 010806 Receive 13 bytes Returns one byte response in location 12-13 of received data short fuel trim bank2 = b/128*100-100 % PID 09 - Long term fuel trim bank 2 -send string 010906 Receive 13 bytes Returns one byte response in location 12-13 of received data long fuel trim bank2 = b/128*100-100 % PID 0A - Get Fuel Pressure -send string 010A06 Receive 13 bytes Returns one byte response in location 12-13 of received data fuel pressure.Kpa = b fuel pres. psi = b*3*0.14504 PID 0B - Get Manifold Air Pressure -send string 010B06 Receive 13 bytes Returns one byte response in location 12-13 of received data Manifold Pressure KPa = b Manifold Pressure PSI = b*.29613 PID 0C - Get RPM - send string 010C07 Receive 15 bytes Returns two byte response in location 12-13 and 14-15 of received data RPM=((b1*256)+b2)/4 PID OD - Get Speed- send string 01040 6 Receive 13 bytes Returns one byte response in location 12-13 of received data Speed Kph = b1 Speed MPH = b1/.621 PID 0E - Get Ignition Advance -send string 010E06 Receive 13 bytes Returns one byte response in location 12-13 of received data Ignition Advance Deg. = (b1/2)-64 PIF 0F - Get intake Air Temp -send string 010F06 Receive 13 bytes Returns one byte response in location 12-13 of received data Intake Air Temp. C= b-40 Intake Air Temp F = (b-40)*1.8+32

1/12/2003

www.ghg.net/dharrison

4 of 12

Harrison R&D

1/12/2003

PID 10 - Get Air Flow - send string 011007 Receive 15 bytes Returns 2 bytes in location 12-13 and 14-15 Air Flow gm/sec=((b1*256)+b2)/100 PID 11 - Get Throttle Position Receive 13 bytes Returns one byte response in location 12-13 of received data Throttle % = b/255*100 PID 12 - Get Commanded Secondary Air Status - send 011206 Receive 13 bytes Returns one byte response in location 12-13 of received data bits defined as follows: air upstream cat 1------air downstream ca -1-----air off --1----air reserved ---00000

PID 13 - Get O2 Sensor location send 011306 Receive 13 bytes Returns one byte response in location 12-13 of received data bits defined as follows: O2 location 1-1 O2 location 1-2 O2 location 1-3 O2 location 1-4 O2 location 2-1 O2 location 2-2 O2 location 2-3 O2 location 2-4 O2 sensor 7 voltage = b/200 PID 1B - Get O2 sensor 8 voltage -send 011B06 Receive 13 bytes Returns one byte response in location 12-13 of received data O2 sensor 8 voltage = b/200 PID 1C - Get OBD type -send 011C06 Receive 13 bytes Returns one byte response in location 12-13 of received data Receive 13 bytes 1xxxxxxx x1xxxxxx xx1xxxxx xxx1xxxx xxxx1xxx xxxxx1xx xxxxxx1x xxxxxxx1

www.ghg.net/dharrison

5 of 12

Harrison R&D Returns one byte response in location 12-13 of received data OBDII CARB OBD Fed OBDII and OBD OBD I None 10000000 01000000 11100000 00100000 00110000

1/12/2003

PID 1D - Get O2 sensor locations - 7 same as PID 13 Receive 13 bytes Returns one byte response in location 12-13 of received data O2 location 1-1 1xxxxxxx O2 location 1-2 x1xxxxxx O2 location 2-1 xx1xxxxx O2 location 2-2 xxx1xxxx O2 location 3-1 xxxx1xxx O2 location 3-2 xxxxx1xx O2 location 4-1 xxxxxx1x O2 location 4-2 xxxxxxx1

Mode 2 Read Freeze Frame Data Mode 2 - Read OBD-II Freeze Frame data, format MODE-PP-BC PP=Parameter Identification (PID), BC=byte count to be received by protocol converter. Remember that the received byte count is actually double the value because each byte is transmitted as two ASCII characters. PID 00 - return supported PIDs - send string 02000A You would read 21 bytes, the V and the 20 ASCII characters which represent the 9 bytes response message. PID 00 returns four data bytes, 32 bits, where each bit represents a PID starting with PID 01, a 1 indicates a supported PID and a 0 represents a non-supported PID. Bytes 14,15 represent hex byte 1, 16,17 represent hex byte 2, 18,19 represent hex byte 3 and 20,21 represent hex byte 4. Other than the above differences, Mode2 operates like Mode1.

Mode 3 Read Trouble Codes Mode 3 - Read OBD-II Trouble Codes, format MODE-PP-BC PP=Parameter Identification (PID), BC=byte count to be received by protocol converter. Remember that the received byte count is actually double the value because each byte is transmitted as two ASCII characters. Send string 03000A You would read 21 bytes, the V and the 20 ASCII characters which represent the 10 bytes response message. There are three trouble code values packed into

www.ghg.net/dharrison

6 of 12

Harrison R&D

1/12/2003

the response. They are sent as 12 ASCII characters, starting with byte 10 of the received string, as shown below. Each trouble code consists of four characters.
10 11 12 13 14 Byte Number 15 16 17 18 19 20 21

012500000000 = ASCII Char.

In the above figure there is one trouble code which is P0125, as all powertrain trouble codes always start with P. There are other trouble codes for Chassis and Body computers but these are outside of the OBD-II requirements. If the first digit of the trouble code is not 0 then the code is a manufacturer. Mode 4 Clear Trouble Codes and Turn off the MIL Mode 4 - Clear Trouble Codes, format MODE-PP-BC PP=Parameter Identification (PID), BC=byte count to be received by protocol converter. Remember that the received byte count is actually double the value because each byte is transmitted as two ASCII characters. Send string 040004 You would read 9 bytes, the V and the 8 ASCII characters which represent the 1 byte response message. In string location 8& 9 is the two ASCII characters which represent the response. A 41 is operation failed, a 44 is operation success. OBDScan unique Modes The OBDScan also has several Mode commands which are used for non-OBD related functions. Read Firmware ID This is used to read the firmware version in the protocol converter. Send the string 900504. The converter will respond with four characters in the form of X.XX. Change ECU This is used to switch communication to another ECU, if any respond. Send string 800204. The converter will respond with a VT to indicate receipt of the command. If a second responder is on the bus then communication will only occur with the second ECU, or the first ECU if the change ECU command was previously issued. Passthrough Mode - Future Command This will allow the sending of any generic bus message. This will be used only by advanced users as very detailed knowledge of the vehicle bus protocol is required. The user will be able to receive up to six responses to the command.

Programming Examples 1. Reading the Trouble Codes:

Wait for sync character www.ghg.net/dharrison 7 of 12

Harrison R&D

1/12/2003

send mode 01, PID 01 and byte count 9 returns trouble codes and status on diagnostic evaluations supported wait for the receive buffer to get 18 bytes of ASCII Extract the ECU number ( VB example) textECU.Text = textECU.Text & "ECU #=" & Mid$(rcv_buf, 6, 2) & vbCrLf Extract the value of the four bytes of the response B1 = conv_hex(Mid$(rcv_buf, 12, 2)) B2 = conv_hex(Mid$(rcv_buf, 14, 2)) b3 = conv_hex(Mid$(rcv_buf, 16, 2)) b4 = conv_hex(Mid$(rcv_buf, 18, 2)) Determine if the MIL is on If B1 > 127 Then textECU.Text = textECU.Text & "MIL is ON" Remove the MIL status bit by B1 = B1 - 128 Else textECU.Text = textECU.Text & "MIL is OFF" End If Print the number of trouble codes textECU.Text = textECU.Text & vbCrLf textECU.Text = textECU.Text & "There are " & Str(B1) & " Troubles code(s) set" If the number of trouble codes is >0 print then If B1 > 0 Then wait for sync char from Protocol Converter send mode 01, PID and byte count 0B MSComm1.Output = "030B0B" wait for the receive buffer to get 18 bytes of ASCII in rcv_buf Print the 3 trouble codes, a 0000 indicates no trouble code textECU.Text = textECU.Text & vbCrLf & "TC1 -P" & Mid$(rcv_buf, 10, 2) & Mid$(rcv_buf, 12, 2) textECU.Text = textECU.Text & vbCrLf & "TC2 -P" & Mid$(rcv_buf, 14, 2) & Mid$(rcv_buf, 16, 2) textECU.Text = textECU.Text & vbCrLf & "TC3 -P" & Mid$(rcv_buf, 18, 2) & Mid$(rcv_buf, 20, 2)

2. Reading On-Board OBD-II test status

The code below is Visual Basic 6.0. The PID 01 response is four data bytes. Byte 1 is used to get the number of trouble codes and determine the MIL status as discussed above. B2 is assumed to be the second byte of the response data, B3 the third bye and B4 the fourth byte. If B2 And 1 Then If B2 And 16 Then textECU.Text = textECU.Text & "Misfire Monitoring Incomplete" & vbCrLf Else textECU.Text = textECU.Text & "Misfire Monitoring Complete" & vbCrLf

www.ghg.net/dharrison

8 of 12

Harrison R&D

1/12/2003

End If End If If B2 And 2 Then If B2 And 32 Then textECU.Text = textECU.Text & "Fuel Sys. Monitoring Incomplete" & vbCrLf Else textECU.Text = textECU.Text & "Fuel Sys. Monitoring Complete" & vbCrLf End If End If If B2 And 4 Then If B2 And 64 Then textECU.Text = textECU.Text & "Component Monitoring Incomplete" & vbCrLf Else textECU.Text = textECU.Text & "Component Monitoring Complete" & vbCrLf End If End If If b3 And 1 Then If b4 And 1 Then textECU.Text = textECU.Text & "Catalyst Monitoring Inomplete" & vbCrLf Else textECU.Text = textECU.Text & "Catalyst Monitoring Complete" & vbCrLf End If End If If b3 And 2 Then If b4 And 2 Then textECU.Text = textECU.Text & "Heated Catalyst Monitoring Incomplete" & vbCrLf Else textECU.Text = textECU.Text & "Heated Catalyst Monitoring Complete" & vbCrLf End If End If If b3 And 4 Then If b4 And 4 Then textECU.Text = textECU.Text & "Evaporative System Monitoring Incomplete" & vbCrLf Else textECU.Text = textECU.Text & "Evaporative System Monitoring Complete" & vbCrLf End If End If If b3 And 8 Then If b4 And 8 Then textECU.Text = textECU.Text & "Sec. Air System Monitoring Incomplete" & vbCrLf Else textECU.Text = textECU.Text & "Sec. Air System Monitoring Complete" & vbCrLf End If End If

www.ghg.net/dharrison

9 of 12

Harrison R&D

1/12/2003

If b3 And 16 Then If b4 And 16 Then textECU.Text = textECU.Text & "A/C Refrigerant Monitoring Incomplete" & vbCrLf Else textECU.Text = textECU.Text & "A/C Refrigerant Monitoring Complete" & vbCrLf End If End If If b3 And 32 Then If b4 And 32 Then textECU.Text = textECU.Text & "O2 Sensor Monitoring Incomplete" & vbCrLf Else textECU.Text = textECU.Text & "O2 Sensor Monitoring Complete" & vbCrLf End If End If If b3 And 64 Then If b4 And 64 Then textECU.Text = textECU.Text & "O2 Sensor Heater Monitoring Incomplete" & vbCrLf Else textECU.Text = textECU.Text & "O2 Sensor Heater Monitoring Complete" & vbCrLf End If End If If b3 And 128 Then If b4 And 128 Then textECU.Text = textECU.Text & "EGR Monitoring Incomplete" & vbCrLf Else textECU.Text = textECU.Text & "EGR Monitoring Complete" & vbCrLf End If

3. Using the Passthrough Mode

(applies to f/w 2.16 and 2.17 where noted) The Passthrough mode provides the framework to allow the sending of SAE-J2190 messages and manufacture specific messages to the vehicle. You will also need to be familiar with SAE-J2178-1,2,3,and 4 and knowledgeable with respect to the construction of SAE-J2190 and manufacture specific communication messages. The passthrough mode is designed for SAE-2178 physical addressing in version 2.16 and 2.17 adds virtual addressing capability. The SAE documents are available from www.sae.org for a reasonable fee and this document assumes the developer has the required knowledge for their specific application. As of January 8, 2003, the Passthrough function has been optimized for communication with SAE-J1850 PWM data. We are currently working on the VPW data, but its too early to know if the passthrough mode works with all VPW messages. 3.1 Passthrough Command Structure To enter the Passthrough mode send the ASCII string F0XXYY, where XX and YY are bytes to be used to filter the response, and wait for the single reply character, A. In f/w

www.ghg.net/dharrison

10 of 12

Harrison R&D

1/12/2003

version 2.16, XX and YY are only place holders, the passthrough is used only for SAEJ2178 three byte header messages. The reply will be received within 5ms. The filter bytes, XX and YY should be the first and second bytes of the response message header. Once the A has been transmitted, the Protocol Converter is waiting for a Passthrough Command string. The Passthrough requires binary communication, as opposed to ACSII characters, from this point. The passthrough string format must be as shown in the table below

Byte Number 1 2 3 4 5 6 7 8 9 10 11 12 13

Function Message to be received, range 1 to 3, first second or third reply from vehicle Length of this message, number of bytes to transmit to vehicle following this byte Message byte 1 Message byte 2 Message byte 3 Message byte 4 Message byte 5 Message byte 6 Message byte 7 Message byte 8 Message byte 9 Message byte 10 Message byte 11 Passthrough mode Command message format

Byte Number 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Function Message byte 1 Message byte 2 Message byte 3 Message byte 4 Message byte 5 Message byte 6 Message byte 7 Message byte 8 Message byte 9 Message byte 10 Message byte 11 Message byte 12 Reserved for future use Reserved for future use

www.ghg.net/dharrison

11 of 12

Harrison R&D

1/12/2003

As an example, send a SAE-J2178 message to the vehicle: 1. send Passthrough command (F0,64,Scan tool address) 2. Wait for the A response character 3. Send the following string as binary, not characters: 1, 6, &H64, ECU address, Tool Address, Mode, PID_hi, PID_low, 0, 0, 0, 0, 0 4. Get the 14 byte reply. The reply byte definitions will depend on the Mode and PID selected. Please note, use of the Passthrough mode requires knowledge of the various SAE specifications and should not be used as an experimentation mode on your vehicle. Please obtain the following documents to understand vehicle communication: SAE-2178-1,2,3, and 4 SAE-2190 SAE-J1850

www.ghg.net/dharrison

12 of 12