5

I am connecting to a Bluetooth LE peripheral as a central. I am writing data to a characteristic and I receive data through Notifications in chunks of 20 bytes.

Notification subscription:

private void setCharacteristicNotification(BluetoothGattCharacteristic characteristic, boolean enabled) {
    if (mBluetoothAdapter == null || mBluetoothGatt == null) {
        Log.w("BluetoothAdapter not initialized");
        return;
    }

    Log.d("Enabling Notifications");

    mBluetoothGatt.setCharacteristicNotification(characteristic, enabled);

    BluetoothGattDescriptor descriptor =
            characteristic.getDescriptor(UUID.fromString(CLIENT_CHARACTERISTIC_CONFIG));

    descriptor.setValue(BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE);

    mBluetoothGatt.writeDescriptor(descriptor);
}

This works fine if only small number of chunks need to be received between writes. The bluetooth stack sends notifications for each chunk:

D/BluetoothGatt﹕ onNotify() - Device=B0:EC:8F:00:07:AA UUID=06d1e5e7-79ad-4a71-8faa-373789f7d93c

But if the number of chunks between writes is bigger than about 10, the stack stops the notifications and the rest of the data is lost! The device is definitely sending more data, as we can receive it on iOS devices.

The number of received notifications varies between android devices. A Galaxy S3 (4.3) receives 5, a nexus 5 (4.4.4) and a htc one (4.4.2) receive 12.

The BT stack closes the connection 30 seconds after the last notification.

D/BluetoothGatt﹕ onClientConnectionState() - status=0 clientIf=5 device=B0:EC:8F:00:00:88

Can anybody reproduce this issue?

As the Bluetooth LE stack is polling based, I guess that the stack stops polling data from the peripheral for some reason. The target device does not support indications.

Update: Additional Information provided by the Android L bluetooths stack:

06-27 12:20:02.982 18909-18946/? D/BtGatt.GattService﹕ onNotify() - address=B0:EC:8F:00:01:09, charUuid=06d1e5e7-79ad-4a71-8faa-373789f7d93c, length=20

06-27 12:20:07.666 18909-18984/? E/BTLD﹕ ###################################################################### 06-27 12:20:07.666 18909-18984/? E/BTLD﹕ # 06-27 12:20:07.666 18909-18984/? E/BTLD﹕ # WARNING : BTU HCI(id=0) command timeout. opcode=0xfd55 06-27 12:20:07.666 18909-18984/? E/BTLD﹕ # 06-27 12:20:07.666 18909-18984/? E/BTLD﹕ ###################################################################### 06-27 12:20:07.670 18909-18984/? E/bt-btm﹕ can not interpret IRK VSC cmpl callback 06-27 12:20:07.670 18909-18984/? W/bt-hci﹕ HCI Cmd timeout counter 1 06-27 12:20:34.315 18909-18984/? E/bt-btm﹕ btm_sec_disconnected - Clearing Pending flag

Philipp E.
  • 3,296
  • 3
  • 34
  • 52
  • 1
    This is exactly what we are seeing. Notifications fail after some number of attempts and then the device automatically disconnects after about 15 seconds on a Nexus 5. Our BLE devices works like a charm on iOS. Of note, with specific code, the Galaxy S4 will automatically reconnect when this occurs, leading us to believe there is an issue in the BLE stack that Samsung identified and developed custom handling for. Also of note, the Android L Preview did not resolve this issue. – Kevin Jul 03 '14 at 19:53
  • Additional log from Android L added. We currently work around this issue by delaying notifications on the peripheral side by 60ms. But this is not what I would call a fix, as it slows things down considerably. – Philipp E. Jul 04 '14 at 09:25
  • Have you tried making a ayshronous task? – SeahawksRdaBest Jul 06 '14 at 18:51
  • I am not sure what you mean, can you be more specific? I make every BT call in separate thread, if thats what you mean. But the problem occurs somewhere in the Android BT stack. Even if I remove all code from onCharacteristicChanged() the behaviour is the same. – Philipp E. Jul 07 '14 at 08:08
  • We did notice on Android L that our Nexus 5 produces a new status on the disconnect - D/BluetoothGatt﹕ onClientConnectionState() - status=8 clientIf=5 device=D0:39:72:BF:7F:ED. Digging through the AOSP code for Android L we found this status=8 represents "GATT_INSUF_AUTHORIZATION". This status is not listed on the standard Android documentation... – Kevin Jul 09 '14 at 16:37
  • 1
    Philipp, another consideration is the BT stack is synchronous underneath the asynchronous BtGattCallback interface. By ensuring only a single operation is being processed at a time by the BT stack - i.e. anything that would callback to the BtGattCallback - I've improved overall stability of our app. – Kevin Jul 09 '14 at 23:21
  • Hello, was you able to find solution for this problem. – Sarah Nov 03 '14 at 12:55
  • I want to list down ble enabled device, but example give in sdk folder is not working. I am checking in to Moto G(2nd Gen) and Moto X , so both has BLE support. But still I am not able to get the device listed. If you have working example please mail me on hardik.trivedi_11@yahoo.com – Hardik Trivedi Nov 26 '14 at 06:41

2 Answers2

1

Maybe not an ideal solution, but I've come to accept notifications not working at all or stopping working as an unfortunate reality of doing BLE on Android. With this is in mind, I believe it's best if you set up your own "pseudo-notification" backup mechanism by doing a read poll when it appears normal notifications are broken. For example, in a Handler#postDelayed() loop once a second. You can even abstract it away behind a separate class that stores the last read value and only notifies your UI when the last read value doesn't equal the new value.

Doug Koellmer
  • 407
  • 2
  • 8
0

What worked for us in the end were two changes on the peripheral:

-Adding a small delay to each response on the peripheral

-Reducing the slave latency to 0

Philipp E.
  • 3,296
  • 3
  • 34
  • 52