[参考译文] CC2500：500kBaud 时的最大实际数据包速率？

您好 Bill、

我同意您的数据速率比我们预期的慢。 您是否按照数据表第12节所述在代码中使用了正确的寄存器值？ 我计算出  、如果您使用的是26MHz 晶体、则 DRATE_E = 24 14和 DRATE_M = 52 59。

R_data = 500、000

DRATE_E = floor (log2 (50000 * 2^20/26000000))= 14

DRATE_M =舍入(50000 * 2^28 /(26000000 * 2 ^ 14)- 256 = 59

最棒的

不需要

嗯？ 不确定回复顶部的 DRATE_R="24" DRATE_M="52"。

目前、我将使用以下值：

   MDMCFG4 = 0x0E  (14)

   MDMCFG3 = 0x3B  (59)

...这与您的回复的底部(文本)部分一致、也与 RF Studio7针对500kBaud 数据速率生成的值一致。

目前、我已采用将数据包数每秒减少到每秒250s 的方法、并增加我的 TX 有效载荷。   

我注意到的一点是、当我的 TX 有效载荷大约为32字节时、接收端的 CRC 错误数量相对较少(可能在几千字节中有一个数据包存在 CRC 错误)。   但是、如果我将 TX 有效载荷增加到60字节、我在接收端似乎会遇到大量 CRC 错误(每接收3到5个数据包中大约有1个 CRC 错误)。   即使我每秒发送一个数据包、也会发生这种情况！

误差率的这种大变化表示什么？  时钟同步丢失？   我确定我必须在某个位置设置不正确、但真的不知道在哪里...    

这是我用于 Xmit 的寄存器设置： 对于500kBaud 可变长度数据包模式、该寄存器设置是否看起来正确？

const u8_t CC2500_TX_mode[]=｛
0x00、0x02、//IOCFG2 (x)// GDO2基于 FIFO THR   
0x01、0x2E、//IOCFG1
0x02、0x06、//IOCFG0D
0x03、0x01、//FIFOTHR (x)
0x04、0xD3、//SYNC1
0x05、0x91、//SYNC0
0x06、0xFF、//PKTLEN (x)
0x07、0x04、//PKTCTRL1 (x)
0x08、0x05、//PKTCTRL0 (x)
0x09、0x00、//ADDR
0x0A、0x00、//CHANNR (x)<--注意：此处通道设置为零！
0x0B、0x10、//FSCTRL1 (x)
0x0C、0x00、//FSCTRL0 (x)
0x0D、0x5D、//FREQ2 (x)
0x0E、0x93、//FREQ1 (x)
0x0F、0xB1、//FREQ0 (x)
0x10、0x0E、//MDMCFG4 (x)
0x11、0x3B、//MDMCFG3 (x)
0x12、0x73、//MDMCFG2 (x)
0x13、0x42、//MDMCFG1 (x)
0x14、0xF8、//MDMCFG0 (x)
0x15、0x00、//DEVIATN (x)
0x16、0x07、//MCSM2
0x17、0x30、//MCSM1 // CCA (如果 RSSI 低于阈值)；RX 之后空闲；TX 之后空闲
0x18、0x18、//MCSM0 (x)//从空闲转至 TX 或 RX 时自动校准；到期计数= 64
0x19、0x1D、//FOCCFG (x)
0x1A、0x1C、//BSCFG (x)
0x1b、0xC7、//AGCCTRL2 (x)
0x1C、0x40、//AGCCTRL1 (x)
0x1D、0xB0、//AGCCTRL0 (x)
0x1E、0x87、//WOREVT1
0x1f、0x6B、//WOREVT0
0x20、0xF8、//WORCTRL
0x21、0xB6、//FREND1 (x)
0x22、0x10、//FREND0 (x)
0x23、0xEA、//FSCAL3 (x)
0x24、0x0A、//FSCAL2 (x)
0x25、0x00、//FSCAL1 (x)
0x26、0x19、//FSCAL0 (x)
0x27、0x41、//RCCTRL1
0x28、0x00、//RCCTRL0
0x29、0x59、//FSTEST (x)
0x2A、0x7F、//ptest
0x2B、0x3F、//AGCTST
0x2C、0x88、//TEST2 (x)
0x2D、0x31、//TEST1 (x)
0x2E、0x0B｝；//TEST0 (x)

非常感谢您提供的任何帮助。

您好 Bill、

我已将此任务分配给团队中更熟悉产品的其他人。 他们将很快作出答复。 感谢您的耐心等待。

最棒的

不需要

您好！

很抱歉耽误你的时间。 我正在做一些测试、几天后我会再回来。

此致、

Bill、如何进行测量？ 一个500kbps 上的10字节数据包应该花费0.38ms、而不是2ms。  

更正： 我刚刚重新测量了提交时间。  对于36字节有效载荷、我测量了1.57ms。  我使用了以下方法：

1)用有效载荷(36字节)+ 1个长度字节填充 TX FIFO

2) 2)发送 STX 选通信号

3) 3)将数字输出设置为高电平-(在示波器上开始测量)

4) 4)轮询状态寄存器直到 FIFO 为空

5) 5)将数字输出设置为低电平(结束测量)

如果我包括填充 TX FIFO 所需的时间、则总时间为1.99ms。 大约2ms。

这是否合理？

嗯-优点。  我实际上认为我每次都要进行同步校准。  我将 MCSM0设置为0x18、这会将 AUTOCAL 设置为"01" - 在从空闲状态转至 TX 状态时进行校准。  也许这很糟糕？  如果我正在流式传输数据(几乎是连续的数据包流)、我应该校准多长时间？   

很难在这里提供良好的指导、因为这取决于您的系统。

接收数据包的重要性如何？ 如果非常关键、应经常进行校准。 如果您有一个双向系统、并且您可以将 TX 侧设置为在未收到 ACK 时重新校准、则不必经常执行此操作

-温度和电压变化是同步需要重新校准的最大原因。 如果您的系统处于接近稳定温度且主电源已通电的室内、则无需经常进行校准。 如果节点位于某个位置、则可以看到温度变化和电池功率相当快、因此需要更频繁地进行校准。  

我建议您对您的用例进行一些测试。 从60秒的间隔开始、如果该间隔有效、您可以尝试增加该间隔、但我仍会每小时校准一次左右、这样做比抱歉的原理更安全。   

啊——明白了。  非常好地解释了它、谢谢！  我还有一个与此相关的问题(不确定这是否应该是单独的帖子/问题)。  其中包括：

如果我将有效负载增加到超过34或36字节、我的错误率会急剧上升。  

例如、如果我将有效负载保持在34字节、那么在发送10137个数据包后、我将得到大约589个校验和错误(误差率约为5.9%)。    如果我将有效负载增加到60字节、   那么在发送的13442数据包中、我会得到大约5765个错误- 大约42.8%的错误率！    当有效载荷长度增加时、接收器时钟就好像与发送器时钟不同步。   这是什么原因？   发送器和接收器之间的距离约为2英尺。   错误率显然取决于数据包长度。

有什么想法吗？

数据包内容是否相当随机？ 如果某些符号的0<->1转换次数很少，则可能是调制解调器无法跟踪。 您是否已验证36字节后会发生位错误？  

在本例中、我将反复发送相同的数据包。 数据包内容在高达36字节的情况下是相当随机的、但我在36字节边界之后填充零。  随着数据包越来越长、错误率也会快速上升。   我可以为您提供不同数据包长度的其他统计信息、如果这样做有用的话。

尝试在36字节后使用随机内容。 仅0x00时、内部循环会丢失位同步。 您也可以打开白化。