OBD Problem Vehicles

This page contains a list of vehicles that are known to be non-compliant with OBD-II in one way or another. Typically, the vehicles have problems initiating or maintaining a connection, or incorrect data formats. Each listing specifies which vehicles are affected, provides a summary of the problems, and suggests known workarounds.

2001 Nissan Altima
2001 Nissan Sentra
2001 Nissan Xterra

Problem 1:

The ECU goes to sleep (uninitialized state) immediately after receiving any unsupported request. The problem is compounded by the fact that some ECUs indicate that certain TIDs are supported, while sending a request for any of these TIDs will immediately put the ECU to sleep.

Example:

>0900
49 00 01 3C 00 00 00

ECU reported that TIDs $03, $04, $05, and $06 are supported. While TIDs $03 and $05 are in fact supported, an attempt to request TIDs $04 and $06 return a “NO DATA” response. Any subsequent requests will also return “NO DATA” until the bus is reinitialized:

>0903
49 03 08

>0904
NO DATA

>0903
NO DATA

>atpc
OK

>0903
BUS INIT: ...OK
49 03 08

Workaround:

The software must avoid requesting unsupported requests. If a “NO DATA” response is received, the software should send a “0100″ request to verify that the connection is still active, and reinitialize the connection if a “NO DATA” response is received. The software must then “remember” not to send the unsupported request.

Problem 2:

The ECU strictly enforces intermessage time between the end of all vehicle-sourced responses and the start of the next diagnostic tester request (P3, 55 ms). If P3 is violated, the ECU will immediately go to sleep, and would need to be reinitialized for communication to continue. OBD interfaces which use the “adaptive timing” algorithm to achieve higher refresh rates (such as OBDLink), may violate P3 and lose connection to the vehicle.

Example:

>01001
41 00 BE 1F B8 11

>
41 00 BE 1F B8 11

>
41 00 BE 1F B8 11

>
NO DATA

>
NO DATA

In the example above, the first command specifies that only one response is expected. It is then repeated by sending “newline” characters at the command prompt. Eventually, a request is sent too soon after receiving the response, and the ECU goes to sleep.

Workaround 1:

The software must ensure that a request is sent no sooner than 55 ms (P3) after receiving a response from the vehicle. If connection is lost (“0100″ returns “NO DATA”), the software should increase the intermessage time, and attempt to reinitialize the bus.

Note: keep in mind that the software receives the message some time after the ECU finished transmitting it. It takes time for the OBD interface to process and retransmit the message, and the operating system may introduce additional delays. For optimal performance, set the delay to zero, and increment it until the connection can be reliably maintained.

Workaround 2:

Disable adaptive timing, and set the “NO DATA” timeout to $0F (~60 ms). This can be done as part of the OBD interface startup sequence by the software:

>ATAT 0
OK

>ATST 0F
OK

The changes can be made permanent, by saving them in non-volatile memory (remember to reset the device for the settings to take effect):

>ATPP 03 SV 0F
OK

>ATPP 04 SV 00
OK

>ATPP 03 ON
OK

>ATPP 04 ON
OK

>ATZ