• 状态
  • 已锁定 已锁定
  • 回复 10 回复
  • 订户 0 订户
  • 视图 108 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] CC2745R10-Q1：连接交付问题。 如何配置候选节点参数？

admin
Guru**** 2535150 points


请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1536492/cc2745r10-q1-connection-handover-question-how-to-configure-the-candidate-node-params

器件型号：CC2745R10-Q1


工具/软件：

尊敬的 TI 团队：

我们将使用 SDK 版本 9.11 实现连接切换功能、其中两个 CC2745R10 器件用作服务节点和候选节点、并使用移动电话作为对等节点。 服务节点数据通过 CAN 传输到候选节点。 收到数据后、候选节点设置以下四个参数（与 car_node demo 相同，但最后一个参数除外）、并调用 handover_startCandidateNode () 启动移交。

使用这些设置时、候选节点会向应用程序报告 BLEAPPUTIL_LINK_RESIDEND_EVENT、但很快就会报告 BLEAPPUTIL_LINK_RESIDEND_EVENT。 断开原因是 0xFD (0xFD 表示 ll.h 中定义的 LL_STATUS_HANDOFF_FAILED)、HandoverExtCtrl_startCnEvtHandler() 中接收的状态为 0x3E。

我们尝试了 timeDelta、timeDeltaErr、maxFailedConnEvents 和 txBurstRatio 的各种配置、但结果不一致。 有时会发生相同的问题；其他情况下、断开连接原因会发生变化。 例如、对于另一组参数（如下所示）、候选节点仍报告 BLEAPPUTIL_LINK_RESIDEND_EVENT、然后报告 BLEAPPUTIL_LINK_SHORT_EVENT、但断开原因变为 0x3D（（0x3D 表示 LL_STATUS_CONN_TERM_DEUE_TO_MIC_FAILURE（在 ll.h 中定义）、并且 HandoverEvtHandl() 中的状态为 startExt0x00。

对于配置这些参数以实现稳定的交付、您是否有任何建议或最佳实践？

