Archive for the “2.DISPOSITIVOS (práctico)” Category

Descripción de dispositivos electrónicos de última generación para que puedas probar la parte teórica.

The following is a useful example of how to easily read RTU Modbus devices via GPRS. There are two ways to complete this task using the GPRS modem MTX65i + MTXTunnel.

The first and classic way is to use the MTX65i + MTXTunnel as a GPRS-serial gateway. This means that when you try to get a reading from a Modbus device, the server connects to the MTX modem’s IP and sends Modbus frames directly to the computer. The frames are read through the MTX modem which acts as a GPRS-serial gateway.

The second way, that I will discuss today, is more suitable when large quantities of computers are involved. Basically, a new feature from the new version of the MTXTunnel v7.14 is used. This new function allows the autonomous reading of Modbus devices connected to your serial port and it also forwards these readings on to the Web Server via JSON object.


This is the scenario:

  • We have a PLC Modbus RTU. The PLC has a number of readings/records in its internal memory (e.g. a temperature and three meters) which must be periodically read and sent to a Web Server.
  • Every 15 minutes, the MTXTunnel must obtain these readings from the PLC and it does this via the serial port. Record number 20 is the temperature reading while records 21, 22 and 23 are the respective meters.
  • After taking each reading, the MTXTunnel needs to send the values to a Web Server via HTTP GET using a JSON object. However in case there is a GPRS communication failure, it has to be able to store up to 1500 readings in its flash memory so that it can send them as soon as communication is restored.
  • You need to be able to access the MTXTunnel at any time in order to be able to read real-time PLC records as well as being able to write in them and modify PLC configuration records. To resolve this, set the MTXTunnel up like this:


Some details from this example to take into account:

  1. This example uses an MTX65i with Modbus RS232 PLC communication, but it could work with an RS485 as well. Therefore you could use the MTX65IND2 model (with built-in RS485 communication).
  2. The following is a summary of this example:
    The modem periodically reads (every 15 minutes) a series of Modbus readings from the PLC and sends them via JSON object to a Web server (to the URL specified in the LOGGER_server parameter). If you can’t send the reading (due to no GPRS network coverage or if the server is down), it stores the data to memory in order to send it later. With Telnet it’s possible to connect to the device directly so you can consult/change the PLC’s records in real time. For this you need to search for the following commands in this manual: AT^MTXTunnel=getmodbus y AT^MTXTUNNEL=setmodbus
  3. The JSON object, that is sent to the specific URL in the LOGGER_server parameter, is encoded in the following way as an example:
    {“IMEI”:353234028103206,”P”:”ID00001″,”A”:1,”TS”:”20/08/12 08:31:44″,”V1″:23,”V2″:275,”V3″:274,”V4″:32765}
    This means that the Web Server receives a JSON object with the modem’s IMEI (IMEI), the password field (P) that we can also use to identify the computer if we don’t want to use the IMEI, the device’s Modbus address (A), the time stamp (TS) which is when the Modbus data was read and V1, V2,… along with every single one of the readings taken.

It’s that easy!!!

Tags: ,

Comments No Comments »

The new version of MTXTunnel is now available, version v7.8. In this new version of MTXTunnel, I have included new features and enhancements suggested by MTXTunnel users. As always, the majority of suggestions do not fall on deaf ears. When interesting suggestions are not used they are written down and included in later versions, especially if they could be useful to other people. So if any MTXTunnel users have any suggestions, I welcome them with open arms!


