Nuestra última escapada empieza mañana mismo, pues nos iremos de nuevo unos días a Nuria, en el Pirineo (Queralbs), donde ya estuvimos un Invierno de hará unos 7 u 8 años y de donde tenemos muy buen recuerdo. Un entorno espectacular y un hotel magnífico.

Aprovechando que hoy estoy por casa os pongo un breve post de un dispositivo similar al post que ya puse hace tiempo del dispositivo AnyWhereUSB de Digi.
 

En este caso el fabricante no es Digi, sino Quatech (distribuida por Matrix). El dispositivo es el USBN-500W y es un aparato similar al AnyWhereUSB, es decir, un dispositivo con el que poder accdeder y compartir dispositivos USB de forma remota (impresoras, scanners, cámaras, llaves USB, licencias USB, …). Si el AnyWhereUSB de Digi la conexión era únicamente Ehternet, en este caso la conexión, además de Ethernet (dispone de una conexión 10-100BaseT), es Wifi 802.11b/g (hasta 54Mbps), lo que hace que no tengamos que llevar cable de red de ningún tipo hacia el gateway USB.

El USBN-500W admite conexión de hasta 14 dispositivos USB de forma simultánea, aunque en el caso de querer conectar más de 1 dispositivo deben conectarse a través de un hub USB, pues el equipo tiene una única boca USB, a diferencia del dispositivo de Digi, que contaba con 5 bocas USB.

Aquí tenéis el datasheet, para quien le pueda interesar.

Hasta dentro de unos días
 
 

EJEMPLO_FTP (Download)

Descripción: Muestra una aplicación básica de FTP con java para módems Siemens. Crea una conexión FTP y crea un archivo de nombre “fichero.txt” en el servidor remoto con el contenido “123″. Tan sólo tenéis que modificar la línea del código donde se indica, por orden, el login, el password y el servidor FTP que queráis utilizar.

Válido para los módems: TC65, XT65, TC65T, MTX65 y MTX65+G
 

Un detalle que os quiero comentar de los ejemplos que puse el otro día. He puesto todos los ejemplos con el formato EJEMPLO_xxx. Pues bien, pueden ejecutarse perfectamente todos los ejemplos con el comando AT^SJRA, pero si ponéis ese nombre en “Userware/Autostart/AppName” del comando AT^SCFG para que la aplicación arranque automáticamente, no os arrancará. No pongáis el guión bajo (_) en el nombre de vuestros ficheros .jar para autoarranque.
 
 
Bueno, os dejo, que hoy es el cumple de mi chica y quiero montarle la Wii que le voy a regalar antes de que llegue a casa. Y no, no es un regalo boomerang, que yo soy más de PlayStation . La PS3 me la autoregalaré antes de final de año.  Otro día más.
 
 

Por cierto, quien no sepa lo que diantre es la plaquita de la imagen anterior, deciros que es una memoria USB-DOM, que suele utilizarse en equipos basados en PCs industriales debido a su conector de inserción y por que además puede ser anclada (atornillada) a la placa base, lo que la hace más inmune a vibraciones. Sigue siendo una memoria USB, pero con otro tipo de conector.

El video de Youtube muestra una prueba de dureza ( o tortura como indican ellos en el vídeo ) a uno de sus productos, en este caso una a memoria industrial USB modelo Petito (la otra memoria que tenéis en la imagen anterior, a la izquierda) . Como seguramente sepáis, los modelos USB industriales se diferencian en los comenciales (de los comprados en el Mediamarkt) en que tienen una larga durabilidad (es decir, no te la obsoletan al cabo de pocos meses), rango de temperaturas extendido, alto número de ciclos de escritura (unas 10 veces más que una comercial), resistente al agua y resistencia a presiones y golpes entre otras características.
 
 
Aquí tenéis el vídeo:
 

 
 
Desde luego que el Petito es resistente, además yo doy fe de ello, que tengo algunos por la oficina.

Bueno, mañana colgaré algún ejemplito de java más para los módems de Siemens, para completar el post de hace unos días. Hasta mañana ;)
 
 

Son ejemplos rápidos, es decir, no gestiono completamente todas las excepciones ni mucho menos, pero desde luego, si estas empezando con estos módems, creo que pueden resultarte una buena guía. Verás como la inmensa mayoría de las aplicaciones que puedas llegar a hacer para proyectos reales están basadas en pequeñas tareas, que son las que muestro en los siguientes ejemplos.
 

Vamos allá, éstos son los ejemplos que os cuelgo en el blog:
 
 

EJEMPLO_HelloWorld (Download)
 
Descripción: Muestra una aplicación básica que lo único que hace es sacar información por la salida estandard del módem. Deberás configurar previamente la salida estandard con el comando AT^SCFG, por ejemplo, AT^SCF=”Userware/Stdout”,”",”ASC0″
 
Válido para los módems: TC65, XT65, TC65T, MTX65 y MTX65+G
  
 
 
 
EJEMPLO_SMS (Download)

Descripción: Básicamente el ejemplo lo que hace es enviar cada minuto un SMS a un determinado número de teléfono.

Válido para los módems: TC65, XT65, TC65T, MTX65 y MTX65+G
 
 
 

EJEMPLO_Thread (Download)

Descripción: El programa lanza un hilo que lo que hace es contar hasta 5 sacando el resultado por la salida estandard. El programa espera a que acabe el hilo antes de finalizar.

Válido para los módems: TC65, XT65, TC65T, MTX65 y MTX65+G
 
 
 

EJEMPLO_Timer (Download)

Descripción: este ejemplo crea un timer de 5 segundos. Es decir, cada 5 segundos se ejecuta una tarea que lo que hará es sacar datos por la salida estandard del módem.

Válido para los módems: TC65, XT65, TC65T, MTX65 y MTX65+G
 
 
 
 
EJEMPLO_GPIO (Download)

Descripción: Muestra como configurar un GPIO de entrada y otro de salida desde Java, como cambiar el estado del GPIO de salida y cómo leer el de entrada.

Válido para los módems: TC65, XT65, TC65T, MTX65 y MTX65+G
 
 
 

EJEMPLO_ConexionTCP (Download)

Descripción: Muestra como crear una conexión TCP/IP con la clase ATCommand. El ejemplo crea una conexión con un socket que se conecta a la IP de Google, envía una trama por el socket y recibe una cadena por el socket, que muestra por la salida estandard.

Válido para los módems: TC65, XT65, TC65T, MTX65 y MTX65+G
 
 
 

EJEMPLO_ConexionTCP2 (Download)

Descripción: Muestra como crear una conexión TCP/IP utilizando las clases propias de Java. El ejemplo crea una conexión con un socket que se conecta a la IP de Google, envía una trama por el socket y recibe una cadena por el socket, que muestra por la salida estandard.

Válido para los módems: TC65, XT65, TC65T, MTX65 y MTX65+G
 
 
 

EJEMPLO_Ficheros (Download)

Descripción: Muestra cómo crear un fichero en la memoria flash del módem, cómo escribir datos en el mismo y cómo leerlos.

Válido para los módems: TC65, XT65, TC65T, MTX65 y MTX65+G
 
 
 

EJEMPLO_GPS (Download)

Descripción: Muestra la utilización del GPS con la clase ATCommand. El programa al arrancar activa el GPS y lo programa para recibir un URC con la posición cada 5 segundos. Esta posición se almacena en una variable y además se muestra por la salida estandard.

Válido para los módems: XT65 y MTX65+G
 
 
 

EJEMPLO_GPS_JSR179 (Download)

Descripción: Ejemplo que muestra brevemente cómo capturar una posición GPS sin utilizar la clase ATCommand, es decir, utilizando la clase Location de la JSR179.

Válido para los módems: XT65 y MTX65+G
 
 
 

EJEMPLO_HTTP (Download)

Descripción: Este ejemplo crea una conexión GPRS y utilizando la clase de java HttpConnection se descarga y muestra por la salida estandard la página de inicio de Google.

Válido para los módems: TC65, XT65, TC65T, MTX65 y MTX65+G
 
 
 

EJEMPLO_PuertoSerie (Download)

Descripción: Muestra cómo utilizar el/los puertos serie del módem desde Java. Abre los dos puerto serie ASC0 y ASC1 y lo que recibe por el ASC0 a 115200 baudios lo retransmite por el ASC1 a 57600 y viceversa. Está pensado para el TC65, pero sirve para ver cómo manejar el puerto ASC0 del XT65.

Válido para los módems: TC65, TC65T y MTX65 (XT65 y MTX65+G sólo 1 puerto serie).
 
 

EJEMPLO_Watchdog (Download)

Descripción: muestra cómo utilizar el nuevo watchdog del TC65v3. El programa cuenta hasta 25.000. Ha partir de la cuenta 10.000 el programa deja de refrescar el watchdog, por lo que a los 15 segundos verás cómo se resetea.

