Let's Make Robots!

Cheap bluetooth module for an Arduino

Gives a robot bluetooth capability

Some time ago I ordered a cheap bluetooth module on ebay for my Arduino. I went for a no-name module, when I say cheap I mean it. (well after all it were only a few dollars cheaper than the branded ones)

Anyway, module arrived and I tried to communicate with an internal command processor, which I expected to be there. Hooked up serial lines to the TX(1) and RX(2) pins on the module, 3.3V VCC(12) and GND(13). Nothing happened, no response to AT commands. I read multiple web pages, all describing how it should be done. I think I tried all possibilities. Many people mention that I should pull high pin 34 or 26 to actually enable the command processor.All this were tried and much more too. Nothing, no response to my attempts.

On the other hand, I could see the module on the bluetooth "ether", both on my primary linux box and on an old XP box, so some sort of life were detected. From the web I have learned that the pin code most likely would one of 0000, 1234 or 12345.

Well, after some time I gave up, and cried my failed attempts on the shoutbox. Birdmun asked why I were so eager on speaking to the command processor, well I thought that changing the pin or something would be necessary. Next day aaronsuper1 gave me yet another link (http://arduino-projects.co.uk/tutorials/connect-arduino-android-phone-bluetooth/ which now redirects to http://www.therobotlab.co.uk/2011/arduinoandandroid/) to people using their androids to control an Arduino. Somehow that link were a little better which helped me!

All my struggle to get the command processor speaking where waste of time. I simply skipped that part. Used the XP to wake up the module and pair my USB-bluetooth dongle with the module. 1234 were the correct pin code in the case of this particular module. When the initial pairing were done I moved back to linux where I'm more comfortable.

Right now I have a test setup consisting of the following chain

  1. linux system
  2. terminal program (minicom, putty or something like that)
  3. usb->rs232 converter, showed up as /dev/ttyUSB2 on my system
  4. rs232->logic converter (home made, http://letsmakerobots.com/node/29207)
  5. bluetooth module
  6. air with radio waves. "the ether"
  7. bluetooth->usb dongle
  8. terminal program (connect to /dev/rfcomm4)
  9. linux (actually the same machine as in step 1)

The linux is an older ubuntu box, 10.4 I think. It should not be that important.

Since the terminal program in step 2 is using a real serial communication link, baud rate is important. I figured out that my module is operating at 38400 bits per second. This finding were made by trial and error, and when that failed, I fired up my good old oscilloscope were the bit rate were easily visible)

To get step 7 and 8 working I had to prepare the bluetooth system on the linux a little:

  1. Scan the "ether" for bluetooth devices type: hcitool scan. returned a address and a name
  2. Bind address to a linux device (I picked number 4): sudo rfcomm bind rfcomm4 00:19:5D:24:B7:63

The last one does not make an actual connection between the two bluetooth devices but only prepares them. When a program opens the device file the actual connection gets established.

Now type something and watch it show up in the other window, transmitted via bluetooth.

As seen on the picture, there is a 5'th wire (pin 31) going out from the module. It's a status line, able to drive a LED. If LED is flashing there is no connection. When it is steady on there is a bluetooth connection established.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hmmm... New problem... I used the info around to change the baud rate on this adapter. It worked fine. I know it worked because I had to change the baudrate on the terminal program in order to keep working with it.

However, it seems to forget the setting when I remove power! Is this normal? If I want to work at a different baud rate, must I tell it at every powerup? Anyone know of a command to cause it to remember the current settings?

 

Oh, wait aminute. Cacnel that. It seems to be just this one device not remembering its settings. The other one has remembered. That's irksome. Oddly, AT+VERSION reports that the module is v1.5, but the screen print on the PCB says version 1.05. Maybe the command just reports the firmware version.

Hi.

After several days searching for a spec sheet for the device, you guys have the best information, without a doubt!

I have several a Microchip PIC based devices which use RS-232 comms. SO, I have teh PIC hooked to a MAX232 into my PC serial port. I've read that the inputs to thes BT devices are "inverted." This might be OKay, but I have difficulty with finding a definition of "inverted." Many projects appear to "bit-bang" the serial comms out in softare, but those using the PIC USART will already output inverted 1's and 0's such that when connected to teh MAX232, it inverts them to be the "correct" way around.

The question is this: assuming I'm using the PIC USART, can I simply remove the MAX232 and put the BT adapter in its place? I figure I should probably use a potential divider to pot down the PIC Tx line, but the PIC at 5V will happily tolerate the 3.3V Tx line fromthe BT adapter.

It can be a bit confusing to get all the polarities and levels right when doing serial communication on a hardware level.

RS232, the signal you find on old DB9 and DB25 connectors is +/-12 volt positive (somewhere between +3 and +12 volts) is a logic LOW. Negative (between -3 and -12 volts) is a logic HIGH. Clearly inverted.

Most of our microcontrollers operate directly on logic compatible signals where LOW is close to 0v and HIGH is 3.3v of 5v depending on the uC.

If you are measuring the signals with a voltmeter (most likely a multimeter) when there is no communication going on you will see a logic HIGH. This is because the RS232 defines that all transmitted bytes must start with a start-bit, which is defined as a LOW bit which will only be detectable if the condition before that is the opposite.

Some PIC uC's have a register that can be used to invert the signal level, I'm not a PIC guy my self but google found this:

  • There are two bits in the BAUDCON register that control the polarity of the TX and RX. 

If you need a level shifter between 3.3v logic and 5v logic the 2N7000 mosfet circuit I show over here is a super slick way of doing it: http://letsmakerobots.com/node/30915

If you need a conversion between RS232 and logic levels I have made one here: http://letsmakerobots.com/node/29207

Of cause there are pre-cooked chips out there that can do it all for you, but sometimes it's more fun to build stuff than to wait for the slow boat from China.

Indeed. I suppose the question should have been: since the UART is operating at TTL (HIGH=1) on the PIC, may I connect the UART directly to the el-cheapo BT, or do I need to invert? I'm familiar with serial comms, but unfamiliar with the el-cheapo BT. I know I need a level shifter. Do I need an invering one?

Thanks for getting back so quick.

Working on changing the baud rate and ID now.

Excellent! As I thought, all I did was remove my MAX232, pot down the PIC Tx line to 3.3V and plug in the BT module instead. Bingo! BT interface for any PIC project at half teh price of a serial port. The PIC will happily tolerate teh 3.3V Rx line from the module.

Hmmm... I'm gessing I don't. If I'd thought it through, since the BT module talks 3.3V level, cahnces are it's logic 1 = high, too.

I did not invert the signals here: http://letsmakerobots.com/node/30915

But it really depends on the specific uC and how you have configured it.

Will 10 of these be controlable from a computer (with a USB Bluetooth stick) at the same time? I mean the computer should send commands and the modules should listen to the messages addressed to their own ID. The comuter is the Master, the modules are the Slaves, Master can communicate and get response from the Slaves, the Slaves can communicate only with the Master by request. I know this works with xBees, but does it work with Bluetooth modules?