BLE Pushes not working reliably

Gaff · December 10, 2017, 3:42pm

I know BLE is in beta and all that but I’m finding push notifications via BLE to be very unreliable. It seems that if I update multiple widgets in a single go they tend to lag, or there are delays, or something. The serial monitor shows the push updates pretty much as expected so If I had to guess I’d say you aren’t flushing a BLE buffer somewhere in the app.

On a possibly related note, I find that eventually there is a BLE heartbeat timeout.

My app simply consists of 4 value display widgets assigned to V0…V3 and set to PUSH, plus the BLE widget.

Here’s the sketch I’m using, I can send the console output if it helps?:

#define INTERVAL 5000
int thevalue;
long previousMillis;

void setup() {
  //...ble stuff skipped...
}

void loop() {
  unsigned long currentMillis = millis();  
  if(currentMillis - previousMillis > INTERVAL) {
    previousMillis = currentMillis;   
    dowrites();
  }  
  Blynk.run();
}

void dowrites() {
  Serial.println(F("Tick"));
  thevalue++;
  Blynk.virtualWrite(V0, thevalue);
  Blynk.virtualWrite(V1, thevalue);  
  Blynk.virtualWrite(V2, thevalue);  
  Blynk.virtualWrite(V3, thevalue);  
}

vshymanskyy · May 30, 2016, 12:06pm

First of all, from the information you provided, it is not clear what hardware you’re using…

Gaff · May 30, 2016, 12:11pm

Using an Adafruit Feather 32u4 BLE: https://www.adafruit.com/product/2829

Does my sketch work with your BLE module? Perhaps the adafruit isn’t flushing as expected at the BLE end

Is there some way to turn on forenzic / debug logging in the Android app?

Here’s the full sketch


#define BLYNK_DEBUG
#define BLYNK_PRINT Serial
#define BLYNK_USE_DIRECT_CONNECT

#include <SoftwareSerial.h>
#include <BlynkSimpleSerialBLE.h>

#include <SPI.h>
#include <Adafruit_BLE.h>
#include <Adafruit_BluefruitLE_SPI.h>

char auth[] = "...";


// SHARED SPI SETTINGS (see adafruit webpages for details)
#define BLUEFRUIT_SPI_CS               8
#define BLUEFRUIT_SPI_IRQ              7
#define BLUEFRUIT_SPI_RST              4    // Optional but recommended, set to -1 if unused
#define BLUEFRUIT_VERBOSE_MODE         true

Adafruit_BluefruitLE_SPI ble(BLUEFRUIT_SPI_CS, BLUEFRUIT_SPI_IRQ, BLUEFRUIT_SPI_RST);


#define INTERVAL 5000
int thevalue;
long previousMillis;

void setup() {
  delay(1500);
  Serial.begin(115200);

  Blynk.begin(auth, ble);
  ble.begin(BLUEFRUIT_VERBOSE_MODE);   
  //ble.factoryReset(); //Optional
  ble.setMode(BLUEFRUIT_MODE_DATA); 
  previousMillis = 0; //force an initial publish
}


void loop() {
  unsigned long currentMillis = millis();  
  if(currentMillis - previousMillis > INTERVAL) {
    previousMillis = currentMillis;   
    dowrites();
  }  
  Blynk.run();
}

void dowrites() {
  Serial.println(F("Tick"));
  thevalue++;
  Blynk.virtualWrite(V0, thevalue);
  Blynk.virtualWrite(V1, thevalue);  
  Blynk.virtualWrite(V2, thevalue);  
  Blynk.virtualWrite(V3, thevalue);  
}

vshymanskyy · May 30, 2016, 12:24pm

Could you also post your BLYNK_DEBUG printouts?

Gaff · May 30, 2016, 6:54pm

Sure thing. Did the sketch work for you?

Output pasted below:

