Using KWP2000 messages without address information, i.e. the use of a one-byte header is most often found in the diagnosis of various blocks of Nissan vehicles.

The method consists in sending the part of the data with the standard 3-byte header, the rest data is sent as usual, the ECU response is read from the ELM327 debug buffer.

For example, try to send the following message with the KWP2000 one-byte header to the Nissan ECU:

05 22 11 00 04 01 3D

here [05] is a one-byte header, [22 11 00 04 01] is data, [3D] is a checksum.

ELM327 does not supports setting a one-byte header, only a 3-byte header (with address information). Therefore, the header is set as [05 22 11], the data bytes now [00 04 01], the checksum ELM327 generates automatically.

The ECU's response to such a request will be the message 07 62 11 00 E4 01 03 41 A3, but the ELM327 will not display this data ('NO DATA'), because if considering this data as a message with a three-byte header [07 62 11], then it contains incorrect address information. Therefore, the data must be retrieved from the ELM327 debug buffer with the ATBD command.

You can see an example of using this method from the data exchange log between DAP4CS and ELM327.

After the KWP2000 fast initialization procedure, protocol 3 (ISO 9141) must be set.




Request / response:



09 07 62 11 00 E4 01 03 41 A3 00 00 00 


The limitation of this method is the size of the ELM327 debug buffer, which contains a maximum of 12 bytes. But for Nissan ECUs, parameters are requested not in groups, but by individual parameters, so the ECU's response to a request for a specific parameter does not exceed 12 bytes (message size). Even if the ECU response is 13 bytes and the last byte of the checksum is not displayed (because there is no space in the buffer), it can be calculated by software, so messages up to 13 bytes long can be received from Nissan ECUs using this method.

When citing this information, a link to the DAP4CS website is required.