These are the new features:

  1. It now has the ability to read 868MHz Wavelog radio devices (digital input radio equipment). Until now, it was only capable of monitoring Wavetherm radio devices (temperature), Wavesense (4-20mA and 0-5V) and Waveflow (pulse counters for metering applications).
  2. It now has the ability to send embedded AT commands via GPRS-RS232/RS485 gateways, whether it’s the server or client type. This means that it’s possible to send commands through a transparent gateway, like AT+CSQ for example. This command is used to remotely find out a device’s coverage. There are other commands for switching relays, changing settings etc. However this is very useful in scenarios with client type gateways who have telephone operators that do not allow server type connections (from a central PC to the modem) to run through Telnet.
  3. It has the parameter “DNS_mode: remoteat”. This parameter allows you to reproduce an MTX65i/MTX65IND modem’s digital input state in an MTX65IND’s relay. Therefore you can have a switch connected to a GPRS modem in Madrid and switch a modem’s relay in Miami. How does it work? Well basically when the modem detects a digital input change, it sends an AT command to a remote GPRS modem. On receiving this information, the GPRS modem switches the relays if necessary.
  4. It has the parameter MTX_flushSerialBuffers which allows you to clean the serial buffers before creating a TCP connection. Therefore it will delete everything that the modem’s serial port has read before establishing a 232/485GPRS- serial gateway.
  5. TCP_IP2 and TCP_port2 parameters have both been added. Before, you could configure the MTXTunnel to create up to two 232/485 GPRS-serial gateways that ran simultaneously (e.g. a single modem controlling two serial devices). But until now you could only create two “server” gateways. These two parameters now allow you to create two 232/485 “client” GPRS-serial gateways that work simultaneously.
  6. The MTX_clientReconnection parameter has been added. This parameter allows you specify the time (in seconds) that the MTXTunnel has to wait before reopening a client type 232/485 GPRS-serial gateway when it has been closed from the server. By default, it is currently 30 seconds. This means that the MTXTunnel opens a gateway against the server in order to exchange data. If the socket fails or is closed by the server, this parameter specifies the reconnection time.

Here’s the complete manual for the MTXTunnelv7.8. Remember that you can ask for it to be installed in GSM/GPRS modems:MTX65i, MTX65IND, MTX65INDv2, MTX65ULP, MTX65-RS485 y MTX65+G(and in 3G modems soon ;) )

Comments 2 Comments »

A looooong time ago I presented the MTX-INDv1 here which is a GSM/GPRS industrial modem with DIN rail format.  If we remember, that modem had a Cinterion TC65, therefore it was Java programmable with 400KB RAM and 1.7MB flash. It had 6 opto-isolated digital inputs (2 of which could also be configured as opto-isolated outputs), 2 analog inputs, 4 relays and an input power range of 8-30VDC. This modem also has a USB port and 2 ports which are configurable to RS232/485/422. As seen in the video, you could use an 868MHz Wavecard communications card to communicate with sensors via radio, such as Waveflow (pulse counters), Wavetherm (temperature sensors), WaveSense (sensors 4-20 or 0-5V …).

Nowadays we have the MTX-INDv2 version (the MTX-INDv1 version is still in production), which is the modem that I am going to present to those of you who have not heard of it. This is it in the following picture:

modem gsm gprs IP68

It’s basically the same modem ass a big part of the circuit has the same design as the MTX-INDv1. However it has improvements as it is designed for many scenarios that the MTX-INDv1 could not cover. The following are the MTX-INDv2’s characteristics and options:


-          It is based on the TC65i GSM/GPRS modem. Therefore it is Java programmable and it also has 400KB RAM and 1.7KB Flash. Alternatively, you can be provided with a TC65i-X internal module. It is exactly the same but with 2MB of RAM and 8MB of flash.

-          6 opto-isolated digital inputs ¡ (2 of which can also be configured as opto-isolated outputs)

-          2 analog inputs

-          4 relay 16A

-          USB port

-          2-port RS232/485/422


and here are the main differences:


-          IP68 waterproof box. This is ideal for devices that have to be used outside.

-          Power supply 220VAC or 24VDC. This means that you can connect it directly to a 220V network without needing a current adaptor, although it can also be used with 24V DC voltage.

-          It has a 1600mA internal battery which gives it various advantages. For example, you can use you Java application with 220V and if there is a drop in the voltage an alarm can be sent via SMS.

