ESP8266 Community Forum

A command I would like to see and that most wifi modules out there offer : a simple way to retrieve the RSSI (signal strength) to the base station. Something like AT+RSSI?.

Another important improvement is to remove those "NO THIS FUN" error messages which makes no sense and that are not consistent with the rest of the API.

Finally, errors would be improved with an error code. i.e: "ERROR:02" with the code giving the exact reason and helping recover.

hello everyone


my at cmmand is not working ,while other code i have flashed is working what is issue

kindly help me at tthis issue

Dear Team,

I got a ESP8266 module and apply AT+GMR command,getting the information
AT version: 0.25 and SDK version: 1.1.1
[Vendor:www.ai-thinker.com ]

Unfortunately I am uable to communicate to Andriod mobile.
Module act as server: AT+CWMODE=3; AT+CIPMUX=1; AT+CIFSR->192.168.4.1; Android mobile IP: 192.168.4.2;
AT+CIPSERVER=1, 80; AT+CIPSTO=2000;

Ping from mobile to module is working. But all time we getting AT+CIPSTATUS? -> 5;

Please help me to provide details information.

Thanks

I want receiving to be command driven and not async to be able to make a web server on a connected arduino controller. Arduino usually have 2KBof RAM so you can't barely hold things in memory. If I want to send an AT command and then an incomming packet arrive I will get the packet instead of the AT command answer. I need to process the packet in that moment and later get the AT command answer. This is really hard to do. I can't buffer the packet for later. Even the packet may be too big for ram itself. We need flow control.

Imagine we want to send an AT command (list WIFI networks) and a long HTTP request arrives. It is 2048KB long but we receive it on two packets. We might have to get the first part, half process it as we can't hold it in memory, stop at end of packet, process the AT command answer and resume the HTTP request process. IT IS REALLY REALLY HARD!

ESP8266 has more ram than Arduino. It should buffer the packets. There may be a async notification of a received packet but a short one, not with the data and the data need to be requested later with a command and a size limit. At least for TCP where it is a stream and spliting the packets is not important. On UDP we need to think something similar but spliting the packets is not so simple as it is not a stream. You should not join two UDP packets as one.

Small packet notifications and data flow control may be a workarround. Eg: Max 32 bytes notifications and flow control with AT commands: -> STOP DATA, AT COMMAND, GET AT ANSWER, RESUME DATA.