Android (mostly 7) is misbehaving on BLE connect

RE: Android (mostly 7) is misbehaving on BLE connect

MartinBL — Mon, 19 Feb 2018 07:50:18 GMT

Thanks for telling. Much appreciated!
It looks like you have a better discussion going on over there so please continue there.

RE: Android (mostly 7) is misbehaving on BLE connect

rgrr2 — Fri, 16 Feb 2018 19:06:20 GMT

Martin, I don't want to waste the time of two of you! I now have quite a similar thread here: https://devzone.nordicsemi.com/f/nordic-q-a/30038/reduce-current-of-peripheral-thru-latency-setting (image included ;-))

RE: Android (mostly 7) is misbehaving on BLE connect

MartinBL — Fri, 16 Feb 2018 13:48:42 GMT

I just noticed that you said

[quote user=""]I've already tweaked with local slave latency,[/quote]

So maybe you have already tried what I just suggested? If so, do you mind showing me how you tweaked it? A plot over your current consumption over time would also be useful.

RE: Android (mostly 7) is misbehaving on BLE connect

MartinBL — Fri, 16 Feb 2018 13:15:54 GMT

Devices with tight current constraints are certainly not uncommon and pretty much at the center of our business. 1mA is extreme though. Keep in mind that the CPU draws 4mA and many peripherals, like the UART, draw >1mA alone.

It turns out that the Softdevices has a feature I didn't know about though. I'm not sure what SDK and chip you use, but there is a struct called ble_gap_opt_local_conn_latency_t that you can look into. Use it together with sd_ble_opt_set() to achieve what you wan't.

RE: Android (mostly 7) is misbehaving on BLE connect

rgrr2 — Thu, 15 Feb 2018 13:11:56 GMT

Ok... thanks for the explanation. Nevertheless your conclusion is a little bit too pessimistic for me.

I do not think that our use case is such exotic: connect an Android (>=7) smartphone with a device which has current limitation.

Why isn't it possible to catch such situations on peripheral side? The peripheral still follows the specification, if it would simply ignore connection intervals and leaves Rx and Tx completely off. If I understand the mechanisms correctly, the central would do retries in this case.

This would be close to "local slave latency", or better "forced local slave latency" because even internally queued packets wouldn't be transmitted during those ignore events.

Does something in this direction already exist in the softdevice? If not, I will be your fist beta tester for such a feature.

RE: Android (mostly 7) is misbehaving on BLE connect

MartinBL — Thu, 15 Feb 2018 11:44:12 GMT

I looked more into this today and it seems like this behaviour is embedded in Android's BLE stack as of Android 7 (I think).

[quote user="Hardy"]the Android device is switching to "high" speed during GATT info exchange - that's my current guess.[/quote]

Yes that is correct.

[quote user="Hardy"]Does anybody know of a way to prevent the Android device from switching speed?[/quote]

Since the behaviour is defined by Android's BLE stack this seems to be impossible.

[quote user="Hardy"]Would it be possible to setup the Android internal GATT database so that Andoid sees no need to access the GATT data from the device?[/quote]

Android caches the GATT database after each initial connection procedure and only updates the database if anything changes. This might be why you experience different behaviour based on the device's "mood". If you bond your devices you will also ensure that the database, as well as some security parameters, are stored across connections. However, I can't see anyway around that initial "high-speed" exchange of data, and it sounds like one "high-speed" transfer is one too many in your case.

This is one of the difficult parts regarding BLE. Although BLE is meticulously described in a 3000 pages long specification, there are still some room for interpretation and "unique" mechanisms. Different vendors, chipsets, and stacks might behave differently even though they all (usually) comply with the specification. So the bottom line is that developing an application that expects the exact same behaviour from all peer devices is simply not possible.

RE: Android (mostly 7) is misbehaving on BLE connect

rgrr2 — Wed, 14 Feb 2018 17:30:26 GMT

Concerning the 1mA limitation: our device is an industrial field device (see my profile ;-)) which has really limited power consumption (3.6mA @10V or so). Main part is going to the sensor electronic and some part is available to the BLE connectivity.

There are also limitations to buffering capacitors due to space requirements and Ex.

RE: Android (mostly 7) is misbehaving on BLE connect

rgrr2 — Wed, 14 Feb 2018 17:28:15 GMT

yes, the Android device is switching to "high" speed during GATT info exchange - that's my current guess.

Does anybody know of a way to prevent the Android device from switching speed? Would it be possible to setup the Android internal GATT database so that Andoid sees no need to access the GATT data from the device?

Or is there any chance to tell the softdevice to slow down internally its GATT info exchange?

Or a way to force a lokal slave latency?

As you might see, I'm getting desperate...

RE: Android (mostly 7) is misbehaving on BLE connect

MartinBL — Wed, 14 Feb 2018 14:14:05 GMT

Hi,

This sounds like your Android device is trying to balance speed and power consumption. It does this by using faster connection intervals when it knows that a lot of data is about to be transmitted so that the transfer completes faster. Then, after the intensive data transfer is completed, the connection intervals are relaxed again to save power. A typical scenario is that the Android device enforces fast intervals during the connection process and service discovery, and then throttles down afterwards (as far as I know Apple devices don't use this mechanism).

In BLE the connection parameters are ultimately enforced by the central (your Android device). The min and max parameters you set in your peripheral application is just your preferred values and the central may chose to reject them. Furthermore, different Android devices ships with different chipsets and BLE stacks, which may behave and perform differently.

There is nothing you can do with TX power or timeslot API to change this. The change needs to be made on the Android side.

Here are two relevant threads:
High BLE activity for 15 seconds after connection
Questions about connection interval negotiation

May I ask what it is that limits your current consumption to just 1mA?