ESP8266 strange "SEND OK" delay

Flodis
Posts: 4
Joined: Tue Nov 14, 2017 9:23 am

ESP8266 strange "SEND OK" delay

Postby Flodis » Tue Nov 14, 2017 9:51 am

Using CIPSEND there is a long 290ms delay between the "Recv NN bytes" and the "SEND OK" confirmation.

The delay is much shorter if there is a response from a web server or similar. As soon as data is coming back from the destination server the "SEND OK" also returns. If the response time is 20ms the SEND OK is also returned fast and comes first, with no time separation from received remote data.

The images below show a blue signal being data sent to the ESP8266 and yellow being the response.

Image
If server response is delayed the "SEND OK" comes by itself after 290ms.

Image
If remote server responds in 20ms the "SEND OK" returns much faster in front of the response data.

It looks like the ESP8266 "forgets" to flush the input stream. With no remote response, flushing is finally done by an internal timer after 290ms. When a remote response returns earlier than the 290 ms, the ESP8266 is forced to send data back - starting with "SEND OK".



It is strange functionality?? Can it be explained?

Flodis
Posts: 4
Joined: Tue Nov 14, 2017 9:23 am

Re: ESP8266 strange "SEND OK" delay

Postby Flodis » Tue Nov 14, 2017 6:11 pm

Here is another test approach:

First I send it a completely fine AT+CIPSEND=0,<datalength> and while it is busy sending i just send it a ms:[<ms>] text string to see what it responds while busy.
...
Recv 79 bytes
ms:[36]
busy s...
ms:[60]
busy s...
ms:[94]
busy s...
ms:[128]
busy s...
ms:[153]
busy s...
ms:[188]
busy s...
ms:[223]
busy s...

SEND OK
ms:[248]
ERROR
...

It looks like the "SEND OK" is the condition to accept new messages and there is no hidden internal state where it might be ready to receive more commands - before that event. After SEND OK it is no longer busy - now my test command is treated as a command and generates an appropriate error.



Now. With the exact same http request having HTTP response data returned really fast from the server:

...

Recv 79 bytes
ms:[24]
busy s...

SEND OK

+IPD,0,183:HTTP/1.1 204 No Content
Content-Type: text/plain; charset=utf-8
Date: Tue, 14 Nov 2017 09:40:59 GMT
Server: X54JetStream
Connection: Keep-Alive:
Keep-Alive: timeout=15, max=1000


ms:[60]
ERROR
...

After 60 ms we got BOTH the SEND OK and the entire HTTP response back. And following the same logic. Before sending my false timestamp strings will be rejected with "busy" but after SEND OK the ESP8266 also have an opinion on the quality of the false commands and you get an ERROR.


It is all a mighty strange observation????

Forgot to mention the firmwares of some devices tested:

Code: Select all

AT+GMR
AT version:0.40.0.0(Aug  8 2015 14:45:58)
SDK version:1.3.0
Ai-Thinker Technology Co.,Ltd.
Build:1.3.0.2 Sep 11 2015 11:48:04
OK


Code: Select all

AT+GMR
AT version:1.1.0.0(May 11 2016 18:09:56)
SDK version:1.5.4(baaeaebb)
compile time:Mar  9 2017 19:22:12
OK

Her Majesty
Posts: 186
Joined: Mon Oct 27, 2014 11:09 am

Re: ESP8266 strange "SEND OK" delay

Postby Her Majesty » Tue Nov 14, 2017 10:18 pm

TCP is a reliable communication which needs ACK.
"RECV XXX bytes" means that ESP8266 got xxx bytes from UART and send it through TCP.
"SEND OK" means that ESP8266 received the TCP ACK.
I guess that if your remote peer also keep sending data to ESP8266, the ACK will be sent to the ESP8266 sooner.

Flodis
Posts: 4
Joined: Tue Nov 14, 2017 9:23 am

Re: ESP8266 strange "SEND OK" delay

Postby Flodis » Tue Nov 14, 2017 10:30 pm

Her Majesty wrote:TCP is a reliable communication which needs ACK.
"RECV XXX bytes" means that ESP8266 got xxx bytes from UART and send it through TCP.
"SEND OK" means that ESP8266 received the TCP ACK.
I guess that if your remote peer also keep sending data to ESP8266, the ACK will be sent to the ESP8266 sooner.


Thank you for the fast reponse.

The problem is the response should not be the "ACK". There is already TCP and packages have already been ACK;ed. The user should not have to send data back to confirm what has already happened on the TCP level.

Sending data back to confirm something is typically already what you do in HTTP traffic. But the "SEND OK" should not be triggered by sending back events. As you can see after some time you get a "SEND OK" even without any response back. That is basically a "SEND OK" without ACK. The long delay is like an ACK timeout but it has no error. It is odd.

Data has already been sent. You have to check the TCP layer to confirm data has been sent. Not rely on some clear text response in packages being returned.


Then data transfers would be super fast if you, please, make the "SEND OK" trigger by TCP send completed.


Sending once every 5ms when data has been sent instead of 290ms would be a factor X 60 in transfer speed!


Who objects to that?

Who is online

Users browsing this forum: No registered users and 2 guests