• 状态 Resolved
  • 已锁定 已锁定
  • 个回复 18 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 673 次查看
  • 用户 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.

[参考译文] CC110L：将 ATA5760功能移至基于 CC110L 的解决方案-一些问题

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

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1237299/cc110l-moving-ata5760-functionality-to-cc110l-based-solution---some-questions

器件型号：CC110L
主题中讨论的其他器件： CC1101、 CC115L

您好！

我最近又重新启动了一个项目，希望将(过时的) ATA5760设备的功能复制到 CC110L 芯片(另请参阅 https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1036447/trying-to-get-synchronous-serial-mode-w-manchester-encoding-to-work-so-far-getting-only-noise )。

目前、我已设置好 CC110L、可以与某些发送器配合使用、但不能与所有发送器配合使用。 我想我遇到了一些关于 IF 和带宽的问题、我很难找到答案。

旧的 ATA5760使用950 kHz 的中频和300 kHz 甚至600 kHz 的带宽,但当我在 CC110L 中设置这些参数时,事情根本不起作用-- 载波输出(CS)不响应、串行信号输出始终显示噪声。 在 IF 设置为~395kHz (FSCTRL1 = 0x0F)和带宽~60kHz (MDMCFG4：MDMCFG3 = 0xF637)的情况下、我可以获得到目前为止的最佳性能。

遗憾的是、尤其是 CC110L 仍然无法正确选择旧的发送器、这可能是因为其发送器频率与新产品略有不同、并且60kHz 带宽太窄。 另一个问题是、我只设计了较新的产品、而对较旧的产品没有正确的射频规格。

由于我对有关数字接收器的更详细的细节还不是很了解、因此我有一些问题：

  • 绝对接收器带宽(频率范围)与基础频率(869.200MHz)有何关系？ 这一带宽是以 Fbase 为中心的吗?所以绝对频率范围是 Fbase-1/2BW。 Fbase+1/2BW？ 或者是 Fbase 的最低频率,频率范围从 Fbase ... Fbase+BW？
  • 即使是在60kHz 接收器带宽下可靠工作的发送器产品、在超过80kHz 的频率下也无法正常工作、即使在非常近距离(1米)也是如此、这是我不明白的。 这怎么会发生呢？ 更大的带宽应该使接收各种信号变得更容易、而不是更困难、在这一范围内、噪声不应该把事情弄得一团糟。 另外、数据表提到300 kHz 及以上的带宽对于这个类型的应用来说是很正常的。
  • 是否实际选择了"重要"？ 在使用模拟接收器时、我知道正确选择 IF 以及对 IF 电路进行调优和滤波的重要性、但 CC110L 等器件在这方面对我来说更像是一个黑盒。 现在我有 SmartRFStudio 7在 Linux 下的 Wine 工作、我注意到 IF 频率显然是自动选择的。

感谢您提供任何信息、

此致、