You have many other options:

-          You can order either a 25mW (1Km scope) or 500mW (4Km scope) Wavecard communication card.

-          You can order Ethernet-Serial converter which allows you to connect to a LAN network.

In short, it is an evolved version of the old MTX-INDv1 modem and it allows for a range of very important outdoor scenarios. Another day I will present the MTX-Remote (a series of 868MHz wireless sensors), and also the IP68. I am sure that they will be of interest for many applications that work seamlessly using the MTX-INDv2 as an 868MHz GPRS-radio communications hub.

For those who are interested, here is the MTX-INDv2 datasheet

Comments 2 Comments »

It has been a long time since I last wrote in blogElectronica, therefore I have quite a lot of new things in the pipeline. Some are very, very interesting, especially regarding 3G devices with Java, which I will discuss soon. ;)

However today I will discuss a new GSM/GPRS terminal from the MTX family. Certainly, more than one of you will find it interesting, especially as you are able to save costs involved in some scenarios where you use an MTX65i + RS232-RS485 converter. This is the new MTX65i-RS485 terminal.

What features does it have?

Well, basically they are more or less the same as the well-known, widely used MTX65 but there are some slight differences.  Here are the main features:

  1. GSM / GPRS Class 12 modem
  2. Java programmable, 1.7MB Flash, 400KB Ram (optional 8MB Flash and 2MB Ram available)
  3. 1 RS485 port with terminal block
  4. 1 RS232 port
  5. 1 USB port
  6. 2 analog/digital convertors
  7. 2 opto-isolated digital inputs
  8. 2 opto-isolated digital outputs
  9. 1 general purpose digital input/output
  10. 1 pulse counter input (up to 1kHZ)
  11. 1 I2C bus

As you can see, the main difference/feature is that the RS485 port is built into the modem; it is different from the MTX65i as it has a higher number of opto-isolated inputs and outputs.

Another important difference is the modem’s ability to turn itself off. If you remember, one of the main properties of the MTX65i GPRS modem is that it’s designed to never, ever be turned off under any circumstances. It always needs to be switched on. This gives you extra security like when modems are installed in rural environments and any in-person interaction with the modem would be traumatic. In this case, this option also ensures that the modem won’t fail you. However if you wish you can also get the modem to turn itself off voluntarily with a special input in the power connector.


Can you use this GSM/GPRS modem with MTXTunnel software?

Of course, ever since the MTXTunnel version 7.6 was created, you can use it no problem. I will talk about it on here again to discuss is at a later date.



If up until now you are using the MTX65i along with an RS485 converter, you could save on the converter, installation time and physical space with the new MTX65i-RS485 modem. This is a brief conclusion, I will add more later on. I will take this opportunity to wish everyone a happy start to 2013!!!


Tags: , , ,

Comments 1 Comment »

Some of you already know that the new Cinterion TC65i-X GSM/GPRS module exists, many others may not, and therefore today I will discuss the most relevant aspects of this new and interesting module. As I said before, the name of this module is TC65i-X and as is suggested by its name, it is basically the TC65i module with a few changes. These positive changes affect the product on both hardware and software levels.

How has the hardware changed? 

Basically for me this change is one of the most important changes of them all, including all of the software changes.  As you know the TC65i GSM/GPRS module is Java programme (J2ME). This module has about 400KB of RAM and 1.7MB of Flash. The new TC65i-X module has greatly increased its capacity and has up to 2MB of RAM and 8MB of Flash memory (split into 2 x 4MB parts).

This is obviously very significant. Those, including myself, who develop large applications, always come to a point when we have to cautiously programme because the TC-65i’s RAM memory is somewhat limited for some applications. Everything changes when you have 2MB of RAM as it is possible to make large and complex Java applications without any problems. When thinking about analog, this can also occur with the Flash memory which is now 8MB.


