Android 6.0棉花糖BLE:连接参数 [英] Android 6.0 Marshmallow BLE : Connection Parameters

查看:447
本文介绍了Android 6.0棉花糖BLE:连接参数的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Android 6中的蓝牙低功耗连接参数管理似乎已更改.

The Bluetooth Low Energy connection parameters management seems to have changed in Android 6.

我有一个BLE外围设备,需要使用一些特定的连接参数(特别是连接间隔),并且我想使用BLE规范允许的最小连接间隔(即7,5ms).

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).

Android SDK不允许从BLE GAP Central(智能手机)端进行选择,因此正确的方法是在建立GAP连接后,使我的GAP外围设备发送L2CAP Connection Parameter Update Request.

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.

我要求的参数是:

  • conn间隔最小值:7,5ms
  • conn间隔最大值:7,5ms
  • 从属延迟:0
  • 监控超时:2000ms

这在我测试过的所有Android设备(从4.3到5.x)中均按预期工作:发送L2CAP Connection Parameter Update Request后,我的设备收到带有0x0000(可接受)的L2CAP Connection Parameter Update Response,然后是LE Connection Update Complete event在该处可以看到已充分考虑了所请求的连接参数.

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.

现在,使用Nexus 9平板电脑或2个不同的Nexus 5设备(都具有Android 6.0.1),我可以看到L2CAP Connection Parameter Update Request始终被拒绝(我收到了带有0x0001的L2CAP Connection Parameter Update Response(已拒绝)) .然后,我收到一个LE Connection Update Complete event,可以看到未考虑所请求的连接参数.

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.

我一直在尝试在外围方面使用2种不同的实现方式(一种使用ST Microelectronics的BlueNRG,一种使用Nordic Semiconductor的nRF52),两者的结果完全相同.

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.

然后,经过更多测试:我尝试了不同的参数集,更改了conn interval max(我保持其他参数不变).这是我发现的:

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 :

  • conn间隔最大= 18.75ms,更新请求被接受,间隔设置为18.75ms
  • conn间隔最大= 17.50ms,更新请求被接受,间隔设置为15.00ms
  • conn间隔最大为15.00ms,更新请求被接受,间隔设置为15.00ms
  • conn间隔最大= 13.75ms,更新请求被接受,间隔设置为11.25ms
  • conn间隔最大= 11.25ms,间隔为11.25ms的更新请求被接受
  • 任何其他conn间隔最大值低于11.25ms,我都会被拒绝.

因此,观察发现,Android 6的BLE堆栈处理连接参数的方式已经发生了明显变化.但是似乎没有任何信息或文档可以证实这一点.

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.

我的观察得出的结论是,现在允许的最小连接间隔为11.25ms(实际上符合我的需求),而不是早期的Android版本中的7.5ms.但是凭经验找到它之后,我想确保我不会错过其他一些限制/规则,或者该最小值是否不是动态的,例如取决于当前的电池电量...

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...

最好具有与 Apple的蓝牙设计指南(参阅第3.6节),以使您清楚地了解LE外围设备应如何处理该主题.

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.

有人遇到同样的问题,或者知道来自Google的更多有用信息吗?

Is anyone having the same issue or is aware of some more helpful information from Google ?

推荐答案

比较AOSP 6.0.1_r17和AOSP 5.1.1_r14中来自GattService.java的方法connectionParameterUpdate().在这两种情况下,调用均以相同的参数一路直达bta_dm_api.c中BTA_DmBleUpdateConnectionParams()中的Buedroid.

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;
    }

这可能是您问题的答案的一部分.尽管BLE允许低至7.5ms CI,但我无法推测为什么链路层不会根据外设的要求切换到较低的CI.我不知道android代码的任何部分是否可以控制与外围设备进行协商的结果.

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.

这篇关于Android 6.0棉花糖BLE:连接参数的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