Recent Posts

Pages: 1 ... 8 9 [10]
91
OBDLink / Re: obdlink mx which one should i get... wifi or bluetooth?
« Last post by sealmindset on May 22, 2016, 06:57:40 AM »
I have the MX BT version and it works pretty well.  Had some initial setup problems but once I set the protocol from auto to static. Now it's good to go.  The limit to the BT is that it's dedicated 1 to 1.

I also ordered the Wifi version for similar reasons as yours.  One so that I can remote start from my phone.

I've read else where on the forum that you can connect to a hotspot on the tablet and still access the web.    Are you good with the wifi?
92
OBDLink LX / Re: Another OBDlink not sleeping thread
« Last post by thekow on May 22, 2016, 12:25:34 AM »
Torque was changing the settings. I just made sure it could sleep when torque exited.
I asked the developer to be able to disable the setting he uses.
93
OBDLink MX Bluetooth / Re: 2007 Silverado Service Traction Control
« Last post by sealmindset on May 21, 2016, 10:06:20 PM »
Yup, that seemed to fix it.  Waited a few days before reporting back.  Its locked in to just one protocol and now no more service warnings!
94
DashCommand / Re: New obdlink sx not being recognized.
« Last post by Mark-Surface on May 21, 2016, 03:24:36 PM »
Ditto!  :D
95
OBDLink / Not all frames from a multi frame type response are captured
« 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:

Code: [Select]
00F
0:6181950000DF
1:8D000000000497
2:03440000000497

>

I am getting only this:

Code: [Select]
00F
0:6181950000DF

>

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:

ATZ
ATE0
ATL0
ATS0
ATH0
ATSP6
ATFCSD300000
ATFCSH777 (*)
ATFCSM1

(*) 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:

ATSH<target header>
ATCRA<response header>
ATFCSH<target header>

and only then I send the actual requests for that ECU.
96
OBDLink MX WiFi / Re: BMW F10 2012 systems mailfuction when MX Wifi connects
« Last post by cooo on May 21, 2016, 09:29:53 AM »
Dwell time: 5msec. :problems
Dwell time: 10msec:problems
Today it hapened twice on the highway after 30 minutes. I quit the test, it is to dangerous.

How can it be that the OBDLink is interfering with my car when using the OBDLink in the most standard way?
Is the OBDLink sending commands or is is disrupting commands?
97
OBDLink SX / Re: Obdlink sx problems
« Last post by STN-Brian on May 20, 2016, 01:59:59 PM »
I am curious to see what the OBDLink SX reads the voltage as when hooked up to the laptop and OBDwiz.  You should be able to find it under Diagnostics -> PID Values -> Input voltage read by the scan tool.
98
OBDLink MX Bluetooth / Re: 2007 Silverado Service Traction Control
« Last post by STN-Brian on May 20, 2016, 01:50:53 PM »
Quote
Found two other entries and I'll follow the suggestion by selecting one protocol versus leaving it on automatic.

Refer to: https://www.scantool.net/forum/index.php?topic=12675.msg44531#msg44531
I would recommend trying this one first.
99
OBDLink MX Bluetooth / Re: OBDLink MX BT Lose Communication With Phone
« Last post by hdn259os1 on May 20, 2016, 06:15:31 AM »
Hi Brian,

I completed the steps you recommend several times already. That's the only way to reconnect the MX with the phone once it loses connection.
100
OBDLink SX / Re: Obdlink sx problems
« Last post by Gariy on May 20, 2016, 05:02:52 AM »
Ok i guess i tried to copy it in my text message ,thats why i coldn't get it to show. Got the attachment finaly working.

Pages: 1 ... 8 9 [10]