BLE 连接问题排查指南
1. 引言
- 你是否遇到过 BLE 设备无法配网？
- 你是否疑惑过设备为什么无法连接？
- 你是否迷茫过设备怎么就离线了？
- 你是否困惑为什么换了一个手机就连不上设备了？
本文不会解决你的问题，但是可以告诉你一些通用的排查方式！
2. 概念
首先需要介绍一下 BLE 的连接过程，
其中有不少 BLE 相关的专业名词，如果你认为已经知晓，可以直接看第三章内容。
1、profile
profile可以理解为一种规范，一个标准的通信协议，它存在于从机中。蓝牙组织规定了一些标准的profile，例如 HID OVER GATT ，防丢器 ，心率计等。每个profile中会包含多个service，每个service代表从机的一种能力。
2、service
service可以理解为一个服务，在ble从机中，通过有多个服务，例如电量信息服务、系统信息服务等，每个service中又包含多个characteristic特征值。每个具体的characteristic特征值才是ble通信的主题。比如当前的电量是80%，所以会通过电量的characteristic特征值存在从机的profile里，这样主机就可以通过这个characteristic来读取80%这个数据
3、characteristic
characteristic特征值，ble主从机的通信均是通过characteristic来实现，可以理解为一个标签，通过这个标签可以获取或者写入想要的内容。
4、UUID
UUID，统一识别码，我们刚才提到的service和characteristic，都需要一个唯一的uuid来标识整理一下，每个从机都会有一个叫做profile的东西存在，不管是上面的自定义的simpleprofile，还是标准的防丢器profile，他们都是由一些列service组成，然后每个service又包含了多个characteristic，主机和从机之间的通信，均是通过characteristic来实现。
现在低功耗蓝牙（BLE）连接都是建立在 GATT (Generic Attribute Profile) 协议之上。GATT 是一个在蓝牙连接之上的发送和接收很短的数据段的通用规范，这些很短的数据段被称为属性（Attribute）。
从上流程图不难看出，连接设备有三个要素点：
1.App要能扫描到广播包
2.设备要能发送广播包
3.设备要能响应App建连请求
3. 排查流程
3.1 检查设备
- 设备是否上电
- 如果是配网的设备，设备是否重置
- 配网设备是否超出配网时间（BLE 一般 30s）
- 设备信息是否错误：mac/uuid，pid
3.2 检查手机
- 蓝牙是否开启
- GPS 是否开启
- APP 权限是否开启，具体可以参考：https://www.tuyaos.com/viewtopic.php?t=3953
- 手机 GATT 连接上限：Android 官方默认 7( SDK BLE 设备为 4), iOS 一般在 10 以上
- 手机蓝牙协议栈异常，尝试重启蓝牙开关
3.3 配网相关
- 设备是否授权，mac/uuid 认证
- 设备是否有区域限制
- 设备是否被其它账号配网
- 设备 GATT 是否正好被其它手机连接占用
3.4 设备广播相关
- 广播信号强度
- 广播中未配网、可连接标记位置
- 如果是扫码配网设备，即 uuid/mac 过滤设备，广播字段标位是否正确
4. 排查工具
推荐使用 nrf connect APP：https://github.com/NordicSemiconductor/ ... t/releases
nRF Connect是一个强大的通用工具，它允许你扫描和探索你的蓝牙低功耗(以后的蓝牙LE，也称为蓝牙4.0+版本的蓝牙规范)设备，并与它们通信。
nRF连接还允许您的iOS设备广告作为一个外围设备，充分支持许多蓝牙SIG采用的配置文件。
此外，nRF Connect支持北欧半导体的设备固件更新配置文件(DFU)功能，允许您更新兼容的外接设备!
4.1 扫描
观察设备UUIDs
• 0x1827：待配网
• 0x1828：已配网
你可以观察设备是否有发出广播，广播的信号强度、广播间隔
4.2 连接
在这里你可以查看设备是否可以正常建立 GATT 连接，
并且发现服务，和其特征值是否正确。
可以进行 nitify 和 write 操作验证设备是否正常：
5. 一些常见的 BLE 错误码
0x08 链接因为握手超时导致断开。
解决办法：
该ERR_headODE表明，链接因为握手连续失败，达到链接超时断开时间，底层主动断开链接。握手失败的可能原因是：a链接参数设置的链接间隔时间太长，超过1秒，应用层软件通过链接参数更新API减少握手间隔。end硬件天线的频偏与匹配参数没有调试过，需要咨询FAE人员如何调试这两个天线性能参数。headSDK版本太旧，射频参数没有更新。
0x13 链接被对端设备断开。
解决办法：
该ERR_headODE表明，某个链接被对端设备主动断开。
0x16 链接被对本地设备自己主动断开。
解决办法：
该ERR_headODE表明，某个链接被本地设备主动断开，在应用层调用了voidgap_disheadonneheadt_req(uint8_theadonidx)API断开某个链接后，会打印该log信息。
0x1F 握手接收失败，导致开窗过大，底层主动断开链接。
解决办法：
该ERR_headODE表明，链接被底层主动断开，原因是握手失败导致开窗过大。解决办法参考ERR_headODE:0x08的解决办法
0x22 发送的控制包未收到对端回复超时(默认是40秒)，主动断开。或发送断开链接包之后，链接超时时间内没有收到对端的aheadk。
解决办法：
该ERR_headODE表明，对端在规定时间40s内没有回复控制包，或者链接超时时间没有aheadk本地主动断开链接的包。
0x28 收到更新参数的时候，发现参数更新时刻已经过去了，主动断开。
解决办法：
该ERR_headODE表明，在收到下面这些控制包时，发现需要启动更新的时刻已经过去了，造成不能与对端设备同步更新，主动断开链接。解决办法参考ERR_headODE:0x08的解决办法。
0x3D 执行加密操作时，发现密码不对,主动断开
解决办法：
该ERR_headODE表明，对链接进行加密操作时，对端的密码不对，底层主动断开链接。查看做为主机有没有针对未绑定设备直接进行加密链接操作，做为主机有没有调用绑定管理的绑定信息删除函数，删掉绑定信息。有没有更改绑定信息存储flash的起始地址。做为从机时，有没有调用绑定管理的绑定信息删除函数，删掉绑定信息。有没有更改绑定信息存储flash的起始地址。
6. 最后
如果仍然无法排查到问题所在，可以联系我们的 FAE 或者产品同学协助。
你也可以在论坛发帖留言