On the receiving end, I have an mit app inventor app which acts like a client.

In arduino, I check for connection status and do a serial write to send the text. The code for that is below:

#include <SoftwareSerial.h>

#define D2 2
#define D3 3
#define BT_STATE_PIN 4

SoftwareSerial BTSerial(D3, D2);
long lastMark;

void setup() {
  // put your setup code here, to run once:
  pinMode(BT_STATE_PIN, INPUT);    

  int counter = 0;
  lastMark = millis();

bool isBTConnected() {
  return (digitalRead(BT_STATE_PIN) == HIGH);

void sendText(char* message) {
  Serial.println("SEND: " + String(message));
  if(isBTConnected()) {
  else {
    Serial.println("did not send");

int msgCount = 0;
void loop() {
  long now = millis();

  if(now - lastMark > 2500) {
    String msg = "This is a really really long MSG" + String(msgCount);
    if(msgCount == 5) {
      msgCount = 0;  
    lastMark = millis();

This is how the device is wired currently:


simulate this circuit – Schematic created using CircuitLab

On the app inventor side of things, I have a very simple app that connects to the bluetooth module; it listens for anything received, and then just receives the text.

aia file

enter image description here

Here is a pic showing the issue I am facing currently:

enter image description here

Sometimes the breaking up happens randomly at some other place. Hoping someone can help sort this issue.


Without having experience in AppInventor, I see the following problem:

In your app you are outputting the received data regularly with a timer in form of distinct messages. This code can naturally only display text, that was already received. You seem to think, that only because you use a single line oft code on Arduino for sending the message data, the data would be send in one big chunk. For Serial that is not the case. Actually the write() function only fills the libraries buffer and the actual data will then be send serially (thus the name). There is nothing like a chunk of data or a message on a serial interface, unless you yourself impose this principle on the data stream. All the bytes in the libraries buffer are the same and are being send in the order of the buffer. Moreover Bluetooth does consist of packages of data, but they will be automatically packed; in a way that will not correspond to your messages.

So in the end, arbitrary parts of your message will be received by the phone at arbitrary times, that highly depend on timing conditions. In your code you should constantly receive the data and only display a message, when you have received an \n character, which is the delimiter of a message. It is a very common and helpful technique to first receive a full message and then processing it, when the message is complete.


I did something similar (multiBT) using HC-05 and PC BT, with the same App. Results: all the incoming data from the PC_BT to the phone are right, but with the HC-05 sometimes is chunked as @deostrol show. I think is a bug with the HC-05 firmware.

To correct this, I've implemented StartBegin and StopFinish character in the received string before use.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.