I am going to test the connection of a serial Bluetooth module to my Mac laptop. Serial data will be provided to the module through a Teensy 2 used as a USB-to-Serial adapter.
Soldering the module on a breakout board
The difficulty is to correctly align all the module pins to the breakout pads. The module is so light that it can moves just because of the solder surface tension.
Two rows of header are added to fit in a prototyping breadboard.
Teensy 2 USB-to-Serial profile
I use the USBtoSerial project from LUFA 101122.
I already covered how to compile this project for the original Teensy in this previous post (Testing the LUFA USB Serial with GPS data). I apply the following modifications to the makefile:
MCU = atmega32u4
F_CPU = 16000000
Here is the binary: Teensy2-USBtoSerial.hex
To connect to the virtual serial port on a Mac:
$> sudo cu –s 9600 –l /dev/cu.usbmodemXXXX
A quick loopback test (direct wire from TX to RX) confirms that the profile is correctly working.
Useful to exit cu: ~.
Connections between the Teensy 2 and the BT module
The TX pin of the BT module is connected to the RX pin of the Teensy 2, and the RX pin on the TX pin.
My Teensy 2 board has been patched with a 3.3V regulator (see Converting the Teensy2 to 3.3V). I will use it to power the BT module.
The TX pin of the BT module is connected to the RX pin of the Teensy, and the RX pin on the TX pin.
Two leds are connected on PIO8 and PIO9 to display the status of the BT link.
The PIO11 pin is used to select the boot mode:
- High => Command/Response mode where you can issue AT command to setup the module.
- Low => Slave or master automatic operation.
I connect the PIO11 pin to the 3.3V rail. In this mode, the baud rate is 38400.
I open a cu session in the terminal and communicate with the BT module over its serial interface:
$>sudo cu –s 38400 –l /dev/cu.usbmodemXXXX
The module sends the OK response repeatedly. Sending Ctrl-C can stop it. Then you can enter another commands.
We can see that the module is currently configured for 9600 bauds operations with 1 stop bit, no parity.
I speedup the baudrate to 115200 bauds.
I also change the role to slave-loop. In this mode, the module sends back all data it receives over the BT link. It is useful to check that the module can correctly receive and send data over the BT link before connecting it to your system.
Now I power up the module with the PIO11 connected to GND to boot in autoconnect mode.
Pairing with a Mac
The connection of Bluetooth devices is handled by the System Preferences/Bluetooth panel.
The connection fails because the default passkey of the module is 1234. It can be changed with the AT+PSWD command.
The module is now successfully paired with the Mac but currently not connected.
It is recognized as a virtual serial port and corresponding devices are automatically created in the /dev directory:
$> ls /dev/*HC*
I can now connect to the BT device and use it as a classic serial interface. In slave-loop mode, the characters are echoed back to the terminal.
$> sudo cu –s 115200 –l /dev/cu.HC-05-DevB
The status of the bluetooth connection is reflected in the System Preferences panel.
I switch to the command/response mode and change back the role to slave:
In this mode, the BT module acts as a full duplex serial interface. The data received over the BT link are forwarded to the its TX pin, while the RX pin incoming data are sent over the BT link.
So to test the connection I open two cu sessions. One is connected to the BT module, the other one to the Teensy 2 serial emulation. As the 2 devices serial pins are connected together, I am able to send characters on one session and receive them on the other sessions.
The first window displays the connection to the Teensy 2. The second window displays the connection to the BT module.