I have a very strange situation.I own an Arduino UNO and this Bluetooth module:http://dx.com/p/jy-mcu-arduino-bluetooth-wireless-serial-port-module-104299

I have written an Android App to communicate with my Arduino, pairing etc. works nicely.But if I send as example the String "testtest" from my Android Smartphone,the Arduino recieves "t¬. ¹º", the number of characters is right, but only the first one iscorrect.I can confirm this behaviour with different transmitted data.

The strange thing is, that it also never goes inside theif(aChar == '\n') block.The first char received is always right, and if I just send one char commands via bluetootheverything works as expected. But I need to send more data.

First thought was that the bps are wrong, but all internet resources confirm that 115200 is the right one for bluetooth.If i set it lower I only receive garbage, not even one char correct.So is there something wrong in how I read the incomming data?

If I connect from CoolTerm on OSX to the Arduino over Bluetoothwith the following settings: baudrate 115200, data bits 8, parity none, stop bits 1everything works.

So I am currently not sure where the issue is (Arduino or Android), but sincethis subforum is about Networking i thought someone already tried to connectfrom an Android device.

where mChatService holts the BluetoothSocket and writes the data on the OutputStream.Basically it consists of the Android Sample App "BluetoothChat" modified a bit.Basically I do createInsecureRfcommSocketToServiceRecord(UUID.fromString("00001101-0000-1000-8000-00805F9B34FB")); to connect to the Arduino.

I now did the work and tried all baud rates from 1200 to 115200, all others did resultin more wrong chars. With 115200 at least the number of displayed chars was correct.I tried a few bluetooth apps to send messages to my arduino do check if others work.According to the sources I found, 115200 should be Ok for Android, so i checked with that:works: BlueTerm, BluControl (it just sends one char, this also works fine with my code)does not work: my App, Android Sdk BluetoothChat sample App, Amarino 2.0, SENA BTerm

I find it surprising that Amarino does not work. It should require 115200 baut rate, but instead of therandom integers I receive char garbage.

I would like to ask about your code. I have the same bluetooth modul but v1.05. I want to change te name and pin code, but I can't. When send "AT" from terminal, is replies OK. But all the other commands replies ERROR. So I tried your code, but it isn't work for me. What is the value of "cmdDelay"? If you run your code, do you get reply OK after each AT command? Thx.

I tried to play around with the AT commands, but this is a bit messy, as I can't find any documentationfor this specific module.As it did not respond to AT+UART? command (the one where I could configure parity and stop bits)I downloaded the following code I found in the forum (just modified slightly):

It's a very simple and inexpensive Bluetooth Serial Module. 4-Pin connection: 5V, GND, TX, RX. You can configure the NAME, PIN, and BAUD using this utility, settings are stored in the module firmware until you modify them again.

This utility will search for the bluetooth module on all the possible BAUD options, then configure the module according to the configuration parameters below:

Note: You can only configure the module when it does not have an active bluetooth connection!

O is 0x4F and K is 0x4B so (adding Start and stop bits) in binary that should be:

XXXS01001111sXXXS01001011sXXX

é is 0xE9 in ISO Latin 1 so what you seem to be getting is:

XXXS01001111sXXXS11101001sXXX

Start = 0stop = 1X = 1 (dead time between characters)

XXX001001111 1XXX0 010010111XXXXXX001001111 10111 010011XXX

Looks like it is somehow picking up three extra bits between the first and second character. Instead of the one stop bit (1) of the first character and the single Start bit (0) of the second character it is is seeing 10111. If there is a delay between characters it will be filled with 1's so if, instead of 8N1 it was sending 9Z2 (9 data bits, Zero parity, 2 stop bits) that would cause the 9th data bit to be read as a STOP bit, the parity to be read as a START bit, the STOP bits to be read as two data bits and the delay between characters to be read as a third data bit.

Just a note: the Arduino serial code seems to ignore all framing errors. It doesn't care if a STOP bit isn't 1 or if the Parity doesn't match.

I did some further experimenting but did not have any success.The question is now what causes that problems.I tried other ports on my Arduino UNO, so I think the Arduino itself should be ok.So either the JY-MCU is defect, or there is an issue with the SoftwareSerial library.In the meantime I will try to buy another one, but I would like to solve that issue.Any ideas on what to try next?

If you have access to an oscilloscope I would check the serial waveforms coming from the bluetooth module to make sure they have the expected bit timing and contents. If they do, something is wrong with SoftwareSerial. If they don't, something is wrong with the bluetooth module.

Unfortunately I do not have a oscilloscope available.But I borrowed an Android Mega from a friend.If I use the Hardware serial ports on the Mega, everything works perfectly, no odd bits Using SoftwareSerial it does not work on the Uno or Mega.

So I assume that the bluetooth module is fine, but the SoftwareSerial has a problem (or I used it the wrong way).I have to give back the borrowed Mega, so I would like to get the issue solved.I have a bit of software engineering background, but I am new to the Arduino stuff,so any hints where to start are welcome.

Will try to have a look at the SoftwareSerial source, but I think without oscilloscope it is hard for me to checkmy modifications.

This makes more sense. Looks like the SoftwareSerial just wasn't fast enough to catch the start bit of the second character. It saw the first two '1' bits of the second character as idle line and saw the 0 in the third bit as a start bit. You'd think that it wouldn't have the same problems are lower bit rates but apparently it does.