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.

[参考译文] CC3235S:WLAN 事件和 SlNetConn 连接

Guru**** 2553260 points
Other Parts Discussed in Thread: CC3235S

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1167834/cc3235s-wlan-event-and-slnetconn-connection

器件型号:CC3235S

您好!  

我使用的是具有 SDK 6.10的 CC3235S

 

我进行了以下测试。

我通过将 一个用作 AP、 另一个用作 STA 连接了两个 CC3235S 模块。

重新启动 AP 后、STA 中发生 SL_WLAN_EVENT_DISCONNECT 事件之前的时间因每次测试而异。

甚至在某些情况下、事件也不会发生。 (此时,调用 sl_NetAppPing () API 时会发生一个事件)

  

问题1. 实际 WLAN 事件发生和事件处理程序被调用需要多长时间? (NWP 的 WLAN 连接状态扫描周期)

问题2. 能否设置 Q1中提到的内部 WLAN 连接状态扫描周期? (我设置 SL_WLAN_POICE_SCAN、但它不起作用)

 

 

我正在使用 SlNetConn () API 来使用 ifmodule。

在上述测试中从 STA 连接到 AP 时,我使用带非持久选项的 SlWiFiConn_addProfile() API。

AP 断电后,发生 sl_WLAN_EVENT_DISCONNECT 事件,我调用 SlNetConn_STOP()以停止 NetConn 操作。

但是、当 AP 再次运行时、即使 NetConn 停止、它也会自动连接到 AP。

(在停止 NetConn 运行后、SlWiFiConn 的状态在连接时保持为关闭)

 

问题3.  为什么 SlNetConn 会自动连接到 AP、即使我使用非持久配置文件并停止 NetConn?

 

 

请帮帮我。 谢谢你

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

    关于断开连接、可由于 以下三个原因之一触发断开事件:

      1) AP 的断开事件(如果处于低功耗模式、我们可能会错过此事件)-假设它在重新启动之前发送一个中断事件。

      2) TX 故障(来自 APP 的流量或内部传输、如 KA 帧)

      3) 信标丢失-当我们无法接收大约20个信标时(具体取决于信标间隔和 PS 配置、例如 LSI 值、时间可能会有所不同:通常大约2-3秒)。

      

    Q3:不应发生这种情况(当 SlNetConn 关闭时、射频应关闭)。 您使用的是什么 SP? 您能否提供完整的终端日志(以查看导致关闭状态的顺序)? 您是在代码中的任何位置使用 SL_Start/SL_Stop、还是仅通过 SlNetConn 控制 NWP?

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

    感谢您的回复、

     

    我使用带 NetConn 的 SL_Start/SL_Stop 进行 NWP 设置。 (由于以下链接中的问题、请使用 sl_Start/sl_Stop 而不是 SlWifiConn_reset ()))

    CC3235S:调用 SlWifiConn_reset () API - Wi-Fi 论坛- Wi-Fi - TI E2E 支持论坛时出现延迟

     

    关于断开连接、当 AP 或 STA 在没有断开连接事件的情况下被强制终止时、能否创建并检查定期发送 ping 以了解断开情况的线程?

     

    谢谢。

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

    使用 SlNetConn 时、最好使用 SlWifiConn_RESET、该器件内部调用 sl_Stop/Start、但也会按照模块的要求处理连接策略设置(即、它将确保禁用自动连接)。 直接使用 SL_Stop/Start 可以解释您当前的问题。

    如果 您在器件关闭时调用了 SlWifiConn_reset()(即针对之前调用的每个 SlNetConn_start 函数遵循 SlNetConn_stop()),则不应存在长时间延迟。 请发送显示长延迟的终端日志(定义了 SLWIFICONN_DEBUG_ENABLE)。

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

    现在没有 SlWiFiConn_reset()延迟的终端日志,因为它并不总是发生。

    不过,我已将《工作方案》的记录附在上一个问题之后。

    如果您也需要终端日志、我将捕获它、如果我找到它、我将发布它。

     

    [引用 userid="459139" URL"~/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1167834/cc3235s-wlan-event-and-slnetconn-connection/4394258 #4394258"]关于断开连接,当 AP 或 STA 在没有断开连接事件的情况下被强制终止时,能否创建并检查定期发送 ping 以了解断开连接的线程?

    对此问题有什么更好的想法吗?

     

    谢谢。

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

    如果需要更快地识别断开连接、可以使用周期性 ping。

    对于 AP、每个站点都有一个 KA 机制(预计每个(通常) 1-5 分钟每个站点至少发送一个 NULL 数据包)。 如果空闲超时到期、AP 会将其声明为已断开连接。因此、小于此时间的 ping 周期有助于加快磁盘检测。

    对于基站、信标跟踪是识别 BSS 损耗的另一种机制(例如  由于关闭 AP)。 使用 SimpleLink 、这可能需要几秒钟的时间才能检测到。 如果我们刚刚错过了断开连接事件、但 AP 仍然正常工作(例如、如果其中一方不符合 802.11省电协议、例如基站处于睡眠状态时发送的 AP 断开)、则需要更长时间、应用程序 KA 可以加快检测 (但这不是常见情况)。

      

     

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

    感谢您的回复、

    对于 AP 模块、如您所述、断开事件在大约1分钟后发生、此时 STA 会丢失。

    对于基站模块、 每次测试在 STA 中发生断开连接事件之前的时间是不同的。

    有时、它在几秒钟内发生、有时不会发生。

    无论如何、我将实现它以使用周期性 Ping。

    谢谢。