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.

[参考译文] CC3301:通道13上的弱 WLAN RX 灵敏度/ HT MCS7

Guru**** 2478765 points
Other Parts Discussed in Thread: CC3301, BP-CC3301, CC3100

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1413772/cc3301-weak-wlan-rx-sensitivity-on-channel-13-ht-mcs7

器件型号:CC3301
Thread 中讨论的其他器件:CC3100

工具与软件:

尊敬的 TI 专家:

我有一个定制 PCB、包括 CC3301 + Linux 主机。 我通过将处于 STA 模式的 CC3301连接到用作 AP 的测量设备(R&S CMW500)来测量 WLAN RX 灵敏度、并在 CMW500降低其 TX 功率时测量数据包错误率。 在其他通道和数据速率上、RX 灵敏度接近数据表2.4GHz 接收器特性、但在通道13上 HT MCS7 RX 灵敏度非常弱。 请参阅随附的测试报告。

测试已通过同轴射频电缆并在屏蔽环境中执行、这意味着没有可能影响测试结果的外部干扰。 是否有任何与通道13上的 WLAN RX 灵敏度相关的已知问题?

CC3301顶部的标识:
   XCC3301
   ENJA
   TI 378
   AJ6T G4

Linux 主机在上电期间打印的软件信息:
   wlcore:无线驱动程序版本1.7.0.114
   wlcore:无线固件版本1.7.0.120
   Wlcore:无线 PHY 版本1.2.36.5.22.66


此致、

Kaisa.