[1503] Blynk v0.3.7 on Arduino
[3522] Connecting...
Tick
[5001] Cmd skipped:20
[5003] Cmd skipped:20
[5005] Cmd skipped:20
[5005] Cmd skipped:20
[8982] >[02|00|01|00] 
[9029] >9aef6a9e386b49a98013b6fb364cc0db
[9031] Ready
[9031] <[00|00|01|00|C8]
Tick
[10002] <[14|00|05|00|06]vw[00]0[00]2
[10047] <[14|00|06|00|06]vw[00]1[00]2
[10094] <[14|00|07|00|06]vw[00]2[00]2
[10139] <[14|00|08|00|06]vw[00]3[00]2
Tick
[15003] <[14|00|09|00|06]vw[00]0[00]3
[15048] <[14|00|0A|00|06]vw[00]1[00]3
[15095] <[14|00|0B|00|06]vw[00]2[00]3
[15140] <[14|00|0C|00|06]vw[00]3[00]3
[19032] <[06|00|0D|00|00]
Tick
[20004] <[14|00|0E|00|06]vw[00]0[00]4
[20051] <[14|00|0F|00|06]vw[00]1[00]4
[20097] <[14|00|10|00|06]vw[00]2[00]4
[20144] <[14|00|11|00|06]vw[00]3[00]4
[20406] >[00|00|0D|00|C8]
Tick
[25006] <[14|00|12|00|06]vw[00]0[00]5
[25053] <[14|00|13|00|06]vw[00]1[00]5
[25098] <[14|00|14|00|06]vw[00]2[00]5
[25145] <[14|00|15|00|06]vw[00]3[00]5
Tick
[30007] <[14|00|16|00|06]vw[00]0[00]6
[30052] <[14|00|17|00|06]vw[00]1[00]6
[30099] <[14|00|18|00|06]vw[00]2[00]6
[30144] <[14|00|19|00|06]vw[00]3[00]6
[30410] <[06|00|1A|00|00]
[32411] <[06|00|1B|00|00]
[34412] <[06|00|1C|00|00]
Tick
[35008] <[14|00|1D|00|06]vw[00]0[00]7
[35053] <[14|00|1E|00|06]vw[00]1[00]7
[35100] <[14|00|1F|00|06]vw[00]2[00]7
[35147] <[14|00] [00|06]vw[00]3[00]7
[36409] Heartbeat timeout: 36409, 20408, 34412
[36411] Connecting...
Tick
[40009] Cmd skipped:20
[40011] Cmd skipped:20
[40011] Cmd skipped:20
[40013] Cmd skipped:20
Tick
[45010] Cmd skipped:20
[45012] Cmd skipped:20
[45012] Cmd skipped:20
[45015] Cmd skipped:20

vshymanskyy · May 31, 2016, 7:33am

@BlynkAndroidDev, looks like App stopped responding to heartbeats…
@Gaff, could you add a button to control LED or print something and see if it works?

Gaff · May 31, 2016, 9:00am

The app is still able to send commands, which the arduino responds to. They show up in the debug output. The BLE light remains connected the whole time and the app never thinks that the arduino is disconnected. If I exit the app and restart it’s able to reconnect for a while until the next timeout.

It’s not just that it doesn’t respond to the heartbeat. It doesn’t handle all the push updates either. Typically it picks up the first few, but then tends to stop. It seems that all messages from arduino -> app are unreliable.

My working theories are:

The arduino isn’t actually flushing the send buffer to BLE
The app isn’t correctly pulling all the messages from BLE
There’s some error when processing messages

If I could see the BLE input as received by the app we could very easily work out which case is causing the problem. Is there a debug build of the app perhaps? Or some way of intercepting these messages?

Gaff · May 31, 2016, 10:19pm

I’ve done two additional tests:

I injected a couple of ble.flush() commands, and I poll AT+BLEUARTFIFO. The TX buffer is empty almost all of the time so it appears that the arduino is flushing as expected.
I changed the code to call ble.print() instead of Blynk.virtualWrite and connected the arduino to a generic BLE UART app. The app logs the UART messages from the arduino as soon as the arduino sends them (well within ~200ms).

