Archive for the “Bluetooth” Category

Today we will see how to make a simple Bluetooth hands-free. In this article I won’t into the audio part, I will focus on the display part of the device i.e. when we engage in a call on our mobile, we can show the caller’s number on an external display which is connected via Bluetooth to the mobile. If we the telephone number is associated with someone in our contacts list in our mobile phone, it also shows us the name of this person.

To do this we need to use a Bluegiga Bluetooth module that has iWrap v4 firmware which makes life a lot easier by running the application quickly and effectively.  Truthfully for what I am going to do we could use any of the WT12, WT11WT41 or WT32 modules. Even if you later want audio, it will work with any of these modules. I would choose the WT32 which is based on CSR‘s BlueCore5 as it is more suitable for multimedia applications (audio stereo).

So let’s assume that our “Bluetooth incoming call indicator” mainly relies on a single microphone (with 2 UARTs), a display and a Bluegiga WT12 Bluetooth module. Both the display and the WT12 have to be connected to the micro via a UART.

bluetooth-manos-libres

 

WT12 Configuration

The first thing to do is configure the WT12 Bluetooth module from our microphone. To do this we send the following commands to the Bluegiga module from the micro’s UART:

SET PROFILE HFP ON
SET PROFILE PBAP ON
RESET

With this we activate the Bluetooth HFP (Hands Free Profile) and the PBAP (Phone Book Access Profile– in order to control the contacts list) in the WT12 module. You only need to do this once, once it’s done it stays in the WT12’s non-volatile memory.

Bluetooth Association/ Connection 

Now we are going to connect the Bluetooth module with our mobile phone. Normally you would get your mobile phone and search for the WT12 module in the Bluetooth section and press “connect”. I’ve tried it and this works but I would like to do the reverse, I would like to select my mobile phone in my Bluetooth display and make a connection from the Bluetooth display to my mobile phone.

In order to do this, the following command is sent from the micro to the WT12 module:

INQUIRY 10 NAME
With this, the WT12 will search for nearby Bluetooth devices for 10 seconds and it will return a list of found devices to the MICRO, including the friendly name of each device if it has one. As soon as it is completed the micro will receive a response like this:
INQUIRY_PARTIAL 78:47:1d:ab:78:e1 5a020c
INQUIRY_PARTIAL 00:02:c7:f8:60:e3 1300404
INQUIRY_PARTIAL f4:0b:93:0b:5f:cc 7a020c
INQUIRY 3
INQUIRY 78:47:1d:ab:78:e1 5a020c
INQUIRY 00:02:c7:f8:60:e3 300404
INQUIRY f4:0b:93:0b:5f:cc 7a020c
NAME 78:47:1d:ab:78:e1 “josegg”

As for me, my mobile phone has  MAC 78:47:1d:ab:78:e1 and it has the name ”josegg” associated with it. At this point, the display that is connected to the micro would show us a list of names that it has found so that the user could select the one that corresponds with their mobile phone. As soon as it is selected, the micro can save it onto its flash memory. Now that our micro already has MAC Bluetooth from our mobile phone, it can connect to it. In fact whenever we turn on the display we can do this periodically so that our mobile will connect to it whenever we are near to the Bluetooth display.

You should send the following command to the WT12 Bluetooth module so that the micro can connect to the mobile via Bluetooth:

CALL 78:47:1d:ab:78:e1 111F HFP

This way the WT12 will connect to the mobile phone using the hands-free profile. I assumed that we would configure the same PIN number in the mobile phone and the WT12 module (with the command: SET BT AUTH *). If the connection is successful the micro will receive a response from the WT12 like this:

CALL 1

CONNECT 1 HFP 2
HFP 1 BSRF 103
HFP 1 STATUS “service” 1
HFP 1 STATUS “call” 0
HFP 1 STATUS “callsetup” 0
HFP 1 STATUS “callheld” 0
HFP 1 STATUS “signal” 4
HFP 1 STATUS “roam” 0
HFP 1 STATUS “battchg” 2
HFP 1 READY
HFP 1 NETWORK “YOIGO”
In this instance our “Bluetooth display” is already working with hands-free from our mobile phone. For example if we receive an incoming call, the WT12 will send the following data to the micro:

HFP 0 RING
HFP 0 CALLERID “681319891″ “” 81
HFP 0 RING
HFP 0 CALLERID “681319891″ “” 81

