Archivo de la Categoría 2.DISPOSITIVOS (práctico)

Como dije ayer, hoy voy a presentar un nuevo dispositivo que va a distribuir Matrix en breve. Se trata de un dispositivo basado en el MTX65 del que tanto hemos hablado por estos fueros.

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.
 

MTX-tunnel

  
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:
 

(more…)

En la actualidad hay muchísimas empresas utilizando el módem Siemens MC55. Hablé un poco de él hace ya bastante tiempo, cuando vimos los distintos modelos de módems de la familia Siemens.

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.

Módem GSM GPRS Siemens MC55i


(more…)

Hoy Sábado voy a hablar un poquito sobre CSR y sus soluciones bluetooth. CSR es la empresa más importante a nivel mundial de chips bluetooth y con casi con toda seguridad todos estamos utilizando algún chip de ellos, pues nada menos que el 70% de los equipos que tienen bluetooth, especialmente los móviles, tienen un chip CSR, los mejores.

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.

Bluecore

(more…)

Posiblemente alguna vez hayáis pensado en incorporar una pantalla en vuestras aplicaciones con los módems Siemens TC65, XT65, o los  terminales TC65T, MTX65 ó MTX65+g.  Y es que en muchas ocasiones puede ser necesaria una pequeña pantalla para mostrar cierta información relevante.

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.
 

Pantalla LCD con interfaz RS232 y touchscreen

(more…)

Hace muy poquito salió la versión firmware 3.0 del módem Siemens TC65. Esta versión incorpora una serie de mejoras muy interesantes respecto a su predecesora, la versión 2.0 (hubo también una versión intermedia 2.8, pero ha durado muy poco).

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.

Watchdog-siemens-tc65

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.

(more…)

En mi anterior post vimos como utilizar el sistema de ficheros de algunos de los modems Siemens para almacenar y recuperar información. Creo que fue bastante interesante. En esta ocasión vamos a ver algo que creo todavía más interesante y que la verdad, no hay demasiados ejemplos por ahí (yo no he encontrado ninguno), por lo que creo que este post va a ser bastante leído.

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).

 

modem-gprs

  
¿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 ;-) 
 
 

(more…)

Como seguro ya sabéis, varios de los modelos de módems de Siemens son programables en Java. Hace ya un tiempo puse varios posts acerca de la programación de estos módems. Concretamente puse un ejemplo, publicado en varias entregas, en el que utilicé como base un MTX65+G (recordemos, un módem terminal GPRS con GPS integrado) con el que vimos cómo desarrollar un pequeño localizador por GPS. Entre otras cosas la aplicación básicamente consistía en que el módem al recibir un determinado mensaje SMS, devolvía otro SMS con la posición GPS.

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

Gestión de ficheros modems Siemens


¿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.

(more…)

Hace unos días puse un post sobre los modelos Digi Connect Me y Digi Connect WiMe. Si recordáis eran unos dispositivos que tenían una versión programable, bajo sistemas uFramework y NetOS (bueno si … y también con uClinux ;-) ) pero que también se podían utilizar en su versión estandar, es decir, una versión que no es programable, pero que están principalmente pensados para embeber en nuestros diseños electrónicos y hacer de pasarela serie-ethernet (para la versión Digi Connect ME) y de pasarela wifi-serie (para la versión Digi Connect WiME).

Por lo tanto, con estos equipos, recordemos pin a pin compatibles e intercambiables según necesitemos ethernet o wifi, podemos de manera muy sencilla y rápida, añadir conectividad ethernet o wifi a nuestros diseños electrónicos.

Evidentemente si utilizamos estos dispositivos de Digi en nuestros diseños es para conectarnos vía ethernet o wifi. En la gran mayoría de casos los utilizamos para poder realizar monitorizaciones de estado de nuestros dispositivos a través de una LAN (red de área local) o a lo que se tiende a día de hoy, a poder monitorizar equipos desde cualquier lugar del mundo a través de una conexión GPRS o 3G. Es por eso que voy a presentar el nuevo Router 3G (router umts / hsdpa) DigiWi-Point-3G.

 Router 3G de Digi

 
(more…)

Hoy voy a hablar brevemente de un módulo de Digi que seguro si no lo conoces te va a sorprender, por su tamaño y prestaciones, a más de uno.