Válido para los módems: TC65, TC65T y MTX65 (con versión 3.0 de firmware)
 
 
 
 
Espero que encontréis de utilidad estos ejemplos. Intentaré poner algunos más dentro de poco, relativos a modos de bajo consumo y FTP.
  
Y bueno … enhorabuena a los que estáis ya de vacaciones, y a los que no, como yo, ánimo, que ya falta poco!!!     Otro día más.
 
 
 

La verdad es que Pro-face no tiene un catálogo con cientos y cientos de productos diferentes como los catálogos de muchas empresas, y lo que tienen se pueden resumir en dos palabras: pantallas táctiles. Eso es lo que hacen y en eso es en lo que están altamente especializados.

Realmente sus productos se pueden clasificar en cuatro. Por un lado (1) tienen pantallas táctiles o dispositivos HMI (Human Machinne Interface) para el control de PLC. Por otro lado (2) disponen de lo mismo que lo anterior pero con pequeños PLC incorporados. Como tercer tipo de productos (3) hacen también pantallas táctiles para PC (e incluso pantallas con PC incorporado). Y por último (4) también crean software. Un software que realmente es una herramienta bastante potente para la programación de sus propias pantallas.
 
 

¿De qué tamaño son las pantallas?

Tienen un abanico bastante amplio, van de las 3.8′’ hasta las 19′’. Por supuesto dependiendo del tamaño de la pantalla la resolución varía. Por ejemplo, para el caso de las de 3.8′’ la resolución es de 320×240 pixels y para la 19′’ pues de 1280×1024 pixels.
 
 

 
Hablas de que puedes controlar gráficamente PLCs   ¿pero qué PLCs?   Porque existen multitud de marcas, como Siemens, Schneider, Rockwell, Omron,  Mitsubishi, Fuji, …

Pues hablo de todos. Las pantallas de Proface implementan todos los protocolos de todos (de la inmensa mayoría) de los fabricantes de PLCs . Cada vez que un fabricante lanza un nuevo modelo de PLC al mercado, a los pocos días Pro-face saca en su web una actualización con nuevos drivers para esos nuevos PLC. Con esto se ganan la vida y por lo que se ve, son los mejores.
 
 

Osea que con una pantalla de proface puedo controlar un PLC de un determinado fabricante, que no tiene nada que ver con Pro-face …

Efectivamente. Pero es que no sólo uno. Las pantallas de Pro-face son lo que se llama multiprotocolo. ¿Que qué significa multiprotocolo? Pues que si tengo la necesidad puedo controlar, desde una única pantalla táctil, hasta 4 tipos de dispositivos ó PLCs de distintos fabricantes, esto es, dispositivos que “hablan” distintos protocolos. Más gráficamente lo veréis en el siguiente gráfico. Fijáos como cada tipo de dispositivo (protocolo) cuelga de un determinado bus (RS232, RS485, Ethernet, …)
 

Realmente hay que decir que no con todas las pantallas puedes controlar 4 tipos de dispositivos. Ésto sólo es posible con las pantallas mayores a 5.7′’.  En las de 5.7′’ o menor tamaño “sólo” puedes gestionar de forma simultánea 2 protocolos.
 
 

¿Y cómo se programas las pantallas? ¿Hay un software especial?

Sí, el software GP-Pro-Ex.  No es un software gratuito, es decir, hay que pagar licencia, aunque las actualizaciones de subversiones son gratuitas. Lo tienen en la web y se puede descargar en versión demo. Es completamente funcional y lo único que no puedes hacer es exportar la configuración a una pantalla. Pero el software tiene una opción muy chula de simulación, es decir, que ves exactamente lo que verías en una pantalla táctil de Pro-face, por lo que para evaluar el producto, la demo, sirve muy bien. Además el soft es único para todas las pantallas, es decir, una vez adquieres una licencia, puedes programar con él todas las pantallas de Pro-face.
 

Y respecto a la programación física de las pantallas decir que puede hacerse tanto por un pendrive USB como por ethernet (las pantallas que tengan ethernet, claro). Lo de poder programarlas por USB está muy bien, pues puedes crear una configuración de pantalla en la oficina mediante el software GP-Pro-ex, exportar la configuración y enviarla por email a la otra parte del mundo, donde la pueden copiar en una llave USB con la que actualizar posteriormente la pantalla, evitando así desplazamientos. También, para quien lo esté pensando (que aquí hay mucho GSMero ) permite actualizarse mediante módem.
 
 

¿Pero en qué consiste el software? ¿Qué hace?

El software es increiblemente extenso y completo, aunque también cuenta con una muy completa documentación. Sintetizando al máximo puedo decir es un editor el cual te permite crear pantallas, a las que puedes agregar multitud de botones, figuras, gráficos (graficos en los que uno mismo si quiere puede hacerse sus propias librerías aunque hay miles de serie), scripts, controles horarios, … en fin, todo lo necesario para poder realizar la aplicación que desees de control sobre PLC.
 
 

Hablas de scripts … ¿significa que puedes programar dentro de las pantallas?

Sí. Te permite realizar scripts (o pequeños programitas). Aparte de para usarlos con PLCs es una opción muy interesante, porque por ejemplo, mediante un script podemos crear nuestro propio protocolo de comunicaciones. ¿Y para qué quiero eso?  Pues imagina un módem gprs+gps como el MTX65+G al que le quiero poner una pantallita táctil para una determinada aplicación. Podría crearme un protocolo de comunicaciones propietario en Java dentro del módem y podría comunicarme con la pantalla táctil implementando mediante scripts. Quien dice un módem dice un micro o cualquier otro dispositivo.

Otra opción muy interesante de los scripts, hablando ya más de PLC, es que puedes crear pasarelas de protocolos. Quiero decir, por ejemplo, que podría copiar variables internas de un PLC de un fabricante a otro PLC de otro fabricante, es decir, con distintos protocolos.
 
 

¿Y a la pantalla se le pueden contectar periféricos?

Pues sí. En muchas ocasiones, pese a ser táctil, puede ser interesante como modo de introducción de datos, conectar un lector de código de barras, o un ratón, un teclado USB, … Es posible conectarlos. La pantalla los reconoce.
 
 

¿Y una impresora para salida de datos?

También. Y aquí hay dos opciones. Por un lado puedes conectar directamente una impresora a la pantalla, pues las pantallas de Pro-face disponen de muchos drivers preinstalados de las impresoras más comunes. Y si por lo que sea no tiene el driver, tienen un programilla que, instalado en un PC de la red, te deja imprimir en la impresora que esté asociada a ese PC.

Y ya que hablamos de salida de datos, piensa también que usando una llave USB o una memoria CFlash puedes exportar datos a esas memorias para poderlos procesar en cualquier momento. Puedes exportarlos si los deseas en formato CSV, para poder verlos en Excel.
 
 

¿Puedo hacer aplicaciones multimedia con video y audio?

Depende. Algunas de las pantallas cuentan con entradas de vídeo. Con éstas sí puedes hacerlo. Un ejemplo de aplicación, por ejemplo, si tienes una cámara de vídeo conectada a la pantalla, es poder ir grabando 20 segundos de vídeo de forma cíclica en la llave USB o en una CFlash y cuando salte una alarma, reproducir un fichero de audio y a partir de ese momento grabar de forma continua (no cíclica) el vídeo, de esa manera tendríamos grabados los 20 segundos previos a cuando saltó la alarma y todo lo de después.  O dividir la pantalla en 4 y mostrar distintos vídeos etc … Todas estas cosas se pueden hacer con las pantallas de Pro-face.
 
 

Necesito poder hacer las aplicaciones para varios paises, es decir, en varios idiomas. ¿Es posible?

Sí, es posible. Cuando diseñas una pantalla puedes poner los textos estáticos o bien dinámicos, es decir, que vengan de una tabla de idiomas. En esa tabla, por ejemplo, en la columna 1 pones los textos en castellano, en la 2 en inglés, … y después cada texto en pantalla lo asocias a una determinada fila de la tabla, y, dependiendo del idioma en que estemos, la pantalla cogerá el texto de una u otra columna, mostrando un idioma o el otro.
 
 

¿Y de temas de seguridad cómo andamos?

Pues si nos referimos a que nos puedan copiar la programación de las pantallas decir que no, que puedes incluir un password para que nadie pueda extraer el programa de la pantalla y aprovecharse de nuestro trabajo.

Y si hablamos a la seguridad interna de la aplicación, decir que con el software de configuración GP-Pro-Ex puedes crear una aplicación para que forzosamente se pida al usuario de la pantalla un login y password previo, o que te lo pida para entrar sólo en determinadas pantallas, o establecer distintos niveles de privilegios para las distintas pantallas, es decir, para que no todos los usuarios puedan entrar en cuaquier parte de la aplicación, etc …

