« Last post by Anko on May 21, 2016, 10:28:55 AM »
(I put this here, because I was able to reproduce my finding with both a WiFi and a BT adapter)
I have a little program that sends a series of OBD requests to a series of ECUs. Some OBD requests return a single frame, some return multiple frame type responses. So, every time I switch to a different ECU (using ATSH) I also set up flow control for that ECU (using ATFCSH).
I have two non OBD Link ELM adapters (a Chinese clone and a iCarsoft i6XX adapter) that both work well with this program. But when I try the same with an MX WiFi, quite regularly it returns only the first frame of a multi frame type response.
For example, where I would expect to receive:
I am getting only this:
But this does not happen consistently. Sometimes the full response is captured, other times only the first frame of the same response is captured.
I strongly believe it is not a communication issue between the adapter and my program, as the response is always terminated with “>”.
I have attached three log files, one for each of the adapters. In the log files for the Chinese clone and there iCarsoft adapter, all multi frame type responses indeed consist of multiple fames. In the log file for the MX, you will see that many multi frame type responses consist of only one frame (look for 05-21 16:31:00.909 PROXY-OBD: Read 00F<r>0:6181950000DF<r><r>>). But the responses are not consistently incomplete.
See iCarsoft.rtf, Chines clone.rtf and MX Wifi.rtf
In the above logs, the multi frame responses were always the last responses before sending AT commands to switch to the next ECU. Question is: was only one frame received from the ECU? Perhaps because flow control was not properly enabled for the ECU? Or were other frames received and misplaced? So, I ran another test, where there would always be a normal OBD request (for pid 2134) after receiving a multi frame response and this shows that some of the missing frames from the first request end up as (part of) the response to the second request ….
See MX Wifi 2.rtf
I also thought it might have to do with the the timing of the flow control. So, I tried using SD300A0A instead of SD300000, but that made no difference. Any other parameter that the STN might need to handle this scenario well?
The initialisation pattern I use is this:
(*) During initialisation, I select an arbitrary ECU address for FC setup. Otherwise, the chip will not accept the ATFCSM1 command.
For every ECU switch, I send these commands:
and only then I send the actual requests for that ECU.