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

查看:39
本文介绍了Android 6.0 Marshmallow 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 Peripheral 设备发送一个 L2CAP 连接参数更新请求在建立 GAP 连接之后.

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
  • 监督超时:2000 毫秒

这在我测试过的所有 Android 设备上都按预期工作,从 4.3 到 5.x:在发送 L2CAP 连接参数更新请求后,我的设备收到一个 L2CAP 连接参数使用 0x0000(接受)更新响应,然后是 LE 连接更新完成事件,我可以看到请求的连接参数已被很好地考虑在内.

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 连接参数更新请求 总是被拒绝(我收到一个L2CAP 连接参数更新响应 with 0x0001 (rejected)).然后我收到一个 LE 连接更新完成事件,在那里我可以看到请求的连接参数没有被考虑在内.

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.

我在外设方面尝试了两种不同的实现方式(一种使用 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 间隔最大值(我保持其他参数相同).这是我发现的:

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.75 毫秒,更新请求被接受,间隔设置为 18.75 毫秒
  • conn 间隔最大 = 17.50 毫秒,更新请求被接受,间隔设置为 15.00 毫秒
  • conn 间隔最大 = 15.00 毫秒,更新请求被接受,间隔设置为 15.00 毫秒
  • conn 间隔最大 = 13.75 毫秒,更新请求被接受,间隔设置为 11.25 毫秒
  • conn 间隔最大 = 11.25 毫秒,更新请求被接受,间隔设置为 11.25 毫秒
  • 任何其他连接间隔最大值低于 11.25 毫秒,我都会被拒绝.

因此观察结果表明,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.25 毫秒(这实际上符合我的需要),而不是早期 Android 版本中的 7.5 毫秒.但是根据经验找到它后,我想确保我没有遗漏一些其他约束/规则,或者如果最小值不是动态的,例如取决于当前的电池电量......

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.5 毫秒的 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 Marshmallow BLE:连接参数的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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