Se trata un módulo de Digi (distribuido en España por Matrix) de nombre Digi Connect Me. Es el que tenéis en la foto que os pongo a continuación. Podéis ver las medidas en centímetros entre paréntesis.

Digi Connect ME

Como veis, el dispositivo es extraordinariamente pequeño. Ocupa poco más que un conector convencional de RJ45.
 
 
Está muy bien, ¿pero qué es?

Pues el dispositivo es un pequeño módulo embebido, basado en un ARM 7 de 32bits (concretamente el NS7520 a 55MHz). Está disponible en dos versiones, la versión estandard y la customizable.

Con la versión estandard no tenemos un módulo programable. Tenemos un completísimo gateway serie-ethernet de tamaño ultracompacto, que permite dar a los diseños que tengamos actualmente con conectividad serie capacidad ethernet de manera muy rápida y económica.

Toda la configuración del equipo se realiza mediante browser. Dispone de un sinfín de configuraciones posibles, permite configurarse como servidor TCP, como cliente TCP, podemos almacenar nuestra propia página web en su interior haciendo personalizable el equipo (es decir, poniendo tu logo, por si después tenemos pensado revender un equipo nuestro que incluya este dispositivo y así que el cliente vea nuestro logo ;-) ), podemos embeber también applets java, e incluso, si embebemos una página web con un applet, podemos controlar (leer y escribir) en las 5 GPIO de que dispone. También puede enviar alertas por email automáticamente si se detecta un cambio en una o varias GPIO que nosotros programemos …

(more…)

Hace ya tiempo puse unos post relativos al dispositivo Access Server de BlueGiga, ya sabéis, un equipo abierto, con un procesador ARM + Linux, utilizado principalmente por su servidor obexsender integrado que lo hace ideal para crear sistemas de lo que se conoce como marketing de proximidad o publicidad bluetooth. Esos posts han sido de los más leídos en blogElectrónica (con varios miles de visitas).

Hoy, para aquellos que diseñan servicios de publicidad y que se interesaron por el Access Server de Bluegiga, os presento muy brevemente un pequeño equipo, esta vez de Digi (distribuido por Matrix en España), que tal vez podáis encontrar de utilidad para ser incorporado en alguno de vuestros sistemas publicitarios.
 

digi-show-box.gif

 
Se trata del Digi Show-box. Como ya sabéis, Digi, además de productos embedded, como los procesadores que comentamos en su día Digi Connect Core 9P, Wi9C, … tiene los productos en caja, como son los gateways (serie-ethernet, serie-wifi), router GPRS, router umts, router hsdpa, … y entre ellos ha lanzado este producto, el Digi Show-box.

(more…)

Buenas a todos. Ante todo feliz nuevo año 2008. Hace unos días publiqué la primera parte de un artículo práctico sobre Zigbee, hoy veremos la segunda. En esta ocasión veremos el programita, llamémosle entrenador, que viene con el kit de desarrollo de Maxstream. Un software llamado X-CTU.

Pero antes, vamos a acabar de ver unas pocas preguntas / respuestas que el otro día, para no extenderme, no puse.
 
 
17.- He oído que Zigbee maneja direcciones de 16bits y 64bits. ¿Eso es así?

Cada módulo Zigbee, al igual que ocurre con las direcciones MAC de los dispositivos ethernet, tiene una dirección única. En el caso de los modulitos Zigbee cada uno de ellos tiene una dirección única de 64bits que viene grabada de fábrica. Por otro lado, la red Zigbee, utiliza para sus algoritmos de routeados las direcciones de 16 bits. Cada vez que un dispositivo se asocia a una red Zigbee, el Router padre al cual se asocia le asigna una dirección única en toda la red de 16bits. Por eso el número máximo teórico de elementos que puede haber en una red Zigbee es de 2^16 = 65535, que es el nº máximo de direcciones de red que se pueden asignar.


18.- Y entonces, si tenemos direcciones de 16 y 64 bits, ¿cual he de utilizar con los modulos de Maxstream? porque además las direcciones de 16bits no son fijas, es decir, en caso de rehacerse la red éstas pueden cambiar ¿no? Que lío …

