Archive for June, 2011

Today I am going to post an article that I’m sure will be interesting and curious to many, especially those of you who are regularly working with GSM devices. Last Thursday, I finally brought a little gadget home that I had bought just a few weeks ago. Nobody has anything bad to say about it, so I wanted to be able to test and compare its ability to Cinterion modems as until now it had not been possible to test it and I had to believe in Jamming detection.

I have based my tests on the official Cinterion application note called “AN_45_Jamming_Detection.pdf”. Here you have all of the documentation on that subject, I2m going to focus on the practical part. As for the modem, I have used a Matrix MTX65i that has a TC65i inside, however I could have used another MTX or Cinterion model and it would have made no difference.

Well yes ok. But what is Jamming detection?

Well to put it simply it is the modem’s ability to detect an intentional interference in communication channels that block them.

You might think that it doesn’t matter and certainly in the vast majority of GSM application this is true, but in safety-related applications (alarms etc.), it’s quite important (or it should be).

Let’s take an example. A house or a car has a typical GSM alarm. If the alarm goes off it must communicate this to a central office of GSM alarm receivers. But, what happens if some thugs use a GSM inhibitor? Could the GSM alarm communicate with the central office? Will the alarm at least be capable to detect interference with a GSM inhibitor and act accordingly?

Obviously, no device (no mobile, GSM/3G module etc.) would be capable of making a GSM communication with a powerful enough GSM inhibitor present. But yes, some devices have (al least) the ability to detect interference from a GSM inhibitor: Cinterion modules. This ability allows them to act accordingly. This means to say that if a device suspects that there is interference, it can try to communicate while the interference is still weak (it can pre-activate warning sound etc.). In short, it’s always best for an alarm device to know what’s happening than to not know, how it acts in these situations will depend on the ability and imagination of whoever developed the alarm.

How to operate Jamming Detection in Cinterion modules:

As I said before, all of the documentation is in Cinterion’s applications 45 note. Basically and quickly summarized, it describes the activation of the communication link’s stability indicator “Ista”, for example with:

AT^SIND=”lsta”,1,5

And to activate URCs with:

AT+CMER=2,,,2

As soon as we activate jamming (interference), we will see how the modem is going to indicate the situation through URCs (sending messages through your serial port). First of all it will send messages like this:

+CIEV: “lsta”, , ,

This indicates that there are errors in the communication link. “lstaEdv” (which is a countdown timer) which will quickly decrease to “0″. Hmm… the suspicion begins…

After this URC, the modem will return another type of message:

+CIEV: “lsta”, , , , , ,

This URC already indicates network coverage loss. According to Cinterion documentation, when you get a URC with “IstaNo” = 40, a low “Istavar” (lower than 10) and “IstaMean” > 40, this is a clear indication of jamming.

As everyone always understands better with pictures, here you have a video which is even better. (If you have received the article via email you will probably have to watch it on (www.blogelectronica.com).

jamming-detection

I hope that you found it interesting. Bye  ;)

 

 

Tags:

Comments No Comments »

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 »