1
votes

after this problem Bluetooth connection in Android > 4.1.2 that I fixed by forcing connection by repeatedly try to connect with a while iteration, now I'm having an other issue with Android/Arduino communication. My HW is Nexus 7 MY2012 with Android 4.3, Arduino UNO R3 and a BT module RN42.

From Android I'm sending an array of bytes to Arduino got from a string. At the beginning, with Baudrate 115200 and no parity, only the first byte arrives correct and the rest was apparently mismatched (mostly in a repetitive manner). After setting parity EVEN in the RN42 module, I see that at least first 3 bytes arrive correctly, and the rest is messed up. Here below the core part of comunication from Android (initialization of BT basically follows the SDK example). It is located inside a class estended from AsyncTask used to manage connection work:

        public void write(String message) {
        Log.d(TAG, "...Data to send: " + message + "...");
        byte[] msgBuffer = message.getBytes();

        try {
            mmOutStream.write(msgBuffer);
        } catch (IOException e) {
        mHardwareToServiceHdlr.obtainMessage(MSG_ERR_BT_WRITE).sendToTarget();
            Log.d(TAG, "...Error data send: " + e.getMessage() + "...");
        }

        }

and Arduino sketch

#include <SoftwareSerial.h>
#include <Streaming.h>

const int bluetoothTx = 2;
const int bluetoothRx = 3;
byte incomingByte;
String incomingString;

SoftwareSerial bluetooth(bluetoothTx,bluetoothRx);

void setup() {
  Serial.begin(115200);
  bluetooth.begin(115200); 
  bluetooth.print("$$$");
  delay(100);
  bluetooth.println("U,115K,E");
  bluetooth.begin(115200);
  delay(100); 
}

void loop(){

  if (bluetooth.available() > 0) {  // if the data came

    incomingByte = bluetooth.read(); // read byte
    Serial.println((char)incomingByte);
  }
}

If I send to Arduino a string such as "hello horld" this is what I get in serial monitor in a serie of transmissions:

 hel,o wo2ld
 hel<o wo2ld
 hel,o7orld
 hel,o wo2ld
 hel,o wo2ld
 hel<o7or6d
 hel,o wo2ld
 hel,o wo2ld
 hel,o wo2ld
 hel<o wo2ld
 hel,o7orld
 hel<o wo2ld

This is just example, result depends also on how much often I send the string to Arduino. The most of the times, the fourth and the nineth byte (but not always in the same manner and not always only them) are mismatched.

Transmitting data from Arduino to Android seems to work fine with any particular trouble.

Any help would be greatly apreciated, this thing is making me crazy as far as I need to transmit data longer than 3 bytes. Thanks

2
Hi! I'm not able to receive data sent from Android, but i'm able to receive data from Arduino. Did you had that kind of problem?Florescu Cătălin

2 Answers

0
votes

There could be multiple issues with your setup:

  1. Don't use SoftwareSerial's begin() multiple times. If you need to empty the buffer then use bluetooth.flush() after the println() and before the delays.
  2. Taken from the SoftwareSerial docs:

    If using multiple software serial ports, only one can receive data at a time.

    Try using UART as the serial port instead of a bit-banged serial port.

  3. The Arduino UNO supports interrupts only for pins 2 and 3, and they are frequently used for something else, check that they are really free in your design.

  4. Try using a slower baud rate, there could even be RF issues with your layout at 115200 bps.

  5. If the previous approaches don't work, try storing the characters in a buffer before doing the Serial.print in the main loop. After you are done, finally print it, like this (mind the boundary checks):

    char buffer[MAX_LEN];
    unsigned int count = 0;
    
    void loop(){
    
      if (bluetooth.available() > 0) {  // if the data came
        buffer[count++] = bluetooth.read(); // read byte
      }
      buffer[count] = '\0'; 
      Serial.print(buffer);
      count = 0;
    }
    
0
votes

Kindly ensure pairing the device explicitly from your Android phone’s settings. Usually the pair code is 1234. The Hardware Tx,Rx pin are preferred if free on the Arduino. 96200 baud rate is generally better