esp32c3 例程esp-idf-v4.4中gatt_client作为主机模式连接部分芯片通信异常(见内容)[已解决]

[lala51]

应用背景描述：
参考例程gatt_client工程,实现ESP32C3搜索蓝牙设备，即ESP32C3做为主机(客户端)，被测试设备为从机(服务端)，后文所述主机无特殊说明都是指”ESP32C3”,使用主机搜索不同的从机，都可以建立连接，但是有点无法和从机进行通信，从定义从机A可以通信，从机B无法通信。
手机使用nrf connect测试设备A，是可以正常通信的。
两个设备，设备A和设备B的服务信息：

手机两个设备的信息.png (345.85 KiB) Viewed 8002 times

ESP32代码中配置的信息：
配置服务的UUID：FF17 特征：FF02
#define REMOTE_SERVICE_UUID 0xFF17
#define REMOTE_NOTIFY_CHAR_UUID 0xFF02
通过搜索对比设备A和设备B的MAC地址，进行筛选设备A的MAC地址(00 00 80 00 0006) ,设备B的MAC地址(00 00 4A 11 A1 6E)，搜索到设备建立连接后，发送数据“330580010480”，返回数据:”3305800344900052”。
设备A的LOG信息：

ESP32C3主机的_A_log信息

ESP32C3主机的_A_log信息.png (200.11 KiB) Viewed 8002 times

设备B的LOG信息：

ESP32C3主机的_设备B_log信息

ESP32C3主机的_设备B_log信息.png (226.66 KiB) Viewed 8002 times

在使用ESP32C3和设备A、设备B同时时候抓取空口的数据如下：

[lala51]

在使用ESP32C3和设备A、设备B同时时候抓取空口的数据如下：

无法通信 设备A 空口监听数据.

无法通信 设备A 空口监听数据.png (267.66 KiB) Viewed 7997 times

可以通信 设备B 空口监听数据

可以通信 设备B 空口监听数据.png (222.16 KiB) Viewed 7997 times

[lala51]

手机上使用nrf connect测试设备A是可以正常通信的，手机上数据发送使用的是FF01通道，接收的数据是FF02通道，下图是监听抓取的空口交互数据

手机使用nrf connect测试设备A_OK

手机使用nrf connect测试设备A_OK.png (322.51 KiB) Viewed 7996 times

[lala51]

遇到的问题：
1、ESP32C3测试设备B，使用FF02，收发数据没有问题；
2、ESP32C3测试设备A，使用FF02，收发数据异常，错误码提示03；
3、手机上使用nrf connect测试设备A，发送使用FF01 发送数据，手机接受到数据在FF02服务上。
我现在也想配置ESP32C3在服务FF01发送数据，在服务FF02接收数据，但是事与愿违，无法找到ESP32C3相应的配置位置，ESP32的数据发送和接收都是成对的(即使用了FF02发，同时也是FF02收，但设备A好像是不支持这种方式)，小白对于蓝牙协议细节了解较少，也是在不断的学习中，请各位前辈指导，怎么配置才可以实现上述功能，谢谢！！！

[ESP_XuLZ]

企业微信截图_20220714173004.png (551.97 KiB) Viewed 7968 times

原因是 A 设备 0xff02 特性不允许写， 只可以 indicate
所以正常通讯流程应当是：
1. 连接成功，通过那些 发现筛选 特性和描述符 的 API(如 esp_ble_gattc_all_char、esp_ble_gattc_get_attr_count 等)，先找到 0xff01、0xff02 这两个特性的的handle， 在筛选过程中多加些打印， 打印出 uuid 与handle 值的对应关系
2. 注册 0xff02 特性 indicate ，这样 client 可以接收 sever 返回的数据， 使用 esp_ble_gattc_register_for_notify、esp_ble_gattc_write_char_descr
3. 使用 esp_ble_gattc_write_char 去写 0xff01，注意选对 handle, 看你抓包上使用的2是 prepare write request, 可以把 MTU 调大些，应该会选择单包发送的 write request 方式

[lala51]

原因是 A 设备 0xff02 特性不允许写， 只可以 indicate
所以正常通讯流程应当是：
1. 连接成功，通过那些 发现筛选 特性和描述符 的 API(如 esp_ble_gattc_all_char、esp_ble_gattc_get_attr_count 等)，先找到 0xff01、0xff02 这两个特性的的handle， 在筛选过程中多加些打印， 打印出 uuid 与handle 值的对应关系
2. 注册 0xff02 特性 indicate ，这样 client 可以接收 sever 返回的数据， 使用 esp_ble_gattc_register_for_notify、esp_ble_gattc_write_char_descr
3. 使用 esp_ble_gattc_write_char 去写 0xff01，注意选对 handle, 看你抓包上使用的2是 prepare write request, 可以把 MTU 调大些，应该会选择单包发送的 write request 方式

回复：
我按照您的建议将MTU 调大到1000、512、200及其调小15、32等等，使用 esp_ble_gattc_write_char 去写 0xff01，每次协商后，在抓包上的发送命令一直都是 prepare write request方式，不会单包发送的 write request 方式，不知道到为什么？


基于上述问题，我使用了AT指令(主机模式)去测试链接这个蓝牙芯片是可以成功的，命令如下：
AT+RST --复位
OK

AT+BLEINIT=1--模块客户端模式
OK

AT+BLESCAN=1,3,1,"00:00:4A:11:A1:6E"--搜索这个地址的OBU
OK

+BLESCAN:"00:00:4a:11:a1:6e",-31,0201060302e7fe0d094554432d59474b2d30303233,,0
+BLESCAN:"00:00:4a:11:a1:6e",-31,0201060302e7fe0d094554432d59474b2d30303233,,0
+BLESCAN:"00:00:4a:11:a1:6e",-31,,09ff000000004a11a16e,0

