"\0" command SOMETIMES does not terminate AT+CIPSENDEX transmission

jimyates
Posts: 8
Joined: Wed Sep 14, 2016 3:37 am

"\0" command SOMETIMES does not terminate AT+CIPSENDEX transmission

Postby jimyates » Sat Sep 17, 2016 2:03 am

I am using a WROOM-02 with ESP8266. I have updated the firmware of the ESP8266 over the air to the latest version of the firmware on 9/5/2016. I am communicating with the Wroom using the USART at 115,200 baud. I am using UDP protocol to send strings of data over the wifi.

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?

User avatar
pratik
Posts: 467
Joined: Wed Jun 29, 2016 7:17 pm
Location: India
Contact:

Re: "\0" command SOMETIMES does not terminate AT+CIPSENDEX transmission

Postby pratik » Sat Sep 17, 2016 8:28 pm

Hello,

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.
Regards,
Pratik Panda
Website: http://www.PratikPanda.com

Custom firmware, Knowledge base and freelancing (ESP8266/ESP32):
http://www.iot-bits.com

jimyates
Posts: 8
Joined: Wed Sep 14, 2016 3:37 am

Re: "\0" command SOMETIMES does not terminate AT+CIPSENDEX transmission

Postby jimyates » Tue Sep 20, 2016 1:21 am

Pratik,

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)
SDK version:1.5.1(e67da894)
compile time:Jan 7 2016 19:03:11

Thanks for your help.

Jim

User avatar
pratik
Posts: 467
Joined: Wed Jun 29, 2016 7:17 pm
Location: India
Contact:

Re: "\0" command SOMETIMES does not terminate AT+CIPSENDEX transmission

Postby pratik » Wed Sep 21, 2016 11:00 am

Hi Jim,

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:
http://www.espressif.com/products/hardware/esp8266ex/

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.
Regards,
Pratik Panda
Website: http://www.PratikPanda.com

Custom firmware, Knowledge base and freelancing (ESP8266/ESP32):
http://www.iot-bits.com

jimyates
Posts: 8
Joined: Wed Sep 14, 2016 3:37 am

Re: "\0" command SOMETIMES does not terminate AT+CIPSENDEX transmission

Postby jimyates » Wed Sep 21, 2016 7:35 pm

Pratik,

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?

Jim

miky_boy
Posts: 1
Joined: Sat Feb 17, 2018 9:31 am

Re: "\0" command SOMETIMES does not terminate AT+CIPSENDEX transmission

Postby miky_boy » Sat Feb 17, 2018 9:35 am

Hi my friend,

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

Her Majesty
Posts: 337
Joined: Mon Oct 27, 2014 11:09 am

Re: "\0" command SOMETIMES does not terminate AT+CIPSENDEX transmission

Postby Her Majesty » Fri Feb 23, 2018 11:44 am

There is a simple example may help you https://bbs.espressif.com/viewtopic.php?f=61&t=560.

andreysnug
Posts: 21
Joined: Wed May 16, 2018 12:33 pm

"0" command SOMETIMES does not terminate ATCIPSENDEX transmission

Postby andreysnug » Fri May 25, 2018 7:08 am

Hello. With the latest update, I do not work in 888 HUD їanyone with the same problem and can help me? Thank you.

jimyates
Posts: 8
Joined: Wed Sep 14, 2016 3:37 am

SOLUTION "\0" command SOMETIMES does not terminate AT+CIPSENDEX transmission

Postby jimyates » Sat May 26, 2018 5:03 am

When sending AT+CIPSENDEX command, you terminate the command by sending the characters \0
BUT
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.
AND
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: No registered users and 7 guests