Optimizing Scan Rate
I have written an application running on an embedded system platform that connects to a serial-based Scan Tool. The vehicle I am testing against is a BMW X3. My goal is to maximize the number of PIDs I can read in a 1s period. The initialization sequence of my application sends the following to my ELM327 Scan Tool:
"ATTP5" // set protocol to ISO 14230 KWP
"AT ST32" // set timeout to 200ms
"AT AT1" // Use adaptive timing option 1
"AT BRD 23" // Set baud rate to 115200
I can successfully poll PIDs at a rate of 1 per second if I use the above settings. Ideally, I need to get 10-20. Technically, is this possible? My application waits 50ms for a reply to each PID request in order meet the goal of 20 PIDs in 1s. I have not been able to to better than 4-5 PIDs in 1s. Is there something I can do to improve the performance? I get the feeling that it is a limitation of the bus on my vehicle. However, when I run a ScanTool software package with my ScanTool dongle on my vehicle I am almost certain it is polling better than 5 PIDs/second.
I should note here that I get better performance on a Ford vehicle (somewhere in the order of 15 PIDs/second).
Thanks in advance for your feedback.
I'd suggest using the elm optimisation of adding one byte on the end of your requests saying how much data you expect in response. That almost doubles the scanrate I see on my getups.
Also, upgrading the baudrate between your computer and your scantool can have highly positive effects.
Both of these optimisations are covered in detail in the ELM327 DataSheet.
For what it's worth, I'm seeing data rates upward of 40-50 PID/s on both my OBDLink and my OBDPro right now, enabling just those two large-scale optimisations. [The rate is probably actually higher - I'm just seeing 40-50 PID/s arriving in my logfile, but my app is single-threaded, so in the time it spends burning those PIDs to the log and looking up the GPS position might translate to another couple PIDs].
Oh. I see you're already upping the baudrate - nvm me. [are you sure it's working, by the way? There's a lot more to making the upgrade fully work than just "ATBRDXX"]
Oh. And if that's all your app is doing right now, you can trim out a bunch of serial comms cruft:
ATS0 - no spaces
ATL0 - no linefeed [just cr]
ATE0 - Don't echo what you send
Probably others that I'm not thinking of right now, too.
Thanks for your prompt reply. Yes, I was able to verify the 115200 baud rate. I confirmed it by polling for one PID every 1 second at that rate. My next step was to keep increasing the number of PIDs. Eventually, I reached a limit of 5 PIDs.
To clarify, would I just, for example, send:
"01 0C 01"
to get my RPM at a highly optimized rate?
It's covered in the data sheet in more detail, but ... almost. RPM is two bytes, and I guess I meant "nibble" at the end of the request [or byte, from the serial port's perspective]. So what you want for RPM would be:
01 0C 2
[you can strip spaces out there, too: 010C2]
I will try that first thing in the morning. Would you expect your observed results on a European vehicle that use the IS0-based protocols?
Gary is right disable space caracters, line feed, etc.. to expect get PID faster. But for an ISO 14230 protocol based vehicule don't expect to get more than 5 or 6 PIDs per seconds. Even your baudrate is set to 115200 the ISO baudrate is still 10400 baud so...
The ISO15765 protocol (CAN) is quite faster. I 've got 10/11 Pids per second futhermore the CAN protocol allows to ask several PIDs per frame
in the example you ask rpm and vehicule speed at the same time. So you can reach 20 PIDs per second.
I know you can ask more than 2 PIDs in the same frame but I can't say you that is the maximun.. Using this method, you will have to decipher multi-frame response
I'm working on the topics too.. Please give us aware of the result of your test. I'm gonna do some too..
Thank you, remus08. Your post got me into thinking about something:
The only way I knew what protocol my vehicle was running was by sniffing the serial data from a PC-based scan tool software package that I was using. The one thing I couldn't decipher was how it was able to determine that my protocol was ISO 14230. My application needs to be agnostic and work for any vehicle. Is there a way to programatically determine the fastest protocol that a vehicle is using? I understand that the "AT SP 0" will automatically select the protocol. Is it safe to assume that this command will find the fastest protocol a vehicle is capable of?
I will post my results of the best scan rate that I can get on my BMW (ISO 14230 - based vehicle) as soon my car returns home :-)
Thank you very much to all for your help!
In all honesty, you probably want to leave ATSP well alone
ATDP and ATDPN are how you find out what protocol the ELM is using to talk to your car.