I can get it all setup and paired with my Android phone (Huawei Ascend Y300). I am using the Android app ArduDroid by TechBitar. I can get it to send messages both ways however when I send text or numbers from Arduino to phone it it received as it is sent, but going from Android to Arduino the output if I send the small letter a comes out as *12|99|99|a#
It is getting the right message but it is wrapped inside that constant string of characters. I have put in a bit of code so it only is receiving the small letters of the alphabet by limiting the ASCII codes. Does anyone know why that constant stream of characters comes across.
Here is my code
#include <SoftwareSerial.h>
SoftwareSerial mySerial(10, 11); // RX, TX
void setup()
{
// Open serial communications and wait for port to open:
Serial.begin(9600);
//Serial.println("Goodnight moon!");
// set the data rate for the SoftwareSerial port
mySerial.begin(9600);
//mySerial.println("Hello, world?");
}
void loop() // run over and over
{
if (mySerial.available())
{
char c = mySerial.read();
if(c >= 97 && c <= 122 || c >= 65 && c <= 90)
Serial.write(c);
}
if (Serial.available())
mySerial.write(Serial.read());
}
Thankyou for the guide you put up in the first link. I have it working now. (The second link didn't work). It led me to try the Bluetooth Graphics app and the text option sends perfect to my arduino while still using SoftwareSerial. Must have been an issue with the app. Perhaps that was a wrapped that let the Arduino know where the communication was coming from if you had more than one Android paired.
Thanks for pointing out my stuff-up with the link. I have now fixed it. The ino is in the guide anyway.
Arduino can only pair with one Android at a time - hence it being called pairing. Different Android apps do indeed treat received data differently but I haven't heard of a problem like yours. I found it simpler to change the app than fix the problem within the app. It may be that the problem would need to be fixed in Arduino. Bluetooth graphics does what is supposed to do with my data logging and I stick with that.
Nick_Pyner:
Arduino can only pair with one Android at a time - hence it being called pairing. Different Android apps do indeed treat received data differently but I haven't heard of a problem like yours. I found it simpler to change the app than fix the problem within the app. It may be that the problem would need to be fixed in Arduino. Bluetooth graphics does what is supposed to do with my data logging and I stick with that.
I really need to do more research on bluetooth, especially if I want to develop my own app. For now this suits perfect as I can program a set of instructions and use phone to control simple robotic projects.
I read somewhere about up to seven connections but looking back now that would be seven connections from Android (master) to multiple slaves (arduinos)? I also thought HC-06 was the type that was master/slave but since read that is HC-05.
rabn21:
I read somewhere about up to seven connections but looking back now that would be seven connections from Android (master) to multiple slaves (arduinos)? I also thought HC-06 was the type that was master/slave but since read that is HC-05.
If Android master, it would be an Android app. I'm not aware of it and actually think it more likely to be an Arduino's job. This would involve polling for several Android's that have been previously paired. I've no idea how you would do that but I imagine the blueteeth in my cars work that way. They can handle multiple phones but once in conversation, they still work with one at a time.
Although all the talk is about HC-05, the HC-06 is fine for most stuff. I believe the only time you can use Arduino in a project with an HC-05 as master is when using a game controller or the like. I also believe the HC-05 is not up to working Arduino<>Arduino comms.
If you’re doing a straight serial read, then you’re also reading the header and trying to print meaningless (to us) data.
If you expect the header data to be stripped off by the H/W, make sure you have compatible devices or do it yourself in S/W. There’s ACL, SCO, LMP, HCI, SDP, SMP and a whole bunch of other TLAs that packetize the data you’re transmitting that, under normal circumstances, we never see. If you examine the ISO/OSI stack, serial.read deals with the physical and data link layers while bluetooth rides up a couple of layers higher.