ESP8266 Developer Zone

I can send a single data packet using AT+CIPSEND. But I have to send a series of binary data packets. How to use AT+CIPSEND or AT+CIPSENDBUF to send several packets of data, what is a correct algorithm?

So far I tried the following with no success:

• 0,CONNECT - external client opens TCP connection 0
• +IPD,0,87 <...> - external client sends a command, eg a data packet of 87 bytes long
• AT+CIPSENDBUF=0,34 - my device starts to send first reply, it is a data packet of 34 bytes long
• My device it waits for "OK" from ESP8266, time-out is 1 sec
• 3,2 OK > - ESP8266 replies "OK >", it happens almost instantly
• My device sends 34 bytes of data, then it waits until all data bytes are sent by UART
• AT+CIPSENDBUF=0,38 - my device starts to send second reply, it is a data packet of 38 bytes long
• My device it waits for "OK >" from ESP8266, time-out is 1 sec
• My device exits by time-out
• busy s... Recv 34 bytes 0,9,SEND OK - after a delay of about 2 sec ESP8266 replies "OK",

It is a huge delay after first data packet. How to avoid that?

Hello,

What kind of device is receiving the data that is being sent by the ESP8266... I could not reproduce this problem when using 2 devices (an ESP and a desktop) on a local network.
If there are too many WiFi networks in your area of operation, please refer to the latest "WiFi Channel Selection Guidelines" (PDF) under ESP8266 Resources page on www.espressif.com
Improper channel selection can cause this type of delays and low latency.

What is the delay between 2 consecutive CIPSEND commands?
Please consolidate the data packets that you need to send. Use multiple send operations only if you need to send over 2048 bytes of data or introduce a small delay between multiple send operations.

What kind of device is receiving the data that is being sent by the ESP8266..

PC

If there are too many WiFi networks in your area of operation

Very few

What is the delay between 2 consecutive CIPSEND commands?

About 20 ms

Please consolidate the data packets that you need to send

I thought it is the whole purpose of the AT+CIPSENDBUF command. It looks like it supposed to consolidate short packets in ESP8266 internal buffer and then send the buffer in one go. Do you mean that it does not work this way and there is no difference between AT+CIPSEND and AT+CIPSENDBUF?

Unfortunately there is no clear description how to use AT+CIPSENDBUF. There is no sample.

Actually the SENDBUF command writes data to the buffer and does not transmit it like the CIPSEND command does.
By the way, if you do not have data packets of size over 2048, you may just use CIPSEND and send in a data stream continuously consisting of packets of size 2048 bytes (with 20ms between packets).
However, if you want to send different, separate packets of data over a TCP/IP connection with 20ms interval, it will be difficult because of the nature of TCP/IP communication.

If your system does not have enough RAM and that is why you want to continuously send data, just use the CIPSEND command and stream data in.

pratik wrote:Actually the SENDBUF command writes data to the buffer and does not transmit it like the CIPSEND command does.

At the moment I do not concern about actual WiFi transmission. I am trying to establish correct communication between my microcontroller and ESP8266 using AT commands.

Document "ESP8266 AT instruction set" describes AT+CIPSENDBUF command as follows:

This command only write data into TCP-send-buffer, so it can be called continually, needn’t wait for “SEND OK”; if a TCP segment is sent successfully, it will return <segment ID>,SEND OK. Before data <length> is met, input “+++” can switch back from data mode to command mode, and discard the data received before, cancel the “AT+CIPSENDBUF” .

As far as I understand this description, I can send a series of AT+CIPSENDBUF commands to ESP8266, causing ESP8266 to accumulate my messages in its internal buffer. I guess ESP8266 then merely sends accumulated data at its own pace, informing me about transmitting process by <segment ID>,SEND OK. So far I have no idea what can I do with those <segment ID>,SEND OK replies, they look like clutter for me. Maybe I can find a good use for them later on.

According to the detailed description, in multiple connection mode I should send:

AT+CIPSENDBUF=<link ID>,<length>

After that ESP8266 should reply

<current segment ID>,<segment ID of which sent successfully>
OK
>

Obviously after that I can send <length> data bytes. I guess I do not need to wait for any reply after sending data.

It works according to that description, but it works only once. When I send AT+CIPSENDBUF=<link ID>,<length> second time, ESP8266 does not response for about 2 sec. My messages are short, typically only 30...50 bytes in one message. I wonder why ESP8266 does not accept the second AT+CIPSENDBUF for so long. I do not expect ESP8266 to send my message instantly to WiFi, but I would expect ESP8266 to accept my message instantly and to store my data in a buffer, more or less this is what the description said.

pratik wrote:If your system does not have enough RAM and that is why you want to continuously send data, just use the CIPSEND command and stream data in.

Then, what is the purpose of AT+CIPSENDBUF command? Does it mean that AT+CIPSENDBUF command is not implemented properly and should not be used at all?

Well, the thing is that your data packets are not huge. The SENDBUF and related commands are better suited when you need to send files like images, which may be several kilobytes.
If you use small packets, you can simply issue a SEND of length, for example, 1000 bytes. And then you may send 100 packets of 10 bytes each with intervals in between. The UART will not time out with 20ms packet gaps.

pratik wrote:The SENDBUF and related commands are better suited when you need to send files like images, which may be several kilobytes.

In some occasions I have to send up to 100 KBytes of data via ESP8266. But they come in small blocks of up to 300 bytes each, but the actual length can vary and is not known in advance. Yes, I do not have enough memory to consolidate my data before sending to WiFi.

Please note, I have no questions what is better suited for me. I have a question why AT+CIPSENDBUF does not work as I expected. Is it a strange AT+CIPSENDBUF implementation and for unknown reasons huge delays deliberately added to it, or is it a bug, or maybe I misunderstand something?

If AT+CIPSENDBUF cannot be used then I'd rather try to use AT+CIPSENDEX. Unless AT+CIPSENDEX has similar problems, offcourse.

UPDATE:
I tried with 3 different routers but I cannot reproduce your problem using AT command set 0.51 (based on SDK 1.5.0).
The CIPSENDBUF command responds very fast and also transmits immediately. My laptop, connected to the router is running XAMPP server.
I tried the same with by connecting to Google, sending a GET request in packet sizes of 24 bytes using multiple SENDBUF commands. Works just find, maximum delay I got anywhere was less than 200 ms. Local network latency is way faster.

You should probably try changing router channel or flashing a different firmware, just in case.

I use AT version:0.60.0.0, SDK version:1.5.2

Sorry, not able to reproduce the situation with v.0.60 either. Some troubleshooting steps with router setup:
- Disconnect router from the internet. Have just the laptop and ESP8266 connected to it and try this thing again.
- Make sure your send and timeout code is correct and bug free.
- Make your network "open" to see if it affects response speed.
- If the ESP8266 is connecting to the router by default, explicitly reconnect and try sending data.
- If your laptop uses virtual server like XAMPP, make sure bandwidth is not restricted.
- Worst case: Try another firmware version.