BLYNK
BLYNK.IO       📲 GETTING STARTED       📗 DOCS       👉 SKETCH BUILDER

Bluetooth BLE support for Adafruit Feather Bluefruit LE

Sorry to bother you guys - I’d like to reopen: [SOLVED] Bluetooth BLE support for Adafruit Feather Bluefruit LE

Specifically I’m (still) having issues connecting Blynk to the Adafruit Feather 32u4 BLE board to android. The board appears to be transmitting data to the app, but the app doesn’t seem to be parsing everything.

My test is to write data from the board to the app every 10 seconds.
What I observe is that the app doesn’t keep up and eventually the board times out.

I have a hypothesis - I’m seeing out-of-order sends, perhaps this is confusing the Android code. Here’s an example where message 0E is sent before 0D:

[58159] <[06|00|0E|00|00]
[58202] <[14|00|0D|00|06]vw[00]3[00]3

Could this be the issue?

Sketch:

#define BLYNK_DEBUG
#define BLYNK_PRINT Serial
#define BLYNK_USE_DIRECT_CONNECT

#define DBG_ENABLE 1

#include <SoftwareSerial.h>

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


#include <BlynkSimpleSerialBLE.h>


//===============
// Blynk setup
//===============

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

//===============
// BLE setup
//===============

// 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 10000
#define POLL_INTERVAL 1000
int thevalue;
long previousMillis;
long previousPollMillis;

void setup() {
  delay(1500);
  Serial.begin(115200);
  Serial.println(F("Dammint why doens't BLE work?"));   
  
  ble.begin(BLUEFRUIT_VERBOSE_MODE);   
  ble.factoryReset(); //Optional  
  ble.echo(true);
  ble.info();
  ble.setMode(BLUEFRUIT_MODE_DATA);   
  
  unsigned long currentMillis = millis();  //0; //force an initial publish
  previousMillis = currentMillis;
  previousPollMillis = currentMillis;

  Blynk.begin(ble, auth);
}

void pollBLE() {
  ble.setMode(BLUEFRUIT_MODE_COMMAND); 
  ble.println("AT+BLEUARTFIFO");
  ble.waitForOK();
  ble.setMode(BLUEFRUIT_MODE_DATA); 
}

BLYNK_WRITE(V10) //Random
{
  int pinData = param.asInt();
  Serial.print(F("Button 10  = "));
  Serial.println(pinData);
}

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); 
  
  //ble.flush(); 
}

Output

[33546] Connecting...
[37724] >[02|00|01|00] 
[37769] >570529042ad34219a964929e2a483f40
[37771] Ready
[37771] Free RAM: 2003
[37773] <[00|00|01|00|C8]
Tick
[37883] <[14|00|01|00|06]vw[00]0[00]1
[37996] <[14|00|02|00|06]vw[00]1[00]1
[38109] <[14|00|03|00|06]vw[00]2[00]1
[38221] <[14|00|04|00|06]vw[00]3[00]1
[47773] <[06|00|05|00|00]
Tick
[47884] <[14|00|06|00|06]vw[00]0[00]2
[47996] <[14|00|07|00|06]vw[00]1[00]2
[48109] <[14|00|08|00|06]vw[00]2[00]2
[48156] >[00|00|05|00|C8]
[48222] <[14|00|09|00|06]vw[00]3[00]2
Tick
[57823] <[14|00|0A|00|06]vw[00]0[00]3
[57935] <[14|00|0B|00|06]vw[00]1[00]3
[58048] <[14|00|0C|00|06]vw[00]2[00]3
[58159] <[06|00|0E|00|00]
[58202] <[14|00|0D|00|06]vw[00]3[00]3
[60160] <[06|00|0F|00|00]
[60397] >[00|00|0E|00|C8]
Tick
[67823] <[14|00|10|00|06]vw[00]0[00]4
[67936] <[14|00|11|00|06]vw[00]1[00]4
[68048] <[14|00|12|00|06]vw[00]2[00]4
[68161] <[14|00|13|00|06]vw[00]3[00]4
[68208] >[00|00|0F|00|C8]
Tick
[77824] <[14|00|14|00|06]vw[00]0[00]5
[77938] <[14|00|15|00|06]vw[00]1[00]5
[78051] <[14|00|16|00|06]vw[00]2[00]5
[78163] <[14|00|17|00|06]vw[00]3[00]5
[78211] <[06|00|18|00|00]
[80214] <[06|00|19|00|00]
[82216] <[06|00|1A|00|00]
[84211] Heartbeat timeout: 84211, 68210, 82216
[84213] Connecting...

BTW guys - I’m more than happy to send you one of these Adafruit Feather BLE boards and make a donation if you’d be willing to take a look at this bug! It’s easy to reproduce :slight_smile:

Also - is there any way to get debug output from the Android app? If so I could send that to you.

OK, I’ll send you a logging build later for BLE debug.

I’ve found (and fixed!) the bug that seems to be causing the majority of the issues - hurrah!!

@BlynkAndroidDev: I’m still seeing some issues in the app though:

  • Sometimes some of the widgets in the app don’t immediately update upon receiving a message from the board.
  • Sometimes the BLE connection will break, but the android app doesn’t seem to notice or reconnect. Typically this happens if my phone goes on standby for a couple of seconds.
2 Likes

Had you checked the second issue with the released today 2.18.3 build?

Logging build:

  1. Reproduce your issues
  2. Go to project list -> press on About button in the top right corner
  3. Press ‘Send logs’ and select Gmail app