Obviously we need to program our micro so that when we receive a caller ID from the WT12 via the UART, it picks up the phone and shows it on the display, simple as that. At this point we have a Bluetooth call indicator implemented.

Very good, but you said that the display would show the caller’s name if it was in the contacts list. Will it be displayed after doing what we have done? 

No, if you want to show data from the mobile’s contact list you have to establish another Bluetooth connection, using the PBAP profile. This will allow you to obtain data from the mobile’s contact list. To do this, similar to what we did with the HFP profile, we need to send the following command from the micro to the WT12 Bluetooth module:

CALL 78:47:1d:ab:78:e1 112F PBAP
Once the PBAP connection is established, we can get data from the contacts list by using the PBAP command. For example to get all of your contacts from the list (name, telephone etc.), we would send this command:
PBAP 00 FFFF 1

I recommend reading about the PBAP command in iWrap’s manual because there are a lot of combinations. In the previous case, it didn’t send a series of XML with the data from the contacts list. Using this data, when there is an incoming call and we have the telephone number, we can search for the name associated with this number and display it. As you can see it’s a very simple application to run with Bluegiga modules that have iWrap.

 Applications?

The applications are obvious. After adding audio (managing a few more iWrap commands that we can look at another day) we will have a complete Bluetooth hands-free that we can use with any application. As for me for example, from time to time I go out with the dune buggy and I can’t hear anything over the engine. My girl tells me off all the time for not answering my mobile (because I can’t physically hear it). With an indicator like this in the dashboard I would be able to see incoming calls. Also when I’m riding the buggy you can locate me easily… Hmm, although thinking about it a bit more… maybe not! :)

I’ll be back with more another day!

 

 

Tags:

Comments 2 Comments »

For those who are looking for new development ideas to ride out these difficult times here I come with something interesting. Today I am going to talk a little bit about something that you probably haven’t heard of: Bluetooth Low Energy.

We all know what Bluetooth is I would dare to say that all of you have used it as it comes with any mobile phone with a medium-low frequency range. You already know that we can create data connections (like using the SPP profile), audio connections and much more with Bluetooth. But with regards to consumption, Bluetooth has always been limited and this also limits certain applications. Lots of people turn Bluetooth off on their mobiles if they aren’t using it as it drains the battery quickly. You can imagine that it’s not feasible Bluetooth connectivity modules with battery powered devices.

So recently a new standard has appeared called BLE (Bluetooth Low Energy). This new Bluetooth (which from my point of view only has the name and nothing else) is designed for low power applications, which is suggested by its name. To date no mobiles have this technology but in coming months we will see if new mobiles with Bluetooth Low Energy technology are going to appear.

But will a Bluetooth Low Energy device be compatible with a standard Bluetooth device?
Well, no. What happens is the telephones will be dual. They will set up a standard Bluetooth module as usual but with a Bluetooth Low Energy module. The standard Bluetooth can be turned off like in any terminal but the Bluetooth Low Energy cannot. ;)

bluetooth-low-energy

Bluetooth Low Energy is designed to efficiently transmit small quantities of information at low speeds. If we compare the consumptions of the standard Bluetooth and Bluetooth Low Energy, we see that it’s 15 times more efficient. In order to achieve this efficiency, 3 basic concepts of how it works have been optimized:

1.-Connection modes and discovery

With a standard Bluetooth module, a device that wants to receive a connection or is in visible mode should enable its receiver for long periods of time so that it’s awake and waiting to receive a packet if someone wants to communicate with it. This means there is at least 22ms of activity, so 32 different frequencies should be scanned and it should take a significant amount of time checking each one before moving onto another.

On the other hand, with Bluetooth Low Energy, when a device wants to receive a connection it only needs to send 3 small packets (on broadcast) and then it will quickly receive a connection or data if there is another device that wants to communicate with it. It only takes 1.4ms, about 17 times less than with normal Bluetooth.

Furthermore, you can include application data in these broadcast packets. This is very important because it means that with Bluetooth Low Energy we will be able to use broadcast in our applications without establishing a connection. You can imagine the amount of applications (door opening applications by proximity etc.)

2.- The number of packets transmitted during the connection.

With Bluetooth Low Energy, when you want to establish a connection all of the connection information is contained in a packet which is transmitted from the master to the slave. This information includes the FHSS map and other settings. This means that no additional negotiations are needed in order to begin sending useful data once the link has been established, which means less time which in turn means less consumption.

