Hi,
I am using AT rev 0.60, module ESP-12.
If I know the length of my message, I can send TCP or UDP messages using AT+CIPSEND or AT+CIPSENDBUF commands. It works quiet well on my test setup.
However, sometimes I need to send messages without knowin their length in advance. How can I do that?
I am trying to send messages as follows:
AT+CIPSEND=0,2048 // start sending data, connecton 0, annonced length 2048 bytes; ESP8266 replied OK >
<....data....>+++ // sendind binary data, terminate transmission by "+++"
ESP8266 replied OK > 0,CLOSED and after that refuses to accept any AT command. After a while it replies:
busy s...
Recv 2048 bytes
SEND FAIL
Apparently "+++" does not terminate AT+CIPSEND, module is still waiting for data bytes. Why? The same thing happens if I use AT+CIPSENDBUF.
Description of AT+CIPSENDBUF reads: "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” . " Does it mean that "+++" supposed to switches back to command mode, but also dichareges all the data in the buffer without sending them? Apparently in my case "+++" does not swithes back to command mode. I was trying to send "+++\r\n", it does not make difference.
AT+CIPSEND or AT+CIPSENBUF
Re: AT+CIPSEND or AT+CIPSENBUF
Postby ESP_Faye » Thu May 12, 2016 10:55 am
Hi,
You can download the latest AT_V1.0 from BBS http://bbs.espressif.com/viewtopic.php?f=46&p=6508#p6508.
Can command "AT+CIPSENDEX" help ?
If your problem is still unsolved, please provide the whole AT logs for debugging.
Thanks for your interest in ESP8266 !
You can download the latest AT_V1.0 from BBS http://bbs.espressif.com/viewtopic.php?f=46&p=6508#p6508.
Can command "AT+CIPSENDEX" help ?
If your problem is still unsolved, please provide the whole AT logs for debugging.
Thanks for your interest in ESP8266 !
Re: AT+CIPSEND or AT+CIPSENBUF
Postby akouz » Fri May 13, 2016 8:35 am
Thank you. I cannot see any difference in AT+CIPSEND and AT+CIPSENDBUF commands in release notes. Thus, I would assume those commands have not been modified.
Description of AT+CIPSEND command is confusing. It can be used in single connection mode (AT+CIPSEND=<length>) and in multiple connection mode (AT+CIPSEND=<link ID>, <length>). However, in the "response" section description states: "This command can only be used in transparent transmission mode which require to be single connection mode." There is no description how it works in multiple connection mode. Maybe in the multiple connection "+++" terminator is ignored. Or maybe "+++" termination was available in earlier versions of AT commands and is redunant now, who knows.
Also AT+CIPSEND description says that "<length> data length, MAX 2048 bytes ", and then says: "Wrap return ">" after execute command. Enters unvarnished transmission, 20ms interval between each packet, maximum 2048 bytes per packet." What is a "packet"? How ESP8266 distinguish one packet from another? When should I wait 20 ms?
One way to interpret that is to think that the "packet" is the whole data message sent via AT+CIPSEND. Thus, the sequence should be as follows:
- send "AT+CIPSEND=<link ID>, <length>"
- wait for ">" (in fact I always see "OK >")
- send <length> of data bytes, it is a "packet"
- wait 20 ms, after that I can issue next AT+CIPSEND command. Maybe ESP8266 returns "OK" when ready, but description does not promise that.
If it is true, then my throughput heavily depends on packets length. If I send short packets, say, 20 bytes long, then troughput cannot be greater than 1 kbytes/sec, because I have to add 20 ms delays between packets.
I guess AT+CIPSENDBUF was added exactly for that reason: probably it was intended to increase performance while sending short packets. But the problem is that I need to know in advance how much data in total I will send via AT+CIPSENDBUF. I cannot declare length 2048, then send several short packets, and the force buffer to send. The "+++" does not work as expected, data not being sent, after "+++" ESP8266 discards the accumulated data. As far as I can see, AT+CIPSENDBUF works only if I send the declared <length> bytes exactly. Because of that, I cannot see the difference between AT+CIPSEND and AT+CIPSENDBUF commands, in practice they work the same way.
Maybe AT+CIPSENDEX can do the job, I did not try it yet. Its description is very brief. It says: "when data length or "\0" is met, starts transmission of data.". Probably it means that sending a data byte 0x00 to ESP8266 will terminate AT+CIPSENDEX command and forces ESP8266 to transmit buffered data. Statement "So if sending "\0" is needed, please send it as "\\0"" probably means that data bytes 0x00 in the packet should be replaced by the pair 0x92 0x00. Description does not say how such a pair will be counted for the <length>, as one byte or as two bytes. Description does not say what should I do if the last byte in my packet has value of 0x92. Perhaps I should add some dummy byte of any vlue other than 0x00 and then send 0x00.
An unclear AT commands description is yet another reason why it is scary to change to a new revision of AT commands. I explored a specific revision and made my program to match ESP8266 behavior, but all that might be ruined with a new revision. Because significant part of behavior is not described and therefore it can be changed without notice.
Description of AT+CIPSEND command is confusing. It can be used in single connection mode (AT+CIPSEND=<length>) and in multiple connection mode (AT+CIPSEND=<link ID>, <length>). However, in the "response" section description states: "This command can only be used in transparent transmission mode which require to be single connection mode." There is no description how it works in multiple connection mode. Maybe in the multiple connection "+++" terminator is ignored. Or maybe "+++" termination was available in earlier versions of AT commands and is redunant now, who knows.
Also AT+CIPSEND description says that "<length> data length, MAX 2048 bytes ", and then says: "Wrap return ">" after execute command. Enters unvarnished transmission, 20ms interval between each packet, maximum 2048 bytes per packet." What is a "packet"? How ESP8266 distinguish one packet from another? When should I wait 20 ms?
One way to interpret that is to think that the "packet" is the whole data message sent via AT+CIPSEND. Thus, the sequence should be as follows:
- send "AT+CIPSEND=<link ID>, <length>"
- wait for ">" (in fact I always see "OK >")
- send <length> of data bytes, it is a "packet"
- wait 20 ms, after that I can issue next AT+CIPSEND command. Maybe ESP8266 returns "OK" when ready, but description does not promise that.
If it is true, then my throughput heavily depends on packets length. If I send short packets, say, 20 bytes long, then troughput cannot be greater than 1 kbytes/sec, because I have to add 20 ms delays between packets.
I guess AT+CIPSENDBUF was added exactly for that reason: probably it was intended to increase performance while sending short packets. But the problem is that I need to know in advance how much data in total I will send via AT+CIPSENDBUF. I cannot declare length 2048, then send several short packets, and the force buffer to send. The "+++" does not work as expected, data not being sent, after "+++" ESP8266 discards the accumulated data. As far as I can see, AT+CIPSENDBUF works only if I send the declared <length> bytes exactly. Because of that, I cannot see the difference between AT+CIPSEND and AT+CIPSENDBUF commands, in practice they work the same way.
Maybe AT+CIPSENDEX can do the job, I did not try it yet. Its description is very brief. It says: "when data length or "\0" is met, starts transmission of data.". Probably it means that sending a data byte 0x00 to ESP8266 will terminate AT+CIPSENDEX command and forces ESP8266 to transmit buffered data. Statement "So if sending "\0" is needed, please send it as "\\0"" probably means that data bytes 0x00 in the packet should be replaced by the pair 0x92 0x00. Description does not say how such a pair will be counted for the <length>, as one byte or as two bytes. Description does not say what should I do if the last byte in my packet has value of 0x92. Perhaps I should add some dummy byte of any vlue other than 0x00 and then send 0x00.
An unclear AT commands description is yet another reason why it is scary to change to a new revision of AT commands. I explored a specific revision and made my program to match ESP8266 behavior, but all that might be ruined with a new revision. Because significant part of behavior is not described and therefore it can be changed without notice.
Who is online
Users browsing this forum: No registered users and 2 guests
Login
Newbies Start Here
Are you new to ESP8266?
Unsure what to do?
Dunno where to start?
Start right here!
Latest SDK
Documentation
Complete listing of the official ESP8266 related documentation release by ESPRESSIF!
Must read here!
- All times are UTC+08:00
- Top
- Delete all board cookies
About Us
Espressif Systems is a fabless semiconductor company providing cutting-edge low power WiFi SoCs and wireless solutions for wireless communications and Internet of Things applications. We are the manufacturer of ESP8266EX.