Develop Reference

BLE Device dissonect after receive Notifications (BLEGattException Status = 0x8)

My BLE server permanently measures a sensor value and sends a notification with 20 byte user data after each measurement. The goal is to generate as much throughput as possible.
On the client side, the value sent by the server is received and processed.
rxBleConnection.setupNotification(setDescriptorEnableNotification(characteristic))
.flatMap(notificationObservable -> notificationObservable)
.observeOn(Schedulers.newThread())
.buffer(1)
.subscribe(bytes -> {
onNotificationReceived(bytes, buffer);
} , throwable -> {
// Handle an error here.
onNotificationSetupFailure(throwable);
}
);
If I set the Connection intervall to 11.25ms, I receive all values. However, if I set the connection interval to 30ms, I receive a few values ​​and then the connection is closed.
In the Android Log i see the followed message:
BleGattException status=8 (0x8),
bleGattOperationType=BleGattOperation{description='CONNECTION_STATE'
Why is the connection interrupted and what is the trigger?
With the help of a BLE Sniffer this is not recognizable. The set connection parameters are accepted and the transfer begins. Suddenly the transmission ends and the error message appears.
Update:
BLE Sniffer screenshot has been added:

30ms, this is connection interval you set in server or android?
Btw, on android you can set speed mode
if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.LOLLIPOP) {
mBluetoothGatt.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_HIGH);
}

Error 8 means the connection timed out. There is nothing wrong on the Android side. The problem is with the communication between the two Bluetooth controllers. If you have a sniffer then you should be able to see who is the one that fails to send packets.

Here is an Image from BLE Sniffer.
BLE Sniffer

I have the similar problem. On Android 7.0 there were two ways to keep connection:
1) If devices are bonded and there is a charachteristic reading callback with constant thread of packets. If there are no packets by some time, then connection fails.
2) If devides are not bonded, but I do TXCharacheristic.read every few seconds. If don't do that some time, then connection fails.
But now in Android 7.1.2 this way doesn't work.
May be the first way will work for you.
On your Android device you should make bonding, on your kit you should handle this bonding.
On Nexus 6P and Samsung S7 it doesn't work anymore, but I didn't try it on the other devices.

I suppose, you have min connection interval 7.5 on your BLE kit, but now it is deprecated on Android.
Try to set min connection interval to 11.25 on your BLE kit and set connection priority
gatt.requestConnectionPriority(CONNECTION_PRIORITY_HIGH);
where CONNECTION_PRIORITY_HIGH = 1
in onConnectionStateChange.
It had worked for me when I had changed min connection interval in my nordic from 7.5 to 11.25.

BluetoothGatt: onClientConnParamsChanged()

I am developing an Android App that communicates with a BLE Peripheral. I am able to enable the notifications and receive data from the BLE Peripheral. However, a few seconds later, I receive the following message on my Android Terminal in Android Studio and the Notifications stop.
I noticed that Android phone is still connected to the BLE Peripheral as Status = 0, but after the BLE Connection Interval Change = 156, the Notifications stop.
Has anyone encountered a similar problem? I am using the BluetoothLEGatt example from Android Studio.
Thanks
Hani Abidi
D/BluetoothGatt: onClientConnParamsChanged() - Device=80:EA:CA:00:A8:77 interval=156 status=0enter code here

So I ran into this issue as well and although I don't 100% know the exact cause, I can at least relay how I "fixed" the problem and my experiences.
So I'm using a Samsung Galaxy Note 4 running 6.0.1 and using RxAndroidBle to ease the pain of having to deal with BLE on Android. My application connects to a PSoC4 BLE microprocessor and immediately does a back and forth data transfer with said microprocessor. What I was seeing was similar to the OP: more often than not the back and forth transmission would just stop dead in its tracks with the following messages:
03-15 16:06:39.989 27793-28784/application D/BluetoothGatt: onClientConnParamsChanged() - Device=00:A0:50:65:24:91 interval=6 status=0
03-15 16:06:40.289 6292-6754/? D/BtGatt.GattService: onClientConnParamsChanged() - clientIf=7 address=00:A0:50:65:24:91, interval=39status=0
03-15 16:06:40.289 27793-28561/application D/BluetoothGatt: onClientConnParamsChanged() - Device=00:A0:50:65:24:91 interval=39 status=0
03-15 16:06:54.989 6292-6754/? D/BtGatt.GattService: onClientConnParamsChanged() - clientIf=7 address=00:A0:50:65:24:91, interval=6status=0
03-15 16:06:54.989 27793-27823/application D/BluetoothGatt: onClientConnParamsChanged() - Device=00:A0:50:65:24:91 interval=6 status=0
03-15 16:06:55.259 6292-6754/? D/BtGatt.GattService: onClientConnParamsChanged() - clientIf=7 address=00:A0:50:65:24:91, interval=39status=0
03-15 16:06:55.259 27793-28784/application D/BluetoothGatt: onClientConnParamsChanged() - Device=00:A0:50:65:24:91 interval=39 status=0
It appeared to me at first that for some reason the phone was still negotiating the connection interval in the middle of the data transfer and, for some reason, would just completely get screwed up as a result.
Maybe this is what is happening, maybe it isn't, but what I found was the root cause of this was that I am (apparently) connecting and interfacing with my microprocessor over BLE before the BLE device scanner is completely done shutting down.
When the user taps on the table view cell to connect to the device, I was originally calling to stop subscribing to the RxAndroidBle observable that is scanning for devices, which should end the BLE scanning and then immediately launched into showing a new Activity for communicating with the PSoC4 which in turn immediately connects and starts interfacing with the microprocessor:
scanSubscription.unsubscribe();
Intent myIntent = new Intent(MainActivity.this, ConnectedActivity.class);
myIntent.putExtra("address", testdevice.getAddress());
myIntent.putExtra("name", testdevice.getName());
MainActivity.this.startActivityForResult(myIntent, CONNECTED_ACTIVITY);
It appears, however, that simply unsubscribing from the scan subscription does not immediately end the BLE scanning so my current strategy is to wait 500 ms before starting any communications with the other device. This is obviously not ideal - ideally you'd have a method callback when scanning actually was ceased, but I haven't figured out how to do that just yet.
Hopefully this helps someone.

