nRF51822 S110 versus Android Connection Inverval

RE: nRF51822 S110 versus Android Connection Inverval

Andrew Fernandes — Fri, 05 Sep 2014 21:18:17 GMT

Although I can't comment on the BLE stack in Android precisely, because it is closed-source, we've used tricks like this for quite a while in the Android audio space. And my advice is do not do this for production.

It is vendor-specific, hardware-specific, and Version 0.0.X-specific. It will break. Your customers will hate you. Then they will talk down Bluetooth on Android forever.

I'd be willing to bet money that your "trick" will be flagged as a "bug" in the bluetooth stack, unfortunately. Because it relates to power usage, I expect that "bug" to be one of the few to be fixed.

Yes, it's a gloomy outlook. Sorry... but that's my experience.

RE: nRF51822 S110 versus Android Connection Inverval

Ali — Wed, 27 Aug 2014 00:48:35 GMT

I seem to have found a way around this very issue, assuming the device is capable of a faster connection interval. I was seeing behavior where sometimes it would connect with a 7.5 ms interval, and sometimes it would be 48.75 ms. Our application requires 7.5 ms. Basically what I do is check the connection interval after a connection is fully established (BLE_HIDS_EVT_REPORT_MODE_ENTERED), and if it is not fast enough, I do a disconnect with this parameter (BLE_HCI_CONN_INTERVAL_UNACCEPTABLE) telling the Central device that I want it faster. It seems to do the trick and doesn't take more than 2 connect attempts to work so far with my testing.

sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_CONN_INTERVAL_UNACCEPTABLE);

RE: nRF51822 S110 versus Android Connection Inverval

Joe Merten — Mon, 23 Jun 2014 10:40:38 GMT

Thanks for your reply (although I do not like the answer ;-).

RE: nRF51822 S110 versus Android Connection Inverval

Andrew Fernandes — Wed, 18 Jun 2014 15:03:52 GMT

In my tests with iOS and KitKat 4.4.3 on a Nexus 4... the short answer is "you can't". Android BlueTooth is as vendor-specific as Android Audio... on some devices it's great, on most devices it's okay, and on a lot of devices it's horrible.

If you look at the Android Open Source Project (AOSP), you can see that all the native C/C++ code for BlueTooth is firmly in the vendors' hands, so quality is going to vary greatly.

There is no way to "force" a central to connect outside of its offered connection parameters.