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 firstname.lastname@example.org 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
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
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
email@example.com 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
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 220.127.116.11.