What are the software changes in the new TC65i-X module? 

Well there are lots of changes, I will write about what seems most relevant to me.

  1. Finally you can now work with the following as it supports: Entorno Eclipse and MES with 64-bit Windows versions, that is, 32/64-bit Vista and 32/64-bit Windows7. Basically it’s due to the new MES being available.
  2. It includes certain Java API’s for GPS handling (just connect a GPS module to one of the two TC65i-X module’s serial ports).
  3. Transparent TCP sockets – You already know that these days you use AT commands to work with Cinterion TCP/IP stack. To send data through a socket you use the command AT^SISW and to read data you use AT^SISR. However personally for me, the best way to work is with multi-socket. In order to be able to have multi-socket, Cinterion has added the ability to send data through a socket in a transparent manner. This for some users (and for monosocket applications) may be interesting for resolving simple issues.
  4. TLS/SSL support from its own AT commands to socket and to http. Until now it was only possible from Java, but it’s now also possible from AT commands.
  5. COM port gateway. The TC65i-X as well as the TC65i both have 2 serial ports and a USB port. Therefore you can configure the modem so that the data comes through the ASC0 and goes out the ASC1 and vice versa or you can configure the combinations ASC0-USB/ASC1-USB. However it’s a shame that it’s not a permanent configuration in the flash memory and also that you can’t configure it from any ports where it will “intervene in the couple”.
  6. One of the most interesting things for me is the introduction of the AT^SNMON command. This command (even without a SIM) will return a complete list of all GSM antennas around it that are organized by RSSI. For me, this is very important because if you are going to install a modem in a certain place, you can see beforehand which operator will offer you the best coverage without having to go there with a rucksack full of SIMs from different operators.
  7. Continuing from the last point, Cinterion has included the interesting command AT^SPCL. With this command we can make a list of preferred GSM antennas that the modem will try to connect to. So if we have a list of available antennas from the same operator (obtained with AT^SNMON), we could always connect to a specific antenna, for example the one with the most coverage. Or even the other way around, as in some cases you may install a modem that’s only a few metres away from a GSM antenna and then the modem could have signal saturation problems.

Very interesting. So can I use a Java programme that I have developed for the TC65i and put it in the TC65i-X?

No. You need to make a few small changes to the software and you will need to recompile it.

Oh, man, I have programmes for the TC65 and I can run them on the TC65i. Why I can’t I do it with the TC65i-X?

Well it’s for business reasons, Cinterion (the old Siemens M2M) no longer wants to use the word Siemens in its products; this has been dragged out over the past few years. The only change you will have to make in your programs will be to change the line:

import com.siemens.icm

import com.cinterion

That’s all.

So we have a new GSM/GPRS module which is Java programmable with a lot more memory and features. Despite the hard times we are going through, in time there will be more pleasant surprises.

Tags: , ,

Comments 7 Comments »

This weekend I brought a little toy home to mess around with. I wanted to try it out for a long time. It could be useful in some applications in the m2m world which is becoming more and more present in our lives, although many do not realize it.

This little device is a mini camera module with VGA resolution from Comedia which in turn is based on a CMOS sensor from Onmivision (the world’s largest manufacturer of these types of devices, so much so that nearly all of us have one of their sensors in our mobile phones). So far it’s nothing special. The peculiar thing about this mini camera is that as well as its low cost, you can directly control a uart through a serial port with a very basic protocol suitable for everyone.

The latter obviously enormously helps you to be able to control the camera and get a picture of what is happening in the world from any device with a serial port. In my case, I am particularly interested in the possible integration with MTX65i modems, especially with MTXTunnel software. I am assessing how much time it would take to integrate the possibility of “taking a snapshot” from the MTXTunnel or even from the  MTXTunnelGPS.

The camera I’ve been testing is particularly the model I had at hand, the C328R. The following is the block diagram of the camera:


