SoftwareSerial, some letter come out wrong

Projects Programming
1

I have esp8266 comunicating with arduino using SoftwareSerial.

When I send a command to the esp8266 from the arduino i write :

mySoftwareSer.println(cmd);

Then I wait 1 second. and then I write the following code to see on the serial monitor the esp8266 response:

while (mySoftwareSer.available()>0)
{
Serial.write(mySoftwareSer.read());
}

Things are working, and the esp8266 does do (the very simple) commands I send to it.

BUT, what bothers me is that the responses I get from it are many times with "misspelling"

Sometimes I got "recw" instead of "recv", sometimes i get "Seod" instead of "send".

Maybe it is because they have a different baud rate ?

=========starting new loop===========

Sending: AT+CIPSTART="TCP","184.106.153.149",80

Recv 51 bytes

SEND OK

+IPD,2:81CLOSED
AT+CIPSRARTO$Õ(%Sending: AT+CIPSEND=51

=========starting new loop===========

Sending: AT+CIPSTART="TCP","184.106.153.149",80

Recw 51 bytes

SEOD OK

+IPD,2:84CLOSED
AT+CIPSRART=!TCPSending: AT+CIPSEND=51

2

3.3V power supply

3.3V logic level for RX for ESP8266

3

RX is the receiving side of the serial interface and the esp8266 receiving everything great.
just to make sure I did what you suggested and it did not help.

I assume the problem is with the TX of the esp8266, he is sending data in 3.3v and the arduino expects 5v.

this might be one problem.
I tried to use pull up resistor but it did not help.

Another problem is my esp works in 115200 baud rate, maybe the arduino is not fast enough to handle this ?

any more ideas ?

4

What does this mean?

Maybe it is because they have a different baud rate ?

Maybe you should post the entire sketch.

5

Software serial will choke sometimes at 115200 bauds

Also it has only a 64 byte buffer that can quickly be overflown at that speed (which you can check with the overflow call)

If you don't need to use that speed, would suggest changing to 9600 or as low as you feel acceptable.

In a recent project where I needed high speed and for convenience the hardware serial connected to a computer - I duplicated the library files into my own project and changed the name of the class throughout the file and used a 256 byte buffer. Things worked fine then but obviously that is quite a tax on your memory.

An alternative is to use a hardware serial (mega boards have 4) to not run into the issue or plug and unplug for programming and use the software serial to talk back to your computer instead of the ESP

6

Also don't wait for 1 second after sending your comment for listening back to your ESP - the longer you wait, the higher the risk of overflowing the 64 byte buffer as you don't empty it when things come in.

What I do is actually put at the end of the main loop 2 statements:

1 reading whatever is on hardware serial and sending it to software serial and 1 reading whatever is pending on software serial and sending it to hardware Serial

7

(But if you have letters REPLACED by others and none missing then that indeed seems to indicate some bits received at 0 instead of 1 in the character bytes and so could be a 3.3 to 5v issue(although 3.3V is read as a 1 on an arduino)

Is your ESP powered separately from the arduino and do you have enough power to keep the ESP happy?it is pretty hungry when doing wifi transmits and pulls lots of current)

Also - If you have an oscilloscope you could plug it to the Tx pin of the ESP and see exactly what is sent back 1 and 0 are easy to spot record the sequence and see the levels

8

The solution was to reduce the baud rate, not simple as it sounds because using AT+IPR=9600 to reduce baud rate bricked the device..

after flashing the device to unbrick it i used AT+UART_DEF=9600,8,1,0,0 which solved the issue.

9

tautau123:
The solution was to reduce the baud rate, not simple as it sounds because using AT+IPR=9600 to reduce baud rate bricked the device..

after flashing the device to unbrick it i used AT+UART_DEF=9600,8,1,0,0 which solved the issue.

I don't see AT+IPR in ESP8266 AT Instruction Set Version 0.30 put out by Espressif
Not sure where you got it from.

I used the AT+UART_DEF command which is in that document.

10

AT+IPR has been deprecated quite a while ago - should not brick the device though, just fail and keep it to the old baud rate (so if you tried to switch baud rate after then there was no chance you could reach the device).

indeed AT+UART_DEF is the new way of doing it. it's saved in Flash so you do that only once.