Version 1.3 of the ELM327 introduced a way to speed up the retrieval of information, if you know how many responses to expect. By telling the ELM327 how many lines of data to receive, it knows when it is finished, so does not have to go through the final timeout, waiting for data that is not coming. Simply add a single hex digit after the OBD request bytes – the value of the digit providing the maximum number of responses to obtain, and the ELM327 does the rest. For example, if you know that there is only one response coming for the engine temperature request that was previously discussed, you can now send:
>01 05 1
and the ELM327 will return immediately after obtaining only one response. This may save a considerable amount of time, as the default time for the AT ST timer is 200 msec. (The ELM327 still sets the timer after sending the request, but that is only in case the single response does not arrive.)
Some protocols (like J1850 PWM) require an acknowledgement from the ELM327 for every message sent. If you provide a number for the responses that is too small, the ELM327 will return to the prompt too early, and you may cause bus
congestion while the ECU tries several times to resend the messages that were not acknowledged. For this reason, you must know how many responses to expect before using this feature.
As an example, consider a request for the vehicle identification number (VIN). This number is 17 digits long, and typically takes 5 lines of data to be represented. It is obtained with mode 09, PID 02, and should be requested with:
>09 02
or with:
>09 02 5
if you know that there are five lines of data coming. If you should mistakenly send 09 02 1, you might cause problems.
This ability to specify the number of responses was really added with the programmer in mind. An interface routine can determine how many responses to expect for a specific request, and then store that information for use with subsequent requests. That number can then be added to the requests and the response time can be optimized. For an individual trying to obtain a few trouble codes, the savings are not really worth the trouble, and it’s easiest to use the old way to make a request.
We offer one additional warning when trying to optimize the speed at which you obtain information from vehicles. Prior to the APR2002 release of the J1979 standard, sending J1850 requests more frequently than every 100 msec was forbidden. With the APR2002 update, scan tools were allowed to send the next request without delay if it was determined that all the responses to the previous request had been received. Vehicles made prior to this time may not be able to tolerate requests at too fast a rate, so use caution with them.