2

I am using an ELM327 adapter to talk to the OBD2 port on my car over ISO 15765-4 11b/500k. I want to query for non-standard messages outside of standard OBD2 PIDs, (which I have separately logged from a diagnostic tool). I am trying to reproduce manually via a serial terminal (and then later programmatically) the successful request/response message flow that I see from that diagnostic tool.

I have it working for everything except multiline responses which require the CAN flow control message. The flow control message is not working, preventing the receive of the additional payload lines.

A good example would be Air Intake Temperature. Here is a successful trace from the diagnostic tool:

5F0 02 21 01                -> initial request to 5F0 of length 02 with payload 21 01
6F0 10 1A 61 01 60 6B 5F 60 -> response from 6F0 explaining that there are 1A bytes to come
5F0 30 00 01                -> flow control message back to 5F0 saying send the lines
6F0 21 EF 81 05 69 67 05 F7 -> three additional lines of content.
6F0 22 65 1A 28 41 05 E8 65 
6F0 23 05 FF 65 3B 00 00 AA

So to reproduce this myself manually without the diagnostic tool I:

ATZ         -> Reset
ATSP6       -> Select Protocol: ISO 15765-4 11b/500k
ATSH5F0     -> Set Headers 5F0 (target can ID address)
ATCRA6F0    -> Set CAN Receive Address: 6F0

Note: I have 2 serial terminals set up against 2 adapters joined into a Y-split into the ODB port, so I can run another ELM327 in AT MA mode to show whats actually going to the vehicle. One is read-only using AT MA, the other is where I issue the commands. This is how I got the trace from the diagnostics tool, so I dont think this is causing the problem.

I can then go about sending a 21 01 which shows up as (and then stops!):

5F0 02 21 01                -> great
6F0 10 1A 61 01 60 6B 5F 60 -> great, first line back from 6F0 is perfect
6F0 30 00 00                -> problem: seeing this instead of 5F0 30 00 01

Why is my ELM automatically sending a different flow control message to what my diagnostics tool sends?

Ok, then lets try turning off Automatic Formatting and Automatic Flow Control, perhaps we can take care of this ourselves manually.

ATCAF0      -> Set CAN Automatic Formatting off (messages need to start with byte count now)
ATCFC0      -> Set CAN Flow Control off (need to manually send the flow control message when required)

After that, I can send an 02 21 01 (i need to send number of bytes manually now) and get:

5F0 02 21 01                -> ok, as before
6F0 10 1A 61 01 60 D1 31 60 -> ok, as before

now i manually send flow control with 30 00 01:

5F0 30 00 01                - ok, looks good (same as tool) but doesnt yield any more lines

What am I doing wrong, and how can I solve this?

1 Answer 1

0

Are you honoring the time constraints? As per the ISOTP standard, flow control responses must be sent within 1000ms otherwise the frame gets discarded.

That said, are you sure that your OBD2 adapter is using an original ELM327 or is it perhaps one of the behemoth of cheap clones? Many of the clones have a sub-par implementation of certain protocol aspects. If you're doing something outside OBD2 (which they're handling ok, since that's what they made for), I strongly recommend using either a direct CAN adapter or something STN22xx-based, like the OBDLINK family of devices.

3
  • Ok, I will retest to try to ensure I manually respond within 1000ms when trying with auto-format-off and auto-flow-control-off. Any ideas why in the first scenario with auto-formatting-on and auto-flow-control-on the ELM is sending the flow control with a different header to what the diagnostic tool sends? Is there some header settings I can use to control that so i dont need to perform flow control myself? Yeah, i have a bunch of bluetooth ODB adapters of various makes, and 1 USB adapter. I'll explore this scenario with all of them and see if there is any difference in behaviour. Feb 23 at 11:14
  • Well, for some reason your ELM327 does not recognize the non-standard (with regards to OBD2) addressing pair. You might have luck trying to issue ATFCSH5E0, which forces the flow control address to be 5E0. Feb 23 at 15:07
  • 1
    Mickey, yes it was the ATFCSH command, also requires FCSD and FCSM, but I got it working now without manually sending flow control. Thank you so much. But obvious now that I re-read the Elm DataSheet. I owe you a beer(s) one day for LTAutomotive. Cheers! Feb 23 at 21:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .