Data loss using SPWF01SA (multiples of 2kiB)

Posted on October 13, 2015 at 15:03

Hi Georg,

can you please share a simple use case to help me figuring out what's going wrong?

STA/miniAP, socket server/client, config & status dump, other...

Thanks

jerry

Posted on October 13, 2015 at 15:38

Status and config:

# Status & Statistics:

#  version = 150410-c2e37a3-SPWF01S 

#  reset_reason = 2

#  conf_flag = 5

#  system_uptime = 20

#  system_sleeptime = 0

#  gpio_enable = 0

#  captiveportal = 0

#  wifi_state = 10

#  wifi_bssid = 34:80:B3:D4:67:15

#  wifi_aid = 5

#  wifi_channelnum = 6

#  wifi_sup_rate_mask = 0x003FFFCF

#  wifi_bas_rate_mask = 0x0000000F

#  wifi_chan_activity2 = 0x00001FFF

#  wifi_max_tx_power = 17

#  wifi_gf_mode = 0

#  wifi_reg_country = DE 

#  wifi_dtim_period = 2

#  wifi_sleeping = 0

#  wifi_num_assoc = 0

#  ip_ipaddr = 192.168.43.177

#  ip_netmask = 255.25Ãœ :00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

#  wifi_ssid_len = 5

#  wifi_txfail_thresh = 5

#  wifi_ht_mode = 0

#  wifi_channelnum = 6

#  wifi_opr_rate_mask = 0x00003FCF

#  wifi_bas_rate_mask = 0x0000000F

#  wifi_mode = 1

#  wifi_auth_type = 0

#  wifi_atim_window = 0

#  wifi_powersave = 0

#  wifi_tx_power = 18

#  wifi_rssi_thresh = 0

#  wifi_rssi_hyst = 0

#  wifi_ap_idle_timeout = 120

#  wifi_beacon_loss_thresh = 10

#  wifi_priv_mode = 2

#  wifi_wep_keys[0] = 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

#  wifi_wep_keys[1] = 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

#  wifi_wep_keys[2] = 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

#  wifi_wep_keys[3] = 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

#  wifi_wep_key_lens = 00:00:00:00

#  wifi_wep_default_key = 0

#  wifi_wpa_psk_raw = 24:DB:77:EC:C9:64:8A:DC:EC:33:C7:E7:AD:45:4F:90:B5:4F:0A:A8:12:90:CC:FC:DC:9E:58:BF:FA:D6:1D:A6

#  wifi_wpa_psk_text = jeufftdgbvysfjk

#  ip_use_dhcp = 1

#  ip_use_httpd = 1

#  ip_mtu = 1500

#  ip_hostname = iwm-B5-8A-51

#  ip_apdomainname = captiveportal.net

#  ip_apredirect = firstset.html

#  ip_ipaddr = 192.168.0.50

#  ip_netmask = 255.255.255.0

#  ip_gw = 192.168.0.1

#  ip_dns = 192.168.0.1

#  ip_http_get_recv_timeout = 3000

#  ip_wait_timeout = 12000

#  ip_dhcp_timeout = 20

#  ip_sockd_timeout = 5

# Dumping All Configuration Keys:

#  nv_manuf = ST

#  nv_model = SPWF01SA1

#  nv_serial = 2215D28923

#  nv_wifi_macaddr = 00:80:E1:B5:8A:51

#  blink_led = 0

#  wind_off_low = 0x00000000

#  wind_off_medium = 0x00000000

#  wind_off_high = 0x00000000

#  user_desc = anonymous

#  escape_seq = at+s.

#  localecho1 = 0

#  console1_speed = 460800

#  console1_hwfc = 1

#  console1_enabled = 1

#  sleep_enabled = 0

#  standby_enabled = 0

#  standby_time = 10

#  wifi_tx_msdu_lifetime = 0

#  wifi_rx_msdu_lifetime = 0

#  wifi_operational_mode = 0x00000011

#  wifi_beacon_wakeu p_key_lens = 00:00:00:00

#  wifi_wep_default_key = 0

#  wifi_wpa_psk_raw = 24:DB:77:EC:C9:64:8A:DC:EC:33:C7:E7:AD:45:4F:90:B5:4F:0A:A8:12:90:CC:FC:DC:9E:58:BF:FA:D6:1D:A6

#  wifi_wpa_psk_text = jeufftdgbvysfjk

#  ip_use_dhcp = 1

#  ip_use_httpd = 1

#  ip_mtu = 1500

#  ip_hostname = iwm-B5-8A-51

#  ip_apdomainname = captiveportal.net

#  ip_apredirect = firstset.html

#  ip_ipaddr = 192.168.0.50

#  ip_netmask = 255.255.255.0

#  ip_gw = 192.168.0.1

#  ip_dns = 192.168.0.1

#  ip_http_get_recv_timeout = 3000

#  ip_wait_timeout = 12000

#  ip_dhcp_timeout = 20

#  ip_sockd_timeout = 5

As a test, I'm simply sending 1024 byte blocks without pausing, each consisting of 1024 x the same byte. From block to block, the byte increases by one, so I can check how much is lost. I look for the first and last byte of the block, and they are almost always the same. Additionally, using wireshark I can see that always n x 2kiB are lost.

Posted on October 14, 2015 at 09:21

MTU is limited when socket server is opened.

Please take a look at this thread:[DEAD LINK /public/STe2ecommunities/interface/Lists/WiFi%20Modules/Flat.aspx?RootFolder=/public/STe2ecommunities/interface/Lists/WiFi%20Modules/Flow%20control%20not%20working%20as%20I%20expect&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800086789498A6852D4897EA192EB1DEE909&TopicsView=https%3a//my.st.com/public/STe2ecommunities/interface/Lists/WiFi%2520Modules/AllItems.aspx&currentviews=57]https://my.st.com/public/STe2ecommunities/interface/Lists/WiFi%20Modules/Flat.aspx?RootFolder=%2fpublic%2fSTe2ecommunities%2finterface%2fLists%2fWiFi%20Modules%2fFlow%20control%20not%20working%20as%20I%20expect&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800086789498A6852D4897EA192EB1DEE909&TopicsView=https%3A%2F%2Fmy%2Est%2Ecom%2Fpublic%2FSTe2ecommunities%2Finterface%2FLists%2FWiFi%2520Modules%2FAllItems%2Easpx¤tviews=57

Message posted on 10/7/2015 1:53 PM

Let me know if it helps

j

Posted on October 14, 2015 at 09:36

Hi jerry,

flow control seems to work fine, see first post. Concerning the buffer size and timing I'm not sure, what I have to take care of. I would assume that a full buffer leads to an RTS signal, so transmission automatically pauses until the buffer is ready again. Or do I need to somehow check buffer usage?

Posted on October 14, 2015 at 09:52

Hi Georg,

correct. Every time buffer is full, RTS stops (should stop) external MCU/PC.

I always see this behaviour, and, so, I'm not able to reploduce data loss using flow control.

I use ST Eval Board (IDW001), and a PC (linux).

Posted on October 14, 2015 at 10:21

Hi jerry,

with RTS on, a package is lost only within minutes. Disabling RTS leads to about 20% data loss, so I think I can be sure about RTS working fine. I would guess that the problem occurs after UART transmission inside the module.

My SPWF01SA is directly connected to a STM32F4.

Posted on October 14, 2015 at 10:32

     I would guess that the problem occurs after UART transmission inside the module.

I expect data loss over the air only in UDP mode. In TCP, packets are ack-ed, retransmitted, etc.

     My SPWF01SA is directly connected to a STM32F4.

USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_CTS | USART_HardwareFlowControl_RTS, right ?