BLYNK
HOME       📲 GETTING STARTED       📗 DOCS       ❓HELP CENTER       👉 SKETCH BUILDER

Blynk keeps disconnecting on intense usage of communication

Greetings,

As some may remember from my earlier topic, I’m using Robotdyn’s Arduino Uno Board with builtin ESP8266 module. Along with the previous help of a few members of this forum, I have succeeded to connect my Blynk app with Arduino and Esp.

While using, I noticed something odd. I had only one button in my application, which was to turn D13 (Builtin-LED) ON and OFF. If sometimes I pressed it quickly (only 2-3 times), the Blynk app would automatically disconnect me. I said to myself that I should probably not do it that fast, since I don’t need it to be done so fast, but when I implemented a timer to #writeVirtual to a V5 pin with a sensor information with a delay of 2 seconds, it kinda goes fine for around 10 seconds, then it disconnects again and I have to wait for it to reconect.

I have searched on forums and topics and found out that it may be the BAUD rate causing this, if I’m not mistaken, but I am not sure how can I equalize baud rate of my Arduino and ESP and still get it working. I also read that the old firmware of ESP could cause this, but if I get a confirmation that it’s possible, I’ll try to update it. The firmware I currently have is the one that I got in this topic: Encountering issue with robotdyn UNO r3 + esp8266

Current settings:

  • ESP8226 baud rate is: 115200
  • Arduino Uno’s: 9600 (Works, but with the problem above)

I’m connecting to Blynk server, as can be seen in the code below.

I tried setting Arduino to 115200, but it never gets to successfully stay connected to the app for longer than a second, while disconnecting right afterwards.

I also tried settings both to 9600, but it looked as same, tho cannot really remember.

Blynk library is: Blynk_Release_v0.6.1

#define BLYNK_PRINT Serial


#include <BlynkSimpleShieldEsp8266.h>
#include <ESP8266_Lib.h>


// Varijable

BlynkTimer timer;
int i = 0;

char auth[] = "myAuthToken";
char ssid[] = "SSID";
char pass[] = "XYZ";

#define EspSerial Serial1

#include <SoftwareSerial.h>
SoftwareSerial EspSerial(4, 5); // RX, TX

#define ESP8266_BAUD 115200

ESP8266 wifi(&EspSerial);

void setup()
{
  // Debug konzola
  pinMode(7, INPUT);
  Serial.begin(9600);

  delay(10);

  EspSerial.begin(ESP8266_BAUD);
  delay(10);

  Blynk.begin(auth, wifi, ssid, pass);

  timer.setInterval(2000L, updateReading);
}



void updateReading() {
  i++;

  if (i == 1023)
  i=0;

  Blynk.virtualWrite(V5, i);
}
void loop()
{

  timer.run();
 
  Blynk.run();
  
}


I was wondering if anyone has encountered something similiar, and is willing to show me the best way to debug it properly and determine the problem.

EDIT: I switch to 115200 monitor to see the debug of the ESP, and back to 9600 for arduino when needed.

And one question… Should I use hardware serial communication instead of software for Arduino UNO and ESP8266?

Hello again,

I was curious if the software communication was causing this, so I decided to explore and test what happens on hardware, so I switched to it on pins 0 and 1 and it seems to be working without a flaw at the moment!

This is probably off the topic, but I’d like if someone could confirm me that this could have been the problem all the way? If so, I’ll stay on hardware, unless someone tells me not to and helps me understand better why. Thanks!

EDIT: I’m sorry for not editing my first post, but I think that this additional reply would make it much harder to read. I was doing this on conscious.

could be simplified to

void updateReading() {
    i = i++ & 1023;
       Blynk.virtualWrite(V5, i); 
}

Interesting that it is fixed with the hardware change.

I read through your first post and was going to reply, saying that SoftwareSerial doesn’t really work well with baud rates above 9600, but then read your second post.

So yes, trying to get SoftwareSerial to work consistently at 115200 is not going to work and will be the cause of the disconnections.

Pete.

1 Like

Yes, software serial may have caused it because it has to disable interrupts to keep the serial transmission timing. I would recommend using hardware over software serial.
But even more so, you should always check if there is room in the buffer before writing to it, since it could block waiting for transmission to happen.
I have implemented asynchronous modifications to a library for that particular reason Details here:

Understood!

Thanks again to everyone one who tried to help!
Have a nice day! :blush: