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.

[参考译文] Linux/WL1807MOD:WL18x 上的3km 通信用例

Guru**** 2442090 points


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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/815148/linux-wl1807mod-3km-communication-use-case-on-the-wl18x

器件型号:WL1807MOD

工具/软件:Linux

您好、香榭丽舍

您是否在 WL18xx 系列上实现了超过3km 的换向?

根据客户调查、这可以通过外部 指令天线实现。

如果您有这样的参数或示例代码,您能告诉吗?

实际上、客户尝试了3公里以上的通信。 但是、AP 和 STA 连接之间的通信失败。

当它们在此 AP 和 STA 上扫描 SSID (3km)时、SSID 扫描能够在 AP 和 STA 之间进行确认。

然后、RRSI 显示-80dBm 左右的 Rx 灵敏度。 因此、射频性能是经济实惠的。

他们还确认了5公里处的 SSID 信息。 因此、射频信号质量和噪声一定不能成为问题。   

当他们查看日志和数据包捕获时、AP 端发送关联响应。 另一方面、STA 端未发送 ACK。

在该 STA 发送由 MAC 地址交换创建的数据火焰后,由于 “从非关联 STA 接收到3类帧”,STA 将断开连接

但是、当我们建立了接近距离的 AP 和 STA 连接时、他们确认了这一点。  

然后,他们移动到5公里点,这种数据火焰通信继续可用。

我们以前讨论过"ACK Timeout (ACK 超时)"问题。 但是、由于上述其他信息、我们怀疑另一个问题。

那么,您能否建议一些可疑的寄存器或代码?

此致、

Kz777  

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

    Kz777、

    以这种方式使用我们的器件并不是典型的用例、我们也没有提供太多指导。

    我要说的是、如果您使用的是高定向天线、并且能够从 AP 获得-80dBm、您将从基站获得什么? 您需要在此处正确测量和验证两个器件的链路预算、因为连接到接入点需要双向通信。 即使在80dBm 的条件下、我也希望由于信号质量较低而出现性能问题。

    最棒的

    Vince

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

    尊敬的 Vince:

    感谢您的评论。

    这是我们的客户反馈。

    5公里传输速率上的 RSSI/CSI 值为-83dBm@AP 和30dB@STA。 因此、客户不担心这个值。

    因此、当他们实现了低水平的有线通信时、在 RSSI 的-90dBm 灵敏度上、传输是成功协商。

    单元(AP_MODE)⇔VATT⇔单元(STA_MODE)

    因此、它与 Rx 信号强度问题无关。  

    此日志是 无线 日志  

    [TUE JUN 25 11:58:21.308 20193] WLANA:收到事件 TX_STATUS (17)

    [Tue Jun 25 11:58:21.308 20194]管理:assoc_resp CB

    [Tue Jun 25 11:58:21.308 2019] WLANA:STA 40:BD:32:xx:xx:xx IEEE 802.11:未确认关联响应

    [Tue Jun 25 11:58:21.495 2019] nl80211:STA_remove -> DEL_STATION WLANA 40:BD:32:xx:xx:xx -> 0 (成功)

    [Tue Jun 25 11:58:21.495 2019 ] nl80211:提供事件消息

    [TUE JUN 25 11:58:21.495 2019] nl80211:WLANA 接收到 DRV 事件20 (NL80211_CMD_DEL_STATION)

    [Tue Jun 25 11:58:21.495 2019] nl80211:删除 station 40:BD:32:xx:xx:xx

    (三

    *目前,STA 方面决定完成谈判。

    当我们 ping 时、我们有这样的日志

     

    [Tue Jun 25 11:58:21.698 2019 ] nl80211:提供事件消息

    [Tue Jun 25 11:58:21.698 20193] nl80211:WLANA 接收到 BSS 事件83 (NL80211_CMD_Unexpected 帧)

    [Tue Jun 25 11:58:21.698 2019 ] WLANA:收到事件 RX_FER_UNKNOWN (18)

    [Tue Jun 25 11:58:21.698 2019年]来自未关联 STA 40:BD:32:xx:xx:xx:xx 的数据/PS 轮询帧

    [Tue Jun 25 11:58:21.698 2019] nl80211:send_mlme - d= 40:BD:32:xx:xx:xx noack=0 freq=0 no_CCK=0 offchanok=0 wait_time=0 fc=0xa0 (wlan_FC_STYPE_DISASSOC) nlmode =3

    [Tue Jun 25 11:58:21.698 2019 ] nl80211:send_mlme -> send_frame

    [Tue Jun 25 11:58:21.698 20191] nl80211:send_frame - use bss->freq=4980

    [Tue Jun 25 11:58:21.698 20191] nl80211:send_frame -> send_frame_cmd

    [Tue Jun 25 11:58:21.698 2019] nl80211:CMD_FRAME FREQ=4980 WAIT=0 NO_CCK=0 NO_ACK_0 offchanok=0

    [Tue Jun 25 11:58:21.698 2019] CMD_FRAME - hexdump (len=26):A0 00 00 40 BD 32 xx 40 BD 32 xx 40 BD 32 xx xx xx 40 BD 32 xx xx xx xx xx xx 00 07 00

    [Tue Jun 25 11:58:21.698 2019 ] nl80211:接受帧 TX 命令;Cookie 0x14e

    [Tue Jun 25 11:58:21.698 2019 ] nl80211:提供事件消息

    [Tue Jun 25 11:58:21.698 20193] nl80211:WLANA 接收到 BSS 事件83 (NL80211_CMD_Unexpected 帧)

    [Tue Jun 25 11:58:21.698 2019 ] WLANA:收到事件 RX_FER_UNKNOWN (18)

    [TUE JUN 25 11:58:21.308 20193] WLANA:收到事件 TX_STATUS (17)

    [Tue Jun 25 11:58:21.308 20194]管理:assoc_resp CB

    [Tue Jun 25 11:58:21.308 2019] WLANA:STA 40:BD:32:xx:xx:xx IEEE 802.11:未确认关联响应

    [Tue Jun 25 11:58:21.495 2019] nl80211:STA_remove -> DEL_STATION WLANA 40:BD:32:xx:xx:xx -> 0 (成功)

     

    那么、我们还有其他问题。

    1:在 wl1807系统工作期间、我们是否有任何方法可以查看 wl18xx-conf.bin 设置的寄存器值?   

     2:我们能否确认何时发送或接收控制数据包(ACK)?  

      因为,我们使用“tcpdump”确认了管理火焰或数据火焰。 但是、我们看不到控制帧。  

    3:这是否能够确认控制数据包(ACK)是否更改了记录器日志级别?

    此致、

    Kz777

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

    您好 Kz777、

    通常、ACK_TIMEOUT 和帧间间隔时序的默认值将配置为在300米左右的距离内映射。 当距离增加时、需要将空气传播延迟添加到 ACK_TIMEOUT 和其他帧间间隔超时、以实现正确的数据协商。  

    因此、在您的情况下、STA 或 AP 可能会在收到 ACK 之前超时。 希望这对您有所帮助。  

    谢谢