Harrison R&D 4/24/2002

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 SSSSSS’s 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. Don’t

www.ghg.net/dharrison 1 of 7
Harrison R&D 4/24/2002

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 PID’s - 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 ------x-
Component support -----0--
Reserved ----x---
Misfire status ---x----
Fuel status --x-----
Component status -x------
Reserved status 0-------

PID 02 - Get trouble codes – used by Mode2 only

www.ghg.net/dharrison 2 of 7
Harrison R&D 4/24/2002

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
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 %

www.ghg.net/dharrison 3 of 7
Harrison R&D 4/24/2002

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)/4D
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

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

www.ghg.net/dharrison 4 of 7
Harrison R&D 4/24/2002

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 1xxxxxxx

O2 location 1-2 x1xxxxxx
O2 location 1-3 xx1xxxxx
O2 location 1-4 xxx1xxxx
O2 location 2-1 xxxx1xxx
O2 location 2-2 xxxxx1xx
O2 location 2-3 xxxxxx1x
O2 location 2-4 xxxxxxx1

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

www.ghg.net/dharrison 5 of 7
Harrison R&D 4/24/2002

PID 1C - Get OBD type -send ‘011C06’

Receive 13 bytes
Returns one byte response in location 12-13 of received data Receive 13 bytes
Returns one byte response in location 12-13 of received data

OBDII CARB 10000000

OBD Fed 01000000
OBDII and OBD 11100000
OBD I 00100000
None 00110000

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 xxxxx1 xx
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 PID’s - 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.

www.ghg.net/dharrison 6 of 7
 Harrison R&D 4/24/2002

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
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.
Byte Number
10 11 12 13 14 15 16 17 18 19 20 21

0—1—2—5—0—0—0—0—0—0—0—0 = 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 2 bytes response message.

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.

www.ghg.net/dharrison 7 of 7