Si trabajas con comandos AT, las direcciones que debes utilizar son las de 64bits, es decir, tu con los comandos ATDH y ATDL establecerás la dirección destino (los 4 bytes altos y los 4 bytes bajos) del dispositivo al que quieres enviar la información. El módulo internamente ya se encargará de descubrir, si es que no la tiene almacenada en una tabla interna temporal de una transmisión previa, cual es la dirección de 16bits que tiene el dispositivo al que pretende enviar información. Para ello envía un broadcast a la red. Si utilizas el modo API puedes utilizar también las direcciones de 64 bits, pero si quieres, puedes indicarle también la dirección de red de 16bits, ya que por ejemplo, puedes tenerlas almacenadas en la memoria del micro con el que controlas el módulo, de esa manera, ganarás en velocidad.

Bueno, ahora os pondré un pequeño vídeo que he hecho para que veáis el software X-CTU. Para ello he utilizado dos modulitos, un coordinador y un router. Si en el vídeo del antículo antenior no pudísteis apreciar bien los modulitos, podéis hacer clic en la imágen siguiente y la veréis ampliada:
 

zigbee-xbee-mini.gif
 

Y aquí os pongo el vídeo en formato flash. Haz clic en la imagen para visualizarlo:
 

video-zigbee-xctu.gif


Espero que os haya resultado interesante. Otro día más
;-)
 
P.D. He incorporado en el lateral de la página una casilla de subscripción gratutita a los artículos de mi blog, tanto por RSS como por email, para quien le interese. Salu2.
 

Hoy voy a hablar un poco de Zigbee desde un punto totalmente práctico. Hay mucha gente que sabe lo que es Zigbee, incluso un poco a nivel teórico, pero muchos tienen una idea un tanto difusa de cómo llevarlo a la práctica. Voy a poner un par de artículos de este tema en dos entregas y espero que quien tenga actualmente dudas o simplemente no tenga claro cómo llevarlo a la práctica, tras la lectura, tenga totalmente claro qué hacer para montar un sistema Zigbee.

Como digo es totalmente práctico, si no sabes lo que es Zigbee te aconsejo que leas unos articulillos teóricos que puse ya hace tiempo en el blog sobre Zigbee y luego continues la lectura a partir de aquí.

Voy a utilizar un kit de desarrollo de Zigbee de MaxStream (distribuido en España por Matrix). Los módulos que vienen en este Kit de desarrollo son módulos llamados XBee Serie2 (con la serie 2 podemos hacer redes mesh, con la serie 1 no. Ya veremos en otra ocasión cuando elegir Xbee serie1 y cuando Xbee serie2, pero te avanzo que para trabajar con Zigbee necesitas la serie 2).

Os pongo un pequeño vídeo (que he hecho de forma rápida) con lo que viene en un kit de desarrollo Zigbee de Maxstream, pues ésto es mejor verlo que leerlo ;-) :
 
 
 

 
 

Creo que la mejor forma de entender cómo utilizar estos módulos Zigbee va a ser a través del método pregunta / respuesta. Ahí van:
 
 
1.- Estoy pensando en hacer una aplicación RF y barajo usar Zigbee, pero me han dicho que es muy complicado, ¿es así?
 
