Innovate Motorsports OT-1 User Manual

Page 4

Advertising
background image

- 4 -

Looking closely we can see that there are really three different electrical ‘pairs’, each
representing a different type of physical communication link. J1850 (pins 2&10), CAN (pins
6&14), and ISO (pins 7&15). On top of these three physical communication links are six different
communication protocols:

• The J1850 pair uses either J1850pwm (Ford) or J1850vpw (GM)
• The CAN pair uses either ‘standard’ ISO 15765 or ‘extended’ ISO 15765
• The ISO pair use either ISO 9141 or ISO 14230 (sometimes referred to as KWP2000)


So, in order to get OBD-II information from any OBD-II compatible vehicle an interface needs to
‘speak’ six different languages over three different types of electrical links. Starting in MY2008,
this will drop to one electrical link (CAN) and two protocol variations (ISO 15765 standard or
extended) but that still leaves about 12 years of ‘compromise’ vehicles. Fortunately the OT-1 can
take care of most of this complexity automatically. So, from a user’s point of view OBD-II can
primarily be considered on the basis of what is consistent and standard, namely:

• The

Connector

• The Information Provided


In addition to having a standard size, shape, and pin assignments, the OBD-II connector is
required to be within 3’ of the driver’s seat and require no tools for access. The most common
location is behind the dash immediately in front of the driver, though some vehicles have the
connector stashed in the center console or even behind the ash tray.

OBD-II information comes in two basic flavors, “PIDs” and “DTCs”. PIDs, or “Parameter IDs”,
represent real time measurements about the state of the power plant; information such as RPM
and ignition timing. The definitive reference on these standard PIDs is the J1979 Standard (last
revised 4/2002), published by the SAE International (

www.sae.org

). Not all ECUs support all

PIDs, but the OT-1 understands and converts over 100 of the most common ones (see Appendix
B for a complete list).

DTCs, or “Diagnostic Trouble Codes” are, as the name implies, problems reported by the ECU.
Codes can be “Standard” or “Manufacturer Controlled”. An example of a standard code would be
P0051. This code means”HO2S Heater Control Circuit Low, Bank 2, Sensor 1” for all OBD-II
vehicles. But P1336 is in the non-standard code range. The exact meaning is up to the vehicle
maker. Without information from the car maker all we know from the code itself is that the
beginning, P13xx, suggests that it is in the general category of “Ignition System or Misfire” (which
would explain the connection to a shoddily installed crank angle sensor in a certain Suburban,
but let us not digress…)

The definitive listing of standard DTCs is J2012 (last revised 4/2002), also published by SAE
International. All these standard DTCs are reported as both a number and in plain English by the
OT-1. Manufacturer Controlled DTCs are reported solely by number.

1.2 Why is CAN so special?


CAN stands for “Controller Area Network”. It was originally developed by Bosch specifically for
networking together various systems in passenger vehicles. It was presented to SAE in 1986,
the first hardware based CAN controllers appeared by 1987, and it became an official ISO
standard in 1993. Although originally designed for passenger vehicles it was quickly adopted for
use in everything from medical equipment to elevator control systems.

The first obvious benefit in automotive data logging is speed. While ISO 9141 uses a data rate of
10.4K bits per second, CAN is typically implemented in passenger vehicles with a speed of 500K
bits per second. In addition, today’s CAN controller chips offer a number of sophisticated
features like ‘auto reply’ and ‘direct memory access’, which allow ECUs to respond to information
requests very quickly.

Advertising