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.

[参考译文] CC1310:无线 M-Bus 背对背 Rx

Guru**** 1884220 points
Other Parts Discussed in Thread: CC1310, WMBUS
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1321678/cc1310-wireless-m-bus-back-to-back-rx

器件型号:CC1310
主题中讨论的其他器件: WMBUS

您好!

我们将使用 CC1310和应用手册"CC13xx 组合式 wM-Bus C 模式和 T-Mode"中提供的示例开发无线 M-Bus 应用、包括  

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/689154/cc1310-require-partial-mode-example-of-cc1310

我们可以接收数据包、但偶尔会丢失一些数据包、并且希望获得一些建议。

示例是使用一个线程在每次接收到包时激活无线电和回调、但我们已扩展代码来处理错误和 CRC 检查、这可能是原因。

是否可以在背对背接收设置中使用"部分读取"?

我们曾尝试 在不走运的情况下使用 bRepeatNok/bRepeatOk、但可以在回调本身中重新激活回调。

此致 Peter

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

    我已经进行了研发检查、应该没有任何理由不使用重复模式和部分读取条目。 但是、我们没有相关的代码示例、也没有对其进行测试。

    我假设在跟踪数据队列等方面、这会使代码稍微复杂化。

    我不明白为什么这也是必要的。 您不应在回调中进行大量处理、而应将其移动到应用中的其他位置。 然后在接收到数据包后重新启动 RX、然后处理接收到的数据包、同时重新启动射频内核并接收新的数据包。

    Siri

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

    尊敬的 Siri:

    感谢您的快速回复、我将尝试它。

    在回调中停止并重新初始化无线电的最佳方法是什么。 目前我只是设置 rxDone 和 partialReadEntry -> status = data_entry_pending,但有更好的方法吗?

    此致 Peter

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

    你好,Peter

    我不确定我是否理解您在回调中想要做什么。 你是否没有关注你所连接到的线程内的示例?

    您可以在回调中设置长度、如下所示:

    Fullscreen
    1
    RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdPropSetLen);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    这将确保对讲机在接收到正确字节数时自动退出 RX、因此您不必手动停止对讲机。

    今天、我使用重复模式做了一些测试、发现在使用 SET_LEN 命令时无法使用该模式、因此需要将两种重复模式都设置为0。

    Br

    Siri

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

    尊敬的 Siri:

    是的、我遵循该示例并使用  

    Fullscreen
    1
    RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdPropSetLen);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    它工作正常、但在某些情况下会发生错误、我希望在接收到整个包之前重新初始化。  

    此致 Peter

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

    您应该使用 RF_CancelCmd 来退出 RX。

    我正在处理一个更完整的代码示例、该示例中也包含一些错误处理、完成后可以将其发布在此处

    Siri

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

    尊敬的 Siri:

    非常感谢、非常感谢您的帮助、并期待看到您正在学习的示例。

    此致 Peter

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

    早上好!

    我稍微更改了代码、但仍然有一些数据包丢失。 您对下面的代码有什么建议吗?

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /**
    * @file protocol/sndp/src/SndpWMBus.c
    * @brief WMBus message parser
    * @copyright (C) 2023 ReMoni ApS.
    *
    * These computer program listings and specifications, are the property of
    * ReMoni ApS and shall not be reproduced or copied or used in whole or in
    * part without written permission from ReMoni ApS.
    *
    */
    /*---------------------------------------------------------------------------
    Include files
    ---------------------------------------------------------------------------*/
    /* *INDENT-OFF* */
    #include <ti/devices/DeviceFamily.h>
    #include DeviceFamily_constructPath(driverlib/rf_data_entry.h)
    #include <ti/drivers/rf/RF.h>
    #include <remoni/mode.h>
    #include <remoni/Device.h>
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    它仍在进行中、但有点实用。 不过、设置长度实际上效果更好一些、如下所示:

    rf_cmdPropSetLen_wmbus.rxLen = data_entry_header_size + length_position;

    而不依赖 RF_CancelCmd ()。 我错了吗?

    此致 Peter

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

    您好!

    它看起来像使用 RF_cancelCmd (h、ch、0);突然退出产生了影响、所以使用上面的代码做了这个微小的改变。

    此致 Peter

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

    尚未完成演示、但正在进行中。

    只是为了确保我完全理解您的问题。

    您是否丢失了数据包、如未找到同步、还是数据包中出现 CRC 错误。

    如果您丢失了数据包、是否已确认这是时序问题? 即、在传输新的数据包时、您是否已经验证无线电尚未进入 RX?

    如果问题与 CRC 错误有关、您是否已确保遵循勘误表注释中的通报11?

    Br

    Siri

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

    尊敬的 Siri:

    感谢您的更新。  

    我不清楚为什么软件包会丢失、我真的不知道如何进一步调试它。 使用上面的代码、根本不存在任何 CRC 错误、回调不会报告任何异常情况。

    我从水表获得数据 、并过滤掉所有紧凑型封装、因此预计数据永远~2分钟、但有时(每几个小时)存在间隙。 在使用多个有源计量表和紧凑封装的情况下进行调试会有点困难。

    我 还没有实施建议11、因为它与 CPU 从空闲状态切换相关、我不知道是什么情况、但我将在下周执行、因为它不会有任何危害。

    在您的帮助下、上面的代码效果更好、可能每隔几个小时就会丢失一个包裹。 您能看到任何明显的错误或改进建议吗?

    此致 Peter

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

    我将尝试给您提供一些一般的调试提示、以便您可以尝试缩小问题范围。

    如果从您正在传输某些内容的意义上来说数据包丢失了、但没有收到任何数据包、则应检查以下事项:

    您确定器件处于 RX 状态吗? 检查 RX 命令的状态是否为2 (有效)

    将 RF_EventMdmSoft 添加到回调中来查看是否收到 SYNC、也是一个好主意。 通过这种方法、您可以确定数据包是否被过滤掉、或者您是否甚至找不到同步字。

    如果您的设备在 RX 中、但在传输数据包时找不到同步字、可能是因为存在干扰数据包的干扰器导致您错过同步字。 让监听器查看监听器是否接收到数据包始终是一个好主意。 如果监听器收到但并非您(并且您的器件位于 RX 中)、则可能是硬件出错、导致灵敏度不良。

    编写 SW 来接收所有正常数据包通常不算太难、但当您尝试处理所有错误情况时会更困难。

    我制作了一个可用于调试的代码示例。 您应该对设置等进行类似操作、然后确保代码处理所有错误情况。

    为了对此进行测试、我建议不仅要尝试从水表接收正常数据包、 但是、如果有发送器、则可以配置为传输太长、太短、具有 CRC 错误、导致溢出的数据包等的数据包。另外、请确保代码正在处理所有这些情况。

    我的测试代码如下:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /***** Includes *****/
    /* Standard C Libraries */
    #include <stdlib.h>
    /* TI Drivers */
    #include <ti/drivers/rf/RF.h>
    #include <ti/drivers/GPIO.h>
    /* Driverlib Header files */
    #include DeviceFamily_constructPath(driverlib/rf_prop_mailbox.h)
    /* Board Header files */
    #include "ti_drivers_config.h"
    /* Application Header files */
    #include "RFQueue.h"
    #include <ti_radio_config.h>
    #include <ti/sysbios/BIOS.h>
    #include <ti/sysbios/knl/Semaphore.h>
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    我已经测试了以下内容:

    数据包过短:

    A1 A2 A3 A4 1 1

    nRxStopped 递增并且 eventLastCmdDone 被设置

    数据包过长(应用程序将取消 RX 命令)

    A1 A2 A3 A4 14 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0

    nRxStopped 递增,并设置 eventCmdAborted

    有 CRC 错误的数据包:

    A1 A2 A3 A4 5 1 2 3 4 5 6  

    nRxNok 递增并且  eventLastCmdDone 被设置

    OK 数据包:

    A1 A2 A3 A4 5 1 2 3 4 5 6

    nRxOk 递增并且  eventLastCmdDone 和 eventRxOk 被置位

    缓冲区溢出:

    在 rf_runImmediateCmd 的回调中设置断点以溢出

    nBrBuffFull 会递增、而 eventLastCmdDone 和 eventRxBufFull 会被设置

     

    由于您使用的是部分读取条目、因此 CPU 将在射频内核处于活动状态且正在接收数据包时执行代码。 因此、您需要遵循建议11。

    如果您正在使用正常的数据条目、并且在 RX 中完成无线电操作并收到数据包之前未获得回调、则这不是必需的、但在您的情况下是必要的。

    但是、如果问题是缺少同步而不是 CRC 错误、这不能解决您的问题、但您仍然应该实施它以避免 数据包中出现不必要的错误。

    Br

    Siri

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

    尊敬的 Siri:

    谢谢、我来试一下。

    我当前正在调试 T 模式、看起来像  

    RF_runImmediateCmd (rfHandle、(uint32_t*)&RF_cmdReadRfReg); //获取 Mode 值

    仅返回 RF_EventNDataWriten 的正确值、而不返回 RF_EventNDataWriten 的值。 是这样吗?

    此致 Peter

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

    我想您问的是  RF_EventNDataWriten 与 RF_EventDataWritten 的对比情况????

    RF_EventNDataWriten:写入部分读取 Rx 缓冲区的指定字节数

    RF_EventDataWriten: 写入部分读取 Rx 缓冲器的数据

    在我的示例中、长度是同步字之后的字节编号5、这意味着在接收到至少5个字节之前我无法读出长度。

    因此, partialReadEntry0->config.irqIntv 和 partialReadEntry1->config.irqIntv= 5;

    因此、我需要等待第一个 RF_EventNDataWriten 事件、然后才能读取长度信息。

    如果我第一次读取 RF_EventDataWriten 时尝试读取长度(字节5)、则表示尚未接收到长度。

    Siri

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

    尊敬的 Siri:

    感谢您的回答、C 模式现在很稳定。 我引用了我自己的代码、但我认为我已经找到了这个代码并从  

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void callback(RF_Handle h, RF_CmdHandle ch, RF_EventMask e)
    {
    if (e & RF_EventNDataWritten) {
    if (!lengthWritten) {
    lengthWritten = true;
    RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdReadRfReg);
    if (RF_cmdReadRfReg.value == 1) { // C-Mode
    uint8_t preamble = rxDataEntryBuffer[DATA_ENTRY_HEADER_SIZE];
    switch (preamble) {
    case 0xcd:
    {
    uint8_t l_field = rxDataEntryBuffer[DATA_ENTRY_HEADER_SIZE + LENGTH_POSITION - 1];
    uint8_t crc_length = (l_field > 9) ? (2 * (l_field - 10) / 16 + 2 + 1) : 0;
    RF_cmdPropSetLen_wmbus.rxLen = l_field + crc_length + (LENGTH_POSITION - 1) + 2;
    break;
    }
    case 0x3d:
    // Length is 2 bytes longer than wmbusmeters because it is including CRC at the end
    RF_cmdPropSetLen_wmbus.rxLen = rxDataEntryBuffer[DATA_ENTRY_HEADER_SIZE + LENGTH_POSITION - 1] + (LENGTH_POSITION - 1) + 1 - 3;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    至  

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void callback(RF_Handle h, RF_CmdHandle ch, RF_EventMask e)
    {
    if (e & RF_EventNDataWritten) {
    if (!lengthWritten) {
    lengthWritten = true;
    RF_runImmediateCmd(rfHandle, (uint32_t*)&RF_cmdReadRfReg); // Get the Mode value
    rxMode = RF_cmdReadRfReg.value; // Store the mode - reg will change later
    if (rxMode == 1) { // C-Mode
    uint8_t preamble = rxDataEntryBuffer[DATA_ENTRY_HEADER_SIZE];
    switch (preamble) {
    case 0xcd:
    {
    uint8_t l_field = rxDataEntryBuffer[DATA_ENTRY_HEADER_SIZE + LENGTH_POSITION - 1];
    uint8_t crc_length = (l_field > 9) ? (2 * (l_field - 10) / 16 + 2 + 1) : 0;
    RF_cmdPropSetLen_wmbus.rxLen = l_field + crc_length + (LENGTH_POSITION - 1) + 2;
    break;
    }
    case 0x3d:
    // Length is 2 bytes longer than wmbusmeters because it is including CRC at the end
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    但是、这会导致 T 模式封装多于 WMBusMeters 可以看到的具有无效 CRC 的 T 模式封装、并且也会影响 C 模式。 实际上只有1米发送、那么问题出在哪里呢?

    此致 Peter

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

    你好,Peter

    我不确定我是否理解您所问的问题。 "什么意思?

    "这会导致多于 WMBusMeters 可以看到的具有无效 CRC 的 T 模式封装、并影响 C。 模式"

    我无法调试您的实现、我不确定我是否理解您遇到的问题。

    请记住、即使您仅有1米的传输距离、附近也可能有其他仪表可以接收。 此外、由于 wmbus 仅使用2字节的同步字、因此您还将接收伪数据包。 如果接收到伪数据包时占用代码、则此时发送的任何其他数据包都将丢失。

    在验证软件是否按预期工作之前、最好在屏蔽环境中进行一些测试、此时可以完全控制发送到无线电的内容(无干扰源)。

    此外、在调试时将代码简化为仅记录找到的 SYNC 数量、c 模式的数量和 t 模式数据包的数量、并将该数量与您发送的数据包数量进行比较、可能有助于了解传输中有多少其他数据、 这可能会干扰您的数据包。

    Siri

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

    尊敬的 Siri:

    我将尝试进一步解释、不希望您调试我的代码、只需快速查看是否有关闭的东西。

    我认为代码在仅配置为 C 模式(帧格式 A 和 B)时基本没问题、但在启用 T 模式后开始失效。

    我 希望寻找假的 T-Mode 数据包可能会导致 C 模式数据包丢失、但没有办法尽早识别这些情况、例如在新的同步中重新启动?

    我希望能够可靠地处理 C 模式和 T 模式封装。

    此致 Peter

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

    你好,Peter

    仍然不确定我是否理解您遇到的问题。

    当您尝试进行电机控制时、

    1. 接收不到您要发送的 T 模式数据包、
    2. 或者、您是否会收到这些数据包、但还会收到很多虚假 T 模式数据包、这也会导致您丢失 C 模式数据包?
    3. 还有其他问题吗?

    我无法仅通过查看代码来说明问题所在、我只能建议您继续调试问题以缩小问题范围。

    当我们知道问题的原因时、我们也可以查看解决方案。

    我们可以做的是设置具有 SmartRF Studio 的 CC1310 LP、并将其用作监听器。

    您无法从 Studio 运行 C/T 模式补丁、但您可以设置正确的 PHY 参数、例如6字节的固定数据包长度。

    这将给你一个指示,在空气中发生了什么。

    从下图中可以看出、我已将 CC1310在我的办公桌上运行了大约3分钟。

    它接收到27个数据包、其中3个是我从另一个 LP 传输的数据包、其余为噪声或附近的其他仪表。

    从 RSSI 水平可以看出、我实际发送的3个数据包比收集的其余数据包强得多。 一些其他数据包看起来像"真实"C 模式数据包、因为它们具有信令字节(0x54)、其余数据包可能是 T 模式或噪声。

    请注意、wmbus 补丁具有可编程的载波侦听阈值。 此设置默认为-107dBm、因此不接受信号强度低于的同步字。

    出于调试目的、可以将阈值增加到接收到实际发送的数据包的水平、而其他所有内容都将不被接受。

    此处说明了如何更改阈值:

    CC13xx 组合的 wM-Bus C 模式和 T 模式应用手册(修订版 E)

    我对您的代码有一些可能会导致问题的注释:

    在设置了 RF_cmdPropSetLen_wmbus.rxLen 的回调中、您将其设置为 l_field +某个值。

    这意味着得到的长度可以大于255。

    您是否已确保数据条目足够大、从而不会出现溢出的情况?

    从代码来看、似乎您正在设置

    partialReadEntry -> length = MAX_LENGTH + length_position + added_bytes + 4;

    在这里、您不考虑 rxLen 大于 MAX_LEN

    您的代码另一个可能的问题是您没有订阅 RF_EventCmdAborted

     

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    if (e & RF_EventNDataWritten)
    {
    .
    .
    }
    else
    {
    partialReadEntry->status = DATA_ENTRY_PENDING;
    rxDone = true;
    Event_post(rxEvent, RX_EVT);
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    如果您执行 RF_cancelCmd、则不会获得 eventLastCmdDone、而只能获得 RF_EventCmdAborted、这意味着在取消的情况下您的代码不会设置 partialReadEntry -> status = DATA_ENTRY_PUNDING;

    可能还有其他原因、因此、我强烈建议您调试代码、每次仅调试一种数据包类型、以确保所有"错误案例"/"边界案例"都得到正确处理。

    长度字节= 0

    长度字节= 255

    CRC 错误

    C 模式的帧格式错误(不是帧 A 或帧 B)

    Br

    Siri

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

    尊敬的 Siri:

    再次感谢您的帮助、非常感谢。

    我看到的是您的选项2

    或者您是否会收到这些数据包、但还会收到很多虚假 T 模式数据包、这也会导致您丢失 C 模式数据包

    我已经实施了您的建议

    • 已启用事件  RF_EventCmdAborted
    • 将 partialReadEntry ->长度限制为 MAX_LENGTH

    但是设置 载波侦听阈值实际上并不会对任何东西产生影响。 我正在 Linux 上开发、因此使用 SmartRF Studio 有点困难、但我还要尝试获取 Windows 机器。

    这是有道理的,寻找幽灵包将使我松散真正的包.

    此致 Peter

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

    不应将 partialReadEntry ->长度限制为 MAX_LENGTH

    您可能需要增加它、因为您可以接收比此时间更长的数据包。

    在我的示例中、长度字节表示后跟多少个字节(不包括 CRC)

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    / ----------------------------------------------------------------------------------------
    // | DATA_ENTRY_HEADER (12 bytes) | H0 | H1 | H2 | H3 | Length 5 | D1 | D2 | D3 | D4 | D5 |
    // ----------------------------------------------------------------------------------------
    #define DATA_ENTRY_HEADER_SIZE 12
    #define MAX_LENGTH 5
    #define PACKET_HEADER_SIZE 4
    #define LENGTH_POSITION 5
    #define NUM_APPENDED_BYTES 0
    static uint8_t rxDataEntryBuf0[DATA_ENTRY_HEADER_SIZE + MAX_LENGTH + LENGTH_POSITION + NUM_APPENDED_BYTES]
    partialReadEntry0->length = MAX_LENGTH + LENGTH_POSITION + NUM_APPENDED_BYTES + 4;
    RF_cmdPropSetLen.rxLen = payloadLength + LENGTH_POSITION - 1; // Must subtract 1 due to rxConf.bIncludeHdr = 1 (H0 in the figure above)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    有效载荷长度从不大于 MAX_LENGTH (5)、因此最大 rxLen i 将设置为9。

    MAX_LENGTH 为255。 我不知道 wmbus 数据包的格式、因此不知道其中包含的内容、但如果您有如下内容:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    / -------------------------------------------------------------------------------------------------------
    // | DATA_ENTRY_HEADER (12 bytes) | H0 | Length 255 | D1 | D2 | D3 | D4 | D5 |------| D255 | CRC1 | CRC2 |
    // -------------------------------------------------------------------------------------------------------
    #define DATA_ENTRY_HEADER_SIZE 12
    #define MAX_LENGTH 255
    #define PACKET_HEADER_SIZE 1
    #define LENGTH_POSITION 2
    #define NUM_APPENDED_BYTES 0
    static uint8_t rxDataEntryBuf0[DATA_ENTRY_HEADER_SIZE + MAX_LENGTH + LENGTH_POSITION + NUM_APPENDED_BYTES]
    partialReadEntry0->length = MAX_LENGTH + 2 + LENGTH_POSITION + NUM_APPENDED_BYTES + 4;
    RF_cmdPropSetLen.rxLen = payloadLength + 2 + LENGTH_POSITION - 1; // Must subtract 1 due to rxConf.bIncludeHdr = 1 (H0 in the figure
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    必须将2添加到 partialReadEntry0->length 和 rf_cmdPropSetLen.rxLen 中。

    如果将 CS 阈值增大到高值根本没有帮助(例如、-50dBm、具体取决于您的发送器的强度)、我猜大概是问题与处理噪声/伪数据包无关。

    Br

    Siri

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

    尊敬的 Siri:

    我认为、至少目前将大小限制为 MAX_LENGTH 是可以的。 我还没有看到任何这样长的软件包、我们正在通过另一个具有更严格限制的协议转发这些软件包。

    我可能没有以正确的方式或在正确的位置提高 CS 阈值。 I 使用  

    HW_REG_OVERRIDE (0x6090、0x0ACE);//载波侦听阈值覆盖

    并尝试在不同的地方甚至像0x0AFF 一样使用它、但没有任何明显的差别。

    此致 Peter

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

    覆盖已是应与该补丁一起使用的设置的一部分、因此您只需修改它(而不是将其添加到其他位置:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    #include DEVICE_FAMILY_PATH(driverlib/rf_mailbox.h)
    #include DEVICE_FAMILY_PATH(driverlib/rf_common_cmd.h)
    #include DEVICE_FAMILY_PATH(driverlib/rf_prop_cmd.h)
    #include <ti/drivers/rf/RF.h>
    #include DEVICE_FAMILY_PATH(rf_patches/rf_patch_cpe_wmbus_ctmode.h)
    #include DEVICE_FAMILY_PATH(rf_patches/rf_patch_mce_wmbus_ctmode.h)
    #include DEVICE_FAMILY_PATH(rf_patches/rf_patch_rfe_wmbus_ctmode.h)
    #include "smartrf_settings.h"
    uint32_t txShapeTMode[] = {0x00000000, 0x00000000, 0x00000000, 0x4B110200, 0xF2F0E1A6, 0xF2F2F2F2};
    uint32_t txShapeCMode[] = {0x00000000, 0x00000000, 0x00000000, 0x440F0200, 0xD9D8CA96, 0xD9D9D9D9};
    // TI-RTOS RF Mode Object
    RF_Mode RF_prop =
    {
    .rfMode = RF_MODE_PROPRIETARY_SUB_1,
    .cpePatchFxn = &rf_patch_cpe_wmbus_ctmode,
    .mcePatchFxn = &rf_patch_mce_wmbus_ctmode,
    .rfePatchFxn = &rf_patch_rfe_wmbus_ctmode,
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    如果您这样做、您收到的所有数据包的 RSSI 均为-50 dBm 以上、因此您可能有一些您不知道的强干扰器/仪表、或者您的问题不是虚假数据包。

    使用 SmartRF Studio 将同步事件添加到回调和/或测试中将帮助您了解这一点。

    Siri

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

    尊敬的 Siri:

    谢谢、这是我的错。

    现在它的工作和价值-85给出了合理的结果,没有许多"鬼"在我的工作地点,这是非常嘈杂。 我将在明天的实际情景中进行测试、并在团队中进行讨论。

    TI 建议在嘈杂环境中使用大约-90的值还是应 保持在-107?

    此致 Peter

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

    这取决于具体情况、很难给出任何好的建议。

    设置较高的阈值(假设为-90dBm)将减少由于噪声(或附近的其他仪表)而导致的错误数据包的数量、因此您更有可能接收到想要的数据包、因为接收器不会被占用来处理不适合您的数据包。

    另一方面、这也会设置您的灵敏度级别、因为您将无法接收信号强度低于-90dBm 的任何数据包(即使这些数据包是为您准备的)。

    我假设在数据包的开头有一些信息可以用来确定数据包是否适合您(某种 ID 等?)

    如果有、我想您可以检查该信息、并在数据包不适合您时取消 RX、而不必等待接收整个数据包、然后再进行检查。

    Siri

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

    尊敬的 Siri:

    好的、谢谢、这是讲得通的。 我想我将进一步测试和完善这一点、现在您已向我指出了正确的方向。

    谢谢、祝您愉快。 此致 Peter

x 出现错误。请重试或与管理员联系。