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.

[参考译文] CC1201:误报 CRC 错误

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

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1493786/cc1201-false-positive-crc-errors

部件号:CC1201
主题中讨论的其他部件:CC1101、、 CC1200

工具/软件:

e2e.ti.com/.../Successful_5F00_Transmission.xlsxe2e.ti.com/.../Failed_5F00_Transmission.xlsx

您好、

我有一个由两个设备组成的系统、它们需要能够相互通信。 一个器件使用 CC1101、另一个器件使用 CC1201。 将数据包从 CC1201传输到 CC1101时没有问题。 不过、我们发现了一个问题、即尽管接收到的数据包的数据字段与发送的数据包的数据字段相匹配、但在从 CC1101传输到 CC1201时、某些数据包被标记为具有 CRC 错误。

我在这个帖子中附加了两个文件、其中包含用于监控和解码 SPI 总线事务的日志。 "xlsx" Successful_Transmission 显示了与发送的三个数据包(数据包#1 (蓝色)、数据包#2 (绿色)和数据包#3 (橙色))的成功交换。 "CRC.xlsx"显示由于数据包2包含 Failed_Transmission 错误(数据包1 (蓝色)和数据包2 (绿色))而导致交换失败。 请注意、虽然已删除每个数据包的数据字段、但我们确认每个发送的数据包的数据字段与接收的数据包的数据字段相匹配。 在这两个电子表格中、数据包的状态字节都以黄色突出显示。

您是否发现我们配置和使用 CC1201的方式有任何问题? 请注意、数据包长度是可变的、可能超过255字节、这就是我们在本例中未使用固定数据包长度模式的原因。

谢谢您、

Trevor

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

    请记住、即使正确接收到有效载荷、也完全有可能出现 CRC 错误。 如果无线数据中的错误位于 CRC 本身而不是有效载荷中、则会发生这种情况(根据有效载荷计算两字节 CRC 并以无线方式传输(在有效载荷之后))

    请不要像您一样在 Excel 工作表中提供设置、而是从 SmartRF Studio 向我发送导出的设置、以便我可以了解您使用的 PHY 等、而无需手动检查每个寄存器。

    我不理解你关于长度的评论。

    您说数据包长度可能超过255、但您正在将无线电配置为可变峰值长度模式(PKT_CFG0 = 0x20)、并将最大数据包长度设置为50 (PKT_LEN = 0x32)

    使用此设置、无线电将始终将安全同步后接收到的第一个字节解释为长度字节、并且它将接收由长度字节指示的字节数。

    如果在同步字之后接收到的第一个字节大于50、则由于数据包长度过滤(PKT_LEN = 0x32)、RX FIFO 中不会放置任何内容

    如果您要接收超过255字节的数据包、则需要将对讲机修剪为无限数据包长度模式、然后在收到有关实际长度的信息后、将其重新编程为固定数据包长度。

    请记住、如果长度字节+有效载荷+附加的状态字节大于128字节、则需要在接收到完整的数据包之前开始读取 RX FIFO。

    从您发送给我的信息中,我无法理解您的代码是如何工作的。

    如果您能共享一些伪代码或真实代码、这样我就能知道您在软件中所做的事情、那会好得多。

    BR

    Siri   

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

    e2e.ti.com/.../cc1201_5F00_parameter_5F00_summary.txte2e.ti.com/.../cc1201_5F00_registers.htmle2e.ti.com/.../cc1201_5F00_settings.c

    尊敬的 Siri:

    感谢您的答复。

    我以三种不同的方式从 SmartRF Studio 导出了 CC1201的设置、因为我不确定哪种设置最适合您、并在本回复中附上了这些设置。 请告诉我是否有更好的方法来导出这些设置。

    目前、我们在使用这些设置将数据包从 CC1101发送到 CC1201时、CRC 错误率为~43%。 在标有 CRC 错误的数据包中、我们未在数据字段中看到任何错误的证据。 我们假设所有数据包都不太可能仅在两个 CRC 字节中出现错误、因此我们怀疑其中至少有一些 CRC 错误是误报。 此假设是否不正确、并且在发送/接收 CRC 时、数据包末尾发生发送/接收错误的可能性明显更大?

    关于消息长度的注释是因为在将固定长度的数据包从 CC1101传输到 CC1201时、没有看到任何误报 CRC 错误。 但是、在我们的协议的这一部分期间发送的数据包没有固定长度、可能超过255字节、这就是我们需要更改 PKT_CFG0中的数据包长度配置的原因。

    我们最初将 CC1201设置为可变数据包长度模式(PKT_CFG0 = 0x20)、最大数据包长度为50 (PKT_LEN = 0x32)、同时将第一条消息(以蓝色突出显示)从 CC1201传输到 CC1101、因此不会出现任何问题。 发送该消息后、我们将 CC1201重新配置为无限数据包长度模式(PKT_CFG0 = 0x40)、以准备 CC1201以接收 CC1101的响应(以绿色突出显示)。

    我们的协议保证 CC1101的响应将超过32个字节、前32个字节是数据包的标头、其中包含完整数据包的数据字段的长度。

    在之前 Excel 工作表中显示的特定情况下、数据包的数据字段长度为83字节(包括上述32字节的标头)。 因此、在 CC1201以无限数据包长度模式接收到数据包的前32个字节后、CC1201将重新配置为最大数据包长度为83 (PKT_LEN = 0x53)、并处于固定数据包长度模式(PKT_CFG0 = 0x00)。 之后、CC1201读取数据包的其余部分以及附加的两个状态字节。

    希望我们对协议中难以生效部分的描述有所帮助、符合您对 CC1201的预期使用方式。 如果您需要更详细地解释我们的协议、请告诉我、我可以与团队讨论我们可以分享的内容。

    再次感谢、
    Trevor

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

    您好、Trevor

    我只是想让大家知道我正在研究这个。

    我认为最好的方法来帮助你自己尝试创建一个小的例子,然后做一些测试。 希望我能够在今天或明天晚些时候为您提供一些信息。

    BR

    Siri

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

    从射频的角度来看、我假设您的设置是可以的、因为当您使用固定的数据包长度时、您能够收到所有内容。

    由于我不清楚您的数据包的外观、并且当您从无限长的数据包更改为固定的数据包长度时、很难准确弄清问题的所在。

    例如、当您接收到正确的数据包、但 CRC 似乎错误时、您是否检查了您在 TX 端发送了正确数量的数据(不确定您是使用的数据包长度固定、还是在无限和固定之间变化)

    我没有试图猜测问题出在您的身边,我做了一个示例来展示如何正确组合无限和固定的数据包长度。

    我在两端都使用了 CC1200、但只要调整 FIFO 大小和 FIFO 阈值、该实现就可以轻松移植到 CC1101。

    由于我假设您的射频设置正常、因此我使用 SmartRF Studio 的默认38.4kbps 设置进行了测试

    我的测试代码使用一个包含32字节长标头的数据包、其中有关将跟随多少个字节的长度信息由该标头的2 LSB 给出:

    • 30字节+ 2长度字节 n
    • N 个有效载荷字节
    • 2个 CRC 字节

    我使用30到530的有效载荷长度测试了代码

    在 TX 端、我使用2个中断:

    • txFifoBelowThresholdISR
      • 每次将 TX FIFO 消耗到7个字节以下时运行中断(可以写入122个字节)
    • packetSentISR
      • 发送数据包时运行中断(由 PKT_LEN 寄存器确定)

    在 RX 侧、我使用3个中断

    • syncReceivedISR
      • 每次收到同步字时运行
    • rxFifoAboveThresholdISR
      • 每次 RX FIFO 填充超过 阈值(FIFO_THR = 120)时运行的函数(可从 FIFO 读取121个字节)
    • packetReceivedISR
      • 当由 PKT_LEN 寄存器确定的完整数据包被接收时运行

    我区分了3种不同的情况:

    • 当完整的数据包(在 TX 端)或完整的数据包+状态字节(在 RX 端)适合 FIFO 时
      • Tx
        • 使用固定数据包长度模式并等待  packetSentISR
      • RX
        • 在  syncReceivedISR 中检查长度、并立即更改为固定数据 包长度模式、然后等待 packetReceivedISR
    • 小于255时、才会传输数据
      • Tx
        • 您仍然可以使用固定数据包长度模式、但需要使用  txFifoBelowThresholdISR 来重新填充 FIFO
      • RX
        • 在  syncReceivedISR 中检查长度并立即更改为固定数据包长度模式  
        •  由于整个数据包长于 FIFO 大小、因此在 FIFO 溢出之前使用 rxFifoAboveThresholdISR 来读取 FIFO
    • 数据包超过255时
      • Tx
        • 在剩余255或更少字节之前、使用无限数据包长度模式、不要切换到固定数据包长度模式
        • 使用  txFifoBelowThresholdISR 补充 FIFO
      • RX
        • 在  syncReceivedISR 中检查长度并 保持在无限数据包长度模式下
        • 在剩余255或更少字节用于接收之前、请勿切换到固定数据包长度模式
        •  由于整个数据包长于 FIFO 大小、因此在 FIFO 溢出之前使用 rxFifoAboveThresholdISR 来读取 FIFO

    下面显示了我的 RX 和 TX 代码。

    如果你不能解决你的问题,请让我知道你正在测试的包,以便我可以尝试在我的结束

    e2e.ti.com/.../cc120x_5F00_infinite_5F00_packet_5F00_length_5F00_mode_5F00_tx.c

    e2e.ti.com/.../cc120x_5F00_infinite_5F00_packet_5F00_length_5F00_mode_5F00_rx.c

    e2e.ti.com/.../cc120x_5F00_infinite_5F00_packet_5F00_length_5F00_mode_5F00_reg_5F00_config.h

    BR

    Siri

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

    Siri、

    对延迟的回复表示歉意、但我要感谢您帮助解决此问题。

    从您的示例中、我发现 FIFO_THR 设置存在一个问题、导致在错误的时候从无限数据包长度模式切换到固定数据包长度模式。 更正该设置后、我没有发现任何误报 CRC 错误的证据。

    再次感谢您的帮助、

    Trevor

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

    很高兴听到你能够解决这个问题:-)

    Siri