| |||||||||||
ELM OBD2 Data Sampling RateELM 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 error rates. 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. 
|
| ||||||||||
|
|
|||||||||||