Also, when communicating between two devices with traditional Bluetooth, you lose time with packet synchronization and lag time, even though neither of the devices have anything to transmit. With Bluetooth Low Energy, the data packets have 1 bit of “more data” that indicates whether the sending device has packets to send or not and therefore if you need to keep your device “talking” or not.

Another very important feature is ACK packets. You send an ACK (a package without data, just to show that a packet has been received successfully) with normal Bluetooth for each packet sent. With Bluetooth Low Energy empty ACK data packets are only sent when it is really necessary. That way you don’t unnecessarily waste time and energy.

3.- The size of each packet.

The size of the data packet’s headers has decreased. The size of a standard Bluetooth header was made so that it could be sent in 210 us whereas with Bluetooth Low Energy is sent in 112 us (nearly half).

I’m interested, how can I work with a Bluetooth Low Energy module?

Well Bluegiga (distributed in Spain by Matrix) has just brought some Bluetooth Low Energy modules onto the market, specifically the BLE112 and BLED112 models.
Here’s a datasheet for you to look at. I will talk about them more thoroughly when my development kit arrives. As they are so new I still haven’t had the chance to have a SDK and play with them, hopefully I will soon.

I will only talk about the most important thing. Unlike other types of Bluegiga modules, these no longer use an internal CSR chip. They use a Texas Instruments chip, specifically the cc2540. Furthermore the module has an 8051-based processor (with 8Kb of RAM and 128Kb of FLASH) to embed user applications, so you don’t need to use it if you don’t want an external micro. It has 2 UART ports or SPI that we can connect directly to sensors, screens, digital and analog inputs/outputs, watchdog timer, hw AES128 encryption etc.  It’s a low-cost and complete module. As I said, I will talk about these modules when I have an SDK and have done a reliable test.

 

Tags:

Comments 5 Comments »

Good afternoon. A few days ago I posted about a new Multitech device which I was testing that turned out to be very interesting. Today I’m going to continue talking a little bit about Multitech which is perhaps not a very well-known company, but it has always seemed interesting to me especially for a specific application profile.

It’s a family of products with an architecture that Multitech call “Universal Socket”. In short, as the name suggests it’s about a family of communication modules that all have the pin-out in common i.e. if we create a device with PCB designed for use with one of these “Universal Socket” modules, we can interchangeably “click-in” any of these modules.

What types of modules are in this family?

Well there are a total of 10 modules. On one side we have GSM/GPRS/HSDPA communication modules such as SocketModem iCellSocketModem CellSocketModem HSDPA (note is has a Cinterion HC25),  SocketModem EDGE and SocketModem GPRS.

multitech

On the other side we have analog communication modems like SocketModem and SocketModemIP.

Finally we have modules that are suitable for other types of communication like SocketEthernet IP (a module which is basically as Serie/Ethernet convertor), SocketWireless Bluetooth (A Bluetooth -serial module i.e. with SPP Bluetooth profile, class 1 (100m range) and  socketWireless Wifi (a wifi-serial gateway for 802.11b/g networks).

So if I design a device for one of these modules, if one day I want to equip my device with GPRS connectivity, Bluetooth, Ethernet or Wi-Fi etc. for a project, would I only have to swap one module for another?

Yes that’s it.

But would I have to make a lot of software changes?

No. The modules have a common serial communication and configuration interface. All multisocket devices are configured through AT commands and some of them (those that provide IP connectivity) have what they call “Universal IP” in Multitech, a common TCP/IP stack i.e. you only need to create a single host software to control each of the modules, whether it’s a GPRS module, HSDPA, Wi-Fi, Ethernet etc.

Very interesting, the best thing I can do from now on is design my devices with one of these modules.

No. Look at the photo of the “Multisocket HSDPA” module in this post, as I said before is put together with a HC25 Cinterion module. What would be cheaper to use, the Multitech module or just the HC25 module? Well obviously it’s cheaper to just use the HC25 module. The same thing happens with “SocketWireless Bluetooth”, it’s cheaper to use a Bluegiga WT11 module than one of these modules. This means that it will depend on the connectivity features that you need for a particular application.

 So when do you recommend to use this type of module?

From my point of view, and as I said from the beginning, they are very interesting but only designed for devices when we want to provide various connectivity possibilities without needing to redesign hardware and with minimal or no software changes (which really saves time designing and improves “time to market”).

 I hope that you find these modules interesting for an application. Until next time. 

 

 

Tags: , , , , ,

Comments 1 Comment »

Today I had already started writing an article but then I changed my mind as I preferred to make a short video presentation on the new GPRS terminal that I’m sure will be interesting to more than one of you, in a while it’s going to be very well known.

It’s about the new Matrix terminal, the MTX-IND model, which is a terminal based on the powerful TC65i Cinterion module. I’m sure all of you know this GPRS module that allows you to embed Java applications and is based on an ARM9 like I told you a few months ago.

You’ll see it in the video that I made, but to whet you appetite I’ll tell you in advance that it’s a DIN rail GPRS modem, Java programmable, with 2 RS232/RS485/RS422 serial ports, relay outputs, opto-isolated digital inputs/outputs, ADC converters (0-2.4V / 4-20mA), USB and something even MORE interesting (which isn’t available yet) that you can only see in the video. ;)