This makes it look like the app is at fault :(. Have you guys had any luck reproducing?

Gaff · June 3, 2016, 7:09am

@vshymanskyy @BlynkAndroidDev Any thoughts on this?

I updated the android app this morning but it seems to be just the same.

Let me know if there’s any more info you need

federicobusero · July 20, 2016, 8:53pm

Is there any progress in solving this issue? I am also having the same problem on other hardware: the program I show here should increase a counter on a “Value Display S” widget in the app every 3 seconds. However, when sending value 5,5,5,5 you see 5,5,5,4 in the app. So this clearly shows that the last part of the BLE buffer isn’t flushed somewhere (I guess in the Android app).

I am using

Software:

Android app version 1.13.2 (12/7/2016) running on Android version 5.1.1 on Samsung SM-G800F
Blynk library 0.3.8

Hardware

Arduino nano
HM10 BLE module

My code looks like

#define BLYNK_DEBUG
#define BLYNK_PRINT Serial

#define BLYNK_USE_DIRECT_CONNECT

#include <SoftwareSerial.h>
#include <BlynkSimpleSerialBLE.h>
#include <SimpleTimer.h>

// You should get Auth Token in the Blynk App.
// Go to the Project Settings (nut icon).
char auth[] = "0d843a65fc98494e91be76faced09ffe";

SoftwareSerial SerialBLE(2, 3); //  RX, TXconnected to HM-10

long count;

SimpleTimer timer; 

void updateCount()
{
  ++count;
  Serial.println("updateCount");
  
  Blynk.virtualWrite(V6,count);
  Blynk.virtualWrite(V7,count);
  Blynk.virtualWrite(V8,count);
  Blynk.virtualWrite(V9,count);
}

void setup()
{
  Serial.begin(9600);

  SerialBLE.begin(9600);        
  Blynk.begin(auth, SerialBLE);

  while (Blynk.connect() == false) {
    // Wait until connected
  }

  count = 0;
  timer.setInterval(3000L, updateCount);
}

void loop()
{
  Blynk.run();
  timer.run();
}

and the output looks like

[0] Blynk v0.3.8 on Arduino Uno
[0] Connecting...
[2520] >[02|00|01|00] 
[2571] >0d843a65fc98494e91be76faced09ffe
[2572] Ready
[2572] <[00|00|01|00|C8]
[4658] >[14|00|02|00|04]
[4662] >vr[00]5
updateCount
[5634] <[14|00|01|00|06]vw[00]6[00]1
[5686] <[14|00|02|00|06]vw[00]7[00]1
[5739] <[14|00|03|00|06]vw[00]8[00]1
[5791] <[14|00|04|00|06]vw[00]9[00]1
[5843] >[14|00|03|00|04]
[5844] >vr[00]5
[6645] >[14|00|04|00|04]
[6649] >vr[00]5
[7658] >[14|00|05|00|04]
[7662] >vr[00]5
updateCount
[8634] <[14|00|05|00|06]vw[00]6[00]2
[8686] <[14|00|06|00|06]vw[00]7[00]2
[8739] <[14|00|07|00|06]vw[00]8[00]2
[8792] <[14|00|08|00|06]vw[00]9[00]2
[8844] >[14|00|06|00|04]
[8845] >vr[00]5
[9683] >[14|00|07|00|04]
[9688] >vr[00]5
[10658] >[14|00|08|00|04]
[10663] >vr[00]5
updateCount
[11634] <[14|00|09|00|06]vw[00]6[00]3
[11686] <[14|00|0A|00|06]vw[00]7[00]3
[11740] <[14|00|0B|00|06]vw[00]8[00]3
[11792] <[14|00|0C|00|06]vw[00]9[00]3
[11845] >[14|00|09|00|04]
[11845] >vr[00]5
[12684] >[14|00|0A|00|04]
[12688] >vr[00]5
[13659] >[14|00|0B|00|04]
[13664] >vr[00]5
updateCount
[14635] <[14|00|0D|00|06]vw[00]6[00]4
[14687] <[14|00|0E|00|06]vw[00]7[00]4
[14740] <[14|00|0F|00|06]vw[00]8[00]4
[14792] <[14|00|10|00|06]vw[00]9[00]4
[14845] >[14|00|0C|00|04]
[14845] >vr[00]5
[15684] >[14|00|0D|00|04]

It doesn’t matter if the variable count is of type int or long, the issue remains the same.

Gaff · July 20, 2016, 9:45pm

Hurray! I’m glad it’s not just me

I’m pretty sure there’s a android / BLE bug somewhere but I never managed to get traction. I was told it was a hardware issue but I’m not so sure. Also see here https://github.com/blynkkk/blynk-library/issues/127

The good news is that I now have an Arduino 101, so I’ll see if I can reproduce on that.

federicobusero · July 24, 2016, 4:14pm

Until the Blynk developpers fix this issue, I use following workaround: simply execute the last virtualWrite 2 times. The problem is that all widgets (such as led) are using virtualwrite in their implementation, so basically always the last command is delayed … (it took quite some time untill I understood why one LED widget was alway showing the wrong colour, I only changed the value when toggling …). Anyhow I finished my Blynk-code of a car robot with 2 motors using HM10 BLE, line followers, RGB LED, buzzer, ultrasonic module with automatic line following or avoidance mode, or manual using joystick. I wait to publish my code as an instructable until this issue is solved. I hope they do, the other bugs that were there were always fixed within days.

wanek · January 5, 2017, 11:15pm

hello! i know this is an old post, but @federicobusero, @Gaff, did this bug has ever been reeolved? i have same problems now with bluetooth and ble…

federicobusero · January 28, 2018, 1:10pm

Hi @wanek, I checked with the Blynk library 0.5.0, using Android app version 2.18.0 of 26 jan 2018, and this issue is solved in the Android app.

If you have other HM10 BLE problems using Blynk, have a look at [SOLVED] Blynk and BLE using HM10 module (OK+CONN problem)

Gunner · December 10, 2017, 3:52pm