Connection parameter update is unrelated to notification subscription status. Are you saying your onCharacteristicChanged are not being called although you send notifications from the peripheral? You should check your code again. If you think you've done everything correct you should check android's hci snoop log or use a BLE sniffer to see what really happens.

Proper way to handle BLE Error Codes

Here is the list of error which i got while developing BLE App for A&D UA-651BLE model
onClientConnectionState() - status=8 clientIf=5 device=D0:5F:B8:03:79:70
onClientConnectionState() - status=22 clientIf=5 device=5C:31:3E:5E:E2:36
onClientConnectionState() - status=19 clientIf=5 device=5C:31:3E:5E:E2:36
As of now I'm handling this with gatt.disconnect(); ,
Description of above error codes :
22 is 0x16 which means connection terminated by local host.
8 is 0x8 which means connection timeout.
19 is 0x13 which means connection terminate by peer user.
How to handle this in different way?
1.Is there any way to handle this issue other than disconnecting BluetoothGatt? (Just curious to know)
2.Shall I show popup to user that your values are stored in BP device,On next successful connection vital device will push your values automatically?
P.S: If I see from developer's perspective,I know that this is BLE Stack exception,By if i see from user's perspective,they will think something wrong in android app,that is why it is not Showing my BP reading in android Screen.

BLE Number of Packet per Connection Interval in Wireshark

I need to know exactly how many packets per interval my BLE can handle. The peripheral, as per its datasheet, handles 6 packets per interval, but I have been unable to find out how many packets the Central can handle. The Central device is a Motorola Moto G (generation 2), running Android 5.0.2.
By examining he btsnoop_hci.log file I have been able to identify multiple connection parameters, such as the connection interval (7.5ms in my case). My questions is wheter it is possible to determine how many packages can be exchanged in a single coonection interval, by examining the negotiation packets in Wireshark.

In the spec, there is no negociation about the max number of packets in a Connection Event. A connection event can simply last for at most (ConnectionInterval - 150µs) (See 6.B.4.5.1).
Limitations, if any, are in the PHYs, at either side. Most HCI firmwares limit to 4-5 packets per connection event, per direction.

It is up to the controller on the master side to decide how long the connection event should be open (as long there are more packets from any side). The slave has nothing to say about this.
For a central host, when creating a connection as well as when updating connection parameters there are two HCI parameters Minimum_CE_Length and Maximum_CE_Length. These are informational parameters that indicate how long it should keep its connection event open. If these are set to high numbers, the controller will have the connection event open as long as possible.
Sadly, Android set these parameters both to 0 which means most controllers will restrict the connection event to only 3 or 4 packets.

Android Bluetooth Low Energy connection timeout while BLE chip is computing

My BLE application requires computation on the server side (BLE chip) which takes time and results with disconnection.
Th flow is like this:
1- Android phone writes the characteristic value to the BLE chip.
2- The chip evaluates this value and starts computation.
3- The connection is lost soon after the computation has started.
What solution can I apply to prevent the disconnecton? I have two solutions in my mind:
1- Changing the connection interval: Currently Android uses 7.5 msec as connection interval. Since the computation on BLE chip takes time, packets are not sent or received during the computation. Increasing the connection interval will decrease the number of lost packets. However there is no guarantee that Android phone will accept the new connection parameters.
2- Running the computation in a separate thread: I dont think that BLE chips' SDK support multi-threading such that while there is a computation process going on, it will keep receiving and sending packets and prevent the disconnection. I use CSR chip and I think it doesnt support.
Please correct me if I am wrong at my points.
Do you have any other suggestions to solve the issue?
Thanks in advance.

Thank you for the answers. I found out what the problem is after spending hours.
First of all, when Android gives error 133 or 129, it is most probably because of the remote device.
At the beginning I thought that the problem occurred because of the supervision timeout. Then I re-configured the connection parameters of the CSR chip but it didn't help.
There is a problem about CSR app development with xIDE (IDE of CSR). When there is run-time-error due to index overshoot or accessing some invalid pointers, then you would not receive any errors in xIDE. I finally found out the array problem and fixed it. Now it works perfect.
Thanks a lot!

I don't know exactly if what i going to explain it's feasible under Android because I used BLE only with a low level applications, anyway if your problems are the connection parameters you can try to change the Slave_Latency.
It should be usefull since playing with this parameter, you can change the number of connection intervals in which the Central device can wait until it considers the connection lost.
The following equation is usefull to derive the connection parameters:
Effective_Connection_Interval = (Connection_Interval)*(1+(Slave_Latency))
Remember that can exists some kind of Supervision_Timeout that can collide with your Effective_Connection_Interval