If your vehicle was manufactured after 1996, it contains an On Board Diagnostic (OBD) computer that captures information about how it’s running. OBD II is version 2.0 of the standard for communicating this information.
The data tracked by the OBD II system was originally intended to monitor the engine’s emissions and track down problems that caused cars to pollute more than normal. Today, however, manufacturers have extended the standard to contain a great deal of data about problems and performance. OBD II data is what causes your car’s “check engine” light to go on when there is a problem, and it is your mechanic’s tool of first recourse when you bring the car in with symptoms that have no obvious cause.
Since the data’s transmission format and content are standardized, a number of third parties have developed hardware to detect and display these codes. Some of these devices hook up to laptops, which means you can display and catpure this data.
The OBD II port allows your car to report three kinds of information: Diagnostic Trouble Codes (DTCs), real-time data, and freeze frame data.
DTCs are simply error codes that can be looked up to determine what problem your car is experiencing. For example, the DTC P0302 means “cylinder 2 misfire detected”. If the condition that caused the DTC persists, the car’s computer will turn on the “check engine” light. (See the references section, below for places to look up codes.)
Real-time data is the raw sensor data reported to the OBD computer. This data can be helpful for troubleshooting problems and monitoring engine performance.
Freeze frame data is a snapshot of the real-time sensor feeds at the time of a DTC condition. An auto mechanic can use this data to figure out what was going on at the time your car’s “check engine” light went on.
Within the OBD II standard, there are several protocols for transferring data from the car to a diagnostic device.
|ISO 9141||10 Kbits/second||most Asian and European manufacturers|
(Pulse Width Modulation)
|100 Kbits/second||Ford, Mazda|
(Variable Pulse Width)
|100 Kbits/second||primarily GM|
(Controller Area Network)
|varies by application; see the Kvaser CAN page for more details||newer vehicles|
Consult Scantool.net’s list for the standard supported by a specific vehicle. When shopping for an OBD tool, you need to make sure it supports the protocol your vehicle uses, but after that you probably don’t need to worry about the protocol.
The CAN standard is newly emerging. It will be required on all new vehicles by 2008, and it will help various computer systems within your car to communicate. For example, your GPS system could talk to your OBD system or your DVD player.
The OBD II port’s physical connector is called the Data Link Connector (DLC). It is a 16-pin plug that’s usually located under the dashboard near the steering wheel. (The standard specifies that the connector must be within three feet of the driver.) On my Mazda, the connector is located near the hood release in a difficult-to-photograph position.
When searching for your DLC, remember that a three-foot sphere around the driver is pretty large, and the port may actually be on the passenger’s side. (You can be fairly certain it will be hard to see and/or reach, though.) Luckily, there is a database of DLC locations.
One of the pins on the OBD II connector is power from the car’s battery, which means that OBD II readers do not need batteries or an external power source.
A standard set of DTCs is available on all vehicles, but each manufacturer includes hundreds of proprietary codes that help pinpoint malfunctions on a specific vehicle.
Real-time data sent through the OBD port includes vehicle speed, RPMs, air temperature, and the readings of various sensors (typically oxygen sensors and knock-detectors). Not every vehicle passes the same information over the interface, so your data streams may vary.
OBD II hardware breaks down into two categories: stand-alone devices that are intended exclusively for diagnostics (see example at right), and signal conversion tools that provide a physical connection, but require software on a computer or PDA to display the data.
Obviously the conversion tools will be slightly cheaper, because they are only interfacing to the vehicle and have no processor or memory. They’re also more flexible, because the software can be replaced or modified.
There are a number of suitable conversion tools, including BR-3 and Autoterra, but the one I have is Scantool, so that is the one we’ll talk about here. If you want to make your own OBD II signal converter, start at over at CarPlugs.com.
It’s also worth mentioning a couple of consumer devices that use OBD data to provide useful data to drivers. ScanGauge reads and clears DTCs, provides a digital dashboard, and has a trip computer. CarChip is a data logger that tells parents and bosses if their cars have been driven harder or farther than they should have been.
Scantool’s hardware comes in three parts: a converter box that translates the OBD signal to something that can be read by your computer’s serial port, a cable that connects the converter to the OBD port, and a serial cable that goes to your computer. The converter box’s cable jacks are helpfully labelled “OBD II” and “PC” to avoid confusion.
Hooking up an OBD reader of any type is easy: just find the vehicle’s OBD port and plug in the cable. Since most readers require power from the OBD port, the ignition will need to be at least in the “accessories” position for anything to work, and the engine will need to be running if you want to get any useful data.
After that, it’s just a matter of plugging the other end into your computer’s serial port and running the software. (I have not tried the Scantool software with a 9-pin to USB converter, so I don’t know how well it will work with USB.) The software initializes the Scantool when it starts up, so if you launched the program before plugging in the Scantool, you’ll need to reset the interface.
Just as you have a number of options on the hardware side, you also have choices when it comes to software. Not every OBD program works with every available converter, but the vendors are pretty good about providing compatibility information, so it’s easy to make sure you’re getting pieces that will work together.
Since Scantool is the hardware we’re talking about, we will also primarily talk about their software, but first there are a couple of other interesting products to mention.
Autotap sells a line of products that includes OBD software for Windows and Palm handhelds. It allows you to monitor multiple data streams in a slick dashboard format or with charts and graphs so that you can see how the values change over time. You can also save data to a file and open it in a spreadsheet for deeper analysis.
Digimoto is another interesting product for Windows. It also provides dashboards, data logging, and graphs with a nice user interface. Their product also uses some formulas to estimate engine horsepower and torque from acceleration, making it useful if you are tuning your car for performance.
A search of SourceForge naturally turns up a handful of moribund projects, but one promising package appears to be Freediag. With just the command line interface, it is not as flashy as the commercial products, but it is GPL’d C code that runs on Linux or Unix.
Scantool’s software represents a compromise between flashiness, openness, and functionality. Versions are available for DOS, Windows, and Linux. The GPL’d C source code is also available for download.
A quick look at the main menu shows that the software is organized around OBD’s three primary functions: read codes, show sensor data, and check freeze frame data. (Although the freeze frame and tests functions are not yet implemented.) The options menu lets you choose your COM port, baud rate, US or metric units, and Windowed versus full screen mode.
Checking and clearing error codes (DTCs) is a basic function of any OBD tool, and Scantool provides a good interface for performing these functions. If your “check engine” light is on, you probably want to use this feature to see what is wrong with your car, but not every DTC triggers the “check engine” light (or doesn’t trigger it immediately), so you may have undiagnosed errors stored in your OBD computer. Some states’ emissions tests include a check of your OBD computer for stored DTCs, so if you’re headed to the testing station, it might be good to know if your car is carrying around any DTCs.
Note: one common cause for a “check engine” light is driving with the gas cap unfastened, resulting in a code such as P0455. Before paying a mechanic to tighten your gas cap and clear the code, it might be worth giving it a try yourself. Of course, if the code reappears, there could be other problems.
Unless your “check engine” light is on, there are probably no codes to read, so the main function of Scantool is to watch the sensor data. There are over 60 channels of data to monitor, but not every channel is available on every vehicle.
Scantool polls all of the data channels in a loop, so turning off channels that you’re not interested in will enable you to get a higher sampling rate on the channels that you are interested in. You can watch the data change in real time, but since it doesn’t log or graph the data, it can be difficult to notice patterns.
Unfortunately, the OBD specification is not an open one, meaning that you have to buy it if you want a copy of the spec itself. Luckily, you can get pretty far using just the information that’s freely available on the Internet.
A good starting point is Scantool’s web site. Besides product information about their hardware and software, they have a lot of information about OBD II and links to more information and even other vendors.
Two more good references are OBDII.com and OBD Codes. Either one of these sites will, in turn, point you to lots of other sites. If you’re interested in looking up error codes, the DTCodebank is a good reference (free registration required). Your car’s service manual should also list DTCs and, helpfully, ways to fix the indicated problems.
As far as books are concerned, there are three that come to mind. OBD II Diagnostic Secrets Revealed by Peter David seems claims to be the “OBD II bible”. While it does have a lot of good information, it falls well short of bible status in my opinion. Getting to Know OBD II by Ralph Birnbaum seems to be favorably reviewed, but I am not personally familiar with it. Finally, The Isaac Newton School of Driving by Barry Parker is a clever book that talks about the various aspects of automobiles in mathematical terms. While it is not directly related to OBD II, it is good reading if you plan to use OBD to instrument your vehicle for performance reasons.
For information about the CAN standard, see the Kvaser CAN Protocol Tour.