También tiene una opción para grabar absolutamente todo. Es decir, podemos ir grabando en una memoria USB o CFlash todas las operaciones y acciones que realice cualquier usuario de una pantalla de Pro-face. Esto está muy bien para empresas en las que el nivel de seguridad exigido es muy alto y quieran registrar todas las acciones que realice el personal.
 
 

¿Hay algún tipo de control remoto, tipo VNC?

Sí. Con todas las pantallas que tienen Ethernet puede usarse GPViewer. Es decir, desde un PC podemos ver y operar como si estuviéramos en la propia pantalla, tipo VNC o terminal server.  De igual forma hay varios modos de funcionamiento. Por ejemplo podemos hacer que el usuario de la pantalla vea todas las acciones que realizamos de forma remota desde nuestro PC o bien que no vea nada de lo que hacemos.

 
Bueno, espero que os haya resultado interesante por si alguna vez usáis PLCs. Otro día más.
 
 

Básicamente el estándar IEC60529 es un sistema de clasificación para los diferentes grados de protección de los contenedores de los dispositivos electrónicos.
 

No entiendo ¿qué quieres decir?

Hablando de forma más simple, si dispones de una electrónica la cual esta dento de una caja o de un molde de plástico o dentro de lo que sea, este estándar indica el grado de protección y estanqueidad ( frente agua y partículas ) de dicha caja o molde. En definitiva, indica cómo está de protegida la electrónica que guarda en su interior. Esto, los que no conozcáis todavía este estándar, lo veréis como requisito de dispositivos en multitud de proyectos y de concursos, sobre todo, de aquellas partes que deben instalarse a la intemperie.
 

¿Y cómo se define el grado de protección de una caja o contenedor?

Pues por ejemplo, podéis ver en algún datasheet que un determinado dispositivo tiene una protección IP55, IP65, IP67, … Estos valores, 55, 65, 67 o los que sean, tienen un significado. Por ejemplo, las cajas de Bopla (Bopla es una empresa de cajas que distribuye Matrix en España) que aparecen en la siguiente imágen:

son de IP65, una proteción alta.
 

Muy bien, ¿pero qué significa exactamente el 65?

Pues una protección IP”xy” tiene distinto significado en función de “x” e “y”.  La “x” hace referencia al grado de protección frente a partículas y la “y” hace referencia al grado de protección frente al agua.
 

¿Y cuales son los diferentes grados de protección “x”, es decir, frente a partículas?

x=0
No protegido.

x=1
Protegido frente a objetos sólidos mayores de 50mm de diámetro.
Es decir, que un objeto de 50mm no debe poder entrar en el interior de la caja

x=2
Protegido frente a objetos sólidos mayores de 12.5mm de diámetro
Un objeto de 12.5mm no debe poder entrar en el interior de la caja

x=3
Protegido frente a objetos sólidos mayores de 2.5mm de diámetro
Un objeto de 2.5mm no debe poder entrar en el interior de la caja

x=4
Protegido frente a objetos sólidos mayores de 1mm de diámetro
Un objeto de 1mm no debe poder entrar en el interior de la caja

x=5
Protegido frente al polvo
No evita que entre algo de polvo. Pero el polvo que entre no debe interferir en el buen fucionamiento de la circuitería

x=6
Protegido totalmente frente al polvo
Evita totalmente la entrada de la más mínima partícula de polvo.
 
 

¿Y diferentes grados de protección “y”, es decir, frente a agua?

y=0
No protegido.

y=1
Protegido frente a caida de agua.
Volcando agua desde arriba (de 3 a 5 mm3) durante 10 minutos no debe entrar agua

y=2
Protegido frente a caida de agua con diferentes ángulos
Volcando agua  (de 3 a 5 mm3) durante 10 minutos no debe entrar agua. Se realiza la prueba 4 veces, con variaciones de ángulo en sentido horizontal y vertical de 15º

y=3
Protegido frente a agua pulverizada
No debe entrar agua pulverizanda durante 5 minutos hasta 10 litros de agua por minuto con hasta 60º de inclinación y una presión de hasta 100kN/m2

y=4
Protegido frente a agua arrojada
No debe entrar agua lanzada durante 5 minutos sobre el contenedor desde cualquier ángulo. Hasta 10 litros de agua por minuto con una presión de hasta 100kN/m2

y=5
Protegido frente a chorros de agua
No debe entrar agua durante 3 minutos lanzada a chorro (12.5 litros / minuto) desde una distancia mayor a 3 metros con una presión de 30kN/m2.

y=6
Protegido frente a chorros potentes de agua
No debe entrar agua durante 3 minutos lanzada a chorro (100 litros / minuto) desde una distancia mayor a 3 metros con una presión de 100kN/m2.

y=7
Protegido frente a immersiones en agua
No debe entrar agua durante 30 minutos a una profundidad de 1 metro.

y=8
Protegido frente a immersiones prolongadas en agua
Condiciones especificadas por el fabricante y que sean más severas que las especificadas en el punto 7.

Entonces, por ejemplo, la estanqueidad de las cajas del ejemplo anterior IP65 (las de la foto) significa que están totalmente protegidas frente al polvo (x=6) y protegida frente a chorros de agua (y=5).
 
 
Espero que algún día encontréis de utilidad este artículo. Otro día más
 
 
Actualización:   en el blog de electronicapascual.com podéis encontrar una interesante ampliación de este artículo.
 
 

Hoy simplemente quiero hacer un pequeño pero interesante apunte a un artículo sobre la tendencia del tamaño de las pantallas de los teléfonos móviles. Este dato tiene cierta importancia en sistemas de marketing de proximidad, pues en ocasiones es necesario adaptar los contenidos que se envían a los móviles desde los Access Servers para que sean bien visualizados en los distintos tamaños de pantalla que componen el parqué de móviles. Hay que tener presente también que cada vez son más los teléfonos móviles que reescalan las imágenes automáticamente al tamaño de su propia pantalla, pero por el momento es interesante enviar los contenidos con el tamaño más adecuado posible para que no sea necesario que los telefonos reescalen la imagen, pues la calidad de reescalado, por el momento, es mejor si está hecha con Photoshop que si la hace el propio terminal.

El artículo al que quiero hacer referencia y que es interesante de leer lo podéis encontrar aquí:
http://sender11.typepad.com/sender11/2008/04/mobile-screen-s.html

En él puede verse claramente que la tendencia del tamaño de las pantallas de teléfonos móviles es de 240×320, claramente al alza, mientras que los otros tamaños también comunes, como 128×128/160 y 176×208/200 van claramente a la baja, por lo que creo que lo más adecuado a día de hoy es generar contenidos formateados principalmente para 240×320.

Aquí tenéis el gráfico de tendencias:

Y ya por último comentar una intuición, y es que en muy poco tiempo, al menos en España, las pantallas con formato 320 x 480 también van a ser muy pero que muy populares, pues al parecer Telefónica va a sacar al mercado en exclusiva el iPhone 3G (de Apple) a 99€. He de reconocer que si eso es así, un servidor que ha sido fiel a su antigua operadora durante los últimos 10 años, dejará de serlo

Lo primero que tenemos que tener claro es que debemos contar con una dirección IP de Internet fija (no dinámica) en nuestra oficina. Una vez la tengamos seleccionamos un ordenador el cual hará de servidor. También puede utilizarse un servidor IIS (Windows), Apache (Linux) o el que queráis y sepáis configurar, pero yo en este caso no voy a utilizar ninguno de estos Servidores, sino un pequeño software gratuito, de nombre HFS, que puedes instalar en cualquier PC Windows y que es muy sencillote al mismo tiempo que completo (puedes gestionar permisos de directorios y demás).

Pues vamos allá. Una vez instalado el programita arrastramos los ficheros .JAD y .JAR al directorio raíz de nuestro servidor de ficheros, tal y como aparece en la captura de la pantalla de debajo. Hecho esto, asignaremos permisos al directorio raiz haciendo clic con el botón derecho del ratón en el directorio del home (el icono de la casita ) y especificamos por ejemplo user blogElectronica y password blogElectronica. Veremos que si asignamos un login y password aparece un candado.

Escogemos qué puerto vamos a utilizar en el servidor de ficheros. Si utilizamos por ejemplo el puerto 20010, debemos especificarlo en la casilla Port. Una vez hecho esto ya sólo nos queda pulsar el botón de ON y el servidor lo tendremos en marcha. Bueno, quedaría también hacer NAT en el router de nuestra oficina, mapeando el puerto TCP 20010 del router al puerto TCP 20010 del PC donde se encuentre instalado el software HFS. ¡Y ya lo tenemos listo!

Sólo un detalle, no olvidar indicar en el fichero .JAD que hemos puesto en el servidor la ruta completa al fichero .JAR. Por ejemplo, el fichero .JAD debe contener una línea similar a:

Midlet-Jar-URL: http://217.126.x.x:20010/HelloWorld.jar

