ELM OBD2 Data Sampling Rate
For more OBD2 technical information please visit our OBD2 Technical index page.
ELM 32x chipset converters with default settings sample data much slower than the 10 per second (100ms)
OBD2 specification. Our testing with the wOBD software indicates about 3 or 4 data
elements per second. Although this is sufficient for most purposes, we had a few applications in mind that required
more data samples per second, so we set about trying to speed up the sampling.
The ATST command (Set Timeout)
The ATST command is documented in the data sheets, but is easy to misunderstand. The data sheet states
that it controls the amount of time that the converter will wait before issuing a NO DATA response. What is not
apparent is that the converter will wait that amount of time even after it has received data, perhaps allowing
for multiple responses. The command accepts values between 08H and FFH, each increment worth an additional 4ms.
The default value is 32H (50 decimal), which is about 200ms, which allowing for some time to pass sending commands,
sets the maximum at about 4 data samples per second.
Setting this value too low will result in excessive errors reported back, so the optimum setting varies per vehicle.
We do find that the default setting is very conservative, and have not found any vehicles that needed 200ms to respond.
Most were pretty happy around 100ms, so we commonly set ATST at 19H (25 decimal). This effectively doubles
the sampling rate, so we were able to get 6 to 8 samples per second even on older vehicles with only minimal rise in
The ATPD command (Packed Data)
The ATPD command was one of the first things we tried, and under certain circumstances can yield better sampling rates,
but is also the most work to implement. A typical unpacked response is 40H+mode, pid, data, which is about 11 bytes long
(assuming the data returned is two bytes) when all the spaces and linefeeds are added up. In packed mode, this same response
is 5 bytes. At the communication rate of 9600 bps (theoretically 9.6 bits per millisecond, we will assume each byte takes a
little under a millisecond to keep it simple) we save a whopping 7ms per response. (5ms for the reduced data, and no cr/lf)
It is in some ways easier to code with the response length included in the response, (rather than wait for the linefeeds to
signify end of response) but it terms of sampling rate this command has little impact. Perhaps in some applications (such
as listening to everthing on the bus with an ATMA command) where every millisecond counts this would be useful. Or if the
responses were long and mostly double digit there might be a significant cumulative savings.
The ATE0 command (Echo off)
Following the above logic, there isn't much to save by turning the echo off. We did it anyhow in our software since it was
easier to not have to peel the query away from the response. Version 2.0 ELM allows for commands upto 7 bytes (14 digits),
which with spaces embedded, could lead to as much as 21 ms spent in regurgitation.
Our savings could range from 3ms to 20ms per response, but is more likely around 6ms.
The ATL0 command (Linefeeds off)
For the truly tight, that extra millisecond for the completely superfluous linefeed after the carriage return is a must.
Intended to make terminal display nice, there is no reason for it in your super efficient program. Note that no linefeeds
or carriage returns are present when using the ATPD packed mode, which you would be of course already be using.