Thread: Optimizing Scan Rate

Originally Posted by remus08

Yes, it is the best way to stay "agnostic". Using parameters 0 for AT SP command let the charge to the ELM to fid the protocol automaticaly. The automatic research take for time for the initialization. I insist only on the initialization. I guess it's advice to wait 14s before sent the first OBD command.

Thanks, remus08. I changed my application to do a discovery of the protocol then send "0100". After that I wait 14s for the initialization to complete.

Originally Posted by remus08

Could you please let us know on what you are working.

I am trying to get a better grasp of some embedded system platforms that I am working with. I thought that interfacing a hardware platform with a Scan Tool would give some good technical practice with serial I/O and working with a Real-Time Operating System.

I sincerely appreciate everyone's feedback. As promised I wanted to let the readers of this thread know that I can only get a maximum of 5 PIDs on a ISO 14230-based car.

Originally Posted by remus08

Yes, it is the best way to stay "agnostic". Using parameters 0 for AT SP command let the charge to the ELM to fid the protocol automaticaly. The automatic research take for time for the initialization. I insist only on the initialization. I guess it's advice to wait 14s before sent the first OBD command.

Unfortunately, the built-in ELM327 protocol detection algorithm is not 100% reliable. In fact, on some vehicles it will fail 100% of the time.

For example, some cars support ISO 9141 and KWP, but only ISO 9141 reports OBD-2 data. Since ELM327 tries KWP before ISO, it will connect on KWP but you won't get any useful data.

Another example is 2000+ Chevy trucks. If you hard-set the protocol to VPW, ELM327 will connect just fine. If you don't, it will try PWM first, and cause the ECU to go deaf for almost a second -- which means it will not hear your VPW request either.

Doing protocol detection "manually" is harder, but if you do it right it is far more reliable. An added benefit is that you can display the progress to the user as you try each protocol.

Vitaliy

OK, I didn't know that. So you advice to test each protocol with the ATSPx command and try to get the response of 0100.. and by the same time to inform the user on which protocol you're trying... This way will be more reliable than the automatic research (ATSP0).

Thanks Vitaliy for sharing your experience

Originally Posted by remus08

OK, I didn't know that. So you advice to test each protocol with the ATSPx command and try to get the response of 0100.. and by the same time to inform the user on which protocol you're trying... This way will be more reliable than the automatic research (ATSP0).

Correct, and most professional software does it this way. You also need generous delays b/w PWM & VPW, and ISO and KWP. Try CAN last.

Vitaliy

To come back to the original topic subject: Optimizing Scan Rate
Is someone already trying the command 010C1 to get the engine rpm more quickly?

From ELM327 datasheet (p. 50)

Instead of sending 01 00 for the above request, the ELM327 will now also accept 01 00 2 This tells the IC to send 01 00, then return immediately after receiving 2 responses. It can not speed up a slow ECU, but it will eliminate the final delay...

How much time can I expect to win? on older protocol like ISO14230?

Much time.
ELM waits after last packet to next packet in default 200ms !
So every packet transaction you currently spend 200ms blank.
So your currently time (without 1 on the end) minus 200ms is the outcome.
It almost does not care on which protocol, I think.

Sorry to bump the old thread up.
Recently, I am trying most what OP tried to do: read the RPM and other mode 01 sensor as fast as I can. Actually what I am developing is a SW based Tachometer.
The protocol of the car is ISO 9141-2 (should be 10.4K baud), perhaps the bottleneck is here?
Here is what I have tried...
The OBDII dongle is an ELM327 based one with USB interface.
Besides to set ECHO OFF (ATE0), Linefeed off (ATL0), also fine tune the timeout (ATST 0B) to 44ms (it start to loss packet if below than that), but the round-trip time (from sending the command out till receive response form ELM327) for 010C or 010D command still take about 250ms or 4 scan per second.
With this scan rate, the gauge won't act smoothly, I would expect to 10 scan per second.
Is there anything I can do to burst the scan rate up?

Thanks!

Do you know about ODD number sended in your data/command to ELM ?
If you send 010c, ecu response, for example after 50ms, and then ELM waits for 200ms for next packet. After 250ms you get answer in PC and prompt ">". Then you can send next command.
But: if you send 010c1, ELM receives FIRST packet (after 50ms) from ECU and imediatelly ends with receiving. So you can after ?51?ms send second command.

Unfortunatelly, my ELM327 is version 1.2 and this feature (response count) is only supported in 1.3a. But I have modified the response timeout from 200 ms to 44 ms (by "AT ST 0B" command) but only shrink the overall tround-trip time from 300 ms to 250 ms. So as my understanding, even I got a v1.3 ELM327, and use response count feature to eliminate the final delay, perhaps the best I can get still around 200 ms?
Is that a limitation of ISO 9141-2, or is there other thing I can do to improve scan rate?