Take any car into a dealer for service work and the first thing that you'll
see is a handheld electronic service tool being plugged into a diagnostics
socket. Depending on how sophisticated the system is, the tool will be able to
read fault codes, look at the engine operating parameters that were in place
when the fault occurred, or even read out live engine operating data. So that
they can have a much better idea of how their modifications are affecting the
ECU operation, many modified car workshops also use these 'scan'
tools.
And wouldn't it be good if you could access the same information? Being able to see real-time ignition timing, the
'learning' action of the ECU as it responds to oxygen sensor signals - even the
health of the oxygen sensor(s) themselves. And imagine being able to read the
data out on a Palm handheld, so that you can have on your dashboard a virtual
instrument able to display these different parameters in meter or moving
line-graph displays. (Or alternatively, being able to log to a PC so that you
play back the information at your leisure.)
No longer do you have guess what the intake air temp is on a hot day - you
can read it straight off from the factory sensor! No longer do you have to
wonder if that sudden glitch is the timing being pulled back by the knock sensor
- you can read off the ignition timing live and as it happens.
The potential benefits from having access to this type of information are
huge - and the tools to read it are available on budgets affordable by the
individual tinkerer. But there are also some major traps to fall into - so read
on very carefully....
Making the Connection
All current cars and most cars of the last 10-15 years have diagnostics
ports. Manufacturers use these ports not only during the servicing of the car,
but also to determine that all is well as they leave the end of the production
line. But because each manufacturer doesn't care much what other manufacturers
are doing, many have come up with their own unique system of diagnostics sockets
and software protocols. That is, GM didn't care what Ford used as their standard
- so GM and Ford went their separate ways. This vast array of formats meant that
data readers had to be carefully matched to individual brands. Any 'universal'
tools were very expensive, because they required a multitude of cables and plugs
to match the different sockets, and a range of different software to read the
data.
The change came when the US Government insisted that all cars had to meet
certain long-term emissions standards. While it was fine if the car left the
manufacturing plant meeting the letter of the law, it wasn't so good if 20,000km
down the track the car was way too dirty. Obviously, maintaining emissions
standards is more important that just having a brand new car meet them. One way
of making sure that a car stays clean is to keep the engine management system in
good health - and this is best done by ensuring that there are no faults in its
operation.
As a result of this thinking, the US Government legislated that On-Board
Diagnostics needed to be implemented across all cars sold in that country. This
standard, now in its second iteration (OBDII) required that a single type of
diagnostics socket be used, and that certain software protocol standards were
also observed. Generic parameters (such as oxygen sensor voltage, throttle
position opening, ignition timing and so on) had to be available on all cars.
This standardisation opened the way for generic scan tools which can plug
into the OBDII socket and read out the data - whether the car is a GM, Ford, or
anything else. And since the US market is so large, cars sold in other markets
often feature OBDII ports as well.
Sound good? - just find the OBDII port and away you go? Unfortunately, it
gets a bit more complex...
OBDII.... and OBDII
While OBDII is a standard, there are four different software ways in which it
can be met. That is, there are four different communication protocols, each
having different pin placements on the socket and different communication formats.
Leaving aside for the moment those people who are skilled enough to develop
their own hardware and software, being able to read the data available from the
OBDII socket requires two things:
- The car has to be fully OBDII compliant in its socket, pin placement and
internal ECU software
- The reading hardware and software has to match the protocol being
used
As indicated above, all cars in the US are legally required to be OBDII
compliant. This has been the case since January 1, 1996, and so if you own a
US-delivered model of this age or younger, you can be absolutely confident that
your car has the right socket and the right ECU software to potentially allow
you to read data.
However, what if you live outside of the US? The first step is to find the
car's diagnostics socket and inspect it. The socket is normally mounted inside
the cabin on the driver's side - under the dash, in the centre console behind a
removable trim plate, or behind the ashtray. If the socket matches the diagram
shown here, that's a good start. (If the socket shape is different, you can
immediately be certain that the car isn't OBDII compliant.)
The next step is to look at which holes in the socket are populated with
pins. Each OBDII standard uses a unique series of pin placements and so you can
gain an inkling of the OBD standard by looking at the socket. This step is
required because some manufacturers use OBDII sockets (and may even have "OBDII"
written on the socket or its cover!) but the cars are not actually
OBDII-compliant...
- VPW standard cars have Pin 2 (bus +), Pin 4 (chassis ground), Pin 5 (signal
ground) and Pin 16 (battery power)
- PWM standard cars have Pin 2 (bus +), Pin 4 (chassis ground), Pin 5 (signal
ground), Pin 10 (bus -) and Pin 16 (battery power)
- ISO and KWP2000 standard cars have Pin 4 (chassis ground), Pin 5 (signal
ground), Pin 7 (K line),
[optionally Pin 15 (l-line)]
and Pin 16 (battery
power)
Note that additional pins may be populated in any of these cases for
manufacturer-specific use (eg a pin to connect to ground to start fault codes
flashing on the check engine light).
Once you've got an idea as to the protocol that the pin placements indicate
is being used, you can consult this table and see if it matches up.
| Car |
OBDII Standard |
| US-delivered GM |
VPW |
Euro GM
Chrysler
Asian manufacturers |
ISO |
| US-delivered Ford |
PWM |
|
Note that you need to be wary if a required pin is not provided - even if you
can easily install it yourself. For example, a car with Pins 4, 7 and 16 looks
just one pin (a signal earth) short of matching the ISO standard. However it is
likely that even if you provide Pin 5 (signal ground) the car will prove
not to be OBDII compliant in its ECU software capability.
|
Readers
Both software and hardware is needed to read the data stream. Packages are
available that can read one, two, three or all of the different formats. The
display medium can be by Palm handheld, Windows CE handheld or normal laptop PC.
In addition to the generic OBDII parameters, manufacturers make available
their own unique data through the same port. Some readers can also see these
enhanced parameters, but the reader is specific to the manufacturer. For
example, data readers are available that can display in great detail all the
operating parameters of current Holdens - including important aspects not
available in the generic OBDII data stream, like knock sensor activity. However,
this package won't display these enhanced parameters for other makes.
If you intend using the package with only the one car, it makes sense to buy
a reader that can display these manufacturer-specific enhanced parameters.
However, if you're going to use the reader with a wide range of cars, a generic
reader will be better. (While the enhanced parameter reader will be able to read
generic OBDII as well, a generic reader is usually much cheaper than
manufacturer-specific readers.)
Note that some readers have the ability to display fault codes for a variety
of cars - for example, you might need to download the specific Mazda listing.
This is not the same as reading enhanced Mazda data, though. Just the
generic OBDII parameters will still be available - it's just that now the
Mazda-specific fault codes will be interpreted for you.
|
A data reader is a great tool to acquire as a group or club buy. That is, if
you have a number of mates who would also be interested in using it (say during
modification set-up or tuning), the purchase price might be able to be
shared around. If this is the case, you need to look even more carefully at the
data formats the system will be required to read, whether the capability to read
manufacturer-specific data is required, and what type of display (eg laptop or
Palm) is most widely available within the group.
|
Summary
It can all get very confusing - so what steps should you take when deciding
on a data reader?
- Inspect the diagnostics socket. If it is OBDII, continue below. If it is
not, search the web for a reader specific to your car.
- Note the locations of the OBDII socket pins.
- Check the pin locations against the above information and work out which
protocol is most likely used (VPW, PWM, ISO or KWP2000).
- Check the likely protocol against the above table of manufacturers and
protocols.
- See if a reader is available to cover your specific car's enhanced data
stream.
- Select the data reader software/hardware package to suit your display
(laptop PC, Palm Handheld, Windows CE handheld).
- Contact the reader's manufacturer with the details on your car, pin
placement in the OBDII socket, etc, and see if they can confirm that the
equipment will work in your application.
If you are dealing with a US-delivered car, just skip #1 and #7 - the rest of
the list still applies.
This sequence of steps is necessary because, especially in cars delivered
outside of the US, the variations are enormous. When confronted with a model
that they haven't seen before, even workshops experienced with using a multitude
of readers on different cars still invariably have to actually connect the
reader to the car to see if it will work.
But when you have a reader working with a car, suddenly a whole new world of
information opens.
Next: Using a Palm-based OBDII reader
|