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:
- 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).
- 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
- The JSON object, that is sent to the specific URL in the LOGGER_server parameter, is encoded in the following way as an example:
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!!!
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:
- 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).
- 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.
- 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.
- 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.
- 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.
- 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 )
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:
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
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:
- GSM / GPRS Class 12 modem
- Java programmable, 1.7MB Flash, 400KB Ram (optional 8MB Flash and 2MB Ram available)
- 1 RS485 port with terminal block
- 1 RS232 port
- 1 USB port
- 2 analog/digital convertors
- 2 opto-isolated digital inputs
- 2 opto-isolated digital outputs
- 1 general purpose digital input/output
- 1 pulse counter input (up to 1kHZ)
- 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!!!
1 Comment »
Nowadays it seems to be clear what PoE is and the advantages that it brings. PoE (Power over Ethernet) means that you can get a power supply through Ethernet cables. It facilitates the installation of multiple electronic systems that have an Ethernet connection, like an interface. This technology is standardized through the IEEE 802.3af and IEEE802.3at and nowadays we can find electronic devices and equipment where the manufacturer has chosen to assemble a SilverTel module. These modules are easy to integrate as they only require a minimal amount of external components, they meet safety regulations and most importantly these days, they are low cost.
This week I heard that SilverTel had a few new modules that can get a power supply of up to 100W through a CAT5/6 Ethernet cable for HDBaseT technology.
What is HDBaseT?
The first thing to know is that the major electronic manufacturers like LG, Samsung, Sony and Valens have formed an alliance. The idea is to promote and commercialize the HDBaseT name. This allows you to eliminate multiple cables and connections in the home and office in exchange for one CAT5/6 cable. With this one cable we can connect computers, TVs, games consoles, multimedia players etc. as you are guaranteed a 10.2 Gbps bandwidth.
I don’t understand the advantages that it offers.
For example: Suppose you have a 1080 Full HD multimedia hard disk and the television is 100m away, how do you connect them? With a CAT5e cable both devices can be HDBaseT enabled.
But there isn’t a plug where I want to install the TV…
You don’t need to find a plug for the TV which is 100m away from the multimedia player if we use PowerOverBaseT technology, called POH.
I don’t think that the TV is powered with this.
Now the consumption of a 40” LED TV is around 70W, Energy Star Consortium 6.0’s intention is that all screen dimensions and LCD/LED televisions don’t reach 85W.
Great… and above all energy savings. Explain a little more what is POH exactly?
Based on POH technology, the idea is to get data and power supply from the same CAT5/6 cable up to a maximum distance of 100m. Just like in PoE, we have devices that inject power supply, PSE and the device that is supplied with PD (in our example, the TV).
And… can’t I use PoE? I already have it working with home and office phones, do I have to get rid of PoE access points?
No don’t throw anything away as it is compatible. If you connect a PoE telephone to the POH network, the PSE injector will recognize it and it will give it less voltage/current in order to meet the specifications, this means that you won’t need to throw away any existing devices.
Do you recognize it? How?
When connecting a PoE or PoH device, before adding the PSE power source, power it with a couple of volts so that there is communication between them and so that the device has an internal electronic signature to show that is PoE-PoH enabled. If valid, the injector will then apply the power. If not, it’s obvious that it’s not a PoE-PoH device and no voltage is applied.
Ok. I am a manufacturer and I want to include PoH in my products. What electronics do I need? Where do I start?
Let’s not complicate matters. The company SilverTel has a lot of experience with PSE injector modules and PoE, PoE+ and PoE Ultra extractors. It has just released some new modules (Ag6600 and Ag5600) which are compatible with the standard PoH for HDBaseT. They have been preparing for PoH for 7 years. With these modules you won’t need to meet the standard, with a minimal amount of components your electronics will be ready.
It seems like this is directed towards television manufacturers…
No it’s not. There are other applications where PoH has great potential and high power is needed. Some examples are: sound amplifiers (sometimes built into the speaker), point of sale terminals with screens, signage applications and display panels. It is also used to ensure that there is a CC power supply when it is essential.
I hope you liked it. It’s an interesting article written by my colleague Jesus Santos. Thank you.
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.
- 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 188.8.131.52 being available.
- 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).
- 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.
- 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.
- 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”.
- 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.
- 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:
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.
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.
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
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…
1 Comment »
In order to make the most of the fact that I have had to test out the PCM interface from Cinterion modules and from Bluegiga Bluetooth modules, I will post about it as it will be of great help to those who want to develop a hands-free GSM device (via Bluetooth). In order to not complicate matters, I will post the information in a simplified, practical way. Well, here we go…
1.- Let’s take a DSB75 evaluation board where we insert the Cinterion GSM module that we want to use (a TC63i, a TC65i, a PH8 etc.) In my case I have a TC65i.
2.- Locate the pins on the DSB75 evaluation board that correspond to the PCM audio pins. They specifically correspond to the board’s x703 connector. In this connector we will see 7 pins: TXDAI, RXDAI, FS, BITClk, FSIN, BCLKIN and GND.
3.- Out of these 7 pins, we only need 5 that are using PCM. The choice you make will depend on whether you use the Cinterion module in PCM MASTER mode or PCM SLAVE mode. If you use the Cinterion module in PCM MASTER mode, use the TXDAI, RXDAI, FS, BITCLK and GND pins. If we use the Cinterion module in PCM SLAVE mode, use TXDAI, RXDAI, FSIN, BCLKIN and GND pins. The following photo shows how I used it in SLAVE mode with the cables connected to these 5 pins.
4.- We took a Bluegiga development kit (the simplest to use is the WT32 Bluetooth module). The reason for choosing this kit is because it has the PCM pins available in the development kit’s PCB. In Bluegiga’s PCB you can easily see where the PCM pins are due to the good screen.
5.- Connect the GSM Cinterion’s PCM pins with the Bluegiga WT32 Bluetooth module’s PCM pins. Basically you have to connect the pins as follows:
TC65i (Slave) WT32 (Master)
What if you want the opposite? If we wanted to use the GSM module in MASTER mode it would be like this:
TC65i (Master) WT32 (Slave)
So once you have done this, all of the hardware is connected. Now you need a Bluetooth hands-free earpiece. I have one from Plantronics with MAC Bluetooth: 00:03:89:a5:a6:72 (I mentioned it because I will use it later).
6.-The next step is to configure the WT32 Bluetooth module to route audio to/from the PCM interface. We do this by sending the following command to the WT32 module via a HyperTerminal at 115200,8,N,1:
SET CONTROL AUDIO PCM PCM
7.- We’ve set up the PCM configuration to the Bluetooth module. Due to the complexity of the different PCM configurations, we use an Excel provided by Bluegiga. With this excel we can indicate the configuration that we want and this way we easily obtain the PSKEY_PCM_CONFIG32 value that we need to configure the PCM. In this case PSKEY_PCM_CONFIG32 has a value of 0×08400000.
As in the previous point we can configure the PSKEY by a command from the HyperTermainal:
SET CONTROL PCM 08400000 006C
8.- Now we are going to configure the Cinterion GSM module to use the audio’s digital interface. These commands can have different functions depending on the model used. I am going to do it with a TC65i. Therefore, from a HyperTerminal we send:
So let’s configure the module to use the PCM digital audio in SLAVE mode at 512MHz and Long Frame.
At this point we have already configured both the Bluetooth module and the GSM module.
So now let’s try the audio!!!!
9.- From the Bluetooth hands-free earpiece (that I imagine is already paired with the Bluegiga Bluetooth module), we can connect to the Bluegiga Bluetooth module (by pressing the only button that it has).
10.- Next we physically connect the TC65i module’s ASC0 RS232 serial port to the WT32 Bluetooth module’s serial port with a serial cable crossover.
11.- We make a GSM audio call from a mobile telephone to the TC65 GSM module. On receiving the call, the module lets out a “RING” from the serial port that will be received by the Bluetooth module in order to inform the Bluetooth earpiece that there is an incoming call (we hear the typical beep beep of an incoming call). We answer the call by pressing the button on the Bluetooth earpiece.
12.- Once you have done this, we answer the voice call in the GSM module with the typical ATA command. If everything has gone well up to now, we will be talking with our hands-free Bluetooth earpiece, connected via Bluetooth to the Bluegiga WT32 module and this in turn is connected to the Cinterion GSM module through the PCM interface.
Well, that’s all for today. This post is perhaps a bit complicated to understand if you don’t have the devices in front of you. But you’ll see that if you ever need to do something similar, this post will be a gem and it will save you lots of working hours. I’ll be fine if I ever need to do it again because I have had to assemble this 3 times over the years. I always think that I won’t forget how to do it but something always slips my mind. From now on this won’t happen
No Comments »
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 blogElectronica.com 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:
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:
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
2 Comments »