Obd2 Protocol Programming
Karlyn Hemmerling
Eventually on your journey into the world of embedded electronics, you will want to "hack" a vehicle for data. As with many other integrated systems, there is a specific 'language' for talking with vehicles. This tutorial will give a basic introduction to the On-Board Diagnostics (OBD) specification that vehicles and other industrial machines use to communicate with the outside world.
On-Board Diagnostics, or "OBD," is a computer-based system built into all 1996 and later light-duty vehicles and trucks, as required by the Clean Air Act Amendments of 1990. OBD systems are designed to monitor the performance of some of an engine's major components including those responsible for controlling emissions.
Saving the planet is great (shout out to you citizen scientists!), but what this also means is we can access other features of the car and collect information from and on those parts. Learning how to work with those protocols also means that you can determine what that Malfunction Indicator Light (MIL) (aka the Check Engine Light) on your dash is referring to when it tells you there's an engine problem. If you or your mechanic has ever read the DTCs (Diagnostic Trouble Codes) on your vehicle, they are using OBD-II.
Any vehicle manufacture from 1996 or later is required by law to have the OBD-II computer system. You can access this system through the Data Link Connector (DLC). It is a 16 pin connector that can tell you which protocol your car communicates with, depending on which pins are populated in it.
In cars, it will be located under the dash, near the driver's seat, or in the vicinity of the ashtray -- somewhere easily accessible from the driver's seat without the use of tools to access it (i.e., you don't need a screw driver to pull off a panel to get to it).
The ECU can refer to a single module or a collection of modules. These are the brains of the vehicle. They monitor and control many functions of the car. These can be standard from the manufacturer, reprogrammable, or have the capability of being daisy-chained for multiple features. Tuning features on the ECU can allow the user to make the engine function at various performance levels and various economy levels. On new cars, these are all typically microcontrollers.
These codes are used to describe where an issue is occurring on the vehicle and are defined by SAE (you can find the whole spec here for a cost). These codes, can either be generic or unique to the vehicle manufacturer.
These are the actual meat and potatoes of the information you can pull off of an OBD-II system. The PIDs are the definitions of the different parameters you could be interested in checking out. These are similar to the third digit in the DTCs.
Not all PIDs are supported on all protocols, and there can be several unique, custom PIDs for each manufacturer. Unfortunately, these also are not generally published, so you may need to do a lot of hunting and/or reverse engineering to determine to which system each PID relates.
There are five different communication protocols available under the OBD-II spec. Like so many things, manufacturers tend to have their preferences and think their protocol is best, hence the variation. Here's a quick overview of each and a description of the pins used on the DLC for each.
This protocol has been mandated in all vehicles sold in the US from 2008 and later. However, if you have a European car from 2003 or later, the vehicle may have CAN. It's a two-wire communication method and can run at up to 1Mbps.
While these protocols are great for collecting data from your vehicle, it can be a real pain when prototyping to have to sit with a computer, various electronics, and cables running all over the place in the front of your car. Luckily, there are many simulators out there that allow basic prototyping and testing of OBD-II systems.
Several different programming options are available for configuring the simulator. Check out the programming manual for more information. The version we currently have has firmware compatible with several different OBD-II protocols, which will vary depending on what you order.
If you then need to send data from your simulator to a device such as the SparkFun OBD-II UART Board or CAN-Bus Shield for testing, you can use the transmit command SOMT , . For example, if we want to send the command that the engine fuel pressure is 100kPa, we would send SOMT followed by the Parameter ID (PID) for fuel pressure, which is 0A, and follow that with the hex value for 100 (64) in this case.
If we initially leave the connection floating (by forgetting to tighten the anchor screws on the DB9 connector) in order to simulate a connection problem, we receive the CAN ERROR message the first time we send the command. On this simulator, that means that there is a problem between the simulator and our CAN reader. Once we fix the connection however, the simulator is able to send the data, and tells us exactly what it transmitted. Pretty neat!
I am working on reverse engineering an instrument cluster from a newer truck and currently wrote a program to test out the hex signals and make sure I have the correct CAN ID and Byte Information causing the tach and speedo to move with a potentiometer. and I have an LCD as well in order to make sure I am sending the information I think I am TO the cluster.
I have an elecfreaks can bus shield I am using for a current project,
the vehicle that the obd2 port plugs into is using SAE J1850 OBD2 protocol. will the PID's be the same for the 1850 in order to pull speedometer and tachometer data from this?
Please read the first post in any forum entitled how to use this forum.
,148850.0.html then look down to item #7 about how to post your code.
It will be formatted in a scrolling window that makes it easier to read.
Now I've got the code updated, running with a potentiometer controlling values for the HEX as well as a second potentiometer controlling the CAN ID that the values are sent to, terminated both sides of the CAN BUS with 120 ohms and nothing on the cluster is moving at all.. any advice from a can bus veteran?
in 1996 a federal law took effect requiring most new consumer vehicles in the US to have standards-based On Board Diagnostics, called OBD-II. the OBD regulations were put in place by the EPA for monitoring emissions related components, but the systems have evolved to be much more capable.
the good thing about OBD-II was it defined a limited set of network types that a car maker could implement for the emissions related diagnostics. this meant that tools to interface with those networks could also become standardized and inexpensive. called scan-tools, they come in full-featured versions with built-in software/display/buttons, and dumb versions that must be connected to a PC/Mac/tablet/phone to be useful.
the challenge: OBD-II standards only apply to the emissions related portions of a vehicle bus. other systems often operate on an entirely different bus which may or may not use the same protocol as the OBD-II diagnostic bus. even worse, the non-emissions-related bus data is proprietary manufacturer info that can vary for each make/model/year.
the good news is that for simplicity and cost-savings, most manufactures only implement a single network type during certain year ranges. since they have to use one of the standard OBD-II protocols for the diagnostic bus, they might as well use the same protocol (or a slight variation) on the other buses. this is why we are sometimes able to use a scan-tool to interface with a non-OBD bus.
vehicles usually have at least 2 buses, the main diagnostic bus and an interior or comfort bus. the diagnostic bus often has access to all the drivetrain components as well as the OBD-II emissions stuff. the simplest vehicles to hack are the ones where all the buses use the exact same protocol and all relay messages to each other. some vehicles may have the secondary buses connected to the diagnostic bus through a gateway that may only relay information when queried with the correct command. other vehicles use the same overal protocol on all buses, but different speeds.
Sir : [ -vehicle-bus-cheap-easy-part-1/]
on April 18th, 2013 you wrote you wanted to read the turn signals thru obd / can .
did you succeed ?
can the signals be activated on / off thru obd / can ?
if so , how ?
Hai Bruce, Are you still on your Project, I am too Wondering on the same idea. Well u got any progress? I am wondering if anyone tell me if there is a Pin in the OBD II port that will tell me when the Ignition of the vehicle is ON. I mean any pratical example? Regards success Bruce and thanks all
I have started my own project after having troubles working with windows obd software and also with pyobd.
The program has barely reached Version 0.0000001 but is able to get standard OBD Information.
A great guide, thank you! I am able to communicate with AT commands with my elm mini, but I cant get ATMA to work. Nothing is coming back? Every other command seems to work such as ATI and so on. OK i printed for every AT command I send. What am I doing wrong?!? Please give me some clues :-)
First of all, thank you! You did a great job on writing up the process you used. I am working on hacking the volt and but I cannot seem to connect to the ELM327. I have both the ScanTool ElmScan 5 and the BAFX Products ELM 327 Bluetooth OBD2 scan tool. I have tried both and cannot connect to the adapter. Hyperterminal sees COM3 and COM4 for the adapters but I cannot connect. Likewise with the slick USB serial app. I am sure I am missing something basic. Any thoughts?
figure out what platform you are most comfortable writing code for (Android, iOS, linux, Arduino or other low level MCU) and then look into what specific hardware interfaces can be had for that platform. i personally would use an Android tablet or phone with a BT OBD2 adapter for some stats and a IOIO-OTG board to work with the custom electronics interfaces. my second choice would be a RaspberryPi or similar single board computer and some misc breakout boards that talk over I2C.
4a15465005