What is OBD2? OBD2 stands for On Board Diagnostics version 2. The US government mandated that all vehicles sold in the US beginning with 1996 model year comply with a minimum set of diagnostic functions. These functions were primarily intended for vehicle service, inspection and emissions testing. However, the specification allows for real-time monitoring of many vehicle sensors. This real-time monitoring comes in handy when tuning a high performance vehicle and also when racing to inform the driver of engine conditions.

But there are some limitations to the OBD2 functionality. First, manufacturers are not required to output all sensor data. Only a minimum set of data. This means that a vehicle may not support MAP data, which would be needed to monitor boost. Second, depending on the protocol used, the specification requires a certain amount of time after a message is received before data can be requested again. The reason this is an issue is because the ECU does not stream data. Instead, each sensor data has to be requested. When the ECU receives a request, it then outputs data for the sensor requested at the time it was requested. When the DGauge displays a single sensor, the update rate is approximately 8 times per second (ISO9141 and ISO14230). When displaying 2 sensors, the update rate is approximately 4 times per second. For 3 sensors the update rate is approximately 3 times per second. For this reason, it may not be advantageous to display more than 3 sensors at a time. There are some OBD2 dataloggers on the market that claim as little as 1ms accuracy. This might sound good, but it's misleading because the absolute fastest update rate that can be achieved using the ISO9141 protocol, for example, is approximately 120ms, which is when requesting only 1 sensor data. The CAN protocol is considerably faster, but must share bandwidth with other modules on the network. In ideal conditions, the update rate for CAN equipped vehicles could be 15 times per second.

Up until MY2008, the OBD2 specification did not require a manufacturer to use a specific communication protocol, so long as it was one of the 5 listed below. Most Asian and European vehicles used the ISO9141 protocol, which the DGauge is compatible with. Ford, GM and late model Chrysler vehicles used the J1850 protocol. Compatibility with this protocol is not currently planned. Starting with MY2008, new vehicle models must use the CAN protocol. Compatibility with this protocol is supported by the DGauge.

The OBD2 diagnostic port connector is usually in the drivers footwell and is powered. So, there is only 1 cable to hook up. Installation is nothing more than plugging in the data link cable to the OBD2 connector.

Please note that when the vehicle ECU has stored DTC's, it may not output current sensor values. If you suspect that data being displayed is incorrect, then make sure all DTC's have been cleared. It is impossible for our OBD2 gauges to show incorrect data as there is error checking as part of the communication protocol. The data values displayed on the screen are the values that the vehicle ECU is sending to the OBD2 gauge.

There are a total of 5 protocols in use with 2 "flavors" of CAN:

Beginning with model year 2008, all vehicles sold in the United States must use the ISO15765 protocol for diagnostics. Some manufacturers started to make the switch to this protocol as early as MY2002. Here is a handy chart showing protocol usage since 1996 for most vehicle makes and models.

A partial list of DTC's can be found on the codes page.