Well then, here you have the video, I hope that you like it.

www.blogElectronica.com

Comments 10 Comments »

I have wanted to write a post about this for quite a while in case somebody would find it useful. It’s about providing Bluetooth connectivity to our Siemens TC65 or MTX65 modems. To do this, by way of example I will describe how to make a Bluetooth-GPRS gateway. At first glance, this type of gateway may not seem useful but as I say by way of example I will give you some ideas. Maybe it makes sense in other applications. For example let’s imagine a project where we want to have Bluetooth connectivity with a machine controlled by an MTX65 that has an embedded Java program. For example with Bluetooth a person who has a PDA can maintain it without having to connect any cables or open any machine.

I’m going to go through it very quickly, let me know if you have any questions as I’m just going to describe how to make the application without going into too many details.

To do this I am going to use an MTX65 modem with the MTXTunnel application embedded inside and a Bluegiga WT11 Bluetooth module that I will use with its development board (the MTX65, the MTXTunnel firmware and the WT11 are all distributed by Matrix in Spain). The reason for using the WT11’s development board is because it has an RS232 port and it’s very easy to connect it to an MTX65 simply with a serial cable. Remember that the WT11 Bluetooth module is in class 1 and therefore theoretically we will have a range of about 100m. If we want a smaller range we can choose the WT12 which is a class 2 Bluetooth module that theoretically has a range of about 20m.

gateway bluetooth gprs

On the other hand I will use my amazing Fujitsu-Siemens T830 mobile with Windows Mobile :) I installed the mobile version of this onto my mobile from the well known puTTY terminal (a small program similar to a HyperTerminal).

The SPP (Serial Port Profile) must be enabled in the Bluetooth module’s configuration. All you have to do to check this is find out the SET command response which is sent to the WT11 from a PC with a HyperTerminal connected. This command shows the current settings.

If you have already enabled the SPP in the WT11 Bluetooth module and you have already configured the MTXTunnel configuration parameters (the client mode, the IP and the port the server will connect to), we can connect the WT11 Bluetooth module to MTXTunnel (through the RS232 connector in the development kit) and supply power to both. By doing this MTXTunnel will automatically connect to the IP address and the specified ports via GPRS. The WT11 will keep waiting to receive an incoming Bluetooth connection.

Now touch the phone. First, install puTTY. Once this is installed we have to pair the phone up with the WT11 via Bluetooth. With the telephone’s Bluetooth connection manager, you can find out the WT11’s Bluetooth services in which you should see the SPP (Serial Port Profile). After this is done, we will link this serial port to one of the phone’s virtual COMs.

Terminal pocketPutty

Now launch the puTTY application and open the COM that is associated to the SPP profile that we linked up earlier. When you are opening the COM with the puTTY, what you are really doing is connecting to the WT12 via Bluetooth. Once the COM is open (i.e. the Bluetooth connection is established), everything that is sent through the terminal (puTTY) from the phone to the WT12 is via Bluetooth. The WT12 then sends it through the (development board’s) serial port to the MTX65 (remember that both are linked by a serial cable). Then the MTX65 sends it to the IP address and the previously specified port via GPRS i.e. we have a Bluetooth-GPRS gateway.

I hope that this has been interesting for some of you, as you can see incorporating Bluetooth connectivity into Bluegiga modules or Siemens/Cinterion modems is really simple. See you next time. ;)  

Tags: , , ,

Comments No Comments »