Long delay when connecting to BLE device

[aaknitt]

I'm running into an issue where I sometimes get a very long delay when attempting to connect to a BLE device using Evothings. This only seems to happen after I've already been connected and then disconnected due to loss of RF signal.

When this occurs, my code immediately starts scanning to look for the device again, and it typically finds it right away (upon regaining the RF signal) and then attempts to connect. However, there is sometimes a delay after calling evothings.ble.connect() (from internal.connectToDevice() within easyble.js). This delay has been up to 60 seconds. It will eventually connect, but I'm trying to understand the cause of the delay and how to eliminate it.

Any insight or advice is appreciated.

Thanks,

Andy

[micke]

Hi, what is your environment? Are you on Android or iOS? Which BLE device are you using?

Is it possible for you to try out your app on different combinations of hardware, Android and iOS, different BLE devices if you many have.

I experienced connecting to the TI SensorTag takes longer time on Android than on iOS, in particular when you enable many services. Your case may be something entirely different however.

Let us know how it goes!

Best regards, Mikael

[aaknitt]

I am using Android. I have seen this when using an RFduino, but I don't believe it's limited to just that device. I've seen similar reports from people using the SensorTag.

I think the difference in delay you're talking about is the delay in doing service discovery with different operating systems. However, what I'm seeing is a different delay for the same device with the same services and the same OS.

Andy

[mikepsmith]

I am have been having the same problem, except that the connection can take minutes. I have discovered that restarting the bluetooth device can cause it to connect immediately. There is no timeout in the easyble API and no way to abort the request.

What I did notice that attempting to disconnect via device.close() actually causes the connection to complete! So I am wondering if the problem is that the connection completed but that the connection event never gets detected and the callback never gets called.

Mike

[alex]

For me, it varies between Android devices. Currently, I'm using the Samsung Galaxy Alpha (like a thinner S5), and it does act up on
occation. Turning bluetooth off/on via the phone's GUI usually helps. On iOS, the BT subsystem works like a charm day in and day out.

[mikepsmith]

I have discovered that this is due to a bug in the com.evothings.ble plugin.

In com.evothings.ble.src/android/BLE.java, the connect() call in the app executes the following:-

gh.mGatt = adapter.getRemoteDevice(args.getString(0)).connectGatt(mContext, true, gh);

The second parameter to connectGatt() enable automatic connection which causes a lot of problems.

1. if the connection to the BT device fails, the app receives no callback. Instead, the Android BT stack tries again later - possibly several minutes later. This causes the long delay that you see. This situation occurs more frequently than you might expect because interference or just the fact that the BT device might be busy with other things could cause the connection to fail.

2. If you give up and stop the application, the Android stack still thinks you want to connect to the device and will connect in the background when the device finally responds to a connection request. When you start your app, the app thinks it needs to connect, not knowing that the Android stack has silently connected for you! Connecting from the app then seems to lock up.

The fix is to set the second parameter to false by editing BLE.java and rebuild your project having first copied it to where the BLE.java file gets copied too when the plugin was installed e.g.

cp plugins/com.evothings.ble/src/android/BLE.java platforms/android/src/com/evothings

After this, things work a lot better:-

1. the connect() fail callback get called if the connection request fails. You should then reissue the connect() request until the win callback gets called.
2. the app is now in control of the retry mechanism and the connection setup is much faster
3. the app is also in control of the connection and stays in sync with the BT stack connection state

Mike