Problem Vehicles

In this section we have attempted to maintain a list of vehicles that at one time or another had connection problems with OBD 2007.

Each vehicle in this list has required code changes to OBD 2007 or a fix from the vehicle manufacturer to accommodate the problem. Any vehicle in the list that is marked in red is not compatible with OBD 2007. In all the instances listed below, the vehicle failed a particular part of the OBDII specification. Please note this list only applies to OBDII compliant vehicles.

2001 Nissan Xterra 2001 - Canada

This vehicle fails to respond to a standard enquiry about the list of support Tids for Oxygen sensors. When the command is sent to the ECU, the ECU correctly reports the standard NO DATA response for a vehicle not supporting this command, however as a consequence of this the ECU then locks up and then the ECU will reported NO DATA even for commands that it does support. This is a typical example of a manufacturer not quite getting the implementation of the OBDII specification right. OBD 2007 now has a special switch used at start up to bypass the standard command. This switch should only be used for this vehicle. Please contact for the details of how to engage the switch.

2006 Pontiac G6 GT 3.5L SFI Engine - USA

This vehicle failed to connect on the very first command because GM where not adhering to ISO15765-4, using variable data length messages rather than the prescribed 8 byte ones. The problem was rectified by GM under warranty with a firmware upgrade. OBD 2007 then immediately connected and performed normally.

2000 Mazda Protégé - USA

We recently had a user experience a runtime error which related to Pid 0x03 Fuel Status. The OBDII specification stipulates that the vehicle’s ECU shall respond with 2 bytes of information for both Fuel Status 1 and Fuel Status 2, even if Fuel Status 2 is unused, as is the case with most 4 cylinder vehicles. This particular vehicle, a 2000 Mazda Protégé only responded with 1 byte of information, thus causing a runtime error. As is often the case with early model OBDII vehicles, the Mazda was not strictly OBDII compliant. We have now rectified this problem, by providing the missing information to prevent the runtime error.

Volvo XC90 D5 - Australia

While testing this vehicle we found a minor bug causing a runtime error with OBD 2007 on pids 0x24 through pids 0x2B, which are wide range Oxygen sensors that have recently been introduced on modern diesel engines. These pids are meant to return a response of 4 bytes as per SAE J1979 and ISO 15031-5. However this particular Volvo only returns a 2 byte response. We have rectified this anomaly by supplying the missing bytes with harmless values of zero. When Volvo does correct the problem, our values will be automatically replaced by their values. Please note this bug does not affect any petrol engines which do correctly return a 4 byte response.

2001 Nissan Sentra - USA

This vehicles behaviour is identical to the Nissan Xterra mentioned above. It would seem that these Nissan engines share the same fault. Presently this vehicle is still being tested using the special switch designed for the Xterra. As soon as we have completed the testing the entry will be updated.

We can now confirm that the same fix for the Xterra above works with the Sentra as well.

2004 Renault Espace Mk 4, 2 litre Petrol - United Kingdom

This vehicle is an OBDII compliant, ISO 14230-4 vehicle. However it fails OBDII compliance on a number of standard OBDII services.

The most obvious failure is Service 07 - Pending DTCs. This vehicle always returns a response of $7F, $07, $11 which is a service not supported response for service 07. Any $7F response is known as a negative response, the remaining two bytes provide the details. As all OBDII compliant vehicles are required to support service 07, this vehicle therefore fails OBDII compliance.

It also responds with similar responses to services 06, 08 and 09.

It appears to support both engine and transmission ECUs, but invariably responses from the tranmission ECU are either negative responses or responses that vary markedly from the same pid value from the engine ECU. The most obvious example being pid 0x04 Engine Load.

Our conclusion is that Renault, did not complete the implemenation of OBDII compliance with this vehicle. It is quite likely that the problem has been rectified with a firmware upgrade of the ECUs. When we receive confirmation from the owner of the vehicle of the ECU upgrade, we will update this entry.

Land Rover Discovery 3 TDV6 Diesel - Australia

While this engine was being tested on an engine dynamometer, we found a number of unusual OBDII compliance issues. The TDV6 engine is running the ISO 15765-4 protocol (CAN 29 bit/500K). The first problem was that all the pid values returned were either zero or absolute minimum values with the ignition on, but engine off (KOEO).

We then found a pid value problem which caused a runtime error in OBD 2007. Pid 0x43 Absolute Load Value is a two byte value, but the Discovery was returning a single byte which consequently caused a runtime error in OBD 2007.

We have rectified this oversight by Land Rover by testing for the missing byte and then supplying the missing byte with a harmless value of zero. This fixed the run time error and the Absolute Load value of zero was returned with engine off, which is the normal value of Absolute Load with the engine off.

We then confirmed that the behaviour of absolute minimum values for all pids in the KOEO position was not just related to the engine on the dynamometer. The same behaviour was true when we tested another Land Rover Discovery on the road.

Fortunately when the engine starts, both engines then gave correct values for all pids, including pid 0x43. We presume that Land Rover will rectify this problem with a firmware upgrade at some point in the future.

2003 Dodge 2500 Van 5.2 litre V8 – USA

This vehicle is an OBDII compliant vehicle using the ISO -9141-2 protocol. It behaves similarly to the two Nissans mentioned above.

The Dodge correctly responds to the standard query re a list of supported Tids for the Oxygen sensors. A vehicle which supports O2 sensors will respond with a list of Tids. A vehicle that doesn’t support service $05 should respond with a NO DATA response.

This vehicle responds with the standard NO DATA response for service $05. However at the same time it locks up the ECU/scan tool communication, so that any further supported commands that are sent to the scan tool will also result in a NO DATA response, effectively stopping all communication between the scan tool and the ECU.

This is just another example of the manufacturer not getting the OBDII implementation correct. If we use the same switch at start up that was developed for the Nissans, the vehicle then correctly responds to all other OBDII services. Please contact for details of how to engage the switch.

We suggest contacting a Dodge dealer to check whether there has been any firmware updates issued for the ECU as we suspect the problem would have been corrected with a firmware upgrade.

2007 Tata Safari 2.2 litre - India

This vehicle is an ISO 14230-4 protocol vehicle made in India, which is also exported to EU countries such as Spain and Italy. We don’t believe that India has regulated for OBDII compliance, but because the vehicle is exported to EU countries it should be OBDII compliant. From the logs we have seen, this vehicle appears to support all OBDII services other than Service $06 - On Board Monitoring.

It is unusual for an ISO 14230-4 vehicle not to support service $06. The correct response to the command 0600 for an ISO 14230-4 vehicle which doesn’t support service $06 is a 7F response, known as a negative response. However the Tata responds with NO DATA.

Unfortunately like some of the above vehicles, this causes the ECU/scan tool communication to lock up. All subsequent commands sent, then also respond with a NO DATA response, whether they are supported commands or not.

At this stage we haven’t developed a workaround for this service $06 problem, but suspect we could do something similar to what we developed for the Nissans and Dodge above. Again the conclusion is that this manufacturer has failed to implement OBDII compliance correctly and that a firmware upgrade would correct the problem.

A solution to this problem with the Tata Safari was introduced in build