e2e.ti.com/.../WLAN_5F00_802.11n_5F00_RX-Sensitivity_5F00_ch11_2D00_13_5F00_MCS0_2D00_7_5F00_2024_2D00_09_2D00_11_5F00_14_2D00_34_2D00_30_5F00_744.pdf

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

    您好、Kaisa

    我将在内部对此进行探讨、明天再与您联系。

    谢谢!

    Jonathan  

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

    尊敬的 Kaisa:

    您能介绍一下 RX 突发功率的测量对象吗?  

    您是否检查过第13章 MCS7中的 TX 质量是否也显示较差结果?

    您能否发送原理图和布局设计文件?  

    谢谢!

    Jonathan  

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

    Jonathan、您好!

    我假设测试报告中的"RX 突发功率"实际上是 DUT 的 TX 功率、但这与 RX 灵敏度测量并没有实际关系。 结果表中最重要的值是左侧的测量设备("AP")功耗以及右侧的 PER 值。 这些也显示在图中。

    通道13/MCS7的 TX 质量正常、请参阅随附的测试报告(适用于 ch13/MCS7的第140页起)。

    我们的原理图已于4月通过电子邮件(" connectivity-wifi-hw-reviews@list.ti.com ")共享。 如果需要、我也可以通过电子邮件共享我们的布局。 很难相信布局中的某些问题只会对通道13/MCS7产生如此巨大的影响、对于任何较低的通道或较低的数据速率都不会产生影响。

    此致、
    Kaisa.

    e2e.ti.com/.../WLAN-n_5F00_non_2D00_sig-TX_5F00_CH-1_2C00_3_2C00_6_2C00_8_2C00_11_2C00_13_5F00_MCS0_5F00_MCS4_5F00_MCS7_5F00_2024_2D00_09_2D00_05_5F00_08_2D00_46_2D00_36_5F00_474.pdf

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

    尊敬的 Kaisa:

    此问题是否会在多个器件上重现? 每次您在 Ch.13上测试时是否会出现此问题?  

    我同意您的观点、这很可能与布局无关。

    我曾尝试在参考平台(BP-CC3301 + BeagleBone Black (BBB))上重现此问题、但没有看到这种现象、我测量的 Rx 灵敏度与数据表持平。

    此外、我查看了我们的 PER 曲线验证结果、 所有速率和渠道(包括第13章 MCS7)的结果看起来都很好。

    此致、

    Jonathan   

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

    Jonathan、您好!

    我们在通道13上进行的每次测量中、在多个器件上都会重现此问题。

    请问您使用的软件版本与我列出的版本相同:

    [quote userid="432407" url="~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1413772/cc3301-weak-wlan-rx-sensitivity-on-channel-13-ht-mcs7   wlcore:无线驱动程序版本2.7.0.114
       wlcore:无线固件版本1.7.0.120
       Wlcore:无线 PHY 版本1.2.36.5.22.66[/QUOT]


    到目前为止、我们一直在 Linux 主机上使用内核版本5.15、但我们将在未来几周内更新到6.1 Yocto。

    我还注意到本论坛上的另一个主题可能与该问题有关。 您是否有任何信息、该问题的根本原因是什么以及问题是否得到了解决?



    此致、
    Kaisa.

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

    尊敬的 Kaisa:

    我使用了与上述软件版本相同的软件版本、在您的版本或最新版本上我没有看到此问题。  

    您可以共享您的 INI BIN 文件吗? 这是 位于/lib/firmware/ti-connectivity 文件路径中的 cc33xx-conf.bin 文件。

    您何时在校准器工具中运行校准命令? 每次更换通道或改变温度10度以上时、都应执行校准命令。  

    校准器 wlan0 cc33xx_plt set_manual_calib -tx 0 -rx 1 

    您链接到的主题是不同器件 CC3100的相关主题。 该器件与 CC3301完全不同。  

    此致、

    Jonathan

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

    Jonathan、您好!

    我使用了默认 cc33xx-conf.bin 文件、请查看下面的配置设置。

    我只使用了校准器工具进行 TX 测试、如果您查看我之前发送的 TX 测试报告、您将看到我使用过的所有校准器命令、包括校准命令。 RX 灵敏度测试在正常工作模式下完成、而不是使用校准器工具、我已了解在正常模式下无需手动校准命令。

    此致、
    Kaisa.

    ##################################################
    ##      CC33XX INI Template                     ##
    ##  All Param values are in HEX                 ##
    ##################################################
    
    InsertionLoss_2_4GHz     		= 00 00 # [Trace to Ant-1, Trace to Ant-2]. Board trace loss for 2.4GHz band
    InsertionLoss_5GHz       		= 00 00 # [Trace to Ant-1, Trace to Ant-2]. Board trace loss for 5GHz band
    Reserved0                		= 00 00 # Reserved
    AntGain_2_4GHz           		= 00 00 # [Ant-1, Ant-2]. Antenna gain for 2.4GHz band
    AntGain_5GHz             		= 00 00 # [Ant-1, Ant-2]. Antenna gain for 5GHz band
    Reserved1                		= 00 00 # Reserved
    BleChLim1M               		= FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF # BLE Reg Domain
    BleChLim2M               		= FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF # BLE Reg Domain
    OneTimeCalibrationOnly   		= 00 # Enable One Time calibration Only (Default is periodic Calibration)
    IsDiplexerPresent        		= 00 # 0: Diplexer doesn’t exist; 1: Diplexer exists. Is diplexer for combining 2.4GHz trace and 5GHz traces, exists on board
    NumOfAntennas            		= 01 # 1: Single antenna; 2: Two antennas. Number of antennas on board. Two for diversity.
    RegDomain                		= 00 # 0: World Wide; 1: FCC; 2: ETSI
    PowerSaveScheme          		= 00 # Power Save Scheme - 0 (PS_SCHEME_LEGACY), 1 (PS_SCHEME_UPSD_TRIGGER), 5 (PS_SCHEME_NOPSPOLL)
    HE_Enable                		= 01 # Enable HE (11ax)
    ApMaxNumStations         		= 04 # (ApMaxNumStations can be either 4 decimal or 16 decimal ) -> 4 or 10 Hex
    EnableBle                		= 01 # Enable BLE
    BleUartBaudrate          		= 1C200 # 115200 in decimal, Ble Uart BaudRate
    EnableUartFlowCtrl       		= 01 # Enable/Disable Uart Flow Control
    ListenInterval           		= 01 # Listen interval, when waking up for nDTIM (Only activated if WakeUpEvent is set to nDTIM), range 1-10
    WakeUpEvent              		= 01 # Firmware wakeup conditions configuration – 0x0 (beacon) / 0x1 (DTIM) / 0x2 (nDTIM)
    PowerLimitArray          		= 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F 3F # Per channel power limit parameters, channel 14 not supported
    InternalSlowClkDrift_WakeupEarlier		= 189C # Wakeup Earlier offset In Units of ppm, Default Value For Internal Slow Clock is 6300 (0x189C), External Slow Clock
    InternalSlowClkDrift_OpenWindowLonger		= 4588 # Beacon Open Window Offset As Result of Slow Clock Drift, For Internal Slow Clock Deafult is 17800ppm (0x4588)
    ExtSlowClkDrift_WakeupEarlier		= 1F4 # Wakeup Earlier offset In Units of ppm, Default Value For Internal Slow Clock is 500 (0x1F4), External Slow Clock
    ExtSlowClkDrift_OpenWindowLonger		= 1F4 # Beacon Open Window Offset As Result of Slow Clock Drift, For Internal Slow Clock Deafult is 500ppm (0x1F4)
    Is_ExtSoC_Connected      		= 00 # Yes/No Choose if External SoC entity is connected - 1 - YES, 0 - NO
    ExtSoC_grant_polarity    		= 01 # External SoC grant polarity - 0 - Active High, 1 - Active Low (Default)
    ExtSoC_priority_polarity 		= 01 # External SoC priority polarity - 0 - Active Low, 1 - Active High (Default)
    ExtSoC_request_polarity  		= 01 # External SoC request polarity - 0 - Active Low, 1 - Active High (Default)
    ExtSoC_min_grant_time    		= 96 # 150 in decimal, Minimum grant time for External SoC
    ExtSoC_max_grant_time    		= 3FFF # 16383 in decimal, Maximum available grant time for External SoC
    ExtSoC_t2_time           		= 05 # T2 time for External SoC
    ExtSoC_to_wifi_grant_delay		= 1E # 30 in decimal, Maximum time for changing the grant from External SoC to WiFi
    ExtSoC_to_ble_grant_delay		= 23 # 35 in decimal, Maximum time for changing the grant from External SoC to BLE
    DisableLogger            		= 00 # Disable Logger Prints (Except For FW Init Logs)
    MixedModeSupport         		= 01 # Enables connection to AP’s with WPA mixed mode configuration
    XTAL_SettlingTime        		= 6A5 # Units in us
    DefaultAntenna           		= 00 # Default antenna to use: 0/1
    SLOW_CLOCK_IN_pull_val   		= FF # None
    SDIO_CLK_pull_val        		= FF # None
    SDIO_CMD_pull_val        		= FF # None
    SDIO_D0_pull_val         		= FF # None
    SDIO_D1_pull_val         		= FF # None
    SDIO_D2_pull_val         		= FF # None
    SDIO_D3_pull_val         		= FF # None
    HOST_IRQ_WL_pull_val     		= FF # None
    UART1_TX_pull_val        		= FF # None
    UART1_RX_pull_val        		= FF # None
    UART1_CTS_pull_val       		= FF # None
    UART1_RTS_pull_val       		= FF # None
    COEX_PRIORITY_pull_val   		= FF # None
    COEX_REQ_pull_val        		= FF # None
    COEX_GRANT_pull_val      		= FF # None
    HOST_IRQ_BLE_pull_val    		= FF # None
    FAST_CLK_REQ_pull_val    		= FF # None
    ANT_SEL_pull_val         		= FF # None
    

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

    尊敬的 Kaisa:

    我不确定在正常工作模式下测试 Rx 灵敏度的含义。 要在不使用校准器工具的情况下测试 Rx 灵敏度、您要运行哪些命令? 测试 RX 灵敏度的唯一方法是使用校准器工具命令或无线电工具。  

    如果使用校准器工具、则应在每次调谐到新通道时运行手动校准命令。

    此致、

    Jonathan  

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

    Jonathan、您好!

    在正常操作模式下测试 Rx 敏感度意味着我们有一个专业级宽带无线电通信测试仪(R&S CMW500)作为 AP。 我们在 STA 模式下将 CC33xx 连接到此 CMW500-AP、然后 CMW500会自动降低其信号电平并报告数据包错误率、正如您从我分享的测试报告中所看到的。
    在此 PER 测量中、CMW500将用户数据传输到 CC33xx、并根据未确认的数据包与传输的数据包的比率计算 PER。 未确认的数据包不会重新传输。
    报告中的 TX 突发功率(校准到 CC33xx 末端)和 MCS 是 CMW500-AP 设置。 该测试未注意 CC33xx 的 TX 功率或数据速率、但仅注意数据包错误率。 这是高度自动化的测试、如果没有绝对必要、我们不会降级我们的测试设置。

    您能解释一下我们为什么不应该像我们现在所做的那样测试 RX 灵敏度吗?

    您能否同时分享您的测试结果以及测试设置的更多详细信息? 如果我回答正确、使用校准器工具进行测试意味着您正在使用信号发生器发送 WLAN 数据包、这些数据包由 CC33xx 接收、然后只需使用校准器工具命令检查 RSSI、FCS 错误等?

    此致、
    Kaisa.

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

    尊敬的 Kaisa:

    感谢您的澄清、这一点现在很清楚。 我们执行了全面验证测试运行、并根据 运行 CC33xx + A VSG/VSA LitePoint 的无线电工具设置的结果定义了我们的数据表规格。 无线电工具是一款 GUI、我们无需主机即可在外部 PC 上运行、用于测试射频功能。 校准器工具命令与无线电工具相同、唯一的区别是这些命令通过托管设置中的 Linux 终端而非独立运行。

    本质上、我们像运行 TX 测试一样执行了 RX 灵敏度测试、其中 CC33xx 在 RX 中使用校准器工具命令、 CMW500是 VSG。 CC33xx 对接收到的良好数据包进行计数、并将该数字与 VSG 发送的数据包进行比较。 这是我在尝试重现您看到的问题时测试的方法。  

    以下是我使用的命令:

    ifconfig wlan0 down 
    校准器 wlan0 plt power_mode 打开 
    校准器 wlan0 cc33xx_plt tune_channel 13 0 0 0 
    校准器 wlan0 cc33xx_plt set_manual_calib -tx 0 -rx 1 
    校准器 wlan0 cc33xx_plt start_Rx -source_mac FF:FF:FF:FF:FF -ack_enable 0 -rate 20 -preamble_type 3 

    从 VSG 传输1000个数据包
    校准器 wlan0 cc33xx_plt get_rx_stats 
    校准器 wlan0 cc33xx_plt stop_rx 


    我建议您尝试以这种方式测试 RX 灵敏度、看看它是否有用。 就像我说的,当我用上面提到的固件和驱动程序版本进行测试时,我发现了良好的结果。

    至于为什么会有差异、不应该有差异。 根据我对您的测试设置的理解、您使用的方法应该可行。
    唯一稍稍有不同的是、当您尝试执行纯 RX 测试时、还必须进行 TX、因为您是在等待 CC33xx 发送确认数据包。
    不过没关系。
    我将尝试模拟您使用我们的一个 AP 所执行的测试、尽管我们通常不以这种方式测试 Rx 灵敏度。

    您也可以尝试更新到我们的最新固件和驱动程序版本、这可能会有所不同。 您使用的版本已过时。

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

    尊敬的 Kaisa:

    这里有更新吗?  

    我建议您在没有 AP 和 ACK 数据包的情况下尝试使用校准器工具来测量 RX 灵敏度-您成功完成了该实验吗?  

    同时、我们还可以使用  R&S CMW500进行测试、其参数和测试设置与上述完全相同、我们在测试 MCS7 Ch.13时发现了良好的结果。 但是、我们没有使用自动化脚本、而是在几种不同的 MCS 速率和信道手动进行了现场测试。

    此致、

    Jonathan   

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

    Jonathan、您好!

    感谢您的更新。 能否就您使用过的两种测试方法分享更详细的结果?

    我们的 CC33xx 固件和驱动程序版本已更新、但这些版本对 ch13 MCS7 RX 测试没有任何影响。 以下是我们目前使用的版本:

    	Wireless driver version 1.7.0.127
    	Wireless firmware version 1.7.0.185
    	Wireless PHY version 1.2.39.5.42.67


    按照您的建议、我们一直在尝试使用校准器工具进行测试、但到目前为止、我们尚未能够生成 CC3301将作为"良好数据包"接收的数据包。 我们将在本周重试。

    BR、
    Kaisa.

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

    尊敬的 Kaisa:

    我确认我们使用了与您测试的相同的固件和 PHY 版本进行了测试、但未出现此问题。

    我们的测试设置与您自己的测试设置非常相似-我们的 CMW500 有效载荷大小和数据间隔与您使用的相同、并尝试 MCS7 Ch13、结果具有灵敏度、如数据表中所示。

    我相信在使用校准器工具测试 Rx 和计算接收到的良好数据包数量时、您将获得良好的结果。

    随时更新您的进度。

    此致、

    Jonathan   

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

    Jonathon、您好!

    归根结底、重要的是正常生产/信号模式下的 RX 灵敏度。  现场器件在正常运行时不接收带有校准器的数据包。

    如果器件在正常信令模式下具有与校准器不同的接收器灵敏度、则这是一个问题...

    此致、

    Dean

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

    您好、Dean:

    我同意您的看法、信令模式下的 RX 灵敏度很重要。 现在,我专注于了解什么是失败在你的当前设置导致灵敏度行为这种方式只在 MCS7 ch. 13. 为了消除问题与射频或固件相关的选项、可以使用校准器工具所述的方法测量 RX 灵敏度。

    请使用此方法测试 Rx 灵敏度并发送结果。 根据该实验的结果、我们可以继续提供解决方案建议。  

    此外、最好使用您描述的方法在没有自动化的情况下测试 RX 灵敏度、仅单独测试特定的通道和速率、看看这是否会造成影响。

    此致、

    Jonathan    

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

    Jonathan、您好!

    我们最终能够使用校准器工具进行测试、并在 MCS7通道13上获得了-71dBm 的结果。

    我还详细研究了在正常操作模式下测试时使用的测量设备("AP")设置。 我最终发现、有一项设置可显著提高11n RX 灵敏度、尤其是在 MCS7通道13上。 该设置称为"HT Smoothing"、RS 和 CMW500用户手册中对此进行了如下说明:

    "向接收器指示是否建议对频域平滑处理
    通道估算。 值"Non recommended"指示 DUT 仅执行
    每个载波独立通道(未平滑)的估算。"

    当此设置设置设置为"建议"时、其他11n 信道/数据速率的结果提高了1-4dB、但 MCS7信道13的结果比不使用"HT 平滑处理"时的结果提高了12dB (-59dBm 与-71dBm)。 包含测试报告。

    下一个问题是、为什么这个特定设置对 CC33xx 有如此大的影响、尤其是在 MCS7通道13上? CC33xx 在用作 AP 时是否支持该功能;如果我们将一个 CC33xx 配置为 AP、将另一个配置为 STA、我们可以假设现场的 RX 灵敏度足够好吗?

    此致、
    Kaisa.

    e2e.ti.com/.../WLAN_5F00_802.11n_5F00_RX-Sensitivity_5F00_HT-smoothing_5F00_2024_2D00_10_2D00_23_5F00_14_2D00_15_2D00_46_5F00_068.pdf

    e2e.ti.com/.../WLAN_5F00_802.11n_5F00_RX-Sensitivity_5F00_2024_2D00_10_2D00_24_5F00_09_2D00_25_2D00_10_5F00_807.pdf

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

    尊敬的 Kaisa:

    这是一个好消息! 我正在内部检查此 HT 平滑设置及其为什么会产生如此大的影响。

    我会让你知道我在未来几天所发现的。

    此致、

    Jonathan  

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

    尊敬的 Kaisa:

    您能否从 R&S CMW500发送配置文件?  

    我们想要再现您看到的确切内容、但我们需要准确了解 R&S 上配置的内容  

    如果无法输出配置文件、请分享一些屏幕截图、以便准确查看正在配置的内容。

    此致、

    Jonathan  

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

    Jonathan、您好!

    请查看随附的配置文件、其中包含 CMW500 WLAN 信令设置、我希望它适合您。 我还附上了我的试验中关键设置的屏幕截图。 在配置文件中、HT 平滑处理设置为屏幕截图中的"建议"、但将其更改为"不建议"(CMW500中似乎是默认设置)会导致 RX 灵敏度降低、尤其是在 MCS7通道13上。

    此致、
    Kaisa.

     e2e.ti.com/.../SaveFile_5F00_CMW500_5F00_WLANsignaling.zip

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

    尊敬的 Kaisa:

    感谢您提供配置文件、我们将尝试在我们这边重新生成、并了解 HT 平滑处理为何会产生如此大的影响。

    我会在一周结束前回复你。

    此致、

    Jonathan

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

    尊敬的 Kaisa:

    我相信我们已经给出了 HT 平滑效应的解释:

    1. HT 平滑处理定义为前导码中的位、表示建议进行信道估算平滑处理。 平滑处理会对噪声异常值求平均值、从而降低总体噪声影响。   

    2、一般 OFDM 接收器是基于在前导码中对 LTF (长训练场)的信道响应进行估算、然后在接收数据部分期间对信道进行补偿。  这意味着系统中的噪声将应用2次、首先是在通道估算时、然后是在数据符号期间。 这通常会导致噪声高出3dB。 在对通道估算应用平滑处理时、这意味着通道估算上的总噪声较低、为您提供的平均值大约为2.5dB。 这解释了所有通道的改善。  

    3.对于通道13 MCS7:CC3301具有一些针对该频率下杂散发射的额外滤波器、并且我们会擦除一些受影响的数据单元。 这是有意为之。 特别是在 MCS7上、编码速率较高(5/6)、因此任何"坏"频段都将在结束数据包中感受到更多。 高编码速率+有意的频段下降会在未启用平滑处理时增加噪声的 LTF、从而破坏超过其余速率+通道的 RX 灵敏度。  

    4.当 CC3301处于 AP 模式时、始终启用 HT 平滑处理。

    此致、

    Jonathan   

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

    Jonathan、您好!

    感谢您的解释、我相信现在一切都很清楚。

    此致、
    Kaisa.