It’s a very small camera (only 2cm x 2.8cm), with VGA resolution, with low power consumption (60mA) and as I said before with the serial control peculiarity (UART). Note that this camera has serial ports but doesn’t have an RS232, this means that RX and TX output level is 0-3.3V so we can’t directly connect to a PC’s serial port or a MTX GPRS modem. Fortunately, there is also a small evaluation board called C328-EV232 that allows this and adapts RS232 levels. This is what I am testing.

Here is a picture of the evaluation board next to an MTX65i so that you can see how big it is:


And here is another with the C328 module mounted on its mini evaluation board:


Together with the mini evaluation board you get a CD-Rom with the datasheet from the camera and from the evaluation board itself, a rapid use test program (which does not work with Win7 but works with WinXP, it doesn’t really matter) and most importantly, the complete manual of the camera’s protocol which tells you how to configure the camera (resolution, compression etc.) and how to get an image from the serial port. It’s fairly informative which means that it is easy to do the first tests. This is a picture of the software test:


Basically, in addition to trying out the test program that comes in the CD-Rom, I have done some tests sending serial frames to the camera from a VB6 program. I followed the protocol and example in the manual and it responds very well. From what I gather, it doesn’t take much to generate the necessary JAVA code to take a snapshot from an MTX terminal.

It’s obvious that you can’t send video streaming from a GPRS terminal as the bandwidth does not allow it. But yes, it could be interesting to occasionally send some snapshots (we’re talking about very few KB, according to the settings less than 10KB per image) as this doesn’t cause any problems for GPRS transmission. For example, if we designed an alarm system using an MTX65i GPRS terminal, it could be interesting as we could send an image as well as sending an alarm. Or it could be interesting for a fleet management system (based on the MTX65 + G) that as well as GPS positioning via GPRS, it allows you to physically visualize the load at any given moment (for example when opening a trailer’s doors).

To conclude, if you sacrifice very little time and money, this little camera allows you to send photographs to any device that has a single serial port free. Small details like this are what differentiate devices that we can design over others, in a world which is becoming more and more competitive and in which there is more and more of everything.

Tags: , ,

Comments 2 Comments »

Today we are going to speak about GPS, or rather GNSS. A few days ago a very explanatory document fell into my hands, made by my colleague Jesús Santos, as a result of a new product launched by the company Fastrax which many of you know. I think that it could be quite interesting for a lot of you, especially those of you who are dedicated to the issue of positioning. So I included it in the article.

What is GNSS?

GNSS stands for Global Navigation Satellite System. “GNSS modules” are satellite receivers whatever brand they are or whatever country they come from. What happens is that we use the word GPS receivers for everything related to positioning. It’s suitable but this American system is not the only one that exists, there are many others:

Russian GLONASS system
Chinese Beiuou-2/Compass
Japanese QZSS
Indian Gagan

And we are waiting for the European Galileo system expected in 2014…

Fastrax has a GNSS module. The IT6000 is based on an ST chipset. The great thing about this GPS module is that it works with the American GPS system as well as the Russian GLONASS system simultaneously.

Some would think…would this benefit me?

The answer is that the receiver will work in the most extreme conditions. Imagine a street with tall buildings (what we call the urban canyon). The receiver will not only be able to see the few GPS satellites, but it will also be able use the GLONASS satellites.

Let’s look at an example. Pay attention to the following chart. GPS satellites are light blue. GLONASS satellites are dark blue. There you have the IT600 module working with 22 satellites simultaneously.


To make it clearer, here it is on a map. Here you have a test drive in Dallas. In yellow you have GPS only module traces, the “best” working all the time with 4-6 satellites. In blue you have the same route working with an IT600 module and with 8-12 satellites simultaneously (as many GPS as GLONASS). The result? Amazing, the picture says it all.


Can I make use of the same antenna that I use with my GPS module now with the IT600?

