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
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.
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.
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:
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".
Maybe You can increase the amount of data in each burst just to see if the device fires the "SEND OK" earlier based on some ESP8266 buffer used limit.
Also check if the ESP8266 has some TCP package size that may affect sending.
Since You obviously have full control of the server it can be interesting to see some timing on when data hits the server after you have sent the negotiated number of bytes to the ESP8266.
Try some of the other WiFi devices from the new Espressif product range to see if they all work the same.
Finally, if nothing helps, try to have the server send back some dummy, out of protocol data as soon as the first character hits the server. Unfortunately the receiving end of your application will have some garbage but just read on until you find valid input.
