• 状态
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 0 订户
  • 视图 652 视图
  • 用户 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.

[参考译文] CC3100：CTS-to-self

admin
Guru**** 2535750 points
Other Parts Discussed in Thread: CC3100

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1009998/cc3100-cts-to-self

器件型号：CC3100

我正在尝试延长使用 CC3100模块的嵌入式产品的电池寿命。  根据我的判断、该模块使用的是 CTS-to-self。 此网络上没有其他设备、因此我们更喜欢不启用 CTS。

在监听器跟踪中、我们看到 CTS 由 TI STA (数据包11111)发送、而在下一个数据包(11112)中是来自同一 TI STA 的数据传输。   检查时、CTS 的 NAV 为262微秒。 有趣的是、数据包11112在11111之后会接收到369微秒、因此在传输数据包11112之前、NAV 似乎已经过期。   数据包11111之前没有 RTS。

我们使用的功率设置为7 (比最大功率低7dB)。  请注意、接收到的 CTS 信号比数据信号高大约8dB、这意味着它在传输时的功率设置为0、此时外部 PA 被启用。

您能否确认 CC3100是否实现了 CTS-to-self？  

如果是：

  1.  是否有方法禁用它？
  2. 是否有办法确保 CTS 仅使用与数据相同的 Tx 功率？
  3. 为什么在发送数据包之前、在 CTS 之后会有369微秒的延迟？  我会期望一个 SFF (10微秒)。  导航过期后传输的数据帧、 您能解释 一下 CTS 的用途吗？

如果 CC3100未实现 CTS-to-self、那么您能帮助我了解 CTS (数据包11111)的用途吗？

谢谢、

Steve

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

    您好、Steve、

    我需要更多信息。  您能否连接 监听 器跟踪？

    1.  刷写了什么服务包版本？
    2. 配置了什么电源策略？
    3. 器件是用作 AP 还是工作站？   是否已连接？

    此致、

    Sarah

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

    您好、Sarah、

    TX 以获取响应和其他问题。   

    1.   我正在咨询 FW 工程师、并在收到信息后进行更新。   

    2. 正常功率模式，功率级别7.

    3. 该器件在 P2P (传统 Wi-Fi Direct 模式)下充当 STA。  它已连接。  在数据包11112中、带有 TI 无线电的器件正在向另 一个802.11器件发送1580 B 数据包。  另一个802.11设备配置为 Wi-Fi Direct、TI 无线电与其关联。 另一个设备具有 MAC 地址： fA：e4：e3：c7：22：61

    我将其减少到550 KB、但 Web 服务器似乎对 作为文件上传的内容不满意。  该 链接提供了(希望如此)跟踪。  原始数据包# 11111现在为#1111。   

    请注意、从#1111开始、我们可以看到没有 RTS 的 CTS 和数据对。 (这就是为什么我认为这是一个 CTS-to-self)。  类似的序列发生在其他地方、例如从#1161开始。   

    • 1111 CTS (目的  TI_ff：F9：DE)
    • 1112数据(来自 TI_ff：F9：DE)
    • 1113 CTS (目的  TI_ff：F9：DE)
    • 1114数据(来自 TI_ff：F9：DE)
    • 1115 CTS (目的  TI_ff：F9：DE)
    • 1116数据(来自 TI_ff：F9：DE)

    相比之下、在数据包#1255处、我们可以看到标准 RTS/CTS/数据序列

    • 1255 RTS 至 TI 无线电、来自 fa：e4：e3：c7：22：61
    • 1256 CTS，目标为 fa：e4：e3：c7：22：61
    • 1257将 fa ：e4：e3：c7：22：61中的数据传输到 TI 无线电。

    另一个奇怪的问题是：CTS。

    数据包1072和1073、来自 TI 无线电的两个 CTS 数据包相距约340微秒。  由于 CTS 不需要 ACK、因此 TI 为什么会无线电。  这种情况在迹线中多次发生、包括1153和1155处、两个 CT 数据包相隔约400微秒。

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

    您好、Steve、

    感谢您使用监听器跟踪。 需要一天或两天的时间才能对其进行审查。

    当您确定服务包版本时、请告诉我。 如果 不是最新版本 v1.0.1.15-2.14.0.0、这将是我首先要求您测试的内容。  请注意、服务接收器是向后兼容的、因此您可以在不更新主机驱动程序版本或更改主机应用程序的情况下对其进行测试。

    此致、

    Sarah

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

    您好、Sara、

    感谢您的更新。 我知道、可能需要一段时间才能通过轨迹。

    BTW、用户指南中指示的选项不包括我们看到的"service pack"版本。  

     printf ("生成版本%d.%d.%d.%d.31。%d.%d.%d.%d.%d.%d.%d.%d.%d.%d\n"、
    _ver.NwpVersion[0]、_ver.NwpVersion[1]、_ver.NwpVersion[2]、_ver.NwpVersion[3]、
    _ver.ChipFwAndPhyVersion.FwVersion[0]、_ver.ChipFwAndPhyVersion.FwVersion[1]、
    _ver.ChipFwAndPhyVersion.FwVersion[2]、_ver.ChipFwAndPhyVersion.FwVersion[3]、
    _ver.ChipFwAndPhyVersion.PhyVersion[0]、_ver.ChipFwAndPhyVersion.PhyVersion[1]、
    _ver.ChipFwAndPhyVersion.PhyVersion[2]、_ver.ChipFwAndPhyVersion.PhyVersion[3])；
    在 EVK (而非我们的生产代码)上、我们从之前的 printf 收到了这一信息。   
    这是您要求的吗？
    最棒的
    Steve
  • 0
    TI__Guru**** 2535750 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Steve、

    servicepack 版本的前四个数字对应于测试的主机驱动程序版本。 接下来的四个数字是 NWP 版本。 有关更多详细信息、请参阅 servicepack 发行说明。

    服务包与较旧的主机驱动程序向后兼容、但事实并非如此：旧的服务包(即旧的 NWP 固件版本)不能与较新的主机驱动程序一起使用。 因此、如果使用主机驱动程序1.0.1.6、则应至少将1.0.1.6-2.7.0.0服务接收器加载到串行闪存中。

    我建议您更新到最新的服务包(1.0.1.15-2.14.0.0)并再次测试。

    此致、

    Sarah