理查德

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

    您好、Richard、

    • 绝对接收器带宽(频率范围)与基础频率(869.200MHz)有何关系？ 这一带宽是以 Fbase 为中心的吗?所以绝对频率范围是 Fbase-1/2BW。 Fbase+1/2BW？ 或者是 Fbase 的最低频率,频率范围从 Fbase ... Fbase+BW？

    请参阅应用手册  SWRA122  (CC11xx 灵敏度与频率偏移和晶体精度间的关系)： https://www.ti.com/lit/swra122

    第2部分  介绍了如何选择 RX BW 设置(也适用于 CC110L)；它 以为中心Fbase。 其他部分也值得查看、以了解特色 PHY 的推荐设置。

    • 即使是在60kHz 接收器带宽下可靠工作的发送器产品、在超过80kHz 的频率下也无法正常工作、即使在非常近距离(1米)也是如此、这是我不明白的。 这怎么会发生呢？ 更大的带宽应该使接收各种信号变得更容易、而不是更困难、在这一范围内、噪声不应该把事情弄得一团糟。 另外、数据表提到300 kHz 及以上的带宽对于这个类型的应用来说是很正常的。

    值得仔细检查您在 CC110L 中使用的晶体的容差 -如 SWRA122更详细地介绍了(有关指向该文档的链接、请参阅上文)、您需要在 RX BW 设置中考虑这一点。

    如果较旧的变压器的发送器频率与较新产品略有不同、您是否能够测量它们并了解这种差异？ 即、工作/非工作发送器之间的区别是什么？  了解有关较旧发送器的更多信息将非常有助于解决此问题。

    • 是否实际选择了"重要"？ 在使用模拟接收器时、我知道正确选择 IF 以及对 IF 电路进行调优和滤波的重要性、但 CC110L 等器件在这方面对我来说更像是一个黑盒。 现在我有 SmartRFStudio 7在 Linux 下的 Wine 工作、我注意到 IF 频率显然是自动选择的。

    频率编程详情请参阅  第5.21节 的  CC110L 数据表：  https://www.ti.com/lit/swrs109 (还链接至  表5-34 它提供了控制的寄存器说明FREQ_IF。 简而言之、是的、它很重要。

    在 SmartRF Studio 中、您可以看到FSCTRL1.FREQ_IF寄存器根据 PHY 进行了调整、因此您可以查看这些寄存器以进一步了解 CC110L。

    从 SWRA122： 如果发送器载波频率和接收器 LO 频率存在错误、则 IF 频率也存在错误。 为简单起见、假设发送器和接收器中的频率误差相等(晶体类型相同)。 如果接收器有–X ppm 的误差、而发送器有+X ppm 的误差、则 IF 频率将有+2×X ppm 的误差(CC11xx 使用低侧 LO 注入)。 相反、如果接收器有+X ppm 的误差、而发送器有–X ppm 的误差、则 IF 频率将有–2×X ppm 的误差。

    还有以下主题有助于理解： https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/241448/cc1101 -请参阅 Sverre 提供的第一个答案、尤其是有关 CC1101/CC110L 特定信息的部分。

    此致、

    扎克

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

    您好、Zack、

    感谢您发送编修。 我看到我还有更多的学习要做。

    关于那些工作和故障发送器产品：工作的产品在869.195和869.205 MHz 上产生2-FSK (具有~15 kHz =20 ppm 的容差)、较旧的产品分别显示在平均869.245和869.285 MHz 上、显然具有更大的容差(最差的一个显示几乎高出30 kHz 的频率)。 与 CC110L 配合使用的晶体为27MHz 10ppm。

    如果我稍微增加基础频率、结果会变得稍好一些。

    事情会更加复杂、因为我使用"原始"串行同步输出(CS、串行时钟、SSDATA)、而不是内部数据包处理、这是因为旧的数据包格式(基本为1k 波特曼彻斯特编码、但只有一个同步位、而不是同步字)。 这是一个这样的数据包的样子：

    它基本上只有24个前导码位、后跟一个同步位、后跟三个或四个有效负载字节(此处未显示第四个字节)。 到目前为止、我还没有成功地配置 CC110L 在内部将其处理为曼彻斯特编码数据并在 RX FIFO 中获得有效载荷。

    我怀疑外部控制器中对这个时钟和数据流的处理不具备很强的容错能力、尽管我看不到较旧和较新产品在数据包格式方面有什么不同。

    因此,所有的改进建议或尝试的事情是欢迎的-我当然有一些更多的阅读要做!

    再次感谢、此致、

    理查德

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

    如果我理解正确、则会通过无线方式发送以下内容：

    CC110L 可以最少查找2个字节的 SYNC、因此两个 SYNC 位必须组成一个新的同步字以及前导码的一部分。 此外、还应知道 CC110L 会将01解读为0、将10解读为1：

    因此、您可以尝试将 CC110L 配置为0x00 0x01的2字节同步字(16/16)、然后查找3字节长的数据包(使用固定的数据包长度)。

    然后、数据包将通过以下形式接收：0xFE、0xAC、0x5B

    Siri

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

    谢谢、这看起来很有希望！

    我已经决定从 CC110L 射频参数方面的问题入手、仔细地从头开始仔细检查和计算所有内容(例如、我注意到偏差参数太高)、注意使用 SmartRF Studio 建议的寄存器值。

    如果这与通过外部控制器的旧同步串行检测一起使用、我接下来将尝试实施您的建议、因为它会更简单并且很可能更强大。

    我会在收到结果和/或更多问题后立即回复到这个问题。

    此致、

    理查德

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

    好的、我一直在努力让它工作、但到目前为止没有成功。 下面是一般方法：

    1. 数据包长度(PKTLEN)= 4 (见第6点)
    2. 为载波侦听(CS)输出设置 GDO2 (GDO2信号选择= 0x0E)。 GDO2连接到控制器的轮询/中断输入。
    3. 等待 CS 变为高电平。
    4. 当 CS 变为低电平时、我们可能已经接收到一个数据包。
    5. 使用 SNOP 读取命令选通(0xBD)检查 CC110L 状态寄存器。 低半字节应该为我们提供 RX FIFO 中的字节数量。
    6. 当不为零时、从 RX FIFO 中读取这个数量的字节(执行这个过程的原因是发射器能够发送3或者4个字节)。

    只要我仍在使用同步串行模式-返回的状态字节始终为0x10 (RX 模式有效、FIFO 中0字节、符合预期)、步骤1至4就可以工作。

    但当我将 PKTCTRL0位5：4从01 (SS 模式)更改为00 (正常 FIFO 模式)时、会完全错误。 首先、我在 GDO2上不再获得 CS 信号、无论发送器是否处于活动状态。 此外、当我在此时读取状态寄存器时、我总是在初始化后第一次得到0x04、显然这表明 FIFO 中有4个字节并且器件处于空闲模式(这不是我所期望的)。

    在读取这4个字节(看起来像随机噪声)后、状态寄存器现在显示为预期的0x00。 RX 在接收到指定的字节数后自动关闭、必须针对下一个数据包显式重新开启(SRx)(MCSM1 = 0x30)。

    但当我打开接收器时、状态寄存器会立即报告 FIFO 溢出(0x6F)、 读取 RX FIFO 只会产生无限的随机字节流(每行的第一个字节为状态寄存器、随后的四个字节是我从 RX FIFO 中读取的字节)： 

    0x6F 0x43  0x71  0x2B  0xE9 