期待您的答复。 非常感谢！

  • 0
    TI__Guru**** 2535150 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Jiang、  

    请给我几天时间来浏览项目并尝试重现您的问题。  

    首先、修正这些变量的理由是什么？ 您似乎不需要特定的值、那么为什么不只将这些值保留为默认值呢？ 请参阅下图：  

    其次、您能为我提供连接移交实施的主要目标吗？ 在与连接移交相关的汽车节点示例中消除了哪些内容？  

    请告诉我、我将提供星期四的回复 (07/10)。  

    谢谢、

    Isaac

  • 0
    TI__Guru**** 2535150 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Isaac、

    感谢您的答复。

    `您的第一个问题、我们注意到这些变量在` ble_device_connection_handwing.py 脚本中是固定的、如下图所示。

    此外,脚本中的`shuthand_data[“data"]`“`对应于 app_extctrl_shuting.c 的`HandoverExtctrl_startSnEvtHandler()`函数中的`pEvt->pData`,如第二个图所示。

    因此、我们修正了这些变量、但实际的移交数据仍然来自服务节点。

    关于您的第二个问题、我们的目标是在我们的一个 DK 项目中实施连接移交功能。 我们参考了汽车节点示例和 SDK 用户指南 (connection-handw.html)、将连接切换功能集成到我们的项目中。

    如果有任何误解或遗漏任何重要细节、请告知我们。

    期待您的反馈。 非常感谢！

    此致、
    Jiang

  • 0
    TI__Guru**** 2535150 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Jiang、  

    好的、您正尝试将连接切换演示移至 C 工程中并消除 python？  

    我仍然在研究这个问题,但一个快速的建议。 尝试增加错过的连接事件的数量。 我想这将是一种变通办法、但它暂时可能有效。  

    请告诉我。  

    谢谢、
    Isaac

  • 0
    TI__Guru**** 2535150 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Isaac、

    是的、我们正在努力将连接切换演示集成到 C 工程中、并删除 Python 组件。 我们已经尝试增加错过连接事件的数量、但问题仍然存在。 我计划在评估板到达后立即与评估板测试连接移交功能、无论是今天还是明天。 我期待着你对这个问题有任何进一步的发现。

    谢谢您、

    Jiang

  • 0
    TI__Guru**** 2535150 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Jiang、  

    您能介绍一下从 Python 迁移到 C 的各个步骤吗？ 我想再次确认没有任何遗漏。  

    此外、我很难测试此特定案例、因为我没有一个工作中的连接移交项目、所有内容都已移至 C。MIC 错误表示外围设备和中央设备之间发送的数据包出现故障。 这可能是由于多种原因造成的、例如加密/解密问题、或者加密请求与其他数据包之间存在冲突。  

    不成功的交接是很重要的情况。 根据堆栈、只有当链路监控超时导致连接失败时、才会终止连接并导致切换失败。  

    您要将哪些数据从服务节点转移到候选节点？ 您如何传输数据？  

    请告诉我。  

    谢谢、
    Isaac

  • 0
    TI__Guru**** 2535150 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Isaac、

    我们使用 CAN 信息启动移交流程。 收到此消息后,服务节点调用 handove_startServingNode (),如所附的屏幕截图所示。 minGattHandle 和 maxGattHandle 的计算方式如红色矩形所示。

    之后、我们在 HandoverExtctrl_startSnEvtHandler 中获取切换数据、然后调用 HandoverExtctrl_sendSnDataToCn 以使用 5 条 CAN 消息将数据发送到候选节点。 在本例中、移交数据长度为 276 字节、AppExtCtrlHandoverSnStartEvent_t 的大小为 12 字节。 我们还在 HandoverExtctrl_sendSnDataToCn 中附加 1 字节校验和（根据之前的 288 个字节计算）、从而使总数据长度为 289 个字节。

    当候选节点接收到所有 5 条 CAN 消息时、它会提取 276 字节的移交数据、并调用 handover_startCandidateNode ()。 我们还通过 UART 打印验证了服务节点和候选节点上的移交数据、校验和匹配。 这表示移交数据正从服务节点正确传送到候选节点。

    如果您需要更多详细信息、敬请告知。

    谢谢您、
    Jiang

  • 0
    TI__Guru**** 2535150 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Jiang、  

    我们将与团队联系、了解这一问题的发生情况。 对延迟的回复表示歉意。  

    谢谢、
    Isaac

  • 0
    TI__Guru**** 2535150 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Isaac、

    感谢您关注此问题。 我们发现了一些可能有助于确定根本原因的发现：

    新发现：
    1.与手机时间相关的行为
    将手机连接到服务节点时、如果我们在开始移交之前等待几分钟、则不会发生 0x3D 错误。 这表明在成功交付之前可能需要一个连接稳定期。

    2、设备特定的行为差异
    iPhone：通常在候选节点上成功交付
    Android 手机：在移交过程中仍遇到 0x3D (MIC_FAILURE) 错误

    为什么需要几分钟的稳定期？ iPhone 和 Android 行为之间的区别是什么?


    谢谢您、
    Jiang

  • 0
    TI__Guru**** 2535150 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Jiang：

    为什么需要几分钟的稳定期？ iPhone 和 Android 行为之间的区别是什么？

    我不确定是否可以回答第一个问题。 第二个问题可能会得到解答、因为 iOS 堆栈和 Android 堆栈具有不同的实现方式。 两者的分析日志可能有助于我们调试问题。

    此致、

    Nima Behmanesh

  • 0
    TI__Guru**** 2535150 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    嗨、Nima、

    对于第一个问题、iPhone 和 Android 都表现出相同的行为 — 两者都需要等待几分钟才能开始移交，以避免 0xFD 错误。

    关于检测日志、设备目前与我们的合作伙伴在其他位置。 我们将在设备再次可用时收集并共享日志。

    感谢您的支持。

    此致、
    Jiang