Not really. The GPS and GLONASS frequencies differ slightly. For these GNSS receivers to work well, you need an antenna that is ready to receive the 2 signals. Do these antennas exist? Yes, they do.

That’s very interesting. What other stand out features does this module have?

It has a many but here are a few:

  • The IT600 module can be assisted (AGPS) which is what we know as Autonomous AGPS or predictive AGPS. The first one is the most interesting. We can simply say that it collects the ephemerides, it works out a 5 day prediction of them and stores then in an SQI flash memory (fast bus) which is inside. For the other possibility you need the classic AGPS server in order to collect them periodically using GPRS/HSPA.
  • DR support (Odometro/Gyro or CAN DWP).
  • So what is this?
  • Dead reckoning. Receiver’s capacity to continue giving its position without satellite visibility thanks to external sensors (nearly always Gyro and Odometer). Note that this feature is not implemented yet.
  • CAN. CAN bus.
  • DWP: Differential Wheel Pulse info. (something like the odometer)
  • I2C  for MEMS sensors

Most important of all are the sensors that we can connect to the IT600. An accelerometer gives an idea of the acceleration that the module undergoes. There has to be a change in the speed for it to work. An e-compass or magnetometer measures the earth’s magnetic field, like a compass. That’s what it really is, an electronic compass that helps the accelerometer to find the way at low speeds or if it has stopped. Many mobiles and PDAs incorporate the compass to help positioning. Sensor summary: speed (odometer o even DWP), acceleration (accelerometer), turns (gyroscope) and magnetometer (electronic compass).

These sensors are put close together in the I2C bus carrying the IT600 and it will use and it will get information by itself from the same UART serial port. Furthermore, it can be connected to the vehicle’s CAN bus.


Wow this module has some mind-blowing features…

Well there’s more. It’s a programmable device; you can make your own application and embed it inside. This means that the module is used as a microprocessor as it has an ARM946 processor with programmable GPIOs, 3 UART, SPI, I2C, CAN, 2ADC… a 208MHz micro with 8MB flash memory capacity and 128KB of SRAM.

I hope that it has been interesting talking about GNSS for those who did not know of any other systems. I’ll take this opportunity to wish you all a Merry Christmas and a Happy New Year for 2012 (and of course, good luck with the Christmas lottery tomorrow) what a pipe dream… ;)


Comments 1 Comment »

Today I am going to talk about a small module from Imsys. I really think that I should have already mentioned this company as I’m sure that these types of modules will create some interest because many readers use the well-known TC65 and XT65 Cinterion modules (I will share good news about these soon).

As I was saying, I present to you the new module Snap Stamp from the company Imsys. First of all, here is a photo so that you can recognize it:

snap stamp imsys

As you can see it’s a very small module, each side measures 29mm. It is called Stamp because it’s the size of a stamp.The important thing is that this module is based on the IM3910 Java processor.  You program these modules in the same way that we program the XT65/TC65i Cinterion modules and MTX65 java (J2ME) terminals. This means that if you are already familiar with Java programming in Cinterion and MTX modules, you already know how to program the Snap Stamp module. This obviously is an incredible advantage for time-to-market for all of those who need to start a new project with a processor module, as you could have already developed the knowledge of how to use codes and Java classes in Cinterion modules and MTX terminals. It’s like the latter, compile your program (in Eclipse or Netbeans) and upload your file .JAR to the module (this case is not by OBEX but by local/remote Ethernet and then it will run).

Snap Stamp has a complete TCP/IP stack in the same way that Cinterion modules do, but it also has a web server, ftp, telnet, gestor de I/O etc.

Here are the technical specifications of the module:

• High performance multi-threaded Java execution
• Certified J2ME-CLDC virtual machine
• Four channel A/D 16-bit 44 ksps converter with optional external reference voltage
• Two D/A 16-bit 44ksps converters
 2* / 4* / 8 Mbytes Flash memory
• 8 / 32* Mbytes SDRAM
 10/100Base-T Ethernet MAC and PHY
