After sending the command "AT+CIPSENDEX=0,2000" to the ESP8266 (Wroom-02), receiving the ">" response from the ESP8266, and sending the data (varying length from 32 to 1800 characters), the "\0" character combination is sent to tell the ESP8266 that there is no more data to follow, and it should send the data it has received. In every case, a CR LF (0x0D, 0X0A) is sent immediately before the "\0" command.
When the frequency of data transmission is low (1 or 2 transmissions per second), the "\0" is always recognized by the the ESP8266 as a command to terminate the transmission, and the ESP8266 returns "xxx bytes sent SEND OK".
When data transmission frequency is increased, the ESP8266 will usually recognize the "\0" as a command, but will also regularly NOT recognize it as a command to terminate the send, and accept it as characters to be passed via wifi transmission. When the "\0" is not recognized as the command to terminate transmission, it is necessary to send a CR LF followed by the "\0" command again in order to have the ESP8266 terminate the transmission. Unfortunately, this also results in the ESP8266 sending the first "\0" and the "CR LF" over the wifi, which disrupts the data being sent.
On very rare occasions, the second "/0" that is sent is also not recognized as a command to terminate, and it is necessary to send a third "CR LF \0"
I have validated, using an oscilloscope, that the "CR LF /0" (0x0D, 0x0A, 0x5C, 0x30) are received at the correctly at the Wroom without any delay between characters. This is true of both the initial "/0" that is not recognized as a command, and the subsequent "/0" that is recognized. It is also clear that they were received by the ESP8266 because they are subsequently sent over the wifi!
I believe that this is a bug in the ESP8266 firmware.
How can I ensure that when the ESP8266 is more heavily loaded, that the "\0" command will be recognized and terminate the CIPSENDEX initiated transmission?
You should take care that the character "\0" is not preceded by a '\'. Because that is how you tell the ESP8266 firmware to treat the "\0" sequence as "data to be sent" and NOT "command".
And you wrote "/0", isn't it supposed to be "\0"?
Also, could you please specify the command set using AT+GMR? "Latest" firmware on your device might not be the latest available in terms of SDK, depending on what updates have been officially posted by the update team.
Thank you for your response.
First, sorry, I had a typo in my original post, but not my code. I am ALWAYS sending "\0", not "/0". ("/0" would NEVER be accepted as a terminate instruction, so would never work)
Second, my "\0" is ALWAYS preceded by a Carriage Return, Line Feed, so I always send the 4 byte sequence 0x0D, 0x0A, 0x5C, 0x30 and I have verified with an oscilloscope that there is no delay between the characters. Further, I have verified with the oscilloscope that the specific 0x0D, 0x0A, 0x5C, 0x30 that was not recognized as the terminate instruction by the ESP8266 was, in fact, the byte sequence 0x0D, 0x0A, 0x5C, 0x30 with no delay between characters. So, I am never sending "\\0".
Third, here is the result of the AT+GMR? from my ESP8266:
AT version:0.52.0.0(Jan 7 2016 18:44:24)
compile time:Jan 7 2016 19:03:11
Thanks for your help.
The SDK version you are using is like months old and had a lot of things that were not very reliable. You could use 1.5.3 or 1.5.4, but the latest one based on SDK v.2.0.0 is available on Espressif page for ESP8266:
I am not able to reproduce your problem on this AT command firmware (based on SDK v.2.0.0) and so you should try it as well! And if you still face issues, let me know so I will forward the issue to the core developers.
I'm not developing on the ESP8266, I'm using another processor and communicating with the ESP8266 using AT commands. Right now I don't want to develop on the ESP8266, I am trying to use it as an "out of the box" product, ready to go.
I used the AT+CIUPDATE command to update the firmware over the air. As I understand it, this goes to the Espressif server to update the ESP with the latest firmware, which should be created with the latest SDK. Isn't it? If not, why not? If I have the latest "firmware", but not the latest SDK, how do I update the SDK?
I'm having the same problem i'm using a microcontroller to send AT commands to the ESP8266 module and i spend a lot of time to try sending the HTML package.
I used Wireshark to investigate the HTML header and the CR LF doesn't work. I see the header with ...\r\n but for the HTML header isn't a CR LF.
You fixed your problem? Or anyone have any idea to fix this?
Thanks and regards
if you are sending the \0 in a string by using a print type function, you MUST send "\\0", NOT just "\0". The first \ means that the second \ is to be sent as a literal character.
if you are sending the \0 by just sending bytes to the wroom, you do NOT need to send two \'s, just send byte(0x53) and byte(0x30).
I hope this helps you!
Who is online
Users browsing this forum: Bing [Bot] and 4 guests
Newbies Start Here
Are you new to ESP8266?
Unsure what to do?
Dunno where to start?
Start right here!
We also have a RTOS version and a MESH version too!
Complete listing of the official ESP8266 related documentation release by ESPRESSIF!
Must read here!