Bluetooth Module (Re-)Investigation
Some five years ago I bought a nice UART-over-Bluetooth adapter module. The module emulates a serial port (UART) over a Bluetooth connection. All necessary chips and an antenna are mounted on a small PCB board depicted below.
The type I’ve got is the cB-OEMSPA310i-04 with an internal antenna. The module requires only a 3.3V power.
Communication with the module is over serial UART at 3.3V logic levels. The basic RXD/TXD signal pair is complemented with hardware flow control via RTS/CTS, and an optional BT connection status via DSR/DTR. A three-colour LED (red, blue, green) can be directly connected to dedicated pins on the module to visually indicate the state of module to the user.
The BT module is controlled by standard AT commands. When powered up or after a reset the module is in a data mode with no connection over BT. Local application microcontroller connected to the RXD/TXD/RTS/CTS signals first sends an escape sequence, which normally consists of three forward slashes ‘///’. This puts the module into the AT mode. In AT mode the strings sent over the local UART are interpreted as commands, while in data mode all data is passed through to bluetooth and over the air.
The basic AT-mode command is a simple ‘AT’ followed by a carriage-return character
at*agln="PIP-Watch",0
The BT module responds by ‘OK’. We set the PIN code:
at*agfp="1234",0
Then we scan for other nearby bluetooth transmitters by issuing the command:
at*agdd=2,8
The scanning will take about 8 seconds. After that the module will respond by:
*AGDD:1
which means that just one other bluetooth active transmitter was found; and it will list them by sending a line for each one of them:
*AGDDE:00242cbcad3f,4858124,1,"altair.local-0"
where “altair.local-0” is the computer name, and 00242cbcad3f is an ID code. If the local microcontroller wishes to connect to one of the devices it issues the command:
at*adcp=00242cbcad3f,0,1,0
The BT module responds
*ADCP:0
OK
if connection has been established. Finally, we exit the AT-mode by the command:
at*addm
From this point on all data written to the UART will be sent over the air to the other device. The commands shown above are also listed in this spreadsheet.
On Monday I experimented with my bluetooth module. I used a USB-to-UART converter with a picocom software running on a PC to simulate the local microcontroller (picocom /dev/ttyUSB0 -b57600 -fh), and a USB Bluetooth dongle in another USB port in the PC to serve as the other BT device to test the connection.
The USB-BT dongle in the PC must be set-up to accept or initiate any BT connections. In Linux this requires roughly the following commands (actual ID numbers will vary):
$ hciconfig hci0 up
$ hciconfig hci0 piscan
$ hcitool scan
00:12:F3:09:84:5C PIP-Watch
$ hcitool cc 00:12:F3:09:84:5C
$ hcitool auth 00:12:F3:09:84:5C
Not connected
$ rfcomm listen 00:12:F3:09:84:5C
Waiting for connection on channel 1
The rfcomm command creates a new serial port device in Linux called /dev/rfcomm0. You can use any terminal emulator program like minicom or picocom to connect to it. This establishes the other BT endpoint through which data may flow over the air.
Because the PIP-Watch will be powered from a battery, we are interested in the power consumption of the BT module. The module draws around 6mA in idle (unconnected) state, and about 14mA when bluetooth connection is established. This is consistent with manufacturer’s information in datasheet. The power consumption is quite high. The module is more than 5 years old and it supports only Bluetooth v.2.0. The new Bluetooth v.4.0 standard supports a so-called ‘Low-Energy’ profile that lowers power consumption of devices in standby mode by orders of magnitude.
Quite interestingly, according to wikipedia, the low-energy profile in BT4.0 is in fact an entirely new communication protocol that has nothing to do with the original Bluetooth! It shares the same frequency range with classic BT and it has similar encoding, but it was developed by an independent group and originally had no relation to Bluetooth. Only later it was adopted by the Bluetooth consortia and integrated into BT4.0 as the new ’low-energy’ mode. But for now I will use this BT module that I have, even as I am not quite content with its energy consumption. An upgrade to BT4.0-capable module should not be difficult at any future time. Anyway, at this time I don’t have any other BT4.0-capable device or dongle to use as the test partner.