También acordaros que hemos puesto login y password al servidor de ficheros, por lo que debe tenerse en cuenta en el proceso de OTAP. En el ejemplo que puse hace unos días, debería configurarse el módem tal que así:

AT^SJOTAP=”blogElectronica”,”http://217.126.x.x:20010/HelloWorld.jad”,”a:”, “blogElectronica“,”blogElectronica“,”gprs”,”airtelnet.es”, ”vodafone”,”vodafone”,”080.058.000.033″,

Bueno, espero que os haya resultado de interés, otro día más.

Pues hoy voy a poner un pequeño post muy práctico sobre cómo iniciar un proceso OTAP con un SMS. Hay varias maneras de plantear el proceso. Yo lo voy a plantear de la manera más sencilla para que todo el mundo que haga los pasos que voy a poner a continuación realice la práctica sin problemas.
 

Vamos a plantear que tenemos grabados los datos del OTAP en el módem antes de enviar el SMS. Podría enviarse desde SMSs, pero por comodidad voy a ponerlo como si estuvien pregrabados en la configuración del módem.

Para ello escribimos (ojo con las comillas):

AT^SJOTAP=”blogElectronica”,”http://www.blogelectronica.com/TEMP/
HelloWorld.jad”,”a:”,,,”gprs”,”airtelnet.es”,”vodafone”,”vodafone”,”080.058.000.033″,

Si apagamos el módem y lo volvemos a encender podemos ver que esta información es no volátil con el comando AT^SJOTAP?

Bueno, hecho esto ya tenemos al módem listo. Ahora podemos enviar un mensaje SMS al módem para iniciar el proceso de OTAP. Como yo soy pobre y en casa tengo sólo un módem (y prestao ), voy a enviar desde el propio módem el SMS a sí mismo.

Para ello, configuro mensajes SMS de texto (sí, de texto, no PDU )

at+cmgf=1
OK

Configuramos los parámetros de los SMS:

at+csmp=17,167,0,245
OK

Y con todo esto ya sólo nos queda enviar el mensaje SMS con el texto:

OTAP_IMPNG
PWD:blogElectronica
START:install

