Wlan rate control acting strange

[eriksl]

I have some problems with the 802.11g/n rate control. My esp's never connect at 65 mbps (N) or 54 mbps, it's always a slower speed, usually 13 mbps or 24 mbps. That in itself is no problem. But I found out that when I start to send larger amounts of data over tcp, the rate drops (as monitored on the access point) to 2 mbps or lower, reproducable, and stays there. When it limit the rate of the data over the tcp connection to smaller chunks, it does not happen. With the large chunks (tcp payload of 1024 bytes) the problem often happens, but not always.

Now it gets more interesting. When I configure the access point to only allow 54 mbps (G) or 65 mbps (N), this just works, all esp's connect at the appropriate speed and it works like a charm. Sending the same chunks of data now works like it should.

The esp I am testing at, is only three meters from the access point, the others are 5 - 20 meters, and they all work fine at 54 mbps if configured so at the access point, only minimal to none packet loss.

So then I tried to configure the rate at the esp8266 itself to static 54 mbps (G) or 65 mbps (N) using the various API calls, but none of them work. If I use any of them, the esp can't cannect to the access point (f,-180). I doesn't not matter what speed/rate/mcs I choose. This is without rate restrictions on the access point, it will accept any rate.

The esp's I use are esp01 and esp-201 and it makes no difference. Some of them SDK 1.2.0, some have 1.4.0 and I also tested with 1.5.1.

[eriksl]

What are other people's experiences? What speed your ESP's normally connect to your access point?

Does anybody use the rate API?

[ESP_Faye]

So then I tried to configure the rate at the esp8266 itself to static 54 mbps (G) or 65 mbps (N) using the various API calls, but none of them work. If I use any of them, the esp can't cannect to the access point (f,-180).

Could you provide your test code for debugging ?

[eriksl]

Okay, of course. I tried all of these. The calls to the first function wifi_set_use_fixed_rate all result the connection being dropped and reconnection failing. Blue is before wifi_set_user_fixed_rate and red after. The other functions (wifi_set_user_sup_rate and wifi_set_user_rate_limit) don't have any effect at all, the rate with the access point remains the same (which can vary quite a bit).

mode : sta(18:fe:34:99:94:31)
add if0
f r0,
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 5
cnt
connected with 1447NC49AVR, channel 1
dhcp client start...
ip:10.1.12.6,mask:255.255.255.0,gw:10.1.12.1
Mon Feb 01 18:58:30 2016
pm open,type:0 0
state: 5 -> 0 (0)
rm 0
pm close 7
f r0, scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (2)
reconnect
f 0, scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (2)
reconnect
f -180, scandone
no 1447NC49AVR found, reconnect after 1s
reconnect
f r0, scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (2)
reconnect
f 0, scandone
state: 0 -> 2 (b0)
state: 2 -> 0 (2)
reconnect
f -180, scandone
no 1447NC49AVR found, reconnect after 1s
reconnect
f r0, scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 0 (4)
reconnect
...etc...

This code works with mode == 0 (so no specific rate action is performed).

Code: Select all

        wifi_station_set_auto_connect(0);
   wifi_station_disconnect();

   wifi_set_opmode(STATION_MODE);
   wifi_set_phy_mode(PHY_MODE_11G);

   switch(mode)
   {
      case(1): wifi_set_user_fixed_rate(FIXED_RATE_MASK_STA, PHY_RATE_48); break;
      case(2): wifi_set_user_fixed_rate(FIXED_RATE_MASK_STA, PHY_RATE_24); break;
      case(3): wifi_set_user_fixed_rate(FIXED_RATE_MASK_STA, PHY_RATE_12); break;
      case(4): wifi_set_user_fixed_rate(FIXED_RATE_MASK_STA, PHY_RATE_6); break;
      case(5): wifi_set_user_fixed_rate(FIXED_RATE_MASK_STA, PHY_RATE_54); break;
      case(6): wifi_set_user_fixed_rate(FIXED_RATE_MASK_STA, PHY_RATE_36); break;
      case(7): wifi_set_user_fixed_rate(FIXED_RATE_MASK_STA, PHY_RATE_18); break;
      case(8): wifi_set_user_fixed_rate(FIXED_RATE_MASK_STA, PHY_RATE_9); break;

      case(10): wifi_set_user_sup_rate(RATE_11B5M, RATE_11G54M); break;
      case(11): wifi_set_user_sup_rate(RATE_11B5M, RATE_11G36M); break;
      case(12): wifi_set_user_sup_rate(RATE_11G6M, RATE_11G54M); break;
      case(13): wifi_set_user_sup_rate(RATE_11G6M, RATE_11G36M); break;
      case(14): wifi_set_user_sup_rate(RATE_11G36M, RATE_11G54M); break;
      case(15): wifi_set_user_sup_rate(RATE_11G36M, RATE_11G36M); break;

      case(20): wifi_set_user_rate_limit(RC_LIMIT_11G, 0x00, RATE_11G_G54M, RATE_11G_B1M); wifi_set_user_limit_rate_mask(LIMIT_RATE_MASK_STA); break;
      case(21): wifi_set_user_rate_limit(RC_LIMIT_11G, 0x00, RATE_11G_G54M, RATE_11G_G6M); wifi_set_user_limit_rate_mask(LIMIT_RATE_MASK_STA); break;
      case(22): wifi_set_user_rate_limit(RC_LIMIT_11G, 0x00, RATE_11G_G54M, RATE_11G_G18M); wifi_set_user_limit_rate_mask(LIMIT_RATE_MASK_STA); break;
      case(23): wifi_set_user_rate_limit(RC_LIMIT_11G, 0x00, RATE_11G_G54M, RATE_11G_G36M); wifi_set_user_limit_rate_mask(LIMIT_RATE_MASK_STA); break;
      case(24): wifi_set_user_rate_limit(RC_LIMIT_11G, 0x00, RATE_11G_G54M, RATE_11G_G48M); wifi_set_user_limit_rate_mask(LIMIT_RATE_MASK_STA); break;
      case(25): wifi_set_user_rate_limit(RC_LIMIT_11G, 0x00, RATE_11G_G54M, RATE_11G_G54M); wifi_set_user_limit_rate_mask(LIMIT_RATE_MASK_STA); break;
   }

   ets_memset(&station_config, 0, sizeof(station_config));
   strlcpy(station_config.ssid, config.ssid, sizeof(station_config.ssid));
   strlcpy(station_config.password, config.passwd, sizeof(station_config.password));
   station_config.bssid_set = 0;
   wifi_station_set_config(&station_config);
   wifi_station_connect();