0x6F 0xBA  0x48  0x41  0xD5 
0x6F 0x8E  0x51  0xD4  0x2A 
0x6F 0x3A  0xCC  0xB0  0x7D 
0x6F 0xC2  0x90  0x20  0x3E 
0x6F 0x52  0xBA  0x20  0x62 
0x6F 0xEE  0xC4  0x43  0xED 
0x6F 0xE0  0x9B  0x09  0x02 
0x6F 0x71  0xA1  0x57  0xD3
0x6F ...

    因此、我在这里基本上处于损耗状态。 接收器不再对我的发送器做出响应、而是用无穷的噪声流填充 RX FIFO。

    但出于完整性考虑、我目前的寄存器设置如下；我希望忽略一些简单的设置： 

    0x06			    ; [0x00 - GDO2_CFG] Carrier Sense out
0x0E			    ; [0x01 - GDO1_CFG] Carrier Sense out / SPI-DO
0x0C			    ; [0x02 - GDO0_CFG] Serial Synchronous Data Out
0x47			    ; [0x03 - FIFOTHR] RX FIFO and TX FIFO thresholds
0x00			    ; [0x04 - SYNC1] Sync word, high byte
0x01			    ; [0x05 - SYNC0] Sync word, low byte
0x04			    ; [0x06 - PKTLEN] Packet length
0x40			    ; [0x07 - PKTCTRL1] Packet automation control
0x00			    ; [0x08 - PKTCTRL0] Packet automation control - set normal FIFO mode, fixed packet length
0x00			    ; [0x09 - ADDR] Device address
0x00			    ; [0x0A - CHANNR] Channel # 0
0x0F			    ; [0x0B - FSCTRL1] Frequency synthesizer control => IF = 395.50781 kHz
0x00			    ; [0x0C - FSCTRL0] Frequency synthesizer control
0x20,0x31,0x4D	    ; [0x0D-0x0F - FREQ2:1:0] Frequency setting: 0x20 31 0D = 2109709 => 869.199692 MHz
0x96			    ; [0x10 - MDMCFG4] Modem configuration: Channel bandwidth = 168.7500 kH
0x37			    ; [0x11 - MDMCFG3] Modem configuration: Symbol rate = 2.002000809 kHz
0x00			    ; [0x12 - MDMCFG2] Modem configuration: 2-FSK, 16/16 sync word bits
0x02			    ; [0x13 - MDMCFG1] Modem configuration: 2 preamble bytes minimum
0xE5			    ; [0x14 - MDMCFG0] Modem configuration: Channel spacing = 199.813843 kHz
0x24			    ; [0x15 - DEVIATN] Modem deviation setting => 
0x07			    ; [0x16 - MCSM2]
0x30			    ; [0x17 - MCSM1] Main Radio Control State Machine configuration: IDLE after RX
0x18			    ; [0x18 - MCSM0] Main Radio Control State Machine configuration: Calibration from IDLE to RX
0x16			    ; [0x19 - FOCCFG] Frequency Offset Compensation configuration
0x6C			    ; [0x1A - BSCFG] Bit Synchronization configuration
0x03			    ; [0x1B - AGCCTRL2] AGC control
0x43			    ; [0x1C - AGCCTRL1] AGC control
0x91			    ; [0x1D - AGCCTRL0] AGC control
0xF8			    ; [0x20 - RESERVED]
0x56			    ; [0x21 - FREND1] Front end RX configuration
0x10			    ; [0x22 - FREND0] Front end TX configuration
0xE9			    ; [0x23 - FSCAL3] Frequency synthesizer calibration
0x2A			    ; [0x24 - FSCAL2] Frequency synthesizer calibration
0x00			    ; [0x25 - FSCAL1] Frequency synthesizer calibration
0x1F			    ; [0x26 - FSCAL0] Frequency synthesizer calibration
0x59			    ; [0x29 - RESERVED]
0x7F			    ; [0x2A - RESERVED]
0x3F			    ; [0x2B - RESERVED]
0x81			    ; [0x2C - TEST2]
0x35			    ; [0x2D - TEST1]
0x09			    ; [0x2E - TEST0]

    你知道我在这里做错了什么吗？

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

    不确定我是否理解您的代码、或您为什么要这么做。

    若要生成设置、请使用 SmartRF Studio。

    设置必要的射频参数、如频率、带宽、偏差和数据速率。

    然后设置必要的数据包配置。

    假设您使用的是38.4kbps 设置、并且所有射频参数默认为 OK。

    然后您需要更改以下内容：

    2字节同步字(0x00、0x01)

    固定的数据包长度

    数据包长度3 (不确定在上面所示的示例中为什么要将其设置为4 、而 PAYLOAD 为0xFE、0xAC、0x5B

    通过 SmartRF Studio 的设置、IOCFG = 0x06 (在上升沿接收同步、在下降沿接收数据包)

    当您使用数据包引擎时、不应使用 CS 作为 MCU 的中断、然后当数据包被接收时会有信号)

    您的 Vode 应简单地执行以下操作：

    初始化 MCU

    重置对讲机

    初始化无线电

    频闪灯 SRX

    等待 GDO0上的下降沿中断(数据包接收)

    您现在可以读取 TX FIFO

    在 Studio 中使用默认设置时、append_status = 1、并且在 FIFO 中不会有必须读取的5个字节：

    3个有效载荷字节和2个状态字节。

    Siri

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

    我使用 Studio 进行了快速测试、其中我使用 CC115L 作为发送器、使用 CC110L 作为接收器。 我不确定您的所有射频参数是否正确、但想向您展示数据包处理功能。 您刚刚意识到您说数据包也是4个字节、但您没有在图中使用该字节、因此我使用了4个字节。

    对于发送器、我没有使用曼彻斯特、并将完整的数据包写入 TX FIFO：

    从 Studio 进行寄存器设置：

    发送： 

    static const registerSetting_t preferredSettings[]= 
{
  {CC115L_IOCFG2,           0x2E},
  {CC115L_IOCFG0,           0x06},
  {CC115L_FIFOTHR,          0x47},
  {CC115L_SYNC1,            0x55},
  {CC115L_SYNC0,            0x56},
  {CC115L_PKTCTRL0,         0x05},
  {CC115L_FREQ2,            0x21},
  {CC115L_FREQ1,            0x6E},
  {CC115L_FREQ0,            0x3A},
  {CC115L_MDMCFG4,          0xF6},
  {CC115L_MDMCFG3,          0x43},
  {CC115L_MDMCFG2,          0x00},
  {CC115L_DEVIATN,          0x15},
  {CC115L_MCSM0,            0x18},
  {CC115L_RESERVED_0X20,    0xFB},
  {CC115L_FSCAL3,           0xE9},
  {CC115L_FSCAL2,           0x2A},
  {CC115L_FSCAL1,           0x00},
  {CC115L_FSCAL0,           0x1F},
  {CC115L_TEST2,            0x81},
  {CC115L_TEST1,            0x35},
  {CC115L_TEST0,            0x09},
  {CC115L_MARCSTATE,        0x01},
};

    接收： 

    // Address Config = No address check 