En absoluto. La verdad es que es bastante sencillo utilizando los módulos de Maxstream. Toda la complejidad de las tramas Zigbee recae sobre el módulo. Tú, simplemente enviando unos comandos AT vía serie puedes crear complejas redes zigbee y comunicar tus equipos a través de ellas (me atrevería a decir que casi sin saber de Zigbee). Personalmente hace ya mucho tiempo probé un kit de desarrollo Zigbee de Chipcon. Utilizar aquello sí que era complicado :-( ,  nada que ver con esto, palabra.
 

2.- ¿Qué alcance tienen estos modulitos?
 
Pues como siempre depende. Dependerá de si utilizas un módulo con antena chip integrada, o con antena dipolo integrada o con conector UFL para antena externa, de si tienes obstáculos o no, de si está pegado al suelo o a cierta altura (fresnel), … Como máximo, en un entorno urbano con obstáculos pueden llegar hasta unos 40m, y 120m si no hay obstáculos, pero como digo, depende de muchas variables, como con cualquier dispositivo RF.
 

3.- Bueno, ya he visto el kit desarrollo en el vídeo, muy bonito, pero ¿cómo me comunico con estos módulos?
 

Pues la forma de comunicarte con estos modulitos es a través de una comunicación serie por una uart. Puedes comunicarte de dos maneras, con comandos AT (modo transparente) o modo API (modo no transparente). Este modo de funcionamiento se configura con un parámetro de configuración.
 
 
4.- ¿Y qué diferencia hay entre el modo de funcionamiento por comandos AT y API?
 

En modo Comandos AT (transparente) puedes configurar el módulo a través de simples comandos AT. Ejemplo, imaginemos que queremos enviar datos desde nuestro módulo Zigbee A a un módulo Zigbee B con dirección X.  En modo transparente, enviamos el comando +++ por el puerto serie del módulo A y el módulo saldrá de modo datos para entrar en modo comandos. Establecemos entonces un parámetro con la dirección destino X del módulo B y salimos del modo comandos al modo datos. A partir de entonces, todos los datos que enviemos por el puerto serie del módulo A saldrán por el puerto serie del módulo B.

El modo API es algo más complicado. No existe el modo datos y modo comandos. Se utiliza un protocolo, es decir, nos comunicamos con los módulos mediante unas tramas con su cabecera, datos, final de trama, … es decir, con un protocolo.
 
 
5.- Entonces, si el modo API es más complicado ¿para qué sirve?
 

Con el modo API tendremos más control. Es decir, si enviamos una trama de A a B y ésta no llega, obtendremos un código de error. Si necesitamos enviar datos a distintos equipos de la red (distintas direcciones destino), si utilizamos el modo Comandos AT, tendremos que estar continuamente saliendo a modo comandos, cambiar la dirección destino, volver a modo datos y enviar los datos, así continuamente. Muy lento. En modo API la dirección destino forma parte de la trama, por lo que es mucho más rápido comunicarnos con varios equipos.
 
 
6.- ¿Todos los módulos son iguales? Es decir, en el vídeo has dicho que hay 5 módulos Zigbee, pero no si son Coordinadores, Routers o End devices ¿son distintos equipos o se pueden configurar para que actúen de un modo u otro?

El kit lo componen 1 Coordinador y 4 Routers / End devices. La diferencia hay que verla desde el punto de vista del firmware. El firmware del módulo que hace de Coordinador es distinto al firmware de los Routers o de los End devices. El fimware de los módulos Routers o End devices sí que es el mismo.

 
 7.- Y si el firmware de un Router y de un End device es el mismo, ¿cómo puedo hacer que un módulo se comporte de una manera u otra?

Pues con un parámetro de configuración. Si configuras al módulo para bajo consumo, esto es, para que duerma y se despierte cada X segundos, el módulo se convierte automáticamente en End device, en cambio si siempre está online, el módulo actúa como Router.
 

8.- ¿Y en base a qué decido configurar un equipo como Router o como End device?

Si tus equipos van a funcionar con pilas, y quieres que te duren, deberás configurarlos como End device, de esa manera los equipos pueden trabajar en modo Sleep (bajo consumo). Si algunos de tus equipos pueden obtener la alimentación de la red, configúralos como Routers.
 

9.- Hay una cosa que no entiendo. Si configuro un módulo como End device, es decir, si lo configuro para que entre en modo sleep y me quiero comunicar con él desde otro dispositivo de la red Zigbee, si está durmiendo, no va a hacer caso a las tramas que le envíe, ¿no?
 

Un End device siempre está asociado a un Router (o a un Coordinador, pero recordemos que tras iniciar la red se comporta como un Router). Un End device no hace nada mientras está durmiendo, pero cuando despierta hace un polling al Router al cual está asociado para saber si hay algo para él. Y es que los Routers almacenan temporalmente en una tabla interna las tramas que le llegan a sus dispositivos asociados, de esa manera cuando un End device asociado a un determinado Router despierta y le pregunta si hay algo para él, el Router le enviará las tramas que tenga almacenadas para él.
 

10.- He oido que en una red Zigbee es necesario un coordinador. Si por un motivo se estropea o se apaga, ¿se cae la red zigbee?
 
No. El Coordinador sólo es necesario en el arranque de la red zigbee. En el arranque de la red se encarga de seleccionar qué canal RF utilizar de los 17 disponibles (mirando en el espacio radioeléctrico en qué canal hay menor densidad de energía y por tanto menos interferencias) y se encarga de escoger el PANID (identificador) de la red. Cuando ya ha hecho esta tarea se comporta igual que un Router.
 

11.- Pero yo no quiero que escoja de manera aleatória un PANID. ¿Se puede fijar uno?
 

Efectivamente, puedes fijar uno. Si no lo especificas escogerá uno al azar.
 
 
12.- Claro, si fijo un PANID evitaré que un determinado dispositivo Zigbee en vez de conectarse a mi red se conecte a otra red Zigbee vecina ¿es así?
 
Sí. Si configuras todos los equipos con un parámetro PANID determinado evitarás que tu equipo se conecte a otra red cercana con un PANID distinto. Si no especificas un PANID, al encender un equipo, ya sea un Router o un End device, se conectaría a la primera red Zigbee que encuentre.
 

13.- Yo no quiero que puedan asociarse a mi red más dispositivos una vez formada. ¿Puedo evitarlo?
 
Sí. Hay un comando que puedes enviar a los módulos que hacen de Routers con el cual puedes definir un tiempo en el cual permites asociaciones a la red. Pasado ese tiempo la red “se cierra”.
 

14.- ¿Y luego ya no podrá asociar nunca más dispositivos a mi red?
 

No, a menos que modifiques ese parámetro del Router al cual quieres asociarlo.
 

15.- Y si se cae o se estropea un Coordinador de red y queremos adjuntar a la red un nuevo dispositivo ¿no podremos, verdad?, pues es el Coordinador quien da las direcciones de red a los nuevos dispositivos que se quieran adjuntar.
 
No es el Coordinador quien da las direcciones de red, sino los Routers. Es decir, si se cae el Coordinador sí se podrá adjuntar un equipo a la red sin problemas.
 

16.- En una red Zigbee, si quiero comunicar un dispositivo A con un dispositivo B, yo no me tengo que preocupar de la ruta ¿no? Creo que es la propia red quien se encarga de buscar la ruta óptima. ¿Es el Coordinador quien se encarga de esto?
 
Que no :-) . El Coordinador sólo se encarga de lo que pone en el punto 10).  De encontrar la ruta óptima se encargan los Routers. Efectivamente tú no te tienes que preocupar de indicar la ruta, se encarga la propia red.
 
 
 
 
Bueno, espero que os haya resultado interesante, otro día continúo (que hoy es nochebuena y hay que ir a comprar para la cena ;-) ).