Evidentemente no lo vamos a enviar tal cual. Lo convertiremos a hexadecimal, igual que lo haríamos en una codificación PDU de 8bits. Está “chupao”, substituimos cada carácter por su correspondiente valor ascii en hexadecimal (O=4F, T=54, A=41, P=50, …. . También recordar que el fin de cada línea debe acabar en 0A (incluida la última línea)
 
Para los remolones os pongo aquí un programita que acabo de hacer que codifica el texto SMS de forma adecuada a hexadecimal (También os incluyo el proyecto con el código fuente, hecho en Visual Basic 6.0 para quien lo quiera utilizar, copiar o curiosear).
 

Como podéis ver el código fuente de este programita es muy simplón:

cadena = “”
valorHex = “”
For i = 1 To Len(Text1.Text)
valorHex = Hex(Asc(Mid(Text1.Text, i, 1)))
If Len(valorHex) = 1 Then valorHex = “0″ & valorHex
cadena = cadena & valorHex
Next i
If valorHex <> “0A” Then cadena = cadena & “0A”
cadena = Replace(cadena, “0D”, “”)
Text2.Text = cadena

Bueno, hecho esto ya podemos enviar el SMS al módem. Para ello enviamos el comando at+cmgs (ya sabéis, primero se envía el at+cmgs=nº de teléfono y pulsamos ENTER, luego pegamos la cadena larga en hexadecimal que hemos obtenido utilizando el programita que os he colgado y pulsamos CTRL+z El SMS se enviará en un instante.
 

at+cmgs=66627xxxx

>4F5441505F494D504E470A5057443A626C6F67456C656374726F6E69
63610A53544152543A696E7374616C6C0A

Pasados unos segundos veréis como el led del módem empieza a parpadear de forma diferente, señal que está realizando el OTAP. Al finalizar el proceso el módem se autoresetea y podréis ver con el MES cómo ha cargado los ficheros HelloWorld.jar y .jad en el módem.
 

Espero que os resulte de interés. Otro día más.
 
 

Este software, aunque yo lo llame Entrenador de Siemens, no es de Siemens, sino que sirve para facilitar un poco la introducción a las personas que se inician con los módems de Siemens. Este es un software que programé yo hace ya un año y medio aproximadamente. Es un software que Matrix ofrece gratuitamente a sus clientes. Es como una espécie de hyperterminal de Windows, pero donde tienes una serie de botones clasificados para no tener que escribir los comandos AT ni sabértelos de memoria.

Como he hecho yo este software, si lo estás utilizando y crees que le falta algo (y que puede ser de interés para más gente) puedes aprovechar para decírmelo y lo incluyo en siguientes versiones

El software básicamente puedes utilizarlo con los módems gprs MC55, MC55i, TC63, TC65 y XT65 y los terminales gprs MTX63, MTX65, MTX65+G y TC65T. Si te fijas en la parte superior del Entrenador, puedes ver que está dividido por secciones, como Llamadas de voz, Mensajería SMS, Comunicaciones GPRS, Varios y GPS. En cada una de esas divisiones se encuentran los comandos más utilizados para cada funcionalidad (ojo, sólo he puesto los más básicos, recuerda que hay cientos de comandos AT).

Bueno pues vamos allá, veamos cada una de las secciones. Si haces click con el ratón encima de cada imágen la verás ampliada.
 
 

Llamadas de voz.

En esta pantalla puedes utilizar los comandos AT relativos al audio. Puedes establecer los distintos perfiles de audio (AT^SNFS) así como los distintos interfaces de Audio (AT^SAIC). También puedes cambiar los parámetros de ganancias de entrada y salida de audio (AT^SNFI y AT^SNFO). Si te fijas en la pantalla verás que esto último se modifica con sliders, esos scrolls horizontales de desplazamiento. Esto resulta muy cómodo si quieres ajustar y afinar el audio en tu aplicación.

Desde esta pantalla también puedes introducir el PIN del módem y realizar una llamada de audio. También si te fijas a la derecha hay un teléfono móvil. Una vez establecida una comunicación de audio puedes pulsar el teclado numérico del teléfono para enviar tonos DTMF.

Por último abajo tienes una serie de botoncitos, AT Test, AT+csq, … que son unos comandos utilizados habitualmente y que he puesto ahí por comodidad.
 

 
 
Mensajería SMS.

Aquí tienes los comandos básicos para enviar mensajes SMS de texto y poder leer y borrar SMS. Sí, sólo deja enviar mensajes SMS de texto, no me pidas que añada los PDU, que me lleva mucho tiempo Si alguien me pasa alguna DLL u OCX para formatear a PDU, lo incluyo sin problemas.
 

 
 
Comunicaciones GPRS.

Esta es la parte más interesante de todo el entrenador. Te permite aprender de manera muy fácil como establecer comunicaciones GPRS con sockets utilizando los módems de Siemens, ya sean conexiones socket cliente o conexiones socket servidor. Alguna vez he incluido un link a un vídeo que hice sobre cómo crear una conexión GPRS contra un servidor con el entrenador.

En la parte derecha de esta pantalla, puedes ver unos frames de color anaranjado. El de arriba a la derecha tiene título “Cliente TCP/IP”. Esta es una utilidad que simplemente introduciendo una IP y un puerto y pulsando en el botón “Conectar” establece una conexión cliente desde tu PC. Esto resulta muy útil si configuras una conexión “Servidor” en el módem y quieres probarla, pues te conectarás directamente desde tu PC al módem y podrás enviar y recibir datos.

De la misma manera, en la parte inferior derecha tienes una utilidad para montar un servidor TCP en tu PC. Simplemente introduce el puerto en escucha y pulsa el botón “Run/Stop” para arrancar/parar el servidor. Esto resulta múy útil cuando configuras una conexión cliente en el módem Siemens, pues puedes probar la conexión conectándote a tu propio ordenador. Para esto último recuerda hacer NAT en tu router con el puerto que selecciones.
 

 
 
Varios.

Aquí simplemente pones el nombre de un programa java que tengas dentro del módem y lo ejecutará. Obviamente este comando es sólo útil para los modelos de módems que puedes programar en Java, como el TC65, XT65, TC65T, MTX65 y MTX65+G.
 

 
 
GPS.

Esta sección es únicamente para el módem XT65 y el terminal MTX65+G. Desde aquí tienes los comandos AT más importantes para que puedas configurar de una manera sencillísima el GPS del módem. Podrás arrancar el GPS, pararlo, configurarlo en módo transparente o no, leer los datos del almanaque, las efeméresis … todo de manera sencilla.

También en la parte inferior derecha he puesto una referencia a Google Maps, para que puedas ver en tiempo real y muy gráficamente la posición GPS sobre un mapa según te la va dando el módem. (Chulo, ¿verdad? ). Por cierto, en la imágen veréis que aparece Cardedeu, donde yo vivo, un pueblecito cerca de Barcelona, a unos 35Km aprox.

Para quien no sepa cómo hacer lo de Google Maps y le interese o tenga curiosidad, he puesto un botón en el soft con el título “Código fuente Google” donde se muestra el código fuente en ASP que hice para poder hacer esto. De todas maneras, si hay interés, puedo poner algún día algún articulillo rápido en el blog de cómo utilizar la API de Google Maps.
 

 
 

Espero que haya sido de interés. Otro día más.
 
 

El nombre del nuevo dispositivo es MTX-Tunnel. Básicamente es un gateway serie-gprs pensado para aplicaciones de telemantenimiento, es decir, para evitar desplazamientos por el simple hecho de conectar un cable serie RS232 a un dispostivo. Existen otras soluciones, ya las he comentado por aquí alguna vez, como algunos routers de Digi, pero este tiene ciertas ventajas como podréis ver después.
 

  
Para ser sincero debo decir que para mi este dispositivo es especial, pues he participado bastante en el firmware que va dentro del MTX65 y cuyo conjunto da nombre al MTX-Tunnel.
 
Dicho esto, y para quien le interese, pongo más información de la manera que lo suelo hacer, ya sabéis, en modo pregunta / respuesta:
 

¿Para qué sirve el dispositivo MTX-Tunnel?

El MTX-tunnel es básicamente un gateway serie-GPRS, lo que permite poder conectar con cuaquier dispositivo RS232 a distancia evitando desplazamientos. Lo mismo que podrías hacer conectando un cable serie RS232 al equipo, lo puedes hacer de forma remota a través de GPRS.
 
 
¿La configuración del equipo es muy complicada?

En absoluto, es muy sencilla. Básicamente consiste en editar un fichero con el bloc de notas para configurar ciertos parámetros (IP, puerto, baudios, …). Una vez realizada la configuración, basta con arrastrar el fichero dentro del modem, como si fuera un pendrive. El MTX-Tunnel estará en ese momento configurado. Es decir, editando el fichero .jad donde hay una serie de parámetros.
 
  
¿Y cómo funciona? ¿El MTX-Tunnel es quien se conecta a un servidor por GPRS ó espera recibir conexiones? O lo que es lo mismo ¿se comporta como cliente o servidor?

Pues puede configurarse para trabajar de las dos maneras.

En modo cliente el MTX-Tunnel, al conectar la alimentación, lo que hace es conectarse automáticamente a un servidor con una IP y puerto determinados (especificados en el fichero de configuración). Una vez establecida la conexión con el servidor, todos los datos que le llegan desde el servidor por el socket TCP/IP a través de GPRS, los emite por el puerto serie, y viceversa, todos los datos que le entran por el puerto serie los envía por el socket a través de GPRS hacia el servidor.

En módo servidor, el MTX-tunnel se conecta a GPRS y se queda a la escucha por un determinado puerto a la espera de recibir una conexión externa. En el momento que reciba dicha conexión se comporta igual que en el caso anterior. Lo que le llega por GPRS lo emite por el puerto serie RS232 y viceversa.
  
 
¿El MTX-Tunnel en modo cliente tiene que tener una tarjeta SIM con dirección IP fija?

No. En este modo, al ser el MTX-Tunnel quien realiza la conexión no es necesario tener una IP fija. El servidor al cual se conecte el MTX-Tunnel sí debe tener un dirección IP fija.
 
 
 ¿Y si el MTX-Tunnel está en modo servidor es obligatorio tener IP fija?

Es aconsejable, pero tampoco es imprescindible. Si cuentas con una tarjeta SIM con IP fija realizar una conexión es muy rápido. Si no sabes la IP debes averiguar la dirección IP que asigne el operador al MTX-Tunnel cuando se conecte a GPRS
  
 
¿Y cómo se puede averiguar la dirección IP que ha asignado el operador al MTX-Tunnel?

Hay dos maneras. Puedes hacer una llamada perdida al MTX-Tunnel o bien enviar un SMS. Si el MTX-Tunnel está configurado para ello (indicado en el fichero de configuración) el MTX-Tunnel enviará un SMS con la dirección IP que le ha asignado el operador al teléfono que realizó la llamada perdida o que envió el SMS.
  
 
Entonces, ¿cualquiera que por equivocación haga una llamada perdida puede recibir la IP del equipo?

No. En el fichero de configuración del MTX-Tunnel pueden establecerse hasta 10 números de teléfonos válidos desde los cuales pueden solicitarse acciones, entre ellas la acción de enviar la dirección IP. Si el teléfono no es válido el MTX-Tunnel no hace nada.
  
 
¿El MTX-Tunnel tiene que estar permanentemente conectado a GPRS?

Depende. En modo cliente sí, pues la conexión es permanente. En cuando el equipo recibe alimentación se conecta a una determinada dirección IP y puerto como comentábamos anteriormente. Si se corta la comunicación por cualquier motivo, el MTX-Tunnel reintenta una y otra vez la conexión hasta conectarse.

En modo servidor no es necesario estar permanentemente conectado a GPRS. Si queremos que se conecte en un determinado momento a GPRS basta con realizar una llamada perdida o enviar un SMS con la palabra “on”. En ese momento se conectará a GPRS y como decíamos en el punto 6, si está configurado para ello enviará un SMS con la dirección IP que le asigna el operador.
  
 
¿Y si el MTX-Tunnel está en modo servidor y no quiero que la conexión sea permanente, una vez que la activas remotamente con la llamada perdida o el SMS, cómo se desconecta la conexión GPRS?

En el fichero de configuración puedes definir un timeout. Imagina que configuras 3 minutos. Si en 3 minutos el MTX-Tunnel no detecta tráfico proviniente de GPRS automáticamente se desconecta de la red GPRS.
  
 
¿Y si el MTX-Tunnel trabaja en modo servidor, puede conectarse cualquier IP a él?

No. Al igual que con los número de teléfono, en el fichero de configuración pueden definirse hasta 10 IPs desde donde pueden recibirse conexiones. Cualquier intento de conexión de una IP no autorizada es abortado.
  
 
¿Se puede configurar los parámetros del puerto serie del MTX-Tunnel?

Por supuesto. Puedes cambiar el baudrate, el control de flujo, los bits de datos y los bits de stop. Como siempre todo a través del fichero de configuración.
 
 
¿Puedo tener algún problema con alguna aplicación que utilice hasta la fecha con un cable serie y substituyo el cable por un MTX-Tunnel?

Por lo general no, pero hay un caso que debes tener presente. Y es que las comunicaciones GPRS son rápidas pero tienen cierto retardo (al igual que no es lo mismo trabajar en una LAN que a través de Internet). Me explico. Si tú tienes una aplicación pregunta-respuesta (típico caso de un PC que le pregunta a un sensor de temperatura) tienes que tener en cuenta que desde que mandas el comando por GPRS hasta que recibes respuesta con el dato del sensor evidentemente tendrás más retardo del que tendrías si utilizas un cable. Es lo único que tienes que tener presente.
 
 
Espero que lo hayáis encontrado de interés. Otro día más. Buen fin de semana.

Ahora ya vuelta a la carga. Como dice el título del post reestreno el foro forumElectronica.com.  Y es que en su día quise hacer un foro muy ambicioso, con todas las áreas que comprende el mundo electrónico, pero no ha salido como yo esperaba así que toca cambiar. Analizando todos los post de blogElectronica no es difícil ver que los posts de más éxito (con más participación) son los relativos a módems Siemens GSM/GPRS/GPS/UMTS y a los dispositivos bluetooth, por lo tanto voy a ir especializando forumElectronica.com abriendo temas relacionados con los posts de más éxito de este blog que creo es lo más sensato.
 

De hecho pienso que es buena idea tener el foro relacionado con este blog, pues llega un punto en que es complicado mantener una conversación en los comentarios de un post cuando hay docenas y docenas de comentarios. Espero que el foro sea de agrado para todos y cualquier sugerencia constructiva será bienvenida, sobre todo si es para abrir nuevos temas que consideréis interesantes.
 
 

Y ya que estoy hablando de webs, como curiosidad decir que un tiempo también espero reestrenar otro portal tecnológico en un tiempo. Quien me conoce sabe que me gusta mucho la electrónica (pues es con lo que más me gano la vida) pero lo que me encanta es Internet. De hecho tengo ya más de 100 páginas webs de todo tipo (entre ellas suman varios cientos de miles de páginas vistas al mes) aunque gracias a Dios la mayoría de ellas o son estáticas o “trabajan casi solas”.  El portal que espero reestrenar en un tiempo fue uno que hice hará ya unos 6 años, fue de mis primeros portales, pero pese a que empezó como un hobbye ha ido creciendo y no le estoy dando la antención que merece en la actualidad. El portal es TecnoJobs.com un portal de empleo técnico al que voy a darle un nuevo look que seguro a alguno le suena

En fin ya iré comentando en alguna ocasión otras webs mías para quien tenga curiosidad. Mañana publicaré un post de un equipo gateway RS232-GPRS para operaciones de telemantenimiento que puede ser interesante para algunos.

Hasta mañana.
 

Para quien no lo sepa, el módem GPRS Siemens MC55 es un módem tribanda (900/1800/1900)  GPRS de clase 10, de dimensiones muy pequeñas (35 x 32.5 x 2.95 mm) y que cuenta con la pila TCP/IP integrada, es decir, podermos crear distintos tipos conexiones TCP/IP a través de comandos AT.  Puedes ver las características completas en este datasheet.

Pues bien, acaba de salir el nuevo módem Siemens GSM/GPRS MC55i. Aquí podéis ver el datasheet.

 
¿Y qué diferencias tiene con el modelo anterior MC55?

En general básicamente son iguales en prestaciones y es de idénticas dimensiones, pero cuenta con una serie de mejoras muy importantes que limitaban un poquito el modelo anterior. Por ejemplo, esta nueva versión de módem GSM Siemens MC55i, tenemos un módem cuatribanda (850/900/1800/1900MHz) a diferencia del modelo anterior, que como comentaba es tribanda. Esta característica es imprescindible si pretendemos exportar nuestros equipos por todo el mundo. Por otro lado, este nuevo modelo acepta tarjetas SIM de 1.8V y de 3V, mientras que el modelo predecesor acepta únicamente tarjetas SIM de 3V. La tendencia del mercado es ir hacia los 1.8V, por lo que es muy importante esta característica de cara al futuro.También cuenta con los drivers RIL para Microsoft Windows Mobile 6 (el anterior para la versión 5 de Windows Mobile) y cuenta también con el driver multiplex para Windows XP y Windows Vista.

 
¿Y si quiero utilizar este modelo en lugar del anterior en mis equipos, he de rediseñar parte de mi hardware?

No. Este nuevo modelo Siemens MC55i es compatible con su predecesor, por lo que no hay que rediseñar nada. Sacar uno y poner el otro. Un punto a favor de Siemens que hayan mejorado el producto manteniendo la compatibilidad.
 

Espero que los muchos que utilizáis el módem MC55 encontréis interesante este pequeño artículo.

CSR vende chips bluetooth, no módulos bluetooth. Decir que utilizar estos chips no es sencillo, es más, es muy complicado, absolutamente nada que ver con utilizar un módulo bluetooth como los módulos bluetooth de Bluegiga (que por cierto, tienen en su interior un chip de CSR). Los chips de CSR están pensados para aquellas empresas que pretendan vender grandes cantidades de equipos, es decir, cuando hablamos de más de 20.000/30.000 equipos al año, entonces sí sale a cuenta, económicamente hablando, meterse a nivel de chip. Cantidades más pequeñas no compensa y es mejor trabajar con módulos.
 

¿Y en qué consisten los chips bluetooth de CSR?

CSR fabrica los chips que llama Bluecore. Tiene varias familias de chips que han ido desarrollando a lo largo de los últimos años. Actualmente tienen el Bluecore3, Bluecore4, Bluecore5, cada uno de ellos con distintas variantes, y el nuevo Bluecore6 (únicamente versión ROM por el momento),

El Bluecore 3 y Bluecore 5 están más pensados para aplicaciones de audio, mientras que Bluecore 4 está más pensado para aplicaciones de datos y es algo más económico (pues no tiene DSP). Veamos un diagrama que muestra cómo es internamente uno de estos Bluecore. Veamos el Bluecore5.

Como véis este chip es una solución completa, pues a nivel interno cuenta con una parte de radio, una memoria RAM, un codec de audio, un microprocesador RISC y un potente DSP (Kalimba) utilizado por los codecs para MP3, AAC, …  Lo único que tiene esta versión de Bluecore5, a diferencia de la Bluecore3, es la memoria FLASH externa. En Bluecore3 puede tener la memoria FLASH interna o externa, pero es menos potente a nivel de DSP y procesador.

En cuanto a buses, pues la lo véis en el diagrama, el chip cuenta con un bus UART o USB, GPIOs, entrada / salida de audio, PCM/SPDIF y SPI.
 

¿Y puede programarse el micro de este Bluecore?

Sí. Puedes programar este chip con tus propios programas. Todo el proceso de programación y debug de la aplicación se hace a través del puerto SPI.
 

Entiendo que si haces una aplicación embebida en este chip estamos utilizando la “pila interna” bluetooth del chip de CSR.  Pero, ¿puede utilizarse este chip simplemente como una “antena bluetooth” utilizando la pila bluetooth de un PC o procesador externo?

Efectivamente. Los chips de CSR tienen lo que ellos llaman las PSKeys, que son cómo unos valores de configuración no volátiles. Una de estas PSKeys sirve para indicar si el control del chip será a través de HCI, es decir, controlado por un PC o procesador externo a través del puerto serie o USB o bien tomará el control la aplicación embebida dentro del propio chip.
 

¿Y cómo es el entorno de desarrollo de CSR?

Bueno, para desarrollar aplicaciones para los chips de CSR se utiliza el entorno BlueLab, un entorno de desarrollo, similar en aspecto a Visual Studio o similares, con el que se puede crear aplicaciones customizadas.
 

¿Y hay ejemplos y librerías?

Sí, el entorno tiene muchos ejemplos y librerías (da un vistazo a www.csrsupport.com ) , pero como dije en el inicio del post, no son sencillos. Básicamente la programación se basa en utilizar los cientos de funciones con las que cuenta el entorno de CSR. Cuando compiles tu aplicación, ésta se ejecutará sobre una máquina virtual, es decir, no vas a generar código que se ejecute directamente sobre el procesador del chip, sino sobre una capa de software superior, teniendo siempre la máquina virtual de CSR corriendo por debajo de tu aplicación.
 

¿Y hay otras utilidades de desarrollo?

Sí, por ejemplo también tienen lo que llaman el Bluesuite, un conjunto de utilidades. Está por ejemplo la utilidad PSTools, con las que podrás cambiar las PSKeys del micro, el BlueFlash, una utilidad para programar la flash del micro …
 

¿Y si yo quiero utilizar CSR y luego poner el logo bluetooth en mis equipos, puedo hacerlo?

Sí, previo pago de todas las certificaciones correspondientes. Prepara 30.000 euros. Piensa que los chips de CSR no son un end product. Por eso es conveniente utilizar CSR para cantidades muy grandes, pues si pretendes hacer pocos miles de unidades, entre los costes del entorno de desarrollo de CSR, los costes de certificaciones, los costes de horas de ingeniería (no es fácil programar CSR), no te saldrá rentable.
 

¿Y que puedo hacer si quiero hacer aplicaciones bluetooth para pocos miles de equipo?

La mejor solución es utilizar módulos bluetooth. Por ejemplo los módulos bluetooth de Bluegiga. Éstos realmente están basados en el chip de CSR, es decir, no son más que una plaquita donde está montado el chip Bluecore 4 ó 5, la antena, el regulador de tensión y todos los componentes necesarios. Además tienen embebido lo que llaman el protocolo iWrap, un sencillísimo protocolo con lo que con un micro cualquiera, un simple PIC de los más baratos, a través de una uart y con comandos AT, puedes gestionar complejas conexiones bluetooth. Es decir, tienes casi toda la potencia de CSR, pero con mucha más sencillez, mejor soporte (Bluegiga da soporte a pequeños clientes, CSR no) y barato en cuanto certificaciones.
Para tu curiosidad decirte que el protocolo iWrap desarrollado por Bluegiga está desarrollado con el BlueLab de CSR.

Evidentemente si quieres puedes comprar el BlueLab y programar tu propia aplicación dentro del módulo de Bluegiga, pero entonces perderías la condición de end-product y tendrías que pagar de nuevo las certificaciones correspondientes. En cambio si utilizas el módulo con el iWrap, puedes poner tranquilamente en tu equipo el logo bluetooth sin coste alguno, puesto que Bluegiga suministra los módulos como end-product, ya que Bluegiga ya ha pagado todas las centificaciones correspondientes.
 

Dentro de poco pondré algunos ejemplos de cómo crear conexiones de audio y datos entre dos módulos Bluegiga mediante el protocolo iWrap, utilizando simples comandos AT, veréis que sencillo es.
 

Espero que hayáis encontrado de interés este post.

Si hablamos del TC65 o XT65, información como el estado de las GPIO (entradas /salidas digitales), el estado de los conversores A/D o información sobre la posición del GPS interno del XT65 puede ser interesante de mostrar por una pequeña pantalla para un sinfín de aplicaciones. Muy interesante es también la idea de poder tener pantallas con touchscreen (táctiles) incorporado.
 

 
Pues bien, posiblemente algunos ya conozcáis algunas pantallas de este tipo, pero para quien no las conozca, decir que existen pantallas que cuentan directamente con una uart, un bus I2C ó SPI. Algunas pantallas incluso directamente con interfaz RS232 , perfectas para ser controladas por un módem terminal o cualquier otro dispositivo serie RS232.
 

Un ejemplo de empresa especializada en pantallas de este tipo es Electronic Assembly, distribuida en España por Matrix.
 
 

¿Y cómo se puede controlar una pantalla gráfica con un puerto serie?

Pues la controladora de este tipo de pantallas cuenta con un pequeño microprocesador en su interior que incorpora a su vez un pequeño protocolo de comunicaciones, es decir, toda una serie de instrucciones / funciones con las que podemos generar los gráficos y textos que queremos que se muestren en pantalla.

Por poner un ejemplo, si quisieramos escribir la palabra BlogElectronica en la posición 117/32 de una pantalla de este tipo controlada por un TC65T, bastaría con enviar un comando por el puerto serie de módem (si utilizamos la salida estandard)  tal que así:

System.out.println(”#ZL117,32,BlogElectronica”);

De igual forma podemos seleccionar diversos tipos de juegos de caracteres, utilizar comandos gráficos (por ejemplo, funciones para crear líneas, círculos, rectángulos… al estilo de “Draw a rectangle from (0,0) to (64,15)”), tener imágenes precargadas en la memoria de la pantalla y mostrarlas únicamente enviando un comando desde el puerto serie del módem …

Por cierto, otra característica de las pantallas de Electronic Assembly es la gran cantidad de colores de fondo con la que cuentan muchos de sus modelos. Si tienes curiosidad, para algunas familias, como la Dog, tienen una pequeña utilidad que te puedes descargar para que veas las diferentes combinaciones de backlight.  A ver si otro día hago un pequeño programita para utilizar desde un TC65T y hago un vídeo de los míos para que lo veáis .
 

Espero que os haya resultado de interés y haber podido dar alguna idea para vuestros diseños.

De esta nueva versión 3.0 del firmware del modem gprs de siemens TC65 destacaría principalmente que incorpora las clases java para implementar un watchdog y para controlar las GPIO. El módulo TC65 sigue siendo el mismo, no hay cambios de hardware, por lo que es posible actualizar el firmware de la versión 2.0 del módulo a la versión 3.0, aunque ojito por que el cambio no es reversible.

De estas principales características de esta nueva versión, hoy vamos a ver cómo utilizar la más interesante para mi, que es la clase Watchdog de java. Y es que el módulo dispone de un watchdog hardware, y con esta nueva versión 3.0, Siemens nos proporciona las clases java necesarias para controlarlo.

Lo primero que tenemos que hacer es activarlo con el comando AT^SCFG. Si utilizáis el comando AT^SCFG? veréis como aparece una nueva opción de watchdog de usuario, por defecto desactivado. El watchdog lo vamos a poder configurar como desactivado, como activado para reboot, es decir, que si salta reiniciará el módulo (con lo cual si tenemos el autostart a 1 se reiniciará nuestra aplicación) o activado para shutdown, con el que si salta el watchdog se apagará el módem.

Después, en el soft sólo tendremos que importar la clase Watchdog en el inicio del programa:

import com.siemens.icm.misc.Watchdog;

y activar en el inicio del programa el watchdog, mediante una clase estática, de la siquiente manera:

Watchdog.start(15);

Con esto activamos el sistema para que si no ha sido refrescado durante 15 segundos, el watchdog actúe. Podemos configurar el wathdog para que esté desactivado (valor 0) o bien activado, donde se puede establecer un valor entre 10 y 300, osea entre 10 segundos y 5 minutos.

Para refrescar el watchdog basta poner la línea:

Watchdog.kick()

en algún punto estratégico del programa donde se ejecute al menos una vez durante el periodo que hayamos configurado el watchdog.
Consideraciones importantes.

1. Se puede actualizar la versón TC65 2.0 a la 3.0, pero no se puede volver atrás.
2. Es necesario utilizar un SDK nuevo, es decir, hay que utilizar nueva versión de Eclipse, de plugin ME y de SMTK. No vale el que utilizábamos en la versión 2.0
3. Esto vale para el módulo TC65 y el Terminal TC65T. También los modems terminales (en caja) que lo monten, como el MTX65 distribuido por Matrix, pueden actualizarse a esta nueva versión 3.0
4. Aunque ahora el TC65 tenga watchdog, hay que seguir haciendo bien los programas, que no sirva de escusa!!!

Bueno, espero que hayáis encontrado de interés este artículo y os pueda ayudar. Otro día más

Actualización: es posible actualizar a la versión 3.0 tanto el módulo TC65 como el TC65T.

La verdad es que estoy bastante sorprendido de la buena acogida que está teniendo este blog hasta día de hoy. Increíble también el nivel de educación de todos los participantes que escriben sus posts con muchísima educación, y apenas me hacen moderar nada, por lo que aprovecho especialmente este momento para mandar unas enormes gracias a todos
 

Un amigo me dijo una vez que la mejor manera de hacer que un blog que tenga cierto éxito es hacerlo sobre una temática que te guste. Y creo que esto es totalmente cierto. Si empiezas un blog sobre un tema, aunque sepas mucho de él, pero no te gusta, no tardarás mucho en abandonar.

Para ser sincero he de reconocer que aunque me gusta mucho la electrónica, cuando empecé, tenía mis dudas de hasta cuándo sería capaz de continuar, pues aunque pueda no parecerlo, me lleva bastante tiempo. Pero bueno, a día de hoy estoy bastante animado, incluso más que cuando empecé, y eso, sobre todo, debido a la buena acogida que está teniendo. Cuando empecé blogElectronica pensé que tendría unas 150 ó 200 visitas mensuales, pero la realidad es que ya van camino de las 5000 mensuales, lo cual no está nada mal para un blog de una temática de electrónica tan específica.

Para quien tenga curiosidad estas son las estadísticas de este último mes:
 

Y éstas muestran el histórico desde cuando empecé. Realmente las estadísticas que muestro comienzan en Mayo, pues no activé el gestor de estadíscias hasta entonces, pero el blog estaba activo desde Marzo, osea que faltan los datos de 2 meses, pero no son muy significativos a juzgar por el gráfico.
 

 
 

Bueno, de nuevo, muchísimas gracias a todos.
 
 

Vamos a ver cómo realizar una conexión TCP/IP desde un programa Java embebido en un módem de Siemens. Veréis como enviar datos por un socket y cómo recibir datos por él desde un servidor. Yo he utilizado un módem GPRS MTX65, aunque el ejemplo funcionará de la misma manera en un módem GPRS MTX65+G, en un Siemens TC65 o en un Siemens XT65 (distribuidos en España por Matrix).

  
¿Y a qué servidor nos conectamos para hacer las pruebas?

Pues como hago de forma habitual, utilizo la IP de un servidor de Google para hacer pruebas. Lo que veréis en el programa Java que os pongo a continuación es cómo realizar una conexión TCP/IP a un servidor con dirección IP 216.239.59.147 y puerto 80 (el puerto HTTP). En este programa, además de realizar la conexión TCP/IP, se envían una serie de datos al servidor por el socket una vez establecida la conexión (se pide la página principal) y se reciben lo datos también por el socket (los datos HTML). Es muy simple pero creo que ilustra bastante bien la mecánica y puede resultaros muy útil en alguna ocasión.

Ha continuación tenéis un programita de ejemplo. He puesto bastantes comentarios para que podáis seguirlo sin demasiada dificultad, pero cualquier cosa me comentáis, y si está en mi mano, os hecho un cable ;-) 
 
 

package src;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;
import com.siemens.icm.io.ATCommand;
import com.siemens.icm.io.ATCommandFailedException;
import com.siemens.icm.io.ATCommandListener;

public class Conexion extends MIDlet
{

   ATCommand ATC;
   ATCommandListener LIS;
   int hemosRecibidoDatos=0;

   //Constructor de la clase
   public Conexion()
   {
      //Inicializamos la clase ATCommand y el Listener
      try
      {
         LIS = new ATListener();
         ATC=new ATCommand(false);
         ATC.addListener(LIS);
      }
      catch (IllegalStateException e){e.printStackTrace();}
      catch (ATCommandFailedException e) {e.printStackTrace();}

      //Iniciamos una conexión TCP
      iniciaConexion();

   }

   //Defimos nuestra clase ATListener
   class ATListener implements ATCommandListener
   {
      //Sólo controlaremos un URC en este ejemplo
      //y será para saber cuándo recibimos datos
      public void ATEvent(String Event)
      {
         //Sacamos el evento que se ha producido:
         System.out.println(”Evento: “+ Event);

         //Y si el URC corresponde a que han llegado datos …
         if (Event.indexOf(”SISR”)>0)
        {
           //Mandamos leer los datos del socket
           System.out.println(”Leemos los datos TCP”);
           leerSocket();
        }
      }
      public void RINGChanged(boolean Event) {}
      public void DCDChanged(boolean Event) {}
      public void DSRChanged(boolean Event) {}
      public void CONNChanged(boolean Event) {}
   }

   protected void startApp() throws MIDletStateChangeException {}

   protected void pauseApp() {}

   protected void destroyApp(boolean arg0) throws
   MIDletStateChangeException {}

   //Método para conectarnos con el servidor remosto
   public void iniciaConexion()
   {
      //Nos conectaremos a Google 
      String direccionIP = “216.239.59.147″;
      String puerto = “80″;
      String r=”";

      System.out.println(”Iniciando secuancia conexión GPRS”);

      try
     {
         r=ATC.send(”AT^SICS=1,conType,GPRS0\r”);
         Thread.sleep(100);

         r=ATC.send(”at^sics=1,user,CLIENTE\r”);
         Thread.sleep(100);

         r=ATC.send(”at^sics=1,passwd,AMENA\r”);
         Thread.sleep(100);

         r=ATC.send(”at^sics=1,apn,internet\r”);
         Thread.sleep(100);

         r=ATC.send(”AT^SICI=1\r”);
         Thread.sleep(100);

         r=ATC.send(”AT^SISS=1,srvType,socket\r”);
         Thread.sleep(100);

         r=ATC.send(”AT^SISS=1,conId,1\r”);
         Thread.sleep(100);

         r=ATC.send(”AT^SISS=1,address,socktcp://” + direccionIP + “:” + puerto + “\r”);
         Thread.sleep(100);

         r=ATC.send(”AT^SISO=1\r”);
         System.out.println(r);
         Thread.sleep(3000);

         System.out.println(”Enviando datos …”);

         //Enviamos una petición a Google de la página principal
         escribirSocket(”GET / HTTP/1.1\r\n\r\n”);
         System.out.println(”Datos enviados”);

         //Nos quedamos esperando en un bucle a recibir algo vía TCP
         System.out.println(”Esperando recibir un paquete de datos TCP …”);
         while (hemosRecibidoDatos==0);

         //Cerramos el socket
         r=ATC.send(”AT^SISC=1\r”);
         Thread.sleep(100);

         //Paramos el programa
         notifyDestroyed();

      }
      catch (Exception e){System.out.println(”Error.”);}
   }

   //Método para leer los datos del socket
   public void leerSocket()
   {
      try
      {
         //Mandamos el comando AT para leer lo que hay en el socket
        ATC.send(”AT^SISR=1,1500\r”);
        Thread.sleep(1000);

        //Asociamos el stream de entrada de datos
        InputStream is = ATC.getDataInputStream();
        //Y si hay datos disponibles los leemos …
        if (is.available() > -1)
        {
           //Creamos un buffer del tamño de los datos recibidos
           byte[] buffer = new byte[is.available()];
           //Leemos los datos y los cargamos en buffer
           is.read(buffer, 0, is.available());
           //Mostramos los datos por la salida estandar …
           System.out.println(new String(buffer));
           //Activamos el flag, de esa manera ya no nos quedamos esperando
           hemosRecibidoDatos=1;
        }

       //Gestión de las exepciones
     } catch (IllegalStateException e) {e.printStackTrace();
     } catch (IllegalArgumentException e) {e.printStackTrace();
     } catch (ATCommandFailedException e) {e.printStackTrace();
     } catch (InterruptedException e) {e.printStackTrace();
     } catch (IOException e) {e.printStackTrace();}

   }

   //Método para escribir datos en el socket
   public void escribirSocket(String cadena)
   {
      OutputStream os;

      try
      {
         System.out.println(”Enviado: ” + cadena);
         //Asociamos el stream de salida al de la clase ATCommand
         os = ATC.getDataOutputStream();
         //Enviamos el comando AT^SISW de envío
         ATC.send(”AT^SISW=1,” + cadena.length() + “,0,0\r”);
         Thread.sleep(500);
         //Escribimos los datos por el socket
         os.write(cadena.getBytes());
         Thread.sleep(500);
      }
      //Gestión de las exepciones
      catch (IOException e) {e.printStackTrace();}
      catch (IllegalStateException e) {e.printStackTrace();}
      catch (IllegalArgumentException e) {e.printStackTrace();}
      catch (ATCommandFailedException e) {e.printStackTrace();}
      catch (InterruptedException e) {e.printStackTrace();}

   }

}

Bueno, espero que os haya gustado y que os pueda ser útil en alguna ocasión. Otro días más

Ese fue un ejemplo basado en SMS, pero tan vez en alguna ocasión necesitemos almacenar información dentro del propio equipo.

¿Y para qué voy a querer almacenar información en el módem si la puedo transmitir por GPRS o SMS?

Hombre, imagina que recoges la posición GPS cada 10 segundos. Es posible transmitir la posición en tiempo real por GPRS a un servidor remoto, pero tal vez no te es necesario enviar la posición en tiempo real en todas las situaciones (y seguro es más económico). Puede haber situaciones en las que sí, situaciones en las que quieres poder controlar la posición en todo momento, pero otras en las que te interesa simplemente recoger las posiciones para tratarlas o enviarlas más adelante.

Esto si hablamos de módems con GPS, como el XT65 o el MTX65+G. Pero también tiene sentido si hablamos del TC65 (y el TC65T y MTX65) pues tienen entradas digitales, entradas analógicas y varios tipos de buses (SPI, I2C, RS232, …) y pueden, y de hecho se usan mucho para ello, recoger información de dispositivos y sensores externos, como sondas de temperatura, de caudal, de presión, pueden recoger información de PLCs … y puede que tampoco nos interese enviar la información inmediatamente tras haberla recogido, sino al final del día, o cuando nos vaya bien.
 

¿Y no puedo ir almacenando la información en memoria RAM?

Pues sí, puede hacerse. Pero eso es como si haces un trabajo en Word y no grabas nunca durante días. Lo tienes guardadito en memoria RAM, pero si ocurre algún imprevisto, una caída de alimentación, algún problema en la aplicación, puedes perder la información. Eso sin contar que los datos almacenados en RAM no pueden ser muy grandes.
 

¿Y cómo puedo almacenar la información?

Pues de la misma forma que puedes grabar los ficheros java de tus programas en la memoria FLASH de los módems, puedes crear ficheros desde tu aplicación java para guardar, añadir y leer la información cuando lo necesites.

A continuación te pongo un pequeño fragmento de código en Java para que veas cómo guardar y leer información utilizando ficheros que se almacenarán en la memoria Flash del equipo.

try
{
//Creamos un objeto de la clase FileConnection y especificamos
//el nombre del fichero a abrir, que pondremos fichero.txt
FileConnection objFileConnection = (FileConnection)
    Connector.open(”file:///a:/fichero.txt”);

//Si el fichero no existe lo mandamos crear
if (!objFileConnection.exists())
    objFileConnection.create();

//Creamos un objeto de la clase DataOutputStream, con el
//que escribir datos en el archivo
DataOutputStream objDataOutputStream =
    objFileConnection.openDataOutputStream();

//Escribimos un texto dentro del fichero que acabamos de abrir
//(o de crear)
objDataOutputStream.write(”Hola de blogElectronica”.getBytes());

//Mandamos todo lo que quede en el buffer previo al cierre del mismo
objDataOutputStream.flush();

//Cerramos el objeto
objDataOutputStream.close();

//Ahora leemos los datos. Creamos un objeto de clase DataInputStream
DataInputStream objDataInputStream =
    objFileConnection.openDataInputStream();

//Creamos un array para almacenar los datos del fichero leído.
//Lo haremos del tamaño de los datos del fichero, porque
//sabemos que son pocos
byte[] datos = new byte[objDataInputStream.available()];

//Si hay datos, que en nuestro caso los habrá …
if (objDataInputStream.available() > -1)
{
  //Leemos y guardamos todos los datos del fichero
  //en el array que hemos creado
  objDataInputStream.read(datos, 0, objDataInputStream.available());

  //Y los sacamos por la consola para verlos
  System.out.println(new String(datos));
}

//Cerramos los objetos
objDataInputStream.close();
fconn.close();
}

catch (IOException ioe)
{
}
 
 

Por cierto, no olvides de hacer los siguientes imports al inicio del programa.

import javax.microedition.io.Connector;
import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;
import java.io.DataInputStream;
import java.io.DataOutputStream;
import java.io.IOException;
import java.io.OutputStream;
import java.util.Enumeration;
import com.siemens.icm.io.file.FileConnection;
import com.siemens.icm.io.file.FileSystemRegistry;

Todo lo anterior lo puedes aplicar en los módems Siemens TC65, TC65T, XT65, MTX65 y MTX65+G, distribuidos en España por Matrix.
 
 

Espero que os haya resultado interesante este post y que os pueda resultár útil en alguna ocasión. Otro día más.