[参考译文] CC2745R10-Q1：[BLE 6.0 CS DKC]信道探测中的长持续时间测距问题

您好：

似乎可能是与 python 脚本相关的溢出错误。 我会将其分配给我的团队成员、他们将在下周回复您。

此致、

Nima Behmanesh

您好普雷斯顿  

测试环境是否与之前的 E2E 主题相同？ 沟通的环境是 1m 至 10m、其中启动器位于车辆内。 测试 LOS 和 NLOS 情况？ 这种情况是否仍然存在？  

当您说一致报告时、是否始终报告无效结果 (0xFFFF FFFF 或 429496795)、或者您是否获得了一些有效结果、但大多数结果无效？  

问题发生时是否可以捕获嗅探器日志？  

此外、将在本周结束前公开发布 9.11.01 版本。 此 SDK 将包含大量 CS 问题。 9.12 的发布旨在为我们即将上市的新 MCU 提供初始 SDK。 9.11.01 将包含更多与 CS 相关的修复程序。 我建议在发布时切换到此 SDK。  

同时、请回答上述问题、并告知我是否可以使用监听器日志！  

谢谢、
Isaac

您好、 Isaac

我们仅在 NLOS 情况下测试了此问题、测试范围保持在 1-10 米。 “始终报告无效数据“是指系统始终报告无效结果 (0xFFFFFFFF 或 4294967295)。

用于捕获嗅探器日志的工具需要应用程序过程、可能需要一到两天的时间来安排。 但是、如果本周更新了新 SDK、我更希望先验证新版本优先级。 谢谢你。

此致！

普雷斯顿

您好普雷斯顿  

我将在 9.11.00.18 SDK 上运行信道探测测试、看看是否可以在我这边重现问题。 您能告诉我您使用的天线配置和使用的 TX 功率吗？  

嗅探器需要一些时间来安排。 如果可能、请提供错误的监听器日志。 此外、我建议在今天或明天发布的 9.11.01 SDK 中试用该 SDK。  

如前所述、我将在接下来的几天内进行测试、并捕获监听器日志。  

谢谢、  

Isaac

您好、 Isaac

我已根据文档规范配置了双天线设置、CC2340 和 CC2745 均采用此配置。 TX 功率设置为默认值 0x80。

此致！

普雷斯顿

您好、 Isaac

我收到了关于优先验证新 SDK 的说明。 您是否会告知我新 SDK 何时发布？

目前、我们需要在客户现场进行功能演示、并希望使用具有优化信道探测功能的 SDK。 谢谢你。

此致！

普雷斯顿

您好普雷斯顿  

点击此处可找到最新的 SDK。 最新的 SDK 版本为 9.11.01.19。  

如果您对新 SDK 有任何疑问、敬请告知。

此外、CC2745R10-Q1 的最大 TX 功率为 10dBm、而 CC2340R5-Q1 的最大 TX 功率为 8dBm。 如果每个器件使用最大 TX 功率、请务必相应地调整 TX_POWER_DELTA (CC2745R10-Q1 最大 TX 功率为 0x02、而 CC2340R5-Q1 最大 TX 功率为 0x02)。  

谢谢、
Isaac

您好、 Isaac

我正在使用新的 SDK、并已按照前面的方法切换到音乐算法、但发现所有报告的距离值均无效（当使用自适应算法配置时，仅生成无效的值；但是，当配置了 NN 时，可以获得有效的范围值）。 新 SDK 是否需要其他配置选项？

配置方法如下所示：

uint16_t CSProcess_OpenSession( void )
{
    uint16_t handle = CS_PROCESS_INVALID_SESSION;

    // Find an available slot
    for (uint16_t i = 0; i < CS_PROCESS_MAX_SESSIONS; i++)
    {
        if (gCsProcessDb.sessionsDb[i].isInitiated == FALSE)
        {
            handle = i;
            break;
        }
    }

    if (handle != CS_PROCESS_INVALID_SESSION)
    {
        // Mark the session as active
        gCsProcessDb.sessionsDb[handle].isInitiated = TRUE;

        // Clear filtering DB
        memset(&(gCsProcessDb.sessionsDb[handle].filteringDb), 0, sizeof(CSProcessFiltersDb_t));

        // Mark filtering as not initialized
        gCsProcessDb.sessionsDb[handle].filteringDb.initDone = FALSE;

        // Initialize BleCsRanging module configuration.
        // Note that numAntPath parameter is still unknown at this point
        // TODO: Make these values configurable from outside of the module
        BleCsRanging_initConfig(&gCsProcessDb.config);

        // Use adaptive algorithm
        gCsProcessDb.config.algorithm = BleCsRanging_Algorithm_Music;
        gCsProcessDb.config.distFusion = BleCsRanging_DistanceFusion_Min;

        gCsProcessDb.config.sumAntPath = BleCsRanging_MAP_Individual;

    }

    return handle;
}

 BleCsRanging_Algorithm_Music 在 CSProcess_OpenSession() API 中将算法修改为。

此致！

普雷斯顿

无效值为 4294967295.attached 是运行时日志。

e2e.ti.com/.../music_5F00_py.txt

您好普雷斯顿  

音乐和自适应算法选项不再可用。 我们已将 CS 距离处理切换为完全基于 NN 的系统。 选择 MUSIC 和 Adaptive Algorithm 选项将产生无效的数据结果。  

如果您有任何其他问题、请告诉我。  

谢谢、

Isaac

您好、 Isaac

这是否意味着新发布的 SDK 将不再支持音乐算法？ 我们之前的测试都基于音乐算法。 如果我们切换到 NN 算法、则需要重新分析信道探测测距数据。 我们希望与您确认这一点。

此致！

普雷斯顿

您好、 Isaac

我将关闭此问题。 关于与 SDK 相关的新问题、我将在一个新问题中跟踪它们。 链接：e2e.ti.com/.../cc2745r10-q1-channel-sounding-fixed-point-ranging-test-shows-abnormal-fluctuations-in-distance-values

此致！

普雷斯顿