ESP8266 Community Forum

- Sat Aug 15, 2015 11:53 am #26078 I have had trouble with ESP located near the edge of the radio range. What happens is that when the radio link goes down and then later again resumes, the receive direction in ESP does not start working. Only the transmit direction from ESP to AP starts working. The rx signal appears to be lost permanently and only power reset gets it going again as far as I noticed.

My ESP program basics are copied from the UDP code example on the forum. ESP and everything else in my LAN have fixed IP addresses.

It looks to me that there could be some issue in starting ESP rx processing after a temporary WLAN break. Since the radio link does recover, ESP can at least receive protocol messages on the radio link layer.

Perhaps I missed something in my code. Anybody had this kind of problem or knows what to do to? It looks though that I could circumvent the problem by adding to the loop a test if WiFi.status() != WL_CONNECTED and if the state changes from NOT_CONNECTED to CONNECTED, do again WiFiUDP.begin(localPort). But maybe someone knows how this really should be done.

- Sat Aug 15, 2015 3:20 pm #26097 Check this blog post by Peter Scargill:
http://tech.scargill.net/testing-esp8266-wifi/

- Sat Aug 15, 2015 10:48 pm #26111 About adding delay() to the code for ESP packet processing; I have seen these instructions:

http://arduino.esp8266.com/versions/1.6 ... rence.html

My ESP program has delay(200) every time a message is sent or received. Besides that the instructions say that every time the loop function completes, the Wifi and TCP/IP libraries get a change to handle pending events. Thought that would be enough. I guess it depends on how much traffic there is. The LAN creates some unknown amount traffic besides user traffic, like ARP requests.

My program does Onewire temperature measurement once per minute and sends a small UDP packet. Also the host computer tests the connection once per minute and sends a short UDP packet to which ESP should reply. I don't think that is too much traffic. Onewire includes one rather long wait (about 750 ms). Perhaps I should try to open Onewire SW and put delay() in there too. But I have two more ESPs in my tests, located closer to the AP, and they have not had this problem.

Scargill seems to have traffic (TCP/IP) every sec. In his case the connection eventually was lost in spite of his corrections. Don't have time to look at it just now. My tests have been running OK now for some time.