[ESP_Faye]

Hi,

wifi_set_use_fixed_rate() function means ESP8266 will send every package with the fixed rate specified by this function.
If the rate is not reasonable, the AP will not accept the package sent from ESP8266, so the connection maybe failed.
For example of "the rate is not reasonable":
1. The ap could only receive 11B package, but the fixed rate is 11G.
2. The environment is bad, the ap almostly cannot receive HIGH SPEED RATE.

The rate control APIs are advance function for some special scene. Could you explain more about your application, what is the fixed rate for in your application ?

Thanks for your interest in ESP8266 !

[eriksl]

Hi Faye,

wifi_set_use_fixed_rate() function means ESP8266 will send every package with the fixed rate specified by this function.
If the rate is not reasonable, the AP will not accept the package sent from ESP8266, so the connection maybe failed.
For example of "the rate is not reasonable":
1. The ap could only receive 11B package, but the fixed rate is 11G.
2. The environment is bad, the ap almostly cannot receive HIGH SPEED RATE.

The access point is only 2.5 meters away from the ESP and has a direct line-of-sight. It has heen proven on many occassions that 54 mbps (G) and 65 mbps (N) works correctly. The access point is a managed 802.11abgn one and has, when I am testing this, no restrictions on the connected rate, so everything from low rate B to high rate/mcs N will be accepted by the access point.

As soon as I activate one of the rates using wifi_set_user_fixed_rate, you can see I tried many, from the lowest to the highest rate, most of the packets are dropped and the access point still says it's connected at the original speed. Only a reset solves this condition.

The rate control APIs are advance function for some special scene. Could you explain more about your application, what is the fixed rate for in your application ?

I have observed that every time I send greater quantities of data, the connected rate drops, up to the point were only 2 mbps is left and the ESP becomes unresponsive. The data is acknowledged every 1024 bytes, so there is never more than that amount of data sent before the ESP has fully processed it, so it's no buffering issue. The interesting thing is that all problems are gone when I configure the access to only accept 54 mbps (G) or 65 mbps (N). This is no ideal solution though, because other clients may need to connect at other speeds. So that's why I want the ESP to impose the limit and not the access point.

It would be even better if the root of the issue would be solved of course

If you want to test yourself, try my firmware: http://github.com/eriksl/esp8266-universal-io-bridge. It needs opensdk. Try to do a OTA upgrade, you need to have a 16 mbit flash for that to work. I am testing with the verify option, so the flash doesn't get written over-and-over-again and also it eliminates the risk that the page erase (interrupts, delay) would interfere with the rate control.

[ESP_Faye]

Hi,

But I found out that when I start to send larger amounts of data over tcp, the rate drops (as monitored on the access point) to 2 mbps or lower, reproducable, and stays there.

We think there may be something wrong with your AP, could you check the APs nearby with WIFI ANALyzer and provide the captured picture ?
Could you try it with another AP ?

We suggest that you should not use WiFi rate control APIs in your case, these APIs are for special usage which seems not suitable for your case. They are only change TX rate, not RX.

[eriksl]

Okay let's assume "there is something wrong" with my access point, then why don't the other (PDA) clients have no similar problems?

Your remark about the rate limit being only TX makes sense to me. What I am looking for is a way to influence the negotiated speed at PHY level. So it's probably not going to do what I want after all. Maybe it's worth adding a remark about that in the documentation.

I don't quite understand where the api is actually meant for, then.