@BlynkAndroidDev - argh my phone says “The package appears to be corrupt” when I try to install that :frowning:

I’ll try 2.18.3 just as soon as Google Play gets around to updating me!

Try to uninstall your current build before installing logging one

2.18.3 should be already available - we had released it on yesterday

@BlynkAndroidDev, @Gaff suggests a fix where he changes how msgId is assigned.
Can you verify if msgId can have impact on BLE connection?

@BlynkAndroidDev @vshymanskyy - specifically if the app receives a ping request followed by a virtualwrite with a lower message id number it disconnects.

1 Like

Thanks, I’ll check, but the app has no logic based on a ‘messageId’ value. Please install that logging build and send us log to verify what happens on the app side.

@BlynkAndroidDev I’ve sent you some longs. First thing I’ve noticed is a huge delay in receiving some BLE messgaes.

From my arduino I sent 4 messages within ~500ms:

[61081] <[14|00|01|00|06]vw[00]0[00]1
[61192] <[14|00|02|00|06]vw[00]1[00]1
[61302] <[14|00|03|00|06]vw[00]2[00]1
[61413] <[14|00|04|00|06]vw[00]3[00]1

From the android logs:

08:00:43 DEBUG CommunicationService - onPacketReceived messageId = 1, actionId = 20, value = 1972193027
08:00:43 DEBUG CommunicationService - onPacketReceived messageId = 2, actionId = 20, value = 1972193027
08:00:43 DEBUG CommunicationService - onPacketReceived messageId = 3, actionId = 20, value = 1972193027
08:00:53 DEBUG CommunicationService - onPacketReceived messageId = 4, actionId = 20, value = 1972193027

Notice how the 4th message arrives 10 seconds later!!

Also the app responds to ping request 0x16 but not to request 0x1C. I can’t see any evidence of the app receiving 0x1C. (This is the issue that appears to be prevented with my message ordering fix).

[There are more issues which I’ll try and reproduce, but I’m out of time now]

1 Like

The app could not change the time of the message receiving, we even change connection priority to high when the device connects for better and faster communication. I’ll add additional logging for the data parsing to be sure that those 0x1C ping requests are not received by the app.

@vshymanskyy could that be an issue of message rate of the hardware or our library for BLE?

Of course it could…

@BlinkAndroidDev (@vshymanskyy) I know it’s not the board, here’s how:

I frigged the blynk library so that it accepts any string as a connection string, then connected to it via the Adafruit bluetooth app. This app echos UART messages and exhibits no delays. When I reconnected with the Blynk app I see the delay again.

Perusing the Adafruit code, they seem to use the Eclipse MQTT library for their actual comms. Is there any chance I can look at the blynk android code to compare?

No, we would not provide access to source code. We have very ordinary for Android apps implementation of the BLE communication, and I do not see any huge differences with Adafruit code for Android on their github. I’ll update logging to be more detailed and update this thread.

Latest log build: https://www.dropbox.com/s/2xf6ivg3f5282jt/blynk_app-log.apk?dl=0

OK I got one! Full log is in the mail:

22:36:32 DEBUG BLE - onDataChanged: characteristic=6e400003-b5a3-f393-e0a9-e50e24dcca9e value=[0, 0, 1, 0, -56]
22:36:32 DEBUG BLE - parseAndSend: actionId=0 messageId=1 codeOrLength=200
22:36:32 DEBUG BLE - onDataChanged: characteristic=6e400003-b5a3-f393-e0a9-e50e24dcca9e value=[20, 0, 1, 0, 6, 118, 119, 0, 48, 0, 49]
22:36:32 DEBUG BLE - parseAndSend: actionId=0 messageId=1 codeOrLength=200
22:36:32 DEBUG CommunicationService - onPacketResponse messageId=1 responseCode=OK
22:36:32 DEBUG BLE - onDataChanged: characteristic=6e400003-b5a3-f393-e0a9-e50e24dcca9e value=[20, 0, 2, 0, 6, 118, 119, 0, 49, 0, 49]
22:36:32 DEBUG BLE - parseAndSend: actionId=20 messageId=1 codeOrLength=6 message=
22:36:32 DEBUG CommunicationService - onPacketReceived messageId = 1, actionId = 20, value = 1972193027
22:36:32 DEBUG BLE - onDataChanged: characteristic=6e400003-b5a3-f393-e0a9-e50e24dcca9e value=[20, 0, 3, 0, 6, 118, 119, 0, 50, 0, 49]
22:36:32 DEBUG BLE - parseAndSend: actionId=20 messageId=2 codeOrLength=6 message=
22:36:32 DEBUG CommunicationService - onPacketReceived messageId = 2, actionId = 20, value = 1972193027
22:36:32 DEBUG BLE - onDataChanged: characteristic=6e400003-b5a3-f393-e0a9-e50e24dcca9e value=[20, 0, 4, 0, 6, 118, 119, 0, 51, 0, 49]
22:36:32 DEBUG BLE - parseAndSend: actionId=20 messageId=3 codeOrLength=6 message=
22:36:32 DEBUG CommunicationService - onPacketReceived messageId = 3, actionId = 20, value = 1972193027

The onDataChanged messages occur immediately when blynk receives a message from the board - exactly as expected! However the onPacketReceived messages appear to be delayed / offset. Hence there are 5xonDataChanged but only 4xonPacketReceived.

Notice how the second parseAndSend call appears to be a duplicate of the first? What’s going on here?

(incidentally the debug app still says it’s version 2.17.3)