The Bluetooth Low Energy connection parameters management seems to have changed in Android 6.
I have a BLE Peripheral device who needs to use some specific connection parameters (notably, the connection interval), and I want to use the minimum connection interval allowed by the BLE specification (i.e. 7,5ms).
The Android SDK doesn't allow to choose it from the BLE GAP Central (the smartphone) side, so the proper way to do it is to make my GAP Peripheral device send a L2CAP Connection Parameter Update Request after the GAP connection is made.
The parameters I request are:
conn interval min : 7,5ms
conn interval max : 7,5ms
slave latency : 0
supervision timeout : 2000ms
This worked as expected with all Android devices I've been testing, from 4.3 to 5.x : after sending the L2CAP Connection Parameter Update Request, my device receives a L2CAP Connection Parameter Update Response with 0x0000 (accepted), followed by a LE Connection Update Complete event where I can see that the requested connection parameters have well been taken into account.
Now, with a Nexus 9 tablet or with 2 different Nexus 5 devices, all having Android 6.0.1, I can see that the the L2CAP Connection Parameter Update Request is always rejected (I receive a L2CAP Connection Parameter Update Response with 0x0001 (rejected)). Then I receive a LE Connection Update Complete event where I can see that the requested connection parameters have NOT been taken into account.
I've been trying this with 2 different implementations on the Peripheral side (one with ST Microelectronics' BlueNRG, one with Nordic Semiconductor's nRF52), both with the exact same result.
Then, after more testing : I have tried different parameter sets, changing the conn interval max (I kept other parameters the same). Here is what I found :
with conn interval max = 18.75ms, update request was accepted with interval set to 18.75ms
with conn interval max = 17.50ms, update request was accepted with interval set to 15.00ms
with conn interval max = 15.00ms, update request was accepted with interval set to 15.00ms
with conn interval max = 13.75ms, update request was accepted with interval set to 11.25ms
with conn interval max = 11.25ms, update request was accepted with interval set to 11.25ms
with any other conn interval max value below 11.25ms, I get rejected.
So the observation is that something has clearly changed with the way Android 6's BLE stack handles the connection parameters. But there doesn't seem to be any kind of information or documentation to confirm that.
My observations lead to a conclusion that the minimum connection interval allowed is now 11.25ms (which actually fits my needs) instead of 7.5ms in earlier Android versions. But having found it empirically, I'd want to be sure that I'm not missing some other constraints/rules or if that minimum would not be dynamic, depending for example on the current battery level...
What would be great would be to have the equivalent of Apple's Bluetooth Design Guidelines (cf. §3.6) to set things clear on how an LE Peripheral should deal with this topic.
Is anyone having the same issue or is aware of some more helpful information from Google ?
Compare method connectionParameterUpdate() from GattService.java in AOSP 6.0.1_r17 vs AOSP 5.1.1_r14. In both instances, call goes all the way to Buedroid in BTA_DmBleUpdateConnectionParams() in bta_dm_api.c with same params.
6.0:
switch (connectionPriority)
{
case BluetoothGatt.CONNECTION_PRIORITY_HIGH:
minInterval = 9; // 11.25ms
maxInterval = 12; // 15ms
break;
case BluetoothGatt.CONNECTION_PRIORITY_LOW_POWER:
minInterval = 80; // 100ms
maxInterval = 100; // 125ms
latency = 2;
break;
}
5.1:
switch (connectionPriority)
{
case BluetoothGatt.CONNECTION_PRIORITY_HIGH:
minInterval = 6; // 7.5ms
maxInterval = 8; // 10ms
break;
case BluetoothGatt.CONNECTION_PRIORITY_LOW_POWER:
minInterval = 80; // 100ms
maxInterval = 100; // 125ms
latency = 2;
break;
}
This might be a part of the answer to your question. Although BLE allows down to 7.5ms CI, I cannot speculate why link layer would not switch to lower CI on request by peripheral. I don't know if any part of android code controls outcome of negotiations with peripheral device.
Google has not provided any documentation about the Bluetooth LE stack changes concerning connection parameter changes even though there have clearly been some in Android 6.
My experience with it has been the same as your own, that being that 11.25ms is now the fastest connection interval allowed in Android 6+.
My educated guess as to why they don't release documentation is that many manufacturers put their own BLE stacks into their phones (the BLE on Samsung and HTC behave differently from vanilla Android).
One other observation I have made that caused a great deal of problems is that Android 6+ will change the connection parameters 2 to 6 times before settling on the requested parameters.
I observed that after requesting a connection parameter update interval of 800ms to 1100ms, I saw the initial interval come back at 7.5ms, that then jumped to 48.75ms and then jumped to the 1098.75ms I requested. Then I subscribed to notifications on one of my services and the connection interval again jumped back to 7.5ms and then back to 1098.75ms. After this, it stabilized at 1098.75ms for the duration of the connection.
These tests were run on a Nexus 6 with Android 6.0.1
Obviously, some very strange things are happening on the Android 6 BLE stack.
11.25 ms is the new minimum connection interval. The reason they don't allow 7.5 ms anymore is because if you stream audio over bluetooth at the same time the audio might became choppy.
Google guys made a mistake in one of recent commits in Bluedroid by defining BTM_BLE_CONN_INT_MIN_LIMIT as 0x0009 which gives you 1.25ms x 9 = 11.25ms. In order to comply with standard it has to be defined as 0x0006.
Related
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.
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.
The Problem
An app I'm maintaining keeps getting socket timeouts after approximately 21000 ms, despite the fact that I've explicitly set longer timeouts. This seemingly magical value of 21000 ms has come up in a few other SO questions and answers, and I'm trying to figure out exactly where it comes from.
Here's the essence of my code:
HttpURLConnection connection = null;
try {
URL url = new URL(urlString);
connection = (HttpURLConnection) url.openConnection();
connection.setConnectTimeout(45000);
connection.setReadTimeout(90000);
int responseCode = connection.getResponseCode();
if (responseCode == 200) {
// code omitted
}
} catch (Exception e) {
// code omitted
}
finally {
if (connection != null) {
connection.disconnect();
}
}
Catching all exceptions in one block is admittedly not ideal, but it's inherited code and I'm reluctant to mess with it. I know it's catching SocketTimeoutException after 21000 ms because it logs the simple name of the exception class.
Clues
I found a question where an asker was getting a ConnectTimeout after 21000 ms, despite explicitly setting it to 40000 ms. That's intriguing despite the exception class being different.
I also found a poorly-explained answer which claims that the server side is responsible for the 21000 ms timeout.
My Hunch
I don't think any action or inaction of the server could cause a shorter-than-expected socket timeout on the client. But maybe the TCP stacks in Windows and Android share a common ancestor, or at least use similar connect retry logic.
Could it be that Android imposes a maximum connect timeout of 21000 ms, and setting a longer timeout in HttpURLConnection is futile? Or could this timeout be triggered by some Windows machine on the path between the mobile device and the server? Do some Android versions throw a SocketTimeoutException where others throw a ConnectException?
According to RFC 1122 (TRANSPORT LAYER -- TCP), section 4.2.3.1 ("Retransmission Timeout Calculation"):
"Implementation also MUST include exponential backoff for successive RTO values for the same segment".
So xpa1492's answer sounds plausible (despite its Windows-specific nature); the implementation of a TCP stack either follows this RFC or gets panned for failing to do so.
By the way, RFC 1122 specifies 3 seconds as the initial timeout, explicitly, making xpa1492's (3 + 6 + 12 = 21) answer sound like the answer to your mystery.
And yes, the Android TCP stack shares a common ancestor with Windows TCP stack; they were both created using RFC 1122 as a guide ("[The Linux TCP stack is] an implementation of the TCP protocol defined in RFC 793, RFC 1122 and RFC 2001 with the NewReno and SACK extensions").
I suspect that your problem is related to radio interference, so you might want to try enabling F-RTO, as you might be hitting the "magic number" repeatedly because of the environment in which you are testing.
It seems like it is a Windows default configuration...
https://social.technet.microsoft.com/Forums/windows/en-US/9e7f59dd-6469-4ade-91ca-ceb5bcaf2675/windows-7-tcp-parameter-tcpmaxconnectretransmissions-and-tcpinitialrtt?forum=w7itpronetworking
Based on the link and some further reading, Windows will by default do 3 retries and double the timeout with each attempt, starting a s 3sec one. So you end up with 3sec + 6sec + 12sec = 21sec timeout.
I wrote a crude test app, based on the code in my question, that simulates a connect timeout by attempting to connect to a non-routable address as suggested in this answer. On my Moto G (Android 4.4.2), it throws a SocketTimeoutException in approximately 45 seconds as expected. Curiously, if I do not explicitly set the connect timeout, it instead throws a ConnectException after approximately one minute.
I'm going to write a slightly more sophisticated test app and send it to the customer to try to determine if the device itself is imposing a 21s timeout, or if some router on their mobile network might be the culprit. I'll update this answer with the results.
Result: This appears to be an OS bug that affects the Samsung SPH-P100 (Galaxy Tab 1) from Sprint. I don't have access to a Tab 1 from any other carrier, so this could be blamed on Samsung or Sprint. It does not seem to generally affect Android 2.x, because I have a ZTE X501 running 2.3.6 which allows me to set longer timeouts.
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
I've been looking all over the place for the required bluetooth connection parameters that will work for all three of these operating platforms. I'm using the HOGP (Bluetooth over HID GATT) profile for this project.
My project is an embedded system written by myself with a BLE module that I have control over the following parameters for connection.
Connection Interval Min
Connection Interval Max
Slave Latency
Supervision Timeout
Advertising Interval Min
Advertising Interval Max
My target devices to connect will be to satisfy connnections with Android >= 4.3, iOS7, and >= Win 8.1.
Apple was kind enough to give a document with the appropriate parameters on page 22 in the link below. I have not been able to find any information about Android and Win 8.
https://developer.apple.com/hardwaredrivers/bluetoothdesignguidelines.pdf
My current working settings for iOS7 tested fully with bidirection communication with freeware lightBlue is as follows. My embedded code and host software for iOS7 works.
Connection Interval Min 30ms
Connection Interval Max 56.25ms
Slave Latency 3
Supervision Timeout 5000ms
I've found from another stack overflow page that android allegedly works on 7.5ms Connection Interval from the following links.
Android BLE Connection time interval
http://processors.wiki.ti.com/index.php/Bluetooth_SensorTag?DCMP=lprf-stdroid&HQS=lprf-stdroid-pr-wiki1#Supported_Android_devices
Unfortunately the second requirement from apple iOS spec is that "Interval Min ≥ 20 ms".
Am I not understanding these ranges or how they are interpreted? If I set the Interval min to 7.5ms for Android wouldn't that void apples requirements? How can I satisfy both systems and also Win8 if possible?
My understanding is that the slave device offers a suggested setting in between the min and max and the master (smartphone) alerts the user of the actual selected value in that range.
I appreciated any help with this issue and hope this post could benefit others considering the fairly new and incomplete knowledge base for BLE.
Thanks in advance!
First, the connection interval defines a time window during which both devices use the same frequency to transfer data. There are 37 data channels in total, and connected devices hop through them every Connection Interval.
Thus, both devices has to agree on precise values for these parameters from the beginning in order to be in sync, i.e., connected.
Second, when connection is established the master (or Central) sends connection parameters it supports. The other device (or peripheral) just blindly takes them. iOS by default sets connection interval to 30 ms. After the connection is established the peripheral can request connection parameters update, by defining the min and max values, according to the guidelines apple has provide you with. The receiving part, read iOS in this case, will pick whatever it find best for it between [min;max], and will send back response with exact values it has picked. It also can reject the request, if the values do not comply with the guidelines.
Lastly, 7.5ms is the minimum length of the connection interval defined by Bluetooth specification. The maximum value is 4 s. The lower it is, the higher bandwidth, but higher power consumption. And the opposite in the higher values. The best value depends on the specific application. Considering that you work with HID profile I assume latency is important to you.
iOS says that it supports connection intervals down to 20ms (although I found it hard to achieve this some times), but in your case (HID profile) they also allow 11.25 ms.
Hope that helps.
To modify parameters in Android (requesting from Central to Peripheral) you can do something like this:
private String CONN_SERVICE_UUID = "00001800-0000-1000-8000-00805f9b34fb";
private static final UUID CONN_CHARACTERISTIC_UUID = UUID.fromString("00002a04-0000-1000-8000-00805F9B34FB");
private static final int CONN_INTERVAL = 0x0006;
private static final int SUPERVISION_TIMEOUT = 0x000A;
private void findServiceForConnectionParams(List<BluetoothGattService> gattServices){
BluetoothGattService connGattService = filterServices(gattServices, CONN_SERVICE_UUID);
if (connGattService != null) {
setConnectionInterval(connGattService);
}
}
private void setConnectionInterval(BluetoothGattService gattService) {
if (gattService == null) {
Log.e(TAG, "setConnectionInterval. Gatt service is null!");
return;
}
BluetoothGattCharacteristic connCharacteristic =
gattService.getCharacteristic(CONN_CHARACTERISTIC_UUID);
if (connCharacteristic != null) {
byte[] value = { (byte) (CONN_INTERVAL & 0x00FF), // gets LSB of 2 byte value
(byte) ((CONN_INTERVAL & 0xFF00) >> 8), // gets MSB of 2 byte value
(byte) (CONN_INTERVAL & 0x00FF),
(byte) ((CONN_INTERVAL & 0xFF00) >> 8),
0, 0,
(byte) (SUPERVISION_TIMEOUT & 0x00FF),
(byte) ((SUPERVISION_TIMEOUT & 0xFF00) >> 8)
};
connCharacteristic.setValue(value);
boolean status = mBluetoothGatt.writeCharacteristic(connCharacteristic);
Log.d(TAG, "setConnectionInterval. Change connection interval result: " + status);
} else {
Log.e(TAG, "setConnectionInterval. Connection characteristic is null!");
}
}
private BluetoothGattService filterServices(List<BluetoothGattService> gattServices, String targetUuid) {
for(BluetoothGattService gattService : gattServices){
String serviceUUID = gattService.getUuid().toString();
Log.i(TAG, "serviceUUID: " + serviceUUID);
if(serviceUUID.equals(targetUuid)){
Log.i(TAG, "serviceUUID matches! UUID: " + serviceUUID + " Type: " + gattService.getType());
// no needed, just to check which characteristics are offered
for(BluetoothGattCharacteristic characteristic : gattService.getCharacteristics()) {
Log.i(TAG, "serviceUUID characteristics: " + characteristic.getUuid().toString());
}
return gattService;
}
}
return null;
}
I must say though that it didn't work for me using Android 5 devices both as peripheral and central, because Generic Acces Service (0x1800) is not offering in my device Characteristic 0x2a04 for Preferred Connection Parameters. It's only offering 0x2a00 (device name) and 0x2a01 (appearance).
References:
http://www.cumulations.com/blogs/7/Doing-firmware-upgrade-over-BLE-in-Android
https://developer.bluetooth.org/gatt/characteristics/Pages/CharacteristicViewer.aspx?u=org.bluetooth.characteristic.gap.peripheral_preferred_connection_parameters.xml
https://developer.bluetooth.org/gatt/services/Pages/ServiceViewer.aspx?u=org.bluetooth.service.generic_access.xml
https://farwestab.wordpress.com/2011/02/05/some-tips-on-android-and-bluetooth/
I believe that this characteristic is only meant to provide information to the Central device. That is why it is generally read-only (for me, and cxphong). Bingen's answer does not universally work, and I am not certain it is meant to work that way. Has anybody actually got it to work on a specific device?
It appears that Android and iOS do not consult the information in this read-only characteristic, and so I am not certain that it is very useful.
What works for me is described below, for Cypress peripheral and Android central. A similar approach should work with other devices.
On peripheral, define the preferred connection parameters in a CYBLE_GAP_CONN_UPDATE_PARAM_T structure "params".
After GATT connection, in CYBLE_EVT_GATT_CONNECT_IND event handler (for example), call CyBle_L2capLeConnectionParamUpdateRequest(connHandle, ¶ms).
On the central side, there is nothing to do. After it receives the request, it will initiate the parameter update a bit later.
Cheers,
David