[参考译文] CC3200：UDP 封包

您好 Roger、

只需检查一下、接收器侧是否提供了波形？ 还使用了什么电源策略？ 如果是延迟问题、您可以尝试始终开启电源策略以快速排除该问题。

Jesu

您好报价、

感谢您的支持。 您是正确的、波形在接收器侧提供。 它不会将 电源策略设置为 sl_low_latency 策略或 sl_always_ON_policy。 请按如下方式查找图片(分类：pic1、pic2、pic3、pic4)：

1、pico 1：接收器侧的 sl_always_ON_POLOCY。  

2、pico 2：发送方侧的 sl_always_ON_POLOCY。

3、pico：接收器侧的 sl_low_latency 策略。

4、pic4：发送器侧的 sl_low_latency 策略。

你好，Jesu：

我们还在 sl_low_latency 策略设置中将发送器端的电流设置为一个值。 请查找并检查。 谢谢！

您好 Roger、

感谢您提供屏幕截图。 使用"始终开启"可以改善延迟、但从屏幕截图中判断、您仍然会遇到相同的问题。 您是否正在运行 CC3200 SDK 中的 wifi 音频应用示例？ 此外、您是否在开始发送数据之前在接收器侧缓冲样本？  

Jesu

您好、Jesu、

 示例为 C：\ti\CC3200SDK_1.4.0\cc3200-sdk\examples\wi_audio_app。 我们只将 STA 模式更改为 P2P 模式。 如果您可以帮助您进行测试并将测试结果发布给我们、就会更好。  此外、如果您需要、我们还可以向您发布源代码。 谢谢！

您好 Roger、

很抱歉耽误了时间、我本周没有时间测试。 由于环境噪声、您似乎会降低性能、因此即使我运行它、我也无法保证看到您看到的内容。 为什么在应用启动之前不要尝试通道扫描、并选择本底噪声最低的通道？  

Jesu

您好、Jesu、

感谢您的回复！  

WiFi Direct Listen (直接侦听)和 Open (打开)有效频道为1/6/11。 我们似乎 不能做更多的选择。

现在，我们配置为：

#define LISENING_CHANNEL   11.
#define regulatory_class   81.
#define OPERAING_CHANNEL  6.

P2P 说明：

侦听通道(对于2.4GHz、为1/6/11)  

侦听监管等级(2.4GHz 为81)   
Oper 通道(对于2.4GHz、为1/6/11)   
Oper 监管等级(2.4GHz 为81)    
 监听信道和监管类将在 P2P 查找监听阶段确定设备监听信道  
 Oper 通道和管制类别将决定此器件首选的操作通道(如果是组所有者、则为操作通道)  
 渠道应是社会渠道之一(1/6/11)。 如果未选择侦听/选择器通道、则将选择随机的1/6/11。
 此选项将指向_u8[4]的指针作为参数

您好 Roger、

因此、在通道1/6/11中、我建议您在应用程序启动之前运行扫描、并从3个可用的 RSSI 中选择具有最低 RSSI 的。  

Jesu