• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 42 subscribers
  • Views 446 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

Linux/WL1807MOD: ACK time out

Linux/WL1807MOD: 3km communication use case on the WL18x

Kz777
Expert 7895 points
Part Number: WL1807MOD


Tool/software: Linux

Hi Champs,

Have you realized more than 3km commutation on the WL18xx series ?

According to customer investigation, this is possible to realize with external  directive antenna.

If you have such a parameter or sample code , could you please tell ?

Actually, customer tried to more than 3km communication. However, they failed communication between AP and STA connection.

When they scan SSID at this AP and STA with 3km, SSID scan is able to confirm between AP and STA.

Then, RRSI show Rx sensitivity around -80dBm. So, RF performance has affordable.

They also confirmed SSID information at 5km. So, RF signal quality and noise must be no problem.  

When they look into log and packet capture, AP side send Association Response. On the other hand STA side didn't sent ACK.

After this STA send data flame that is created by MAC address exchange , it disconnected due to  "Class 3 frame received from nonassociated STA"

However, they confirmed when we established AP and STA connection near distance. 

Then , they moved to 5km point this data flame communication is continue available.

We used to previous thread about "ACK Timeout" issue. However, we suspect another issue due to above additional information.

So, could you advice some suspect register or code ?

Regards,

Kz777 

  • 0
    TI__Mastermind 28285 points

    Kz777,

    Using our device in such a way is not a typical use case, and we don't have much guidance we can provide.

    What i will say is that if you are using highly directional antennas, and you are able to get -80 dBm from the AP, what are you getting from the Station? You will need to properly measure and validate the link budget here for both devices, because a connection to Access point required bi-directional communication. Even at 80 dBm, i do expect performance issues because of the low signal quality.

    Best,

    Vince

  • 0 in reply to Vincent Rodriguez
    TI__Expert 7895 points

    Hi Vince,

    Thanks for comment.

    This is our customer feed back.

    RSSI/SNR value is -83dBm@AP and 30dB@STA on the 5km transmitt. So, customer didn't concern this value.

    So, when they realize bellow wired communication, transmit was success negotiation around -90dBm sensitivity at RSSI.

    Unit(AP_mode)　 ⇔　VATT 　⇔　Unit(STA_mode)

    So, it is doesn't relate Rx signal strength issue. 

    This log is  wireless  log ************************************************************* 

    [Tue Jun 25 11:58:21.308 2019] wlanA: Event TX_STATUS (17) received

    [Tue Jun 25 11:58:21.308 2019] mgmt::assoc_resp cb

    [Tue Jun 25 11:58:21.308 2019] wlanA: STA 40:bd:32:xx:xx:xx IEEE 802.11: did not acknowledge association response

    [Tue Jun 25 11:58:21.495 2019] nl80211: sta_remove -> DEL_STATION wlanA 40:bd:32:xx:xx:xx --> 0 (Success)

    [Tue Jun 25 11:58:21.495 2019] nl80211: Event message available

    [Tue Jun 25 11:58:21.495 2019] nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for wlanA

    [Tue Jun 25 11:58:21.495 2019] nl80211: Delete station 40:bd:32:xx:xx:xx

    ***********************************************************************************

    *At this moment, STA side judged to complete negotiation.

    When we ping, we have such a log

     

    [Tue Jun 25 11:58:21.698 2019] nl80211: Event message available

    [Tue Jun 25 11:58:21.698 2019] nl80211: BSS Event 83 (NL80211_CMD_UNEXPECTED_FRAME) received for wlanA

    [Tue Jun 25 11:58:21.698 2019] wlanA: Event RX_FROM_UNKNOWN (18) received

    [Tue Jun 25 11:58:21.698 2019] Data/PS-poll frame from not associated STA 40:bd:32:xx:xx:xx

    [Tue Jun 25 11:58:21.698 2019] nl80211: send_mlme - da= 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 2019] nl80211: send_frame - Use bss->freq=4980

    [Tue Jun 25 11:58:21.698 2019] 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 00 40 bd 32 xx xx xx 40 bd 32 xx xx xx 40 bd 32 xx xx xx 00 00 07 00

    [Tue Jun 25 11:58:21.698 2019] nl80211: Frame TX command accepted; cookie 0x14e

    [Tue Jun 25 11:58:21.698 2019] nl80211: Event message available

    [Tue Jun 25 11:58:21.698 2019] nl80211: BSS Event 83 (NL80211_CMD_UNEXPECTED_FRAME) received for wlanA

    [Tue Jun 25 11:58:21.698 2019] wlanA: Event RX_FROM_UNKNOWN (18) received

    [Tue Jun 25 11:58:21.308 2019] wlanA: Event TX_STATUS (17) received

    [Tue Jun 25 11:58:21.308 2019] mgmt::assoc_resp cb

    [Tue Jun 25 11:58:21.308 2019] wlanA: STA 40:bd:32:xx:xx:xx IEEE 802.11: did not acknowledge association response

    [Tue Jun 25 11:58:21.495 2019] nl80211: sta_remove -> DEL_STATION wlanA 40:bd:32:xx:xx:xx --> 0 (Success)

     

    So, we have additional question.

    1:Do we have any method to see register value that is set by wl18xx-conf.bin during wl1807 system working ?  

     2: Can we confirm when control packet (ACK) send or receive ? 

        -because, we confirmed management flame or data flame using "tcpdump". However, we can't see control frame. 

    3: Is this able to confirm control packet (ACK) changing Glogger logging level ?

    Regards,

    Kz777

  • 0 in reply to Kz777
    Prodigy 15 points

    Hi Kz777,

    In general, default values of ACK_TIMEOUT and Inter Frame Spacing timings will be configured to map in and around 300 meters. When distance is increased, air propagation delay needs to be added to ACK_TIMEOUT and other inter frame spacing timeouts for proper data negotiation. 

    So in your case probably the STA or AP is getting timed out before even the ACK is heard. Hope this helps. 

    Thanks