AT+BLESCAN=0 --停止搜索这个地址的OBU
OK

AT+BLECONN=0,"00:00:4A:11:A1:6E" --链接这个地址的OBU
+BLECONN:0,"00:00:4a:11:a1:6e"
OK

AT+BLEGATTCPRIMSRV=0 --获取从机提供的基本服务
+BLEGATTCPRIMSRV:0,1,0x1800,1
+BLEGATTCPRIMSRV:0,2,0x1801,1
+BLEGATTCPRIMSRV:0,3,0xFEE7,1
+BLEGATTCPRIMSRV:0,4,0xFF17,1
OK
+BLECONNPARAM:0,20,40,40,0,600

AT+BLEGATTCCHAR=0,4 --获取 GATTC 服务特征

+BLEGATTCCHAR:"char",0,4,1,0xFFE4,0x02
+BLEGATTCCHAR:"desc",0,4,1,1,0x2901
+BLEGATTCCHAR:"char",0,4,2,0xFF02,0x20
+BLEGATTCCHAR:"desc",0,4,2,1,0x2902
+BLEGATTCCHAR:"desc",0,4,2,2,0x2901
+BLEGATTCCHAR:"char",0,4,3,0xFF01,0x0c
+BLEGATTCCHAR:"desc",0,4,3,1,0x2901
+BLEGATTCCHAR:"char",0,4,4,0xFF03,0x10
+BLEGATTCCHAR:"desc",0,4,4,1,0x2902
+BLEGATTCCHAR:"desc",0,4,4,2,0x2901
OK

AT+BLESPPCFG=1,4,3,4,2--注册收发通道
OK
AT+BLESPP--开启透传
OK

发送16进制：330580010480
命令整理：
AT+BLEINIT=1 LE 客户端
AT+BLEADDR? 获取模块的地址
AT+BLESCAN=1 开始扫描
AT+BLESCAN=0 停止扫描
AT+BLESCAN=1,3,1,"00:00:4A:11:A1:6E" 指定扫描的设备
AT+BLECONN=0,"00:00:4A:11:A1:6E" 与从机建立连接
AT+BLEGATTCPRIMSRV=0 获取从机提供的基本服务
AT+BLEGATTCCHAR=0,4 获取 GATTC 服务特征
AT+BLESPPCFG=1,4,3,4,2 注册收发通道
AT+BLESPP 开启透传
下面是AT指令写蓝牙芯片的抓包数据，向FF01通道发送数据的方式是write request 方式。


通过上述比较发现这个蓝牙芯片BK3432，不支持 prepare write request 写方式，只支持 write request 写方式，请问除了设置MTU外，有什么办法，在这例程中实现 write request 这种方式进行数据的写操作吗？

[ESP_XuLZ]

我这边使用两块 esp32c3 对跑 gatt_client 和 gatt_server_service_table 示例（esp-idf release/v4.4）
esp_ble_gap_write_char() 如果发送的 value_len 大于 ATT_MTU 就会使用 prepare write request
当 esp_ble_gap_write_char() 发送的 value_len 小于 ATT_MTU 是使用 write request 单包发送的，不会使用 prepare write request
或者你使用两片 ESP32C3 对跑下，或者提供下抓包文件看看

[lala51]

您好，在回复中无法上传 抓包数据的log文件，故放在百度网盘中了，抓包工具使用的是Wireshark，烦劳您帮忙看看！！！

现在存在问题的是ESP32(主机模式)和BK3432(从机模式)之间通信存在问题，同样设置ESP32(主机模式)和YC1021(从机模式)是没有问题的。
1、使用AT指令测试BK3432成功20221019方式LE SPP.pcapng ------》这个log是使用AT指令操作BK3432成功的log
2、使用程序写FF01测试BK3432失败20221019.pcapng ------》这个log是使用例程指令操作BK3432失败的log
3、使用程序写FF01测试YC1021成功20221019.pcapng ------》这个log是使用例程指令操作YC1021成功的log
4、尝试写BK3432 MTU为131.pcapng------》这个log是使用例程指令操作BK3432失败的，同时将MTU改为131的log
5、使用程序写FF01测试BK3432失败 ESP32打印的log.jpg ------》 这个log是使用例程指令操作BK3432失败时ESP32打印的log

链接：https://pan.baidu.com/s/1V1uZ8Z-_E-9Qbqe4i6qb1Q
提取码：zcjt

[ESP_XuLZ]

你代码gattc_demo.c 文件应用层代码逻辑有问题
你应当想发送的是 AT 发的这些数据

企业微信截图_20221026113534.png (12.6 KiB) Viewed 7348 times

但是你使用gattc_demo.c 中 esp_ble_gattc_write_char 发送的是如下数据

企业微信截图_20221026114003.png (21.76 KiB) Viewed 7348 times

后面带有太多的零和其他无用的数据
所以发送数据前检查下esp_ble_gattc_write_char 的len 值

企业微信截图_20221026114150.png (29.95 KiB) Viewed 7348 times

[lala51]

谢谢您的回复！！！
我按照您建议在该位置打印了一下 len的长度，正常本意长度是6个字节，实际发送的长度是12000字节，正如您上面提示到“发送小于 ATT_MTU 是使用 write request 单包，大于ATT_MTU 是使用prepare write request”，传入发送函数中的数据长度错误，导致蓝牙蓝牙芯片端拒绝接受该数据(一直傻傻的认为无论多长的数据，esp32都会发送ATT_MTU规定的长度呢 )。
重新更正了发送数据长度，目前是可以正常通信的，再次感谢！！！