Since January 1st, 1996 all vehicles have been required to have On-board Diagnostics II, also known as OBD-II.
On-board diagnostics existed before then, but the process for reading diagnostic data varied from manufacturer to manufacturer.
If you knew the “secret” sequence, you could use your car key to turn the ignition switch a certain way and hopefully get the check engine light to blink out the error code. Not only did you need to know the correct sequence for the ignition switch, you had to then be able to decode the blinks.
The Society of Automotive Engineers (SAE) pulled it all together by defining OBD-II. This made it much easier to read error codes and troubleshoot vehicles.
In fact, it’s so easy that many auto parts stores offer this service for free and will read your check engine light code (in hopes that they can sell you some parts, of course).
So why should electronics enthusiasts care?
These days, cars are literally loaded with electronic gadgets and makers can build some interesting automotive related projects. To do this, an understanding of OBD-II is often necessary.
As a side note, I’m also a sort of gearhead and do all my own work on our two cars. And I find the way things work — both electrical and mechanical – very interesting. I suspect I’m not alone.
But This is an Electronics Blog, Not a Car Blog…
But because cars are loaded with electronic gadgets, it’s easy to see why someone would want to embark on an automotive related electronics project. If you’re one of those people, you will need to know about OBD-II, CAN, and the myriad of other electronics stuffed into today’s vehicles.
If you’re old enough, you may remember a time when you could pop the hood of your car open, gaze into it, and see a lot of the ground underneath. The only electronics in the car were the ignition system, headlights and tail lights, battery and alternator, and maybe a simple AM/FM radio.
Those were the good ol’ days.
Personally, I have never owned a car like this. My current car (the newest one I’ve had) is from 1999. But don’t scoff — in addition to all the fuel and emissions controls, the car boasts distributorless ignition, power everything, heated mirrors, anti-lock brakes, and a CD/MP3 player. The dash even alerts me when a tail light or headlight is out. I Like not having a car payment, but I’ll be looking at buying a new car this year – likely something 2015 or newer.
Due to pressure to reduce toxic emissions and improve gas mileage, manufacturers eventually started putting more electronics into cars.
In the 1980’s electronic fuel injection was showing up on more and more cars, eventually replacing carburetors all together. Along with it came the need for a computer to control it and talk to the other various emissions and fuel system related components. Most of us left these things buried under the hood and gave them very little thought, if we even knew they were there in the first place.
Enter the 1990’s.
Things like power locks and windows, higher quality sound systems, anti-lock brakes, keyless entry, and electronic climate control were becoming standard in many vehicles. Even technology such as navigation, traction control, TV screens in headrests, and “Run Flat” tires were showing up (along with their control circuitry) in some cars later that decade.
Electronic devices were now creeping out from under your hood and into your vehicle’s cabin.
Modern hybrid vehicles became available to the general public around the turn of the millennium.
I remember my parents (who are generally afraid of technology and not early adopters of anything) buying a 2001 Prius. I was shocked. It wasn’t the prettiest car, but later models made the Prius more aesthetically pleasing.
Of course, with the introduction of hybrid cars came the need for more electronics: batteries, electric motor/generator, and all the associated control circuitry.
Later in the 2000s, Bluetooth connectivity, USB ports, and other technologies started showing up in cars. My wife’s 2009 Fusion comes with all the above and Ford’s Sync (with software by Microsoft), so she can make and receive cell phone calls on the car’s audio system, which – even for a factory system sounds nice, sans any amps or subwoofers in the trunk.
In the current decade we have cars that parallel park themselves and apply the brakes for you to avoid a potential collision. Many vehicles come standard with back-up cameras and internet connectivity, along with all the other goodies that were introduced in previous decades.
It’s official: electronics in vehicles are here to stay and will only increase. Pretty soon, cars will be driving themselves while we sit back and relax. There are a few technical, political, and legal hurdles to surmount before this happens, but it’s coming.
Enough about why we should care about OBD-II, let’s get into some nitty gritty!
The OBD-II connector has the shape of a trapezoid and resides underneath the driver’s side dashboard. Figure 1 depicts a picture of the connector and the pinout.
OBD-II is an odd standard in that it is made up of four different main “sub” standards in and of itself. The OBD-II connector supports all of these. You’ll see what I mean soon.
Figure 1: OBD-II connector and pinout.
You’ll notice that some of the pins in figure 1 are specific to the make and model of the car. We won’t worry about those. The standard is the same and works with or without those make/model specific pins.
This single connector contains all the networks in use today as well as the controller area network (or CAN) standard. All vehicles from January 1st, 2008 or later use the CAN standard. If your vehicle was made before 2008, it may use CAN, or it may use one of the other standards.
What do I mean by all the networks in use today?
Earlier, I said OBD-II was composed of other standards.
These standards are:
- ISO 9141-2
- SAE J1850 variable pulse width (VPW)
- SAE J1850 pulse width modulation (PWM)
- And the newer CAN standard (ISO 15765)
While all cars made since January 1st, 2008 use the CAN version, there are still a fair share of older vehicles on the road today that use one of the other three standards.
Quick research suggests the average lifespan of a vehicle in the U.S. today is about 12-13 years. Given this information, it’s easy to see why OBD-II includes the older standards. We’ll go into some detail on each one in part 2 of this series.
When you plug a code scanner into an OBD-II port, the scanner automatically discovers which standard to use. It then communicates using the correct pins, ignoring all the other pins.
OBD-II Passive vs Active States
Throughout this series you’ll see the words passive and active. This has to do with OBD-II bus arbitration. The passive state of a bus can always be over-ridden by an active state by any node. A node is just something that connects to the bus.
This creates a priority where logic 0 (active) wins out over logic 1 (passive). Since nodes always listen to the bus as they send data, if any node detects an active state while it’s sending a passive state, it will stop sending and wait for the bus to become idle.
Because of this, important messages, such as those pertaining to critical engine parameters, can get through while messages of lesser importance must wait.
OBD-II Data Packet Structure
All OBD-II standards us the same basic format for their data packets, though there are some slight differences for each protocol.
The basic structure is a packet beginning with a start of frame (SOF) pulse. Then comes the header which includes a priority, a destination, and a source. After the header comes the data. After that, a CRC or checksum. Finally, there is the end of data (EOD). Note that all buses will go idle if there has been no activity for a certain amount of time.
Header bytes direct the data. The priority byte within the header enables arbitration of the bus. Lower values have a higher priority. The priorities are used in arbitration to ensure important messages get first dibs on the bus. Destination and source bytes help direct the request to the right node and also show where the response needs to go.
The data field generally can contain up to 7 bytes. A running checksum (or CRC in the case of CAN) helps with data corruption.
|0x01||Show current data|
|0x02||Show freeze frame data|
|0x03||Show stored Diagnostic Trouble Codes|
|0x04||Clear Diagnostic Trouble Codes and stored values|
|0x05||Test results, oxygen sensor monitoring (non-CAN only)|
|0x06||Test results, other component/system monitoring (Test results,
oxygen sensor monitoring for CAN only)
|0x07||Show pending Diagnostic Trouble Codes|
|0x08||Control operation of on-board component/system|
|0x09||Request vehicle information|
|0x0A||Permanent Diagnostic Trouble Codes (DTCs)|
Figure 2: OBD-II modes.
Most requests consist of a mode byte and a parameter ID (PID) byte. OBD-II also requires a “functional address” that all nodes must respond to. This is sort of like a roll-call or public shouting of “here I am!” for the nodes.
The figure above shows the 10 OBD-II modes. Note that not all manufacturers support all nodes.
There are too many PIDs to list here, but Wikipedia provides an extensive list of PIDs with different modes. Just search OBD-II PIDs.
Figure 3 depicts a graphical representation of a typical OBD-II data frame.
Figure 3: OBD-II data frame structure.
The actual codes you would see on your code scanner are five characters long. To use the scanner, you simply plug it into your vehicle’s OBD-II port under the driver’s side dash, turn the key to “on” position, hit the appropriate button on your scanner and wait for the codes to come rolling in.
Figure 4 shows a breakdown of the structure of a typical diagnostic trouble code (DTC). Note that you should not get any codes unless your check engine light is on. You can also clear the codes with your scanner and turn that annoying light off. However, it will simply come back on unless the problem is fixed.
Figure 4: anatomy of a DTC.
Coming up: OBD-II, Part II
So far, we’ve talked about why you should care about OBD-II, a brief history of electronics in cars, OBD-II basics, passive and active states, and we dissected an OBD-II data frame.
In part 2, we’ll dissect each of the four protocols or standards in OBD-II and delve into how they work.
Meanwhile, comment and let me know if you’re into automotive related projects (electrical, mechanical or both). If so, tell me a bit about your latest endeavor.