找回密码
 立即注册

微信扫码登录

查看: 278|回复: 9

[BLE SDK] blc_gatt_pushHandleValueNotify发送成功,但对方收不到

[复制链接]

7

主题

13

回帖

99

积分

不屈白银

积分
99
发表于 2025-9-22 15:51:17 | 显示全部楼层 |阅读模式 来自 广东深圳
Information
说明:   建议参照本版块置顶帖内容输入必要信息
芯片型号: tlsr8258
SDK及版本: 多链接sdk
我使用两个tlsr8258,一个做主,另一个做从,  可以正常连接,并配对成功;
配对成功之后我使用:blc_gatt_pushHandleValueNotify接口给从机发送消息,blc_gatt_pushHandleValueNotify返回值是成功,但对方收不到消息,请问可能的原因有哪些?
注:atthandle这些都是正确的。

7

主题

13

回帖

99

积分

不屈白银

积分
99
 楼主| 发表于 2025-9-22 16:48:09 | 显示全部楼层 来自 广东深圳
尝试用:blc_gatt_pushWriteRequest 是可以收到的,这两个接口有啥本质区别, 我用tlsr8258作为从机和app连接时,使用blc_gatt_pushHandleValueNotify给手机发送消息,手机是可以收到的

7

主题

13

回帖

99

积分

不屈白银

积分
99
 楼主| 发表于 2025-9-22 17:41:41 | 显示全部楼层 来自 广东深圳
we_5031366653 发表于 2025-9-22 16:48
尝试用:blc_gatt_pushWriteRequest 是可以收到的,这两个接口有啥本质区别, 我用tlsr8258作为从机和app连 ...

好像, 明白了,和app通信时本tlsr8258是作为server,作为server时使用blc_gatt_pushHandleValueNotify接口发送。 我现在的使用场景是:本tlsr8258作为master 连接另一个tlsr8258,此时本tlsr8258相当于client,此时应该使用blc_gatt_pushWriteRequest 接口发送

0

主题

18

回帖

76

积分

不屈白银

积分
76
发表于 2025-9-23 15:07:40 | 显示全部楼层 来自 上海
是的,你可以详细看一下蓝牙规范。下面是截取的规范内部内容,供你参考:

3.4.7.1 ATT_HANDLE_VALUE_NTF
A server can send a notification of an attribute’s value at any time.

3.4.5.1 ATT_WRITE_REQ
The ATT_WRITE_REQ PDU is used to request the server to write the value of an
attribute and acknowledge that this has been achieved in an ATT_WRITE_RSP PDU.

7

主题

13

回帖

99

积分

不屈白银

积分
99
 楼主| 发表于 2025-9-25 11:19:26 | 显示全部楼层 来自 广东深圳
TL_ZRL 发表于 2025-9-23 15:07
是的,你可以详细看一下蓝牙规范。下面是截取的规范内部内容,供你参考:

3.4.7.1 ATT_HANDLE_VALUE_NTF

感谢答疑, 这部分我还有个疑问想彻底搞清楚;
在我测试验证的过程中,在主机和从机上都定义有如下服务:
1.   主机给从机发送消息时,我指定了handle,并在从机上设置了回调函数:spp_onReceiveData,此时在spp_onReceiveData中可以正确接收和处理;
2.    从机上收到消息之后,然后通过blc_gatt_pushHandleValueNotify给主机回复业务消息,此时也指定了handle,但是实际测试发现,从机发送给主机的消息都在core_gatt_data_handler中收到了(blc_gatt_register_data_handler(core_gatt_data_handler)), 我的疑问是:从机发送给主机的消息也指定了handle,同时主机上也设置了回调函数,但是回调函数没起作用,所有消息都被core_gatt_data_handler拦截了,我想了解下原理,感谢
static const attribute_t my_Attributes[] = {

    {ATT_END_H - 1, 0,0,0,0,0},        // total num of attribute


    // 0001 - 0007  gap
    {7,ATT_PERMISSIONS_READ,2,2,(u8*)(&my_primaryServiceUUID),         (u8*)(&my_gapServiceUUID), 0},
    {0,ATT_PERMISSIONS_READ,2,sizeof(my_devNameCharVal),(u8*)(&my_characterUUID), (u8*)(my_devNameCharVal), 0},
    {0,ATT_PERMISSIONS_READ,2,sizeof(my_devName), (u8*)(&my_devNameUUID), (u8*)(my_devName), 0},
    {0,ATT_PERMISSIONS_READ,2,sizeof(my_appearanceCharVal),(u8*)(&my_characterUUID), (u8*)(my_appearanceCharVal), 0},
    {0,ATT_PERMISSIONS_READ,2,sizeof(my_appearance), (u8*)(&my_appearanceUIID),         (u8*)(&my_appearance), 0},
    {0,ATT_PERMISSIONS_READ,2,sizeof(my_periConnParamCharVal),(u8*)(&my_characterUUID), (u8*)(my_periConnParamCharVal), 0},
    {0,ATT_PERMISSIONS_READ,2,sizeof(my_periConnParameters),(u8*)(&my_periConnParamUUID),         (u8*)(&my_periConnParameters), 0},

     ................................

    // 002e - 0035 SPP for data test
    {8,ATT_PERMISSIONS_READ,2,16,(u8*)(&my_primaryServiceUUID),         (u8*)(&TelinkSppServiceUUID), 0},
    {0,ATT_PERMISSIONS_READ,2,sizeof(TelinkSppDataServer2ClientCharVal),(u8*)(&my_characterUUID),                 (u8*)(TelinkSppDataServer2ClientCharVal), 0},                                //prop
    {0,ATT_PERMISSIONS_READ,16,sizeof(SppDataServer2ClientData),(u8*)(&TelinkSppDataServer2ClientUUID), (u8*)(SppDataServer2ClientData), 0},        //value
    {0,ATT_PERMISSIONS_RDWR,2,2,(u8*)&clientCharacterCfgUUID,(u8*)(&SppDataServer2ClientDataCCC)},
    {0,ATT_PERMISSIONS_READ,2,sizeof(TelinkSPPS2CDescriptor),(u8*)&userdesc_UUID,(u8*)(&TelinkSPPS2CDescriptor)},
    {0,ATT_PERMISSIONS_READ,2,sizeof(TelinkSppDataClient2ServerCharVal),(u8*)(&my_characterUUID),                 (u8*)(TelinkSppDataClient2ServerCharVal), 0},                                //prop
    {0,ATT_PERMISSIONS_RDWR,16,sizeof(SppDataClient2ServerData),(u8*)(&TelinkSppDataClient2ServerUUID), (u8*)(SppDataClient2ServerData), (att_readwrite_callback_t)&spp_onReceiveData},        //value
    {0,ATT_PERMISSIONS_READ,2,sizeof(TelinkSPPC2SDescriptor),(u8*)&userdesc_UUID,(u8*)(&TelinkSPPC2SDescriptor)},
};