// Base Frequency = 869.199646 
// CRC Autoflush = false 
// CRC Enable = false 
// Carrier Frequency = 869.199646 
// Channel Spacing = 199.951172 
// Data Format = Normal mode 
// Data Rate = 2.00224 
// Deviation = 5.157471 
// Device Address = 0 
// Manchester Enable = true 
// Modulated = true 
// Modulation Format = 2-FSK 
// Packet Length = 4 
// Packet Length Mode = Fixed packet length mode. Length configured in PKTLEN register 
// Preamble Count = 4 
// RX Filter BW = 58.035714 
// Sync Word Qualifier Mode = 16/16 sync word bits detected 
// TX Power = 0 
// PA table 
#define PA_TABLE {0x50,0x00}

static const registerSetting_t preferredSettings[]= 
{
  {CC110L_IOCFG0,           0x06},
  {CC110L_FIFOTHR,          0x47},
  {CC110L_SYNC1,            0x00},
  {CC110L_SYNC0,            0x01},
  {CC110L_PKTLEN,           0x04},
  {CC110L_PKTCTRL1,         0x00},
  {CC110L_PKTCTRL0,         0x00},
  {CC110L_FSCTRL1,          0x06},
  {CC110L_FREQ2,            0x21},
  {CC110L_FREQ1,            0x6E},
  {CC110L_FREQ0,            0x46},
  {CC110L_MDMCFG4,          0xF6},
  {CC110L_MDMCFG3,          0x43},
  {CC110L_MDMCFG2,          0x0A},
  {CC110L_DEVIATN,          0x15},
  {CC110L_MCSM0,            0x18},
  {CC110L_FOCCFG,           0x16},
  {CC110L_RESERVED_0X20,    0xFB},
  {CC110L_FSCAL3,           0xE9},
  {CC110L_FSCAL2,           0x2A},
  {CC110L_FSCAL1,           0x00},
  {CC110L_FSCAL0,           0x1F},
  {CC110L_TEST2,            0x81},
  {CC110L_TEST1,            0x35},
  {CC110L_TEST0,            0x09},
  {CC110L_CRC_REG,          0x21},
  {CC110L_RSSI,             0x80},
  {CC110L_MARCSTATE,        0x01},
};

    大家可以看到、数据包格式正确、我能够以正确的格式接收数据包。

    但是、如果我发送20个数据包、我只接收其中的8个。

    这可能是由于 RF 参数错误、或者使用的同步字不是很好。

    我不是射频专家、所以我无法解释为什么如此多的数据包丢失了、但希望您能获得正确的格式。

    Siri

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

    好的、在仔细比较您的设置(并考虑了您的26 MHz 晶体与我的27 MHz 晶体)后、我设法获得与您相同的结果。

    事实证明,我输入了0x40为 PKTCTRL1而不是0x00 -- 可能是因为 SmartRF Studio 的用户界面非常繁琐(在"轻松模式"和"高级模式"之间切换会擦除所有经过仔细调节的设置、而在"轻松模式"下保存配置时、无法在"高级模式"中加载配置、反之亦然)。

    然而、与在您的设置中一样、接收器仍然无法检测到大量的数据包(而基于 ATA5760的原始接收器未检测到一个数据包)。 我将尝试与一位射频专家一起解决这个问题、他也拥有所有必要(且昂贵)的测量设备。 我真的希望我能解决这个可靠性问题、因为这~50%的数据包丢失在最终用户应用中是完全不可接受的。 我会在这方面取得成果后，尽快发表跟进意见，虽然这可能需要几天时间。 我还将检查我旧的同步串行解决方案的性能是否优于此内部基于数据包的解决方案。

    现在,非常感谢您的帮助和时间! 主要问题(在保留向后兼容性的同时迁移 ATA5760功能)尚未完全解决、但至少我现在拥有了基本上可行的设置-以及有关这些数字接收器器件的更多经验和知识。

    再次感谢、祝您一切顺利、

    理查德

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

    很高兴您至少已经能够正确设置数据包格式。  

    我希望您也能对射频参数进行调优、这样 CC110L 就能够接收所有数据包。

    Br

    Siri

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

    数据包格式似乎有些实用、但我仍然丢失了很多数据包(大约35%)-到目前为止、问题似乎与射频无关： 所有发送器都位于距接收器仅2米的位置、RSSI 显示非常强的信号、并且所选的射频参数看起来非常理想。

    我怀疑 CC110L 以某种方式无法正确解码数据包、原因我目前尚不清楚。

    为了收集更多信息、我将示波器的一个通道连接到发送器调制器信号(t：he 底部为蓝色迹线)、并且将另一个通道连接到 GDO2上的接收器 CS 输出(顶部为黄色迹线)-在这里我发现了一些奇怪的地方。

    这是丢失数据包时 CS 信号的样子：

    这与成功接收到数据包时的 CS 信号相同：

    事实证明、当 CS 在接收到最后一个有效负载字节后1毫秒内变为低电平时、即表明能够正确接收数据包。 否则、不能识别它。 在所有情况下、完全相同的信号都在相同的条件下以完全相同的距离传输。

    CC110L 数据表告诉我 CS 信号由 RSSI 电平控制：如果 RSSI 高于特定的阈值、则 CS 为高电平、否则为低电平-但它似乎不像那样简单。 此外、RSSI 水平足够高、并且"最干净"CS 信号是始终丢弃数据包的信号。

    我不知道该怎么说、但这或许告诉了您一些东西。 我最初认为 CC110L 无法可靠地识别只有8个前导码位和16位同步字的数据包—— 但我重新编程了一个发送器、以发送16位前导码和16位同步字、结果完全相同(又丢弃了35%的数据包)、因此前导码不是太短；肯定是错误的。

    您有什么建议我可以调查或尝试吗？ 本周晚些时候、我仍在咨询射频大师、以了解射频参数是否确实是最佳的、但短距离的 RSSI 值(大部分在0x18 - 0x20范围内)表明射频信号足够强、因此噪声或压降不是问题。 但不知何故、数据包往往无法可靠地被检测到。 我在这里有一点失败--我甚至打算使用完全不同的器件进行测试(这位射频专家拥有一个 SX1276评估板，我们可以针对这一应用进行设置)。

    如果有更多数据、我会报告。

    再次感谢、此致、

    理查德

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

    您好、Richard

    我不确定我是否完全理解您展示的内容。  

    除了 CS 信号之外、您能否在 GDO 引脚上输出 SYNC FOUND/SYNC RECEIVED (IOCFGx = 0x06)？

    此外、如果您可以进行以下练习、将会很有用：

    始终从发送器发送完全相同的数据包、然后打印出所有接收到的数据包。 是否有关于数据包故障位置的模式？ 数据包中是否只有一个位错误、还是多位错误？ 错误是否总是在同一位置发生？

    为获得最佳射频性能、CC110L 的建议设置为4字节前导码和4字节同步、因此射频性能会下降、但不确定35% PER 是否在预期范围内。

    Br

    Siri

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

    我再次进行了快速测试并关闭了 CC110L 上的曼彻斯特。我仍然使用16位 SYNC、但将 SYNC 字设置为0x55、0x56。 我将数据包长度增加到8。

    在本例中、我收到了所有数据包。

    不知道为什么,但它是值得一试。 在接收到数据包后在软件中执行曼彻斯特解码不会对代码造成太多开销。

    Siri

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

    很抱歉，如果我有点不清楚——已经很晚了，我正试图弄清楚我观察自己的是什么。 我重复了测量、这次还包括 GDO2上的 SYNC_FOUND。

    我有一个发送器、每20秒会反复发送相同的3字节数据包(上述即您已分析的数据包)、并且发送器与接收器之间的固定距离为75cm (约3英尺)。

    传输的信号(紫色示波器迹线)：

    1. 载波打开(10ms)
    2. 前导码(1个字节)
    3. 同步字(2字节)
    4. 有效载荷(3字节、0x0153A4)

    接收器的 CS 连接到示波器(黄色迹线、GDO0=0x0E)以及 SYNC_FOUND (蓝色迹线、GD02=0x06)。

    正如您所指出的、由于接收到的有效载荷位是反转的、因此接收到的正确有效载荷应为0xFEAD5B。 此外、我已经将接收器配置为将 RSSI 和 CRC 添加到有效载荷字节中。

    以下是正确接收数据包时这些信号的外观(时间的65%)：

    载波(紫色)打开、作为响应、CS (黄色)变为高电平。 正确接收到 SYNC 位后、SYNC_FOUND (蓝线)会变为高电平。

    接收到最后一个有效载荷字节后、SYNC_FOUND 再次变为低电平。 另外、CS 会在1毫秒内变为低电平、然后再次变为高电平(因为载波仍然存在)。

    在以下情况下、大多数时间都能正确接收有效载荷：

    0xFE 0xAD 0x5B 0x48 0x80

    有时、最后一个有效载荷位会被关闭：

    0xFE 0xAC 0x5C 0x40 0x81

    RSSI 值各不相同、但在此配置中通常约为0x48、如果我对其解释正确、会降至36dBm - 74dBm (=RSSI_OFFSET)=-38dBm。 这是足够高的接待。

    当出现问题时、信号如下所示：

    因此、传输(当然)完全相同、会产生不间断的 CS 信号、但不会出现 SYNC_FOUND 信号。 当然、不会接收到任何数据包。

    我想看看当我将接收器的同步字改变一位(0x55 0x56或可能是0xAA 0xA9)时会发生什么——啊，我看到你就这么想了！

    好的，我会尝试这个，是的，在软件中处理曼彻斯特编码根本不是问题--这实际上是我在使用同步串行模式时开始使用的。

    我现在必须休息，但我希望今天晚些时候实施这种新方法。

    哦、非常感谢您花所有这些时间和精力来帮助我！ 我真的很感激,它也迫使我仔细检查我在做什么,所有的时间。

    我会告诉你今天晚些时候该怎么做--希望获得100%的成功

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

    好的、我重新排列了基于 MCU 的曼彻斯特解码的代码、之后发现不再有丢弃的数据包或格式错误的数据包了。 我认为问题终于解决了！

    再次感谢您！

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

    很高兴听到你能够启动和运行:-)

    Siri

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

    很抱歉再次打扰你,但我偶然发现了一个新问题: 我想使用 GDO0作为 SYNC_FOD (GD02=0x06)并将其连接到控制器中断、但当我初始化 CC110L 时、GDO0保持在默认配置(即 CLK_XOSC/192 = 141kHz 的测试信号)、直到接收到第一个数据包。 这是初始化后 GDO0的样子(黄色轨迹)：

    如您所料、控制器主中断线路上的这个141kHz 信号是个问题。 CC110L 数据表甚至多次明确提到此 XOSC 驱动的测试信号应在 RX 开启之前关闭("为了优化 RF 性能、不应在无线电处于 RX 模式时使用这些信号")、但我该怎么做？ 状态图(图5-11)不会显示这些配置更改何时实际执行。

    下面是我的初始化、标记了第8行、表明初始化值正确：

     

    Reset:
