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