Go Down

Topic: ESP8266 strange "SEND OK" delay (Read 64 times) previous topic - next topic

flodis

I noticed when making a http request using an ESP8266 wifi module attached to a Serial1 of Leonardo (Atmel32u4) board the final response "SEND OK" from the module to confirm data has been sent comes with a human noticeable delay.

When the ESP8266 on Serial1 has got the data to send it confirms by

Code: [Select]
Recv 83 bytes

SEND OK


The strange thing is there is a 290ms delay between "Recv 83 bytes" and "SEND OK"


It can only be noticed if the response from the HTTP request is delayed. For http requests with short response time, like 10ms, the "Recv 83 bytes" comes immediately after the TXO to the ESP device has completed. The "SEND OK" comes in front of the HTTP header following 10ms later.

So if there is no data back in the web request within 290ms you have to wait that long to have a confirmation the send was completed.



When there is no immediate response on the input stream "SEND OK" is 290ms delayed?



When http response is fast the "SEND OK" is before the HTTP response.


I have checked to be sure "SEND OK" is not following "Recv 83 bytes" the length of "Recv 83 bytes" is 1.52ms so it is not hiding there. It comes with the HTTP response.


I did not want to involve the Arduino code or timing in Serial1. The pictures show what is going on on the Serial1 interface between Arduino and the ESP8266.



Since this device is used in milions I must be close to false.


I have control of the web server and can delay http responses with ms resolution and I can clearly see "Recv NN bytes" and "SEND OK" be appart.



This becomes a problem when looping the send to stream data in smaller blocks. I think I have to wait for the "SEND OK" or can I move on and SEND again as soon as the "Recv NN bytes" is confirmed.


flodis

#1
Nov 14, 2017, 01:10 am Last Edit: Nov 14, 2017, 01:37 am by flodis
Could it be I somehow tell it to prepare to receive x bytes and only send x-1 or something?

Have to check..


Have checked:
If I fake numbers and announce +1 more character than I really send, the ESP8266 waits for a long time without saying anything. If I announce -1 character than I actually send it has no complaints, but now of course I have an extra character in the out buffer that will be taken as the first character in the next AT command.

flodis

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.
Code: [Select]
...
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:

Code: [Select]
...

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.



How come "SEND OK" is in any way related with what data comes back. The actual data sent by the device in the HTTP request is already at the remote server, have ben parsed as valid HTTP and response is sent back in a few ms. Why does it not signal "SEND OK".

What have I missed here?

Go Up