single byte 0x30

Main init:
address 0x00 + burst = 0x40
0x0E			    ; C [0x00 - GDO2_CFG] Carrier Sense out
0x2E			    ; C [0x01 - GDO1_CFG] High impedance
* 0x06			    ; C [0x02 - GDO0_CFG] Sync Received out
0x47			    ; C [0x03 - FIFOTHR] RX FIFO and TX FIFO thresholds
0x55			    ; C [0x04 - SYNC1] Sync word, high byte
0x56			    ; C [0x05 - SYNC0] Sync word, low byte
0x08			    ; D [0x06 - PKTLEN] Packet length
0x04			    ; D [0x07 - PKTCTRL1] Packet automation control => append status
0x00			    ; C [0x08 - PKTCTRL0] Packet automation control - set normal FIFO mode, fixed packet length
0x00			    ; D [0x09 - ADDR] Device address
0x00			    ; D [0x0A - CHANNR] Channel # 0
0x0F			    ; C [0x0B - FSCTRL1] Frequency synthesizer control => IF = 395.50781 kHz
0x00			    ; D [0x0C - FSCTRL0] Frequency synthesizer control
0x20,0x31,0x4D	    ; C [0x0D-0x0F - FREQ2:1:0] Frequency setting: 0x20 31 0D = 2109709 => 869.1733246 MHz
0x96			    ; C [0x10 - MDMCFG4] Modem configuration: Channel bandwidth = 168.7500 kH
0x37			    ; D [0x11 - MDMCFG3] Modem configuration: Symbol rate = 2.002000809 kHz
0x02			    ; C [0x12 - MDMCFG2] Modem configuration: 2-FSK, 16/16 sync word bits, no Manchester decoding
0x02			    ; C [0x13 - MDMCFG1] Modem configuration: 2 preamble bytes minimum
0xE5			    ; C [0x14 - MDMCFG0] Modem configuration: Channel spacing = 199.813843 kHz
0x24			    ; C [0x15 - DEVIATN] Modem deviation setting => 
0x07			    ; D [0x16 - MCSM2]
0x3C			    ; D [0x17 - MCSM1] Main Radio Control State Machine configuration: IDLE after RX
0x18			    ; C [0x18 - MCSM0] Main Radio Control State Machine configuration: Calibration from IDLE to RX
0x16			    ; C [0x19 - FOCCFG] Frequency Offset Compensation configuration
0x6C			    ; D [0x1A - BSCFG] Bit Synchronization configuration
0x03			    ; D [0x1B - AGCCTRL2] AGC control
0x43			    ; C [0x1C - AGCCTRL1] AGC control
0x91			    ; D [0x1D - AGCCTRL0] AGC control

