Is it possible to get PID commands return data faster? about ltsupportautomotive HOT 15 CLOSED

In general: No. With OBD2-commands, the bottleneck is the OBD2 adapter waiting for more responses.

That said, there are ways to manipulate these timings. You can try adjusting the init sequence with commands like:

• ATAT0 (disable adaptive timing, use hardcoded timing)
• ATSTn (set timeout, with n being the number of milliseconds to wait * 4)

Be warned though, don't set n too low, otherwise the adapter might stop waiting too early and respond with NO DATA.

If this still does not lead to enough speed, there are even more ways, but for these you will have to hack LTAutomotiveSupport:

• If you are sure that you will only communicate with one ECU, you can add a 1 as the suffix of every command. This will tell the adapter to not wait any longer as soon as it received one command. If your vehicle has more than one ECU, you might need to gather the targeted ECU's physical address first and set the masks with ATSH and ATCRA.
• OBD2 supports sending multiple PIDs with one command. Try sending, e.g., 01 04 05 0B 0C which will query four PIDs in a row from the current frame.
• If all that is still not enough and you have a CAN-BUS, you might be able to drop down to UDS where you can programmatically create combined PIDs (search for "dynamically defined data identifier").

from ltsupportautomotive.

@rs38 Should be quite a lot of cars, actually. 0x2C is supported by many BOSCH ECUs, e.g. the EDC45CP45 I have here:

>2c01f300f1900111
7E8 6C 01 F3 00

>22f300
7E8 7F 22 78
7E8 62 F3 00 57 44 44 32 31 32 30 39 34 31 42 32 30 34 32 35 35

from ltsupportautomotive.

Hey @mickeyl thanks for the explanation regarding waiting time.Can you please tell me where to add 1 as suffix ,i am preety beginner to ios development .A single code line demo will be really appriciated .

from ltsupportautomotive.

Try applying the following diff to LTOBD2PID.m in +(instancetype)pidForMode1 (line 33).

-    NSString* string = [@"01" stringByAppendingString:suffix];
+    NSString* string = [NSString stringWithFormat:@"01%@1", suffix];

This way, an '1' will be appended to the PID, hence the adapter will stop after receiving one data message. Make sure you don't use this with broadcast addressing, otherwise you'll miss responses you actually want.

Note also that due to a bug in many ELM327ish implementations, this will not work with ISOTP multi-line answers (e.g. the answer to 0902) – the adapter stops listening after the first frame.

from ltsupportautomotive.

Hey Thank you so much for replying."This will not work with ISOTP multi-line answers (e.g. the answer to 0902)".If we add suffix so it means it will only listen for "pidForMode1".Like multi line asnwer we cant recieve VIN NUMber ? Also Need little bit explatnation for "Make sure you don't use this with broadcast addressing, otherwise you'll miss responses you actually want".Thanks .

from ltsupportautomotive.

The change I've presented only adds the '1' for all PIDs in "current frame" (01xy), so you should be clear for all PIDs from 0100 to 01FF. If you were to do the same for PIDs in the range of "vehicle information" (09xy), then it won't work because most of these PIDs return ISOTP multi line answers like, e.g., VIN (0902).

With regards to broadcast addressing… OBD2 supports broadcast addressing e.g. in CAN11-mode it's when you send anything to 0x7DF. In that case, all of your OBD2-capable ECUs will answer. However – if you're applying the patch from above – you will only get the first ECU answering, since the adapter stops listening after the first answer. That's why you have to be a bit careful with broadcast addressing.

Of course, it would be best, if the library would support this, and in particular, if it could tune itself to work with many kinds of adapters, not just dumb ELM327 clones. All these ideas are way too complex to solve without the proper base infrastructure though.

(FWIW, I have realized all that in a Swift-based successor library Swift-UDS [which was open source for a short time], but I'm afraid this library is going to be have a proprietary license and will remain closed source.)

from ltsupportautomotive.

Thank you so much for better clearification and awesome libraray.Worked really well .

from ltsupportautomotive.

@mickeyl The libraray is working fine getting all the required data but sometime when adater state changed ,I am getting crash with odd logs .Whenever you have have time can you please check.Here the log which i am getting during crash -
Unhandeld adapter state OBD2AdapterStateReady

• thread #53, queue = 'LTBTLESerialTransporter', stop reason = EXC_BAD_ACCESS (code=1, address=0x2ce66b20)
  frame #0: 0x0000000198499880 libobjc.A.dylibobjc_retain + 16 libobjc.A.dylibobjc_retain:
  -> 0x198499880 <+16>: ldrb w10, [x9, #0x20]
  0x198499884 <+20>: tbz w10, #0x2, 0x1984998b4 ; <+68>
  0x198499888 <+24>: tbz w8, #0x0, 0x1984998dc ; <+108>
  0x19849988c <+28>: mov x9, #0x200000000000
  Target 0: (Runner) stopped.

from ltsupportautomotive.

Hey @mickeyl any update on above crash things .It crashed multiple time with same error .

from ltsupportautomotive.

for some reasons I cannot find any documented behaviour of ELM327 to alter the wait behavior with a suffix?!
Pretty sure the suffix will be sent as raw data on the CAN bus...

from ltsupportautomotive.

@rs38 Straight from the horses mouth on page 31:

There is a way to speed up the retrieval of information, if you know how many responses will be sent. 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 response to obtain, and the ELM327 does the rest.

from ltsupportautomotive.

@mickeyl thanks, I should read more carefully!
will test it and wonder if I can speed up also UDS $22 readbyID commands!
(Your advice regarding dynamically defined data identifier $2C seems unsupported for many BEVs?!)

from ltsupportautomotive.

@rs38 Yes, UDS $2C might not be supported. Note that it's definitely only supported for direct adressing, not for broadcast addressing.

from ltsupportautomotive.

@mickeyl can you give 1-2 examples of cars that support $2c? My last try always returns like negative responses 7F ?? 11 or similar.

BTW: The suffix "1" for single DID $22 UDS queries works but not tested for performance improvements 👍

from ltsupportautomotive.

@mickeyl good point! I think I only tested the BMS (11bit CAN id 0x7E5, ECU 0x8C) by physically addressing, so the success could be different from ECU to ECU in one car?!

may I add another question now that I have contact to an UDS guru? :)

Is there a way to translate from ECU ID like VAG cars use

to physical 11 bit and/or 29bit CAN headers ID? in many VW BEVs you can reach certain ECUs by either 11 or 29 bit addressing at least from diag OBD port and probably the gateway routing either way.

from ltsupportautomotive.