• Optional 2nd RMII interface
 TCP/IP stack, Web/FTP/Telnet server
• Three serial ports (3.3V levels, 4-wire, 920 kb/s)
• High-speed I2C bus and SPI
• Parallel 8-bit high speed data bus
 8 to 53 General-purpose digital I/O ports
• MMC / SD card support
 Extensive I/O functions through Java APIs, including PPP, FTP, E-mail, GPIO, Timers
• Enhanced performance for special functions e.g. graphics, crypto, and floating point operations
• Rubus JOS RTOS with failsafe flash file system
• High I/O bandwidth (>650 Mbits/s DMA)
• Real time clock and calendar
• On board Temperature sensor
• 150 / 200* MHz oscillator frequency
• Commercial / Industrial* temp range
• Connection for Imsys JTAG Trace Adapter
• Reference designs available, complete with schematics and firmware for:
Dallas/Maxim 1-wire
     TFT LCD, Touch panel
       CD quality Audio

The * indicates that it is optional and they are supplied with a minimum order of parts.

Here you also have a small comparative between the Imsys processor and different processors.


I hope that you find this small module interesting. We are already aware that many people read this blog so I am sure that tomorrow I will have an email asking me a question :)


Tags: , ,

Comments 2 Comments »

Today I am going to present an interesting device from the company Multitech. I will be making use of a document written by my colleague Jesús Santos, whom I thank. I will be talking about the MultiConnect AW MT200A2W.

Very good. What is it?

Well, imagine you have a device that uses an analog modem to communicate (one external or internal inside the device itself) or simply imagine that you have a switchboard or a traditional fax machine where data is managed (not voice data).

Now imagine that you want to install this device and for whatever reason but it turns out that you don’t have a free telephone line to connect to or simply imagine that you don’t want to use a new analog line or that the telephone cable installation could be expensive.

For that you need this device. It’s an analog line emulator for GSM (for data). This means that instead of plugging the analog modem into the conventional telephone socket, you can connect it to this Multitech device’s RJ11 opening. Thanks to its internal SLIC (that we’ve already talked about), it’s a module that emulates a telephone line.

How easy! Does that mean that the MT200A2W collects data from the SLIC coming from my analog modem and it sends the data directly through its internal GSM modem?

No, you are missing something. The MT200A2W also has an internal analog modem socket that communicates with your analog modem through SLIC. Therefore sending analog signals directly via GSM through the audio channel wouldn’t work due to the damage that these signals would suffer in the GSM network. Then the data is routed through the internal GSM modem in the Multitech device.

This means [your analog modem] — [SLIC--- analog modem socket --- microprocessor --- GSM modem]


Can I not do this with the classic FCT, wireless local loop or gateway that my GSM operator gives me?

No, it won’t work. The devices that you are talking about are designed to connect to analog telephones and to route calls when we phone a mobile telephone, but only to route VOICE calls, not DATA calls. Data calls will NOT work properly with a FCT.

That’s interesting. I understand that you’re talking about the MT200A2W but I see that in reality that there are various models.

Yes, there are two. The MT200A2W, a device designed more for indoor use which has plastic housing and is nicer aesthetically. On the other hand we have the MT100A2W which has aluminium housing, a voltage range, extended temperature range, RS232 port etc. This means it’s more industrial. An important thing to consider when choosing the model is that the MT200A2W model is only able to make calls (calls made by your analog modems) and the MT100A2W is able to both make and receive data calls.

Well that’s all for today. I hope you all had a good holiday. As for me, I had a great 3 weeks holiday. I spent most of the time in Huesca, a great place to relax, to do adventure sports, to eat well as well as always having nice people everywhere. In short, my family and I had a lovely holiday.

Best wishes. ;)



Comments 5 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.



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:


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:

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 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:


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
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 CALLERID “681319891″ “” 81
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:

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.


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!




Comments 2 Comments »