The goal of this blog post is to clear up what we believe to be a common misconception in the tuning industry regarding OBD (On Board Diagnostics) PIDs and how to use them, along with the associated Pros and Cons.

Why the OBD2 name? OBD stands for On Board Diagnostics and this is the second iteration of the system the EPA has forced upon major OEMs. The original thought was that as cars became more complicated with electronics, the average "at home" mechanic needed to be able to diagnose and fix their own cars -- thus the standard came to life.

As part of the standard, Pins 6 and 14 on the trapezoid OBD2 are universally used for OBD2 CAN. Pin 6 is CAN High and Pin 14 is CAN Low.

So what can we use OBD2 for? Well... lots of things, but in this blog post we will focus on the fact that we can read live data from certain electronic units. As part of the OBD2 standard, the EPA mandated that ECUs implement a request and response protocol so that things like scan tools can obtain information. We can use the Kaizen Relay Control Module and this (link below) well published request and response system to obtain universally available information from any car! Link: https://en.wikipedia.org/wiki/OBD-II_PIDs

So what information is available? There's a lot of good stuff available that we can use to trigger aftermarket devices. (see a pretty complete list here: https://en.wikipedia.org/wiki/OBD-II_PIDs#Service_01_-_Show_current_data) The most common ones are Coolant Temp for fans, or Throttle Position for auxiliary fuel pumps but many more are available if we use the Control Module to “request” them. 

So what’s the catch? While the EPA has mandated the OEM ECUs respond to these messages, they did not mandate whether the data is available. So for example, you may request Engine Speed or Vehicle Speed from every car, and it will respond with valid information, 4200 RPM or 69 MPH. But for other 'more specific' messages like "Intake Manifold Pressure" or "Fuel Rail Pressure", the ECUs will always respond but it may only be an acknowledgment to the request. The information itself may be blank if they have chosen to not share this data with the public. Luckily, it is usually pretty easy to check if the information is valid or just an acknowledgment to the request using a little bit of common sense. If the ECU chooses to not share this data it is will usually respond to the message with a maxed out figure. For example, if Vehicle Speed is responded to, but not accurately shared, it will respond with a maxed out message of 255 KPH, which is 158 MPH. For those of you familiar with GM GenIV ECUs and HP Tuners, you would recognize this 158 MPH signal as an error. Lastly using the common sense approach, your car is not likely going 158 MPH.  

Some Cautions:
Firstly, we don't quite know which PIDs the vehicle will respond to with valid information  - as this is different depending on the vehicle. So while we can write a program to poll the ECU, it may not yield good information depending on the vehicle.

Secondly, the polling system implemented by the ECUs is designed to do one request and response at a time making this a pretty slow system for reliable information. If you want to poll 3-4 items, then you'll have to do it in round robin fashion, as only one signal can be requested at once.

Thirdly, since this is the same protocol that's used by all 'aftermarket' devices, only one can be connected to the ECU at once.. So if the Kaizen Relay Control Module is making 100ms polls to the ECU, then a scan tool will not connect. And vice versa, if a scan tool is currently requesting information from the car, then the Kaizen Relay Control Module will not be able to connect with the ECU.

Because of these three reasons, reverse engineering the OEM CANbus is usually the better option to obtain the information required for a project as it will always be present and will not interfere with any other devices on the CAN network.

To summarize:

The main difference between OBD2 Standard CAN and raw OEM CAN is that the OBD2 standard requires us to “request” OBD2 data, and only one device can request data at a time. This means it won’t work alongside a programmer or code reader.

By contrast, OEM CAN is constantly broadcasting information and the Kaizen Relay Control Module can be a passive node that “listens” for the message that it wants. OEM CAN will often include things like all four wheel speeds independently, where OBD2 Standard CAN will only include a generic “Vehicle Speed” channel. The OBD2 port can be an access point for both OEM CAN data & OBD2 Standard CAN data in many vehicles, but some vehicles have a CAN Gateway that limits what messages make it to the OBD2 Port.

One other valid point is the speed of the messages: OEM CAN is likely to broadcast information faster than the request/response method. Using the request/response method and OBD2 Standard CAN you can request messages as fast as you want but the ECU may choose to wait before responding.