Continued init:
address 0x20 + burst = 0x60
0xFB			    ; C [0x20 - RESERVED]
0x56			    ; D [0x21 - FREND1] Front end RX configuration
0x10			    ; D [0x22 - FREND0] Front end TX configuration
0xE9			    ; C [0x23 - FSCAL3] Frequency synthesizer calibration
0x2A			    ; C [0x24 - FSCAL2] Frequency synthesizer calibration
0x00			    ; C [0x25 - FSCAL1] Frequency synthesizer calibration
0x1F			    ; C [0x26 - FSCAL0] Frequency synthesizer calibration

Continued init:
address 0x29 + burst = 0x69
0x59			    ; D [0x29 - RESERVED]
0x7F			    ; D [0x2A - RESERVED]
0x3F			    ; D [0x2B - RESERVED]
0x81			    ; C [0x2C - TEST2]
0x35			    ; C [0x2D - TEST1]
0x09			    ; C [0x2E - TEST0]

    是否有办法强制更改 GDO0的配置、以便它在不接收到数据包的情况下从141kHz 块波信号切换到新配置的状态？我没有找到任何实际执行此操作的命令。

    或者、由于我使用突发模式来初始化器件、是否会出现此问题？ (我还没有尝试将此序列更改为单个指令、因为这需要做很多额外的工作。)

    再次感谢、

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

    您好

    当您配置该寄存器时、它将被更新、而不是在接收到数据包后、因此、您唯一需要确保的是、您在启动 SRX 之前正在将0x06写入 IOCFG0寄存器。

    遗憾的是、许可证服务器存在一些问题、因此我无法向您展示逻辑分析器图、以了解在像您一样执行突发访问时的情况、 但对于单次访问(我可以使用 SmartRF Studio 执行此操作)、您将看到 GDO0线路立即更改。

    如果在执行上述初始化时监视 GDO0行，则会看到相同的内容。 配置好 GSO0后、它将立即停止切换。

    在 MCU 上、必须禁用 GD00上的中断、直到正确配置 IOCFG0。

    在启用中断前、也有必要清除时钟切换线路时产生的挂起中断：

    伪代码：

    初始化 MCU (禁用 GDO0上的中断)

    初始无线电广播(IOCFG0 = 0x06)

    清除 GDO0上的中断

    启用 GDO0上的中断

    启动 RX

    Br

    Siri

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

    尊敬的 Siri：

    再次感谢您的答复！

    这实际上是在初始化 CC110L 之前注册 GDO0中断时存在的问题-在注意到并修复了该问题后、我将 GDO0的单个迹线误解为仍然产生141kHz、而实际上、 在我内置的100ms 初始化延迟后、GDO0停止输出 CLK_XOSC/192、但这超出了屏幕的可见(单触发器)部分。 所以,基本上,我在同一个点搞错了两次... 抱歉！

    到目前为止、一切似乎都在按预期运行。

    此致、

    理查德