Más adelante veremos algunas cuestiones más que me quedan pendientes y la aplicación X-CTU de Maxstream, que es como una especie de entrenador, similar a los entrenadores que habéis visto en blogElectronica de Siemens o de Coronis, así podréis ver de forma práctica cómo funcionan estos dispositivos.
 

Hoy Sábado vamos a retomar un post que puse ya hace algún tiempo, cuando hablé de las wavecard de Coronis, unos pequeños módulos ideales para integrar en nuestros circuitos para realizar comunicaciones RF en la banda de 868MHz (25mw) y 869MHz (500mW) por su bajísimo consumo, su largo alcance (1Km 25mW y 4Km 500mW), y su sencillez de uso (gestionables con un sencillo protocolo a través de una uart).

Para ello voy a utilizar un kit de desarrollo de Coronis. Este kit incorpora 2 waveports. Un waveport no es más que una wavecard con caja (con conectividad rs232 o USB). De esta manera resulta muy sencillo evaluar una wavecard y realizar pruebas de transmisión con un PC o dos PC. En este caso voy a untilizar un único PC con 2 puertos serie. Conectaré un waveport a cada uno de ellos.
 
 

Este es un kit de desarrollo de Coronis:  

   

  
Vamos a ver un vídeo de cómo realizar una transmisión de datos utilizando estos dispositivos. Para ello, en lugar de utilizar un hyperterminal, utilizaremos un software entrenador realizado por Matrix Electrónica para sus clientes, similar al entrenador de Siemens, con el que nos será mucho más sencillo probar los equipos y entender su funcionamiento. Haz clic en el siguiente vídeo:
 

wavecard-video.JPG
 
 