0

主题

18

回帖

76

积分

不屈白银

积分
76
发表于 2025-9-26 14:06:37 | 显示全部楼层 来自 上海
本帖最后由 TL_ZRL 于 2025-9-26 14:15 编辑

你的问题我理解一下:你已经在core_gatt_data_handler中收到了对端消息,也知道可以通过加打印来分析数据包,但不清楚具体如何添加 handle 的处理逻辑。
具体操作步骤很明确:
在core_gatt_data_handler函数中,先找到处理ATT_OP_HANDLE_VALUE_NOTI(通知类型)的代码分支
在这个分支里,添加针对你指定 handle 的判断,例如:
c
运行
// 假设你的回复消息handle是0x1234,主机回调函数是host_spp_callback
if (attHandle == 0x1234) {  // 替换为你的实际handle值
        // 调用你的回调,传入连接句柄、数据和长度
}
这样添加后,当从机回复的消息带有你指定的 handle 时,就会自动触发你的主机回调函数,实现预期的业务处理逻辑了。如果不确定 handle 值是否正确,可以先在这个位置加打印确认:printf("收到通知的handle: 0x%04X\n", attHandle);

7

主题

13

回帖

99

积分

不屈白银

积分
99
 楼主| 发表于 2025-9-26 15:07:44 | 显示全部楼层 来自 广东深圳
TL_ZRL 发表于 2025-9-26 14:06
你的问题我理解一下:你已经在core_gatt_data_handler中收到了对端消息,也知道可以通过加打印来分析数据包 ...

谢谢 回复,我想表达的不是这个意思,可能是我没有描述清楚,我的意思是:
1.   在主机和从机上都定义有 TelinkSppDataClient2ServerUUID服务,回调函数为:spp_onReceiveData
2.   主机发送给从机的消息会自动触发spp_onReceiveData接收到消息;

我的疑问是:
从机 回复给主机的消息 为什么不会被主机的spp_onReceiveData自动触发接收,而是被core_gatt_data_handler收到,

0

主题

18

回帖

76

积分

不屈白银

积分
76
发表于 2025-9-28 16:44:07 | 显示全部楼层 来自 上海
主机(Central Role) host 的逻辑主要在应用层实现,因此相关逻辑需要添加到core_gatt_data_handler中。
协议栈内部未处理这部分逻辑,主要原因是:
- 兼容性:不同 SDP 实现存在差异,交由应用层处理可灵活适配各种场景
- 扩展性:方便后续扩展新的解析需求或自定义处理逻辑,无需修改底层协议栈

7

主题

13

回帖

99

积分

不屈白银

积分
99
 楼主| 发表于 2025-9-28 17:12:12 | 显示全部楼层 来自 广东深圳
TL_ZRL 发表于 2025-9-28 16:44
主机(Central Role) host 的逻辑主要在应用层实现,因此相关逻辑需要添加到core_gatt_data_handler中。
...

明白了,十分感谢

0

主题

18

回帖

76

积分

不屈白银

积分
76
发表于 2025-9-28 17:26:41 | 显示全部楼层 来自 上海
感谢你的提问
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Telink forum ( 沪ICP备17008231号-1 )

GMT+8, 2025-10-12 17:44 , Processed in 0.103248 second(s), 20 queries .

Powered by Telink 隐私政策

泰凌微电子版权所有 © 。保留所有权利。 2024

快速回复 返回顶部 返回列表