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.

[参考译文] CC2642R:运行 AoA 演示 SDK 6.20.0029时扫描混淆的结果数据

Guru**** 2798555 points

Other Parts Discussed in Thread: SYSCONFIG

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1184439/cc2642r-scan-results-data-mixed-up-when-running-aoa-demo-sdk-6-20-0029

器件型号:CC2642R
"Thread:SysConfig"中讨论的其他器件

您好!

背景:

rtLS_responser_CC26X2R1_LAUNCHXL_tirtos7_ticlang

rtLS_Coordinator_CC26X2R1_LAUNCHXL_tirtos7_ticlang

SDK 6.20.00.29

修改了工程以在 Adv 数据(在 GAP_DEVICE_INIT_DONE_EVENT 内)内嵌入 MAC 地址、例如:

// AiRISTA added
advertData[19] = pPkt->devAddr[0];
advertData[20] = pPkt->devAddr[1];
advertData[21] = pPkt->devAddr[2];
advertData[22] = pPkt->devAddr[3];
advertData[23] = pPkt->devAddr[4];
advertData[24] = pPkt->devAddr[5];

问题-在 RC_EVT_ADV_REPORT 事件处理程序中、当我们检查堆栈报告的 MAC 地址与 ADV 数据中的相应字节匹配时、确实偶尔会出现差异、因为 BLE 堆栈报告的 MAC 与 Adv 数据中的 MAC 不同。 我们检查 Mac 的最后3个字节,因为前三个字节从不改变我们的设备,我们可以看到下面的行偶尔打印...

case RC_EVT_ADV_REPORT:
{
    GapScan_Evt_AdvRpt_t* pAdvRpt = (GapScan_Evt_AdvRpt_t*) (pMsg->pData);
    uint8_t status;

    if (pAdvRpt->addr[2] != pAdvRpt->pData[21] || pAdvRpt->addr[1] != pAdvRpt->pData[20] || pAdvRpt->addr[0] != pAdvRpt->pData[19])
        AiRISTA_DEBUG_SendDataToBackend_String("*** MISMATCH1 ***");

日志:

MAC 不匹配时、您可以看到偶尔会打印"MISMATCH1"。

 此时、我们有两个广告标签、主 Adv 间隔为100ms、定期 Adv 间隔为100ms、此时协调器同步到这两个标签、同时还接收 IQ 样本。 我们的问题是、如果 Adv Data 与实际源 BLE Mac 混淆、这是否可能导致 IQ 样本在两个标签之间混在一起? 如果发生这种情况、那么在计算时、角度显然将是错误的

最后3条 MAC 为:

29c2 80和12 12 12 12

正常状态下的行与此类似(请注意"29c280、29c280"-来自 BLE 的 Mac 与来自 Adv 数据的 Mac -相同)

"2023-01-04 00:23:24:314"、$AdvRpt、2981883、273676829c280、29c280、80、-46、26、0、0、1、87

不匹配的行(注意事项"29c280、12121212"- BLE MAC 为29c280、Adv 数据中的 MAC 为121212)

2023-01-04 00:23:24:515",*** MISMATCH1 ***$AdvRpt, 2981883,2736768,29c280,1212,80,-68213,0,1,87

下面的代码用于打印这些代码行、以帮助您了解我们正在查看的内容:

char id_rx[12];
char id_tx[12];
char ble_tx[7];
char ble_tx_adv[7];
char interval[7];
char rssi[5];

itoa(AIRISTA_LOC_ID, id_rx,10);
itoa(((pAdvRpt->addr[2]<<16) + (pAdvRpt->addr[1]<<8) + pAdvRpt->addr[0]), id_tx, 10);
itoa(((pAdvRpt->addr[2]<<16) + (pAdvRpt->addr[1]<<8) + pAdvRpt->addr[0]), ble_tx, 16);//THIS IS MAC FROM BLE STACK
itoa(((pAdvRpt->pData[21]<<16) + (pAdvRpt->pData[20]<<8) + pAdvRpt->pData[19]), ble_tx_adv, 16); //THIS IS MAC FROM Adv Data
itoa(pAdvRpt->periodicAdvInt,interval,10);
itoa(pAdvRpt->rssi,rssi,10);

//2022/09/26 - change the @ to $ sign before AdvRpt
//strcpy(buffer, "@AdvRpt,");

strcpy(buffer, "$AdvRpt,");
strcat(buffer,id_rx);
strcat(buffer, ",");
strcat(buffer, id_tx);
strcat(buffer, ",");
strcat(buffer, ble_tx);
strcat(buffer, ",");
strcat(buffer, ble_tx_adv);
strcat(buffer, ",");
strcat(buffer, interval);
strcat(buffer, ",");
strcat(buffer, rssi);
strcat(buffer, ",");


e2e.ti.com/.../2063.log.txt

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

    大家好、Jan、

    感谢您的建议!

    是的、这允许我们通过硬编码 SID 和通道映射来使用16个以上的器件进行测试、这意味着我们必须编译很多不同的固件输出、或者我们提供一种管理通道映射和 SID 的方法。

    在任何情况下,如果你有一个临时修复,请联系,我很乐意帮助测试,如果你给我们甚至测试库文件.

    谢谢。

    伊万

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

    伊凡、您好!

    不用担心! 对于完全解决此问题的延误、我再次表示歉意。 我们正在努力尽快解决这个问题、但与此同时、我想给您一个权变措施、希望它能够解除您的测试和开发障碍。 我很高兴听到该解决方法将起作用。 我将在完成修复后立即联系。

    此致、

    1月

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

    大家好、Jan、

    是否有永久修复的更新?

    谢谢。

    Ivan S.

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

    伊凡、您好!

    很遗憾、目前没有要共享的更新。 已通知研发部门此问题、将尽快修复。 与此同时、该权变措施是否适用于您的评估?  

    此致、

    1月