Bluetooth Communication to Android: Arduino sending bad data?

Hi all,

I’m currently working on a project where:

  • Arduino reads values from 5 sensors every 1 second
  • rounds the values and packages them as a string
  • converts the string into a byte array
  • transmits the bytes using a for loop

On the Android side:

  • a thread listens for the transmitted bytes
  • packages the received bytes in an array
  • sends the received data to the thread helper
  • bytes are then converted to a string
  • then based on the first character in the string (in this case ‘#’), the string is broken down into 5 variables again to be outputted to the main activity window

Here’s the test Arduino sketch I was working with:

#include <SoftwareSerial.h>

SoftwareSerial BTSerial(10, 9); // RX | TX

//#define ONE_WIRE_BUS 7 // Data bus pin for temperature sensor reading
//OneWire oneWire(ONE_WIRE_BUS); // initialize OneWire to read for reading temperature sensors
//DallasTemperature sensors(&oneWire); // directing the temperature sensors' location to the sensor library

int strLength;
String output;
double temp;

//pulse counts changed within count_ISR's
volatile unsigned int count1;
volatile unsigned int count2;

//variables for protected copies of counts
unsigned int copyCount1;
unsigned int copyCount2;

void count1_ISR()
{
  count1++;
}

void count2_ISR()
{
  count2++;
}
void setup() {

  BTSerial.begin(38400);  // HC-05 default speed in AT command more
  Serial.begin(9600);

  //send test signal to interrupt pins
  analogWrite(5, 127); //980 hz timer 0 jumper pin 5 to pin 2
  analogWrite(11, 127); //490 hz timer 2 jumper pin 11 to pin 3

  attachInterrupt(0, count1_ISR, RISING); //pin2 (Atmega328)
  attachInterrupt(1, count2_ISR, RISING); //pin3 (Atmega328)

}

void loop() {
  static unsigned long lastSecond;
  if (micros() - lastSecond >= 1000000L)
  {
    lastSecond += 1000000;
    getCount();
    Serial.println(copyCount1);
    Serial.println(copyCount2);

    output = "#";
    output += copyCount1;
    output += ".";
    output += copyCount2;
    output += ".";
    output += copyCount1;
    output += ".";
    output += copyCount2;
    output += ".";
    output += copyCount1;
    output += ".";
    output +=  "~";

    strLength = output.length() + 1;
    byte bytes[strLength];
    output.getBytes(bytes, strLength);
    for (int i = 0; i < strLength; i++) {
      BTSerial.write(bytes[i]);
    }

    //BTSerial.write(1);
    
    Serial.println(output);
    Serial.println();
  }

  if (BTSerial.available() > 0){
    byte input = BTSerial.read();

    Serial.println(input);
  }

}
void getCount()
{
  noInterrupts();
  copyCount1 = count1;
  count1 = 0;
  copyCount2 = count2;
  count2 = 0;
  interrupts();
}

Here’s my main activity Java code for my Android app:

http://pastebin.com/x9qyKBRF – (9K character limit sorry)

I’ve tried to comment on the logic in the Java code. Here’s what the main activity window of the app looks like:

So basically, I don’t know what is going on at this point. Last week I tested this setup as is together and it worked! But unless I somehow changed something accidentally in my receiving logic on the Android side (which I can’t see), now it doesn’t work.

To see what the Arduino was sending over Bluetooth, I set my Android to print a little popup (toast) notification to show the full string it was receiving, which came up as empty and very intermittent (not receiving every 1 second).

I then changed my Arduino sketch to simply write a ‘1’ over Bluetooth, and paired it to my PC to view what it was sending in a PuTTY terminal. A ‘1’ would eventually print in the terminal, but again slowly and at random intervals.

On the other hand, I’ve tested transmitting a single byte on pressing one of the buttons I’ve made in my app to the Arduino, and had the Arduino print what input it received to the Serial monitor. That works without issue.

Could this be a hardware issue with the Bluetooth module? I’m using an HC-05 with default settings other than changing it’s device ID name to “PUMPCTRL”.

Any help would be appreciated. If more information is needed please ask.

vmorr: Could this be a hardware issue with the Bluetooth module?

Probably not. It's much more likely to be the code, particularly as the words AT mode are in there somewhere. Perhaps you can try simpler code like

Serial.println(pumptemp);

and try to see it on the serial monitor. If you succeed, disconnect the monitor, connect bluetooth to pins 0,1, and use a standard terminal app on the phone. If that works, it proves there is nothing wrong with the hardware, and may provide some value in software too. Unless you have previously configured the HC-05 to run at 38400, it is probably running at 9600.

Nick_Pyner: Unless you have previously configured the HC-05 to run at 38400, it is probably running at 9600.

As Nick_Pyner pointed out, unless you changed the HC-05's baud, you should use 9600.

The HC-05 uses 38400 baud when it is in its command mode(if command mode is initiated when the device is powered on). If command mode is entered after the device is powered on, then the module uses the same baud in both command mode and normal mode. (I'm not sure if I'm using the correct mode names.)

Which baud to use (while in command mode) with the HC-05 can be a bit confusing. I don't think these quirks are a big problem though. I think the HC-05 is a great Bluetooth module.

DuaneDegn: Which baud to use (while in command mode) with the HC-05 can be a bit confusing.

No it isn't, and quite the opposite. If you are in AT mode, you can only talk to it at 38400, and that applies irrespective of the rate at which it has been configured to communicate. What this means is that there is never any confusion about the rate you use to configure the device. You may then instruct it to use a different speed when in comms mode.

Nick_Pyner: No it isn't, and quite the opposite. If you are in AT mode, you can only talk to it at 38400, and that applies irrespective of the rate at which it has been configured to communicate. What this means is that there is never any confusion about the rate you use to configure the device. You may then instruct it to use a different speed when in comms mode.

If you enter AT mode on power up, then the AT mode's baud will be 38400.

If you enter AT mode after the module has been powered on, then the AT mode baud is the same as the normal baud. I was very surprised by this.

I suppose it's possible not all HC-05 modules exhibit this behaviour but I assure you the one I have behaves this way. (I believe there are different firmware versions for the HC-05.)

Nick_Pyner: Probably not. It's much more likely to be the code, particularly as the words AT mode are in there somewhere. Perhaps you can try simpler code like

Serial.println(pumptemp);

and try to see it on the serial monitor. If you succeed, disconnect the monitor, connect bluetooth to pins 0,1, and use a standard terminal app on the phone. If that works, it proves there is nothing wrong with the hardware, and may provide some value in software too. Unless you have previously configured the HC-05 to run at 38400, it is probably running at 9600.

I think my HC-05 is set to a baud of 38400... In AT mode I might have used the command "AT+ORGL" at some point which sets the default baud to 38400. Looks to be this way as when I send a byte of '1', '2', or '3' from my app by pressing the buttons, it comes up as '254' for each in the serial monitor when the BTSerial baud is set at 9600. At 38400 however it prints as it should.

I've tried what you suggested above. I installed a "Bluetooth Terminal" app and made a simple sketch that ran "Serial.println(1);" every 1 second. While in the serial monitor it prints as it should, nothing appears on the phone. Same with "Serial.write(1);". Writing from this app to the Arduino works however, again. I've also tried apps "ArduinoRC" and "ArduDroid", both don't receive anything either.


PROBLEM SOLVED.

Code was fine. It appears there's a short somewhere in my voltage divider for the RX pin of the HC-05. Just gonna connect the TX pin from the Arduino direct.

Unbelievable lol

vmorr: connect the TX pin from the Arduino direct.

Yes, while I wouldn't call it good practice, I have had one running for years with direct connect, and I have never heard of one being fried.