主题中讨论的其他器件:CC2340R5
尊敬的 TI 团队:
我们的代码基于 data_stream 示例、当智能手机应用程序使用无响应的写入缓慢发送数据时、没有问题、 DSS_writeAttrCB 的回调正在正确接收数据。 当应用发送非常快时、 DSS_writeAttrCB 回调会接收 Frist 数据包、然后再也不接收数据、这是在特性使用加密时发生的情况、如果我们不使用加密和绑定、则数据会正确接收。 内部蓝牙堆栈似乎没有资源。 您是否知道哪个参数会影响该行为?
我等待你的评论。
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
尊敬的 TI 团队:
我们的代码基于 data_stream 示例、当智能手机应用程序使用无响应的写入缓慢发送数据时、没有问题、 DSS_writeAttrCB 的回调正在正确接收数据。 当应用发送非常快时、 DSS_writeAttrCB 回调会接收 Frist 数据包、然后再也不接收数据、这是在特性使用加密时发生的情况、如果我们不使用加密和绑定、则数据会正确接收。 内部蓝牙堆栈似乎没有资源。 您是否知道哪个参数会影响该行为?
我等待你的评论。
您好!
在以下链接中、您可以在重现问题时检查 ROV。 https://youtu.be/VGf-jsIAUH8
我看不到任何问题,至少我看不到它。
此致
您好!
这是不可能 控制连接间隔在 Android 的确切值,只有三种模式
BluetoothGatt。 CONNECTION_PRIORITY_LOW_POWER
BluetoothGatt。 connection_priority_balanced
BluetoothGatt。 CONNECTION_PRIORITY_HIGH
使用 connection_priority_low_power 值并 拒绝 BLEAPPUTIL_LINK_PARAM_UPDATE_REQ_EVENT 以及 BLEAppUtil_paramUpdateRsp (pReq、false)、我可以获得36的连接间隔。 通过这个值、我向您确认、问题仍然存在。
下面的视频向您展示呼叫堆栈内容以及连接间隔为36的问题。
我可以说的唯一一个观察结果是、删除 UART MenuModule_printf 该问题需要更多的时间才能发生、大约还需要5秒。
不是很重要
您好!
感谢您确认问题以不同的连接间隔出现。 我们最近发布了8.10 SDK。 您可以在新的 SDK 上重新测试吗? BLE5堆栈进行了多项改进和修复、这些改进和修复可能会影响您看到的行为。 其中一些内容可在此处查看: https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/8.10.00.55/exports/docs/ble5stack/release_notes_ble5stack_3_03_01_00.html
此致、
1月
您好!
感谢您在新 SDK 上验证这一点! 我已使用您的自定义应用程序进行了测试、我认为我看到的行为与您相同。
使用 该应用程序、我可以看到自定义项目广告:

然后、我可以连接

之后、我可以成功发送单个数据包、看起来就像这样

发送突发时、 它似乎在几秒钟内有效、但随后挂起。

暂停执行会在此处显示器件:

要确认、这是您在您这边看到的吗? 我想确认一下、我们在继续调试时查看的行为与此相同。
此致、
1月
您好!
我已经做了更多的调试、发现问题的计时是位变量。 我添加了一些可跟踪已发送的指示数量和已发送的写入数量的打印语句。


在测试过程中、我发现写入量各不相同。 现在、我猜到 BLE5-Stack 由于指示和写入次数太多而变得不知所措。 我想在下周早些时候截取一些嗅探器日志、以便更好地了解无线通信中发生的情况。
与此同时、我有一些建议、看看我们是否可以解决这个问题。
1.您能尝试降低写入和指示发送的速度吗? 我会将速度减半、直到碰撞不再发生。
2.您可以尝试使用通知而不是指示吗?
3.是否可以在 GATT 写入突发期间停止指示流? 通过这种方式、在任何给定的时刻发送指示或 GATT 写入、但不能同时发送两个指示。
此致、
1月
您好!
很抱歉我迟到了答复。
1.您能尝试降低写入和指示发送的速度吗? 我会将速度减半、直到碰撞不再发生。
我尝试用 handler.postDelayed 在 Android 中发送写入,它允许您发送具有特定周期的写入,其分辨率约为+-10ms。 写入间隔25ms 时失败、较高值有效。 指示周期未修改、因此它仍在发送指示、并且在收到回调时、它会再次发送指示。
2.您可以尝试使用通知而不是指示吗?
在突发模式下、如果我在收到 无响应写入回调时使用 BLEAppUtil_invokeFunction 发送通知、则也会失败。
3.是否可以在 GATT 写入突发期间停止指示流? 通过这种方式、在任何给定的时刻发送指示或 GATT 写入、但不能同时发送两个指示。
我修改了 Android 测试应用和数据流示例、方式如下:当 CC2340R5收到写入而没有响应时、它会向应用发送指示、当应用收到指示时、应用会向 CC2340R5发送无响应的写入。 采用这种方法、一切都正常工作。
在这种情况下、从 CC2340R5的角度来看、它正在快速发送指示和接收 GATT 写入、但不能同时发送。
你这边有什么新消息吗?
此致
您好!
计划于下周初发布。 请密切关注 SDK 的下载页面。可用后、请重试、然后查看问题是否仍然出现。 如果在新 SDK 中仍出现此问题、则建议重试 PDU 大小和数量设置为255。
此致、
1月
您好!
我对这里的延误深表歉意。 获取监听器日志需要额外的时间。 我使用 Ellisys BLE 监听器拍摄了以下日志:
e2e.ti.com/.../BLE_5F00_Packet_5F00_Log.btt
如您所见、当突发发生时、会发生非常大量的指示和 GATT 写入。 我想我们试图在太短的时间内(以不同的方式)发送太多数据。 您可以尝试降低发送指示的频率、还是可能在突发开始使指示减慢之前向 CC2340R5发送消息? 我想看看我们能否在能够执行的指示和写入数量之间找到折衷方案。
此致、
1月
您好!
我们开发的固件使用已在已投入生产的其他芯片组中实现的通用 BLE GATT 协议、但没有问题、例如使用 NRF52840时、突发模式会正常工作。
降低应用端 GATT 写入频率的想法是不可接受的、因为这不在我的控制范围内、在这种情况下、CC2340R5不得崩溃。 我愿意缩短指示周期、因为它在我的控制下、您能告诉我一种以准确方式检测 TI BLE 堆栈何时开始覆盖的方法吗? 然后、我将发送 BLE 堆栈何时饱和的指示、以免出现问题。 我想在写入之间放置一个计时器、如果该值小于某个崩溃值、则等待发送指示、直到该值更好。 您能告诉我其他的方法来做一些流量控制,以控制过热情况吗?
您应该同意上述解决方案是一种权变措施、如果是 BLE5-Stack 问题、则应自行修复。
我认为安排一个小电话交流想法和解决方案 可能很有趣。 您能管理它吗?
此致