JY-MCU Bluetooth Module

Using Arduino Networking, Protocols, and Devices
#1

Hello and thank you for your help!
I have a JY-MCU bluetooth module. Rx is connected to pin 11, Tx is connected to pin 10. I am attempted to simply send and receive characters using the Armino android app.

Here is my sketch:

#include <SoftwareSerial.h>

SoftwareSerial mySerial(10, 11);

void setup() {
  Serial.begin(9600);
  mySerial.begin(115200);
}

void loop() {
  while(mySerial.available()>0){
    Serial.println(mySerial.read());
  }
}

Here are my results when I send the character a:
6
204
3
103
24
255

I attempted every single baud rate recommended. 9800, 4800, 115200, 38400, 36400. Etc.
The only other one that actually receives data is 38400. But it is still garble.

I am at my wits end. I have seen plenty of tutorials to program the module using some AT commands and putty and an RS-232 converter. But is there a way to do it using the Arduino? Or does anyone have any other suggestions as to why this isn’t working! Thank you!!

#2

The standard pins are D0 for Rx and D1 for Tx. I see you are using software serial and maybe you are allowed to do that with that library, but it might make more sense to walk before you run and use the normal ports. Doing so will allow you to dispense with the library. You can then run the bluetooth in its basic mode, using simple serial.print and serial.read commands.

int incomingByte = 0;   // for incoming serial data

void setup() {
        Serial.begin(9600);     // opens serial port, sets data rate to 9600 bps
}

void loop() {

        // send data only when you receive data:
        if (Serial.available() > 0) {
                // read the incoming byte:
                incomingByte = Serial.read();

                // say what you got:
                Serial.print("I received: ");
                Serial.println(incomingByte, DEC);
        }
}
#3

The standard pins are D0 for Rx and D1 for Tx. I see you are using software serial and maybe you are allowed to do that with that library, but it might make more sense to walk before you run and use the normal ports. Doing so will allow you to dispense with the library. You can then run the bluetooth in its basic mode, using simple serial.print and serial.read commands.

void setup() {

Serial.begin(9600);    // opens serial port, sets data rate to 9600 bps
}

Thank you for your response. My train of thinking is as follows: The baud rate for comm between my laptop and the module is different. As a result, I absolutely have to use two different serial connections. One initiated at 9600bps and one at whatever the JY-MCU module uses.

Help is still appreciated for anyone who reads this. But just for my own knowledge, am I correct in assuming that when I transmit from the arduino to the module, the module sends those bytes over the bluetooth connection? And vice-versa, when it recieves, the module sends the data through the transmit pin to my Arduino’s recieve?

#4

012anonymousxyz:
I absolutely have to use two different serial connections. One initiated at 9600bps and one at whatever the JY-MCU module uses.

This sounds like a recipe for certain disaster. The JY-MCU defaults to 9600 anyway. I use JY-MCU as the standard communication for data aquisition. To do this, no extra programming is needed for the Arduino, you just use the serial.print commnands, same as for the monitor. That is the secret, no programnming. All the work is at the other end. I use RealTerm on laptop and the settings made thereon so that it defaults to receiving the Arduino. I imagine the situation is the same with any Android device. Indeed you may find that all your problems are due to the Android device, and you might be better off proving the system with a real computer.

am I correct in assuming that when I transmit from the arduino to the module, the module sends those bytes over the bluetooth connection? And vice-versa, when it recieves, the module sends the data through the transmit pin to my Arduino’s recieve?

Yes. The Tx on the module is connected Rx on the Arduino i.e. they do what their names suggest.

Clipboard01.jpg
Clipboard01.jpg737×444 25.4 KB

#5

Hi, I think that in order to set the BT module speed to 115200 you first need to put it into command mode (should pull a pin of the module up, or down :~ ... better read the docs) and issue the corresponding AT command. So, with the module in command mode, you first connect via SoftwareSerial using the default baud rate (9600?), change the BT baud rate with AT command, then put the module back to data mode (in the meantime, SoftwareSerial would probably disconnect or start reading garbage). You should then be able to reconnect with SoftwareSerial using the new baud rate.

Your assumptions are (mostly) correct: you cannot share the hardware RX/TX pins between the BT module and the Usb, not just because they use different baud rates but because they would be sharing the same interrupts and underlying communications buffer and they would interfere between themselves. It is also correct that, when you connect via SoftwareSerial to the BT module, everything you write is sent to the remote BT device, and everything you read comes from the outside; this happens because the default state of the module is data mode and self-pairing is enabled.

#6

Hi, I think that in order to set the BT module speed to 115200 you first need to put it into command mode (should pull a pin of the module up, or down ... better read the docs) and issue the corresponding AT command. So, with the module in command mode, you first connect via SoftwareSerial using the default baud rate (9600?), change the BT baud rate with AT command, then put the module back to data mode (in the meantime, SoftwareSerial would probably disconnect or start reading garbage). You should then be able to reconnect with SoftwareSerial using the new baud rate.