Bueno, espero que os haya resultado interesante. A ver si dento de poco puedo poner un post similar con un kit de desarrollo de Zigbee. ;-)

Por fin este Sábado he tenido un poquito de tiempo y os puedo poner la tercera y última entrega de la aplicación que prometí a principios de mes y que acabo de terminar. Lo que ha cambiado es lo que dije en la segunda entrega. En esta ocasión la posición GPS no se envía a un número que tengamos grabado en el fichero JAD. Ahora en el fichero JAD sólo tendremos el PIN de la tarjeta SIM por si hace falta.

java.jpg

Entonces, ¿qué es lo nuevo?

Pues ahora si desde un móvil cualquiera se envía un SMS con un texto, el módem MTX65+G va a decodificar el SMS entrante, obteniendo por un lado el nº de teléfono del teléfono que ha enviado el SMS y por otro lado el texto del SMS. Entonces, si se recibe un texto con la palabra:

posicion

el modem coge la posición actual GPS y la envía por SMS al nº de teléfono que envió el SMS.

abrir

el modem activa (pone a “1″) la salida GPIO 0 del módem, con lo que podríamos activar un relé, por ejemplo.

cerrar

el modem desactiva (pone a “0″) la salida GPIO 0 del módem, con lo que podríamos desactivar un relé.

Principalmente se han añadido los métodos al proyecto:
 

int cambiarGPIO(int numGPIO, int valor)

mediante el cual podemos cambiar el estado de una GPIO poniendola a “1″ o “0″. En el ejemplo sólo vamos a utilizar la GPIO número 0.

SMS leerSMS(int posicionDeMemoria)

mediante el cual decodificamos un SMS entrante obteniendo dentro de una clase SMS por un lado el número de teléfono que ha enviado el SMS y por otro lado el texto del mensaje.
 

Quedaría una cosa que no voy a hacer, eso ya os lo dejo a vosotros. Y es que estaría bien que cuando se procese un SMS entrante, después de ser procesado se elimine de la memoria del módem, pues de lo contrario llegará un momento que se llene la memoria del modem de SMSs (como ocurre con cualquier móvil) y no se podrán recibir más. Para ello no habría más que crear otro método que se llamara por ejemplo “borrarSMS” y utilizar el comando AT+cmgd para borrar el SMS una vez procesado. Muy muy fácil.
 
 
Os pongo esta tercera y última entrega aquí.
 
 
Recordar que todo este programa vale tanto para el módulo Siemens XT65 como para el MTX65+G. Para quien le interese estos módems son distribuidos en España por Matrix Electronica
 
 
Espero que os haya gustado y hayáis encontrado de interés estos tres últimos artículos, y que pueda ayudar a aquellos que dáis los primeros pasos con los modems de Siemens ;-)

Hoy no tengo mucho tiempo así que seré breve. Acabo de modificar un poquito el programa de la primera entrega del programa para el MTX65+G (recordar que lleva un modem Siemens XT65 en su interior).

java.jpg

 He añadido algún método nuevo a la clase:

initGPS (int segundosURC)

este método se encarga de activar el GPS (con el comando AT^SGPSS=1) y programamos al GPS para que nos envíe un mensaje URC con la posición GPS cada X segundos. En el ejemplo lo he configurado para actualizar la posición cada 5 segundos.

enviarSMS (String mensaje, String numero)

este método se encarga de enviar un SMS con el mensaje al número indicado en los parámetros pasados al método. Lo utilizaremos para enviar la posición GPS obtenida a nuestro número de teléfono.

Resumiendo, con esta segunda entrega, tenemos el programa de la siguiente manera:  el programa activa el GPS y va capturando posiciones. En el momento que recibe un SMS se envía a un número determinado la posición GPS también por SMS.

En una tercera y última entrega haré que sólo se envíe la posición GPS al número de teléfono que envíe un SMS al módem con un texto determinado, por ejemplo el texto “leerposicion”. También configuraremos el programita para que al recibir un SMS con el texto “activa” ponga a “1″ una de las señales GPIO digitales y cuando se reciba el texto “desactiva” la ponga a “0″. De esa forma nos será muy simple activar y desactivar un relé.
 

Aquí tenéis el programita para que quien quiera pueda darle un vistazo:  proyectoAlarma2 

 

Espero que os sean de interés estos posts ;-)