AutoSpeed - Reading Your Car's Brain

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.

Reading Your Car's Brain - Part 1

Accessing live and stored data from the ECU.

By Julian Edgar

Making the Connection

OBDII.... and OBDII

Readers

Summary

Next: Using a Palm-based OBDII reader