Your assumptions are (mostly) correct: you cannot share the hardware RX/TX pins between the BT module and the Usb, not just because they use different baud rates but because they would be sharing the same interrupts and underlying communications buffer and they would interfere between themselves. It is also correct that, when you connect via SoftwareSerial to the BT module, everything you write is sent to the remote BT device, and everything you read comes from the outside; this happens because the default state of the module is data mode and self-pairing is enabled.

I'm relatively young and a lot newer so I apologize for my ignorance. I just want to me sure, when we are talking about the baud rate, it is the comm speed between the Arduino and the module, not the module and the other bluetooth device, correct? And is the baud rate for command mode (you mentioned 9600) the same as BT mode? I ran a funky sketch that I downloaded from online (there was also a library) and I can't find it anymore. And I don't know if I accidentally changed the rate. So what I'm saying is, if I accidentally changed the rate from its default for BT mode, can I safely assume the baud rate for when I put it in command mode is still its default?

Finally, and I'm 90% sure you just answered this but I can't understand why it wouldn't work, can't I cut off the end of my usb cable, connect my module directly to my computer accordingly, and use putty to enter command mode and change the baud rate to what I want? I can change the baud rate using putty (there is a drop-down menu and everything). I looked up the list of AT commands and have a clear idea of how its gonna work. But the guide used something called an RS-232 converter. Which might be connected to what your saying above. Can I program the arduino to write the characters to the recieve pins of the BT module?

"but because they would be sharing the same interrupts and underlying communications buffer and they would interfere between themselves"

I don't understand this at all.

I appreciate the help btw. Normally, I'd have tested all this stuff out myself and played around with it but since its the weekend, I haven't access to my school's computer lab's equipment. So I just want to be well prepared for Monday.

#7

Technically, the Arduino<->bt-module (UART) and the bt<->bt (wireless) baud rates could be different, but this would result in malfunctions due to overflow: a continuous dataflow of, say, 115200 bits per second coming through the wireless interface could not be retransmitted to the Arduino over a 9600 baud UART interface, even if there were some buffering mechanism in between, and you would experience data loss. So I expect that setting the baud rate on the UART interface automatically changes the baud rate on the wireless interface, though I cannot tell for sure.

What I call “command mode” is a state of the module where you can send AT commands to the module through the UART interface. These commands are not retransmitted to the wireless interface. As far as I understand, this is the only way to change the baud rate on the module (the SoftwareSerial.begin(baudrate) in the Arduino sketch only sets the speed of the SoftwareSerial interface, on the Arduino side of the link). The AT+BAUD8 command sets the baud rate to 115200 on the UART, and should be followed by a new SoftwareSerial.begin(115200). This change should be persistent (preserved after reset).

In order to enter command mode a pin of the module should be set to high (connected to 3.3V) before power up. There may be a way to do that in software, but I think the sketch you used to set the baud rate just failed to change anything, and the module is still working at the default 9600. Did you try SoftwareSerial.begin(9600)? It should test my supposition pretty quickly.

Finally, do not connect the module to the PC Usb because the voltage coming out of the PC is higher than the 3.3 V used by the module, both for power and signal (tx/rx). The same applies to the RS-232 adapter. I think however that you can try this:

  1. Load a simple sketch (such as blink) that does not use Serial (no Serial.open(), print(), read()). This may even be overkill given what follows, but doesn’t hurt.
  2. While the Arduino is disconnected from Usb, connect Arduino RX - BT TXD, Ard TX - BT RXD, Ard 3V3 - BT VCC, Ard GND - BT GND.
  3. Connect the Arduino and press the RESET button (of the Arduino). Keep it pressed until the end of the test.
  4. Open putty and try connecting to the serial port of the Arduino. See if you get something from the BT module.

The principle is the same used for the loopback test: do not let the Arduino take control of the UART (com interface). After that you may also try releasing the RESET button and see what happens. Perhaps, not using Serial, the sketch will just ignore what happens to the com interface.

Last point is an explanation of my phrase about buffers and interrupts: the hardware serial interface (UART) relies on interrupts to see if there are bytes to send or read. Interrupts are small routines that run independently from the main sketch and are activated by the processor itself when some event occurs. For example, if there is incoming transmission on the serial line the UART will notify the processor of the presence of data (in the UART buffer), and the processor will activate an interrupt service routine to read it. Once read, the character will be moved to the Serial input buffer (a memory location) and removed from the UART buffer. Finally, when the sketch executes Serial.read() (or something similar) the character is removed from the Serial input buffer and passed to the sketch. If you have two processes sharing the same serial line they will use the same UART, and interrupts, and buffers, but only the first one of them will be able to get the character using Serial.read(). Actually it’s a bit more complicated than that, but I hope it’s more understandable.

[edit] I failed to notice that the module lists a VCC range of 3.6V–6V, so you should use the 5V of the Uno (you already use it, I guess), and the idea of dissecting a Usb cable may work. Sorry, there are variants based on the same chip and I happen to own one using 3.3V.

#8

Spatula,

You have my thanks. I really really really appreciated it.

And thank you too Nick.

:)

#9