[参考译文] CC1120：寻找处理古老 OOK 协议的接收器

admin

Other Parts Discussed in Thread: CC1120

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

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1320158/cc1120-looking-for-a-reciver-that-deal-with-ancient-ook-protocols

器件型号：CC1120

您好！

十年来、我们一直在 FSK 上使用 CC112x、主要是在异步"透明"模式下工作。
我们正在尝试将所有客户和产品转换为 FSK、当然还有在有新项目时使用的分组模式。

但由于历史的原因、我们在市场上有成千上万的 Keyfobs 可以使用旧的 OOK 协议：12位或40位数据包、500b 和2000b DR 之间(您永远不知道会有什么内容)。
这些数据包在介于5-30ms 的暂停时间内被重复发送-并且接收器一定不能试图在这些暂停中找到任何位。。。 (否、无 AGC/AFC……)

遗憾的是、我们的客户仍然需要这些接收器、用于新项目(使用旧的发送器)或仅作为备件。
目前、这些接收器都是模拟的、非常好的芯片、但是你永远不会知道会因为批次之间的差异而遇到什么意外(今天我们又遇到了大问题)。

长话短说、您可以建议是否有 CC1xxx 芯片(最好是 CC1120)来解决此问题？

提前感谢！

用 www.DeepL.com/Translator 翻译(免费版)

1 年多前

0 admin 1 年多前

TI__Guru**** 2391195 points

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

此外:我做了一些测量。
不好的是在数据包和缺少前导码之间总是有较长的暂停时间。我现在进行的测试(CC1120)显示、即使是 FOC_EN=OFF 也不会改变不良行为。因此、我尝试找到更多与 OOK 相关的参数来获得改进。
-将 CHBW 从例如50k 增加到100k 使它更糟(和100k 应该是最小的,因为 TX 有一定的晶体容差)。
-将数据速率从1增加到4K 使它更糟
- AGC_ASK_DECAY 是一个特定的候选,但"5000"已经在它的最大值。使它更小使它更糟(见图片)。
但我想 AGC 是关键：如果我可以告诉 CC 在收到第一个数据包后不更改 AGC、不管暂停如何、这可能会有所帮助。
表示例如 AGC-DECAY 至~20000 -但是这不被允许。

同时、如果暂停过程中出现尖峰、我也不会太在意：我们正考虑进行一些信号处理：抓取整个数据集并从数据包末尾向后分析-这种数据包总是很干净。但不幸的是、暂停期间的废品会进入数据包的开头-我们无法恢复已销毁的位。

男士们、我们这里的情况真的很糟糕、我迫切要求 TI 人提供任何提示、以便修整 CC11x、使其表现正常。也许您可以访问旧的 Chipcon 团队来解决这个问题... ；-)？

谢谢！

正常数据包(1ms/div)