在 Android 4.3-4.4 (API 18-20) 上使用低功耗蓝牙连接请求 MTU [英] Requesting MTU with Bluetooth Low Energy connection on Android 4.3-4.4 (API 18-20)

查看:23
本文介绍了在 Android 4.3-4.4 (API 18-20) 上使用低功耗蓝牙连接请求 MTU的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个蓝牙低功耗应用程序,它要求 MTU 大小高于默认 23 字节.

I have a Bluetooth Low Energy Application which requires an MTU size above the default 23 bytes.

虽然 Android 引入了 BluetoothGatt#requestMTU() 在 API 21 中,是否有任何方法(包括使用私有 API)来实现此 API 21 之前的版本?

Though Android introduced BluetoothGatt#requestMTU() in API 21, is there any way, including use of private APIs, to accomplish this pre API 21?

推荐答案

如果您可以控制外围设备,则可以从外围设备发出 MTU 请求(ATT_OP_MTU_REQ,操作码 0x02).如果外设要求,Android 能够提供更大的 GATT MTU(更新:517 字节是最大值),并且很乐意发送相应的 ATT_OP_MTU_RESP.

If you have control over the peripheral device, you can issue an MTU request (ATT_OP_MTU_REQ, opcode 0x02) from the peripheral. Android is capable of larger GATT MTUs (update: 517 bytes is the maximum value), if requested by the peripheral, and will happily send an according ATT_OP_MTU_RESP.

唯一棘手的是 MTU 交换可能不会与碎片化读/写重叠.一种解决方法可能是在握手的给定时间让客户端休眠,此时外围设备会发送 MTU 请求.另一种可能的解决方法是对触发 MTU 交换的魔法"特征执行 READ 或 WRITE.

The only tricky thing is that the MTU exchange may not overlap with a fragmented read/write. One workaround might be a client-side sleep at a given time of the handshake, where the peripheral sends an MTU request. Another possible workaround would be a READ or WRITE on a "magic" characteristic that triggers the MTU exchange.

但是,随着 MTU 的增加,我更经常收到 Status=133 错误,这可能是由于较大的数据包导致更高的数据包错误率?

However, with an increased MTU, I'm much more often receiving Status=133 errors, possibly caused by a higher packet error rate with larger packets?

这篇关于在 Android 4.3-4.4 (API 18-20) 上使用低功耗蓝牙连接请求 MTU的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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