Adapters for Vehicle On-board Diagnostic

It is probably happened for many of us, you are driving along in your car and the "Check Engine” yellow light illuminates on the dashboard as clear indication that is something wrong with your car. Unfortunately, it doesn’t give any clue what might be the nature of the problem and can mean many different things, from a loose gas cap to catalytic converter fault. I do remember back to year 94 Acura Integra used to have the control unit under the driver seat and the LED was flashing if something was wrong. Counting the number of blinks during repeated intervals you can get the error code. As vehicle computers getting more and more sophisticated the number of possible error codes increases exponentially. The solution is to use on-board diagnostic (OBD). This article describes how to build simple OBD interface and get access to your vehicle’s Engine Control Unit (ECU).

OBD-II

This project started a few years ago when I wanted to be able to reset the service interval reminder in my 1997 Audi A4. It turned out that the only way to do it for that particular model is connect to ECU using proprietary Volkswagen KW1281 protocol or put myself at mercy of dealer. I was able to build a simple adapter inspired by Jeff Noxon schematic and using VWTool desktop application for resetting the service indicator. That was apparently a design flaw and in later Audi models you can reset the service reminder by pressing predefined key combination on dashboard. Volkswagen KW1281 is an example of proprietary protocol and works only in vehicles manufactured by Volkswagen. These days most of the vehicles equipped with On-Board Diagnostic. The good news is that it’s a standard and should work with any OBD-compliant vehicle. The first incarnation of On-Board Diagnostics specification was developed by Society of Automobile Engineers (SAE)  was known as OBD I. It was not very successful and later on was replaced  with OBD-II. It is mandatory for all cars and light trucks in US since '96. Canada introduced similar requirements two years later. EOBD is a version of OBD-II required in Europe starting year 2004 for diesel vehicles and 2001 for gasoline vehicles. The Data Link Connector (DLC) for connecting the diagnostic equipment  is standard as well. The pinout of DLC connector is shown in Figure 1 as defined by SAE J1962 spec.

Manufacturers are free to use connector pins not listed by SAE document for their own purposes. The connector is usually located on the driver’s side under the dashboard, but you can use the DLC location database. The DLC connector allows the scan tool to read the diagnostic data from engine computer and reset the “Check Engine” light. Note that all DMV emission testing facilities are using OBD diagnostics now and inspection will fail if vehicle has the "Check Engine" light illuminated, even if it is only lit to remind you of a past-due oil change or 60,000-mile tune-up.

Figure 1, DLC connector pin assignment

 

Figure 2, Female DLC connector view

The OBD-II Communication Protocols

Originally OBD-II standard specified only three communication protocols: ISO 9141, SAE J1850 PWM and SAE J1850 VPW. All three are vendor-specifics protocols using by Chrysler, GM and Ford, SAE just incorporated all of them in OBD-II standard. The ISO14230 (Keyword 2000) protocol came in the picture around year 2000 as an attempt to improve and extend the existing ISO9141 protocol. Controller Area Network (CAN) is a serial bus communication protocol developed by Bosch in the early 80s and started to appear in 2003. The detail description of the communication protocols goes beyond the scope of this article, I just want briefly to enumerate them. The ISO9141/14230 is probably the most wide-spread protocol for the moment and being used by Chrysler and the most of European and Asian-made vehicles. It is deploying bidirectional asynchronous bus with the communication speed 10.4 Kbps similar to RS-232. The idle bus is defined by presence of the high (+12V) level and signaled bus has the ground level. To start the communication with the ECU the diagnostic tester using special initialization sequence. After connection is established and there is no activity on the bus the tester periodically has to send “Keep Alive” packets to maintain the communication channel open. The original ISO9141 document defined two communication wires, K and L lines. L line is optional and can be used only on the establishing communication step. It became legacy and not being used these days. SAE J1850 PWM is 41.6 Kb/s Pulse Width Modulation is the original Ford standard with two wire differential approach. The voltage levels on the bus are in 0÷5V range. SAE J1850 VPW 10.4Kb/s protocol is being used by GM and Chrysler and stands for Variable Pulse Width. It is serial communication with a single signal wire. The voltage level on VPW bus is varying between ground and 8V. Both protocols, PWM and VPW employ a multi-master CSMA/NDA arbitration scheme. CAN protocol is a popular standard outside of the US automotive industry and became standard communication bus for today’s vehicles. The communication speeds are being used either 250 Kbps or 500 Kbps with standard 11-bit (CAN A) or extended 29-bit (CAN B) identifiers. By 2008, all vehicles sold in the US will be required to implement CAN, thus eliminating the ambiguity of the existing five communication protocols. Modern vehicle may have many different electronic control units for various subsystems and communications among them are essential. Typically the biggest processor is the ECU, others are used for transmission, airbags, antilock braking, etc. PWM, VPW or CAN protocols are often using for that purpose, making DLC connector just logical extension of an existing communication bus.

What Communications Protocol does my vehicle use?

If you live in US, all '96 and newer passenger cars are required to support OBD-II diagnostics. The same is true for Canada and Europe just years are different, see the table below. If you live in any other country, your country may have started requiring OBD-II.

Figure 3, OBD-II standard support by country

If you know for sure that your car supports OBD-II the next question will be which flavor? In general, GM cars and light trucks use SAE J1850 VPW, when Ford uses SAE J1850 PWM protocol. Chrysler vehicles might use either ISO9141 or VPW. The European and most of Asian cars use ISO9141/14230. All the new vehicles have to use CAN protocol. Another way to tell which protocol is used is examining the DLC connector, see the Figure 4. Note that contacts in pins 4, 5 and 16 should always be present. If your vehicle has this style connector, but doesn't have these pins populated, you probably have a pre OBD-II vehicle built before 1996. Ok, now you have found your DLC connector ant it looks exactly the same... Well, having the connector with the contacts shown in Figure 4 is not a guarantee of OBD-II compliance. Interesting enough the same vehicle models built for different markets may or may not be OBD-II compliant. In general, the car manufactures are trying to avoid open standards and lock in the diagnostic service with proprietary protocols. Dealers want to have their share as well!

Protocol	Pin 2	Pin 6	Pin 7	Pin 10	Pin 14
ISO 9141/14230
J1850 PWM
J1850 VPW
ISO 15765 CAN

Figure 4, OBD-II connectors pin for different protocols

Anecdotally, I know the case when the particular model made for sale in Turkey actually had DLC connector, all the ISO9141 pins populated and even passed OBD-II initialization sequence. Then it replied back with the error code that car was not OBD compliant!

Reading ECU Data

The OBD standard divides the data in multiple groups called services. Within the particular service multiple Parameter Identification Numbers (PID) are defined. For a list of basic PIDs and their definitions see Figure 5. Service 1 provides the access to multiple sensors, like engine RPM, coolant temperature, vehicle speed and etc, see Figure 6. In Service 2 you can retrieve so-called “Freeze Frame” data. The Freeze Frames are a "snapshot" of the vehicle's operating conditions at the time of the fault. Service 3 gives you ability to get Diagnostic Trouble Codes (DTC). That is when you Check Engine light go on. The generic DTC list defined in SAE J2012 document is common for the all vehicles and manufacturers are free to provide the specific codes as an extension. Service 4 allows you to reset the trouble codes reported in Service 3. There is no way to select the particular DTC to be reset, you can only clear all of them. Service 9 let you read Vehicle Identification Number (VIN) and Calibration IDs. See Wiki OBD-II PIDs article for more details.

Figure 5, OBD-II Services

 

Figure 6, Service 1 PIDs supported by Hyundai Elantra ECU

OBD-II vs. Proprietary Protocols

OBD-II was designed for vehicle emission diagnostic in the first place. Even though the standard defined many useful functionality vendors are not required to implement all the PIDs listed in SAE document. That is the most confusing part about OBD-II. For instance, the latest ECUs are supporting the VIN number request in Service 9, but if your car goes back to year '96 you are out of luck here. Take a look on Figure 6. It is listing all the PIDs for Service 1 in blue and PIDs supported by Hyundai Elantra ECU in white bars. Not so many of them...  In general, you can only read the data and erase the DTC when the proprietary protocols give you access to all the components. Want to reprogram your central locks or your Radio? Diagnose a problem with your ABS, Airbags, or Automatic Transmission? Re-align your Immobilizer after swapping ECU's? Reset your Service Reminder Indicator? No way to use OBD here! It is just an example of such device with support for the most of proprietary vehicle protocols, MODIS from Snap-on is shown below with the price sticker around $7,000. Do you really need it? If you just want the check why you are got "Check Engine” light OBD-II still might be handy...