blogElectronica.com

En el último post hablamos de los modulitos WT12 y WT11 de Bluegiga.  Hoy vamos a ver unas prestaciones especiales del Access Server que lo hacen muy úlil.

Veámoslo con un ejemplo. Imaginemos un laboratorio en el cual hay distintos equipos, distintos dispositivos de medición. Ahora imaginemos que cada uno de estos equipos disponen de un módulo bluetooth WT11, lo cual les confiere conectividad RF. Queremos monitorizar el estado de todos estos dispositivos desde un ordenador central que puede estar en ese mismo laboratorio o en un laboratorio de otro país.

¿Se puede realizar la aplicación de una manera sencilla?

Sí, y es muy fácil utilizando un Access Server y la aplicación connector que incorpora en su interior. En el Access Server tan sólo debemos indicar una serie de parámetros.  Por un lado, por cada dispositivo bluetooth (por ejemplo un WT11 ó WT12) que queramos utilizar debemos especificar en la configuración del Access Server la dirección MAC del equipo bluetooth al que nos queremos conectar, el perfil que queremos utilizar (1101 para SPP) y la dirección IP y el puerto TCP del servidor a la que enviar los datos. Si en el laborario tenemos 15 dispositivos bluetooth que queremos monitorizar, pues deberemos rellenar los 4 parámetros anteriores 15 veces.

¿Y una vez todo configurado, cómo funciona esto?

Pues también es muy sencillo. El Access Server cada cierto tiempo busca los dispositivos bluetooth con las MACs que hemos configurado previamente. Sí encuentra uno de ellos establece una conexión bluetooth con el dispositivo encontrado y por otro lado, una vez conseguida la conexión bluetooth, se conecta a la IP y el puerto del servidor que le hayamos configurado para ese determinado dispositivo bluetooth. Una vez establecidas ambas conexiones, todo lo que se envía vía serie al módulo WT12 ó WT11 (por ejemplo los datos leidos de temperatura …) éste los retransmite mediante bluetooth al Access Server, y, a su vez, es Access Server lo retransmite al Servidor central vía TCP/IP. Y vivecersa, todo lo que se envíe desde el Servidor Central vía TCP/IP al Access Server por una derterminada conexión, es reenviado por el Access Server vía bluetooth hacía el módulo WT12 ó WT11 y éste sacará vía serie los datos recibidos.  Todo esto para hasta 21 conexiones simultáneas para un único Access Server.

En resumen, lo que estamos haciendo con los módulos bluetooth WT11 ó WT12 y el Access Server actuando como concentrador, es un “Cable Replacer”, un gateway serie-blutetooth-ethernet de una manera ultrasencilla.

Espero que os haya resultado de interés.

Hoy os presento unos modulos bluetooth que seguramente a muchos os podrán resultar de interés. Se tratan de los módulos WT12 y WT11 de Bluegiga.

La característica principal de estos módulos bluetooth es que facilitan enormemente la capacidad de añadir a nuestros diseños conectividad bluetooth sin ningún tipo de complicación, es decir, sin necesidad de tener conocimientos en profuncidad del complicado protocolo bluetooth. Podemos implementar una conexión bluetooth simplemente a través de comandos AT. Y es que por defecto los módulos WT12 y WT11 de bluegiga vienen con el protocolo iWrap integrado, un protocolo por el que simplemente es necesario enviar comandos AT por el puerto serie del módulo para gestionar las conexiones.
 

¿Y sólo es posible utilizar los módulos a través del protocolo iWrap?

Pues no. También es posible utilizarlos a través de HCI (Host Command Interface). Es decir, es posible utilizarlos utilizando un procesador externo, eso sí, que cuente con la pila bluetooth. Digamos que de esta manera puede usarse el módulo simplemente como una interface radio a través de un puerto serie o USB.
 

¿Cuáles son las características técnicas de estos módulos bluetooth?

Los módulos WT11 y WT12 de bluegiga son de clase 1 y clase 2 respectivamente. Recordemos que los dispositivos de clase 1 tienen un alcance aproximado de unos 100 metros y los de clase 2 de unos 20 metros). Son módulos bluetooth 2.0 + EDR (Enhanced Data Rate), tres veces más rápido que el bluetooth 1.2 que le confieren una velicidad de transmisión de hasta 3Mbps.

Disponen de interface USB 2.0, interface serie (uarth), antena integrada (externa opcional), 8Mb de memoria Flash, para el caso de que queramos programar nuestra aplicación en el interior del propio módulo, una opción posible pero poco utilizada, pues la gracia de este equipo es su facilidad de uso mediante el protocolo iWrap. El firmware de este protocolo iWrap esta almacenado en dicha flash, por lo que si se desea utilizar esta flash para embeber una aplicación propietaria, no será posible usar dicho protocolo. Además, si utilizamos el protocolo iWrap podremos poner el logotipo bluetooh en nuestros dispositivos finales sin necesidad de pasar certificaciones adicionales. Si eliminamos el protocolo iWrap para embeber nuestra aplicación esto no será así, y deberemos pasar toda una serie de certificaciones, con el tiempo y dinero que conlleva.

Los perfiles bluetooth que pueden utilizarse son: SPP, HFP, HFP-AG, OBEX OPP y DUN. Por supuesto, los dispositivos WT11 y WT12 son pin a pin compatibles, por lo que puede usarse uno u otro en función del tipo de aplicación (es decir, en función del alcance necesario).
 
Y es que realmente estos dispositivos pueden verse no sólo como unos módulos bluetooth, sino como unos módulos RF con los que es extraordinariamente sencillo realizar enlaces radio para el traspaso de información radio.
 
 
¿Veremos casos prácticos de cómo utilizarlos?

Por supuesto. En los próximos días veremos algunos casos prácticos de como utilizarlos. En concreto el próximo artículo será relativo al Access Server, y veremos cómo puede usarse este dispositivo en conjunción con estos módulos WT11 y WT12 para realizar aplicaciones realmente muy interesantes con una simplicidad que asombrará a más de uno.

Si os interesan estos módulos saber que el distribuidor en España es Matrix Electrónica.

Espero que os haya resultado interesante. Mañana más.

Hoy en día cada vez las empresas dependen más de Internet, correo electrónico, búsqueda de información, etc. Y no digamos de aquellas empresas en los que en Internet  se basa parte de su negocio, como empresas de seguridad que controlen cámaras IP, servicios de telemantenimiento y telecontrol entre otros servicios.

A un particular, el hecho de quedarse si Internet a causa de un problema con una avería de la línea telefónica puede suponerle molestias ( y “cabreos” sí ) pero normalmente ahí queda la cosa. A una empresa grande o de mediano tamaño puede suponerle unas pérdidas económicas importantes.
 

¿Y qué tiene que ver esto con el protocolo VRRP?

El protocolo VRRP es un protocolo que implementan en su firmware cada vez más routers y, en pocas palabras, permite que si un router “cae”, otro router tome el control.

El funcionamiento del protocolo VRRP se basa en el uso de lo que se llama un “Router Virtual“. Este router virtual lo simulan el conjunto de routers reales que tengamos en la instalación (y que dispongan del protocolo VRRP) y será también la IP de este router virtual la que tengan configurados los equipos de la red como gateway de salida hacia Internet.

Al router virtual se le asocia una dirección IP virtual y una MAC virtual. Esta IP y esta MAC nunca cambian con independencia del router real que se esté utilizando en un momento determinado. El sistema lo forma un router master (el router real que están utilizando en un momento dado los dispositivos de la LAN) y un conjunto routers de reserva llamados routers de backup.
 
 
¿Y cómo funciona el protocolo VRRP?

El funcionamiento del protocolo VRRP es el siguiente: el router master envía periódicamente a la dirección IP 224.0.0.18 (asignada por la IANA, Internet Assigned Number Authority) y utilizando el protocolo IP 112 (también establecido por la IANA) un paquete de datos en el cual indica su estado (si es correcto, el nº de prioridad del router, etc).

Si durante un tiempo determinado los routers de backup dejan de recibir este paquete del router master, entonces el router de backup de mayor prioridad pasa a convertirse en el nuevo router master del router virtual, es decir, todo el tráfico hacia Internet será enrutado por un router de backup reconvertido en router master.

Por último decir que el protocolo VRRP permite, si se desea, que el router de mayor prioridad pueda expropiar de la función de router master a un router de menor prioridad. Por ejemplo, esto puede ser muy útil para el caso de una instalación que disponga de un router ADSL convencional y de un router UMTS/HSDPA de backup. En caso de que la línea ADSL caiga por una avería, el router de backup UMTS/HSDPA toma el control. Cuando la avería se solucione, automáticamente el router ADSL, que lo tendríamos configurado con mayor prioridad, tomaría el control de la instalación y todo el tráfico dejaría de salír vía UMTS para salir por la línea telefónica. Esto supone un ahorro, pues el coste de la línea UMTS es por volumen de tráfico y sólo debería utilizarse cuando fuese necesario.

En unos días os presentaré un interesante Router UMTS / HSDPA con protocolo VRRP.

Espero que os haya resultado interesante.

Hace poco más de una década Intel desarrolló el bus PCI y fue adoptado por la industria como un estandard dirigido por el grupo PCI SIG (PCI Special Interest Group). Este bus nació con el objetivo de superar las limitaciones de velocidad que tenían los ordenadores de la época con el bus ISA. Acordémonos de los ordenadores de entonces que sólo tenían este tipo de BUS. Poco a poco los equipos cada vez tuvieron menos buses ISA, hasta llegar a la actualidad, en que es casi imposible (por lo menos en los ordenadores convencionales de sobremesa) encontrar equipos con este tipo de bus.

El bus PCI, de 32 ó 64 bits con una frecuencia de bus de 33 ó 64MHz consiguiendo velocidades de datos de entre 132 y 512 MB/seg, desbancó por completo al bus ISA. Sin embargo a día de hoy esa velocidad resulta insuficiente para muchas aplicaciones y por ello Intel ha diseñado el nuevo estandard PCI Express, que como en su día el PCI, se está imponiendo poco a poco.

La arquitectura en este caso es diferente. Si bien con PCI el bus se comparte por el conjunto de tarjetas y dispositivos a él conectado, en este caso lo que se comparte es un switch. Es decir, antes cada dispositivo PCI colgaba del bus. Con PCI Express eso deja de ser así y todos estos dispositivos cuelgan de un switch. Esta es la característica más importante de PCI Express. El hecho de dejar de compatir el bus y realizar conexiones punto a punto entre los dispositivos PCI Express y el switch evita tener que dividir el ancho de banda disponible entre los distintos dispositivos, como ocurre con dispositivos PCI. En este caso es el switch el encargado de routear toda la información de un dispositivo PCIe a otro con lo que se garantiza el ancho de banda máximo para cada dispositivo.

La comunicación de los dispositivos PCI Express se realiza a través de Líneas. Cada Línea la forman un conjunto de 4 señales. Dos señales RX y otras dos TX. Esto es porque se utiliza un sistema diferencial. La comunicación es full duplex. Una de las características más importantes de PCI Express es que pueden agruparse líneas con el fin de aumentar el ancho de banda. Por ejemplo, veamos el siguiente dibujo:

En el ejemplo, tenemos un LINK (nombre que decibe la conexión de un dispositivo PCI Express con el switch) x4, es decir, los dispositivos PCIe del ejemplo se comunican a través de un LINK formado por 4 Líneas. De esta manera es posible incrementar el ancho de banda de la comunicación, consiguiendo velocidades extraordinariamente altas. Cada línea tiene un ancho de banda de 250MBytes/seg. Pueden unirse hasta 32 líneas, por lo que la velocidad máxima que se puede conseguir con un dispositivo PCIExpress es de 250×32 = 8GBytes/seg. Como véis con estas velocidades PCI Express va a permitir reemplazar no sólo a los buses PCI, sino también al resto de buses, como el bus AGP. 

Las líneas pueden agruparse en el formato x1, x2, x4, x8, x16 y x32, aunque las agrupaciones más comunes de líneas (las que suelen tener los ordenadores de hoy en día) son: de x1, x4, x8 y x16.

Otras características de PCIExpress son que mantiene la compatibilidad en software con PCI (aunque no en hardware, obviamente), se permite la conexión en caliente y además dispone de gestión integrada de errores e implementa funcionalidades de ahorro energético, aunque para para poder utilizar estas nuevas características es preciso que el Sistema Operativo sea capaz de hacerlo.

En la foto de la placa base que os he puesto salen tres buses PCI estandard. Veremos con toda seguridad con el tiempo como se va reduciendo este número hasta llegar a desaparecer por completo, tal y como ocurrió con el ya obsoleto bus ISA.

Espero que os haya gustado.

Hoy escribo un breve post para hablar únicamente de los conectores más comunes de las antenas. En el vídeo del post anterior que hablaba sobre el módem GPRS MTX65, comentaba que el conector de la antena era de tipo FME.  Cuando hablábamos del módem TC65 Terminal de siemens vimos que el conector de la antena era de tipo SMA. Si nos fijamos en cualquier módulo de Siemens MC55, TC63, TC65, XT65, HC15, HC25 podemos ver que el conector para la antena es de tipo UFL.

Es decir, hay cierto tipo de conectores habituales para antenas que es conveniente conocer. En el gráfico siguiente podéis ver una foto de cada uno de ellos con sus nombres (poner especial antención en los conectores SMA Rerverse Polarity, donde siempre hay confusión).

Por otro lado decir que si alguna vez lo necesitamos, existen en el mercado multitud de conversores de un tipo de conector a otro. Lo más común es utilizar los “latiguillos“. Por ejemplo, en la siguiente foto podéis ver un latiguillo conversor de UFL a SMA

Espero que encontréis de utilidad este post en alguna ocasión

Matrix Electrónica ha lanzado la distribución de un nuevo modelo terminal de módem GPRS MTX65. Esta basado, es decir, tiene en su interior, un modem TC65 de Siemens. Como pudisteis ver en el vídeo del post anterior cuando veíamos como instalar el entorno de desarrollo para el módem TC65 de Siemens, el módem que se mostraba entonces era el módem de Siemens TC65 Terminal.

Este modelo MTX65 distribuido por Matrix Electrónica (con el módem TC65 de Siemens en su interior) es prácticamente igual que el TC65 Terminal de Siemens , pero añadiendo una serie de prestaciones adicionales y con un precio más reducido. También hay que decir que el TC65 Terminal dispone de 10 GPIOs frente a las 4 de este modelo MTX65, por lo que si nuestra aplicación debe gestionar muchas entradas / salidas digitales seguirá siendo más conveniente usar el TC65 Terminal estandard de Siemens.
 
 
¿Pero qué prestaciones tiene este módem MTX65?

Pues dispone de un puerto serie completo (con todas las señales de control de flujo), conector de antena de tipo FME, un conector DB15 que dispone de 4 señales de entrada/salida configurables, 2 señales de entradas analógicas, un bus i2c/SPI, y un bus serie adicional (el TC65Terminal de Siemens no dispone de este puerto adicional) sin control de flujo, es decir, sólo RX y TX. Además dispone de conector USB (el módem TC65 Terminal de Siemens no dispone de conector USB, a menos que lo sueldes tú manualmente) con el que podremos debugar nuestras aplicaciones java. Dispone también de conector de audio, de alimentación, led de estado y porta SIM.

Otra cosa a resaltar es su reducido tamaño, con un volumen que es aproximadamente la cuarta parte respecto al TC65T que vimos en el post anterior.

En el siguiente video que os he colgado podréis ver con más detalle este equipo, que como se suele decir, vale más una imágen que mil palabras, y si es un video, pues todavía mejor

Se me olvidaba comentar que también está disponible el modelo MTX63, es decir, es idéntico al modelo anterior (en cuanto aspecto) pero tiene en su interior un módem de Siemens TC63. Por supuesto hay alguna limitación respecto al modelo MTX65, pues en este caso no se puede embeber java, ni hay señales de E/S, ni i2c/SPI, pues el módem TC63 de Siemens que lleva en su interior no tiene esas prestaciones.

Estos modelos de terminales sólo los podréis encontrar en Matrix Electrónica (915602737) pues son ellos los únicos distribuidores de estos modelos. Aquí también os cuelgo el datasheet del MTX65 por si os interesa.

Espero que os haya gustado

Crear aplicaciones Java para embeber en un módem Siemens TC65 es sencillo, pero requiere de la instalación precisa de una serie de software.

A continuación os muestro un vídeo muy básico del módem Siemens TC65 (en su versión terminal, es decir, en caja) y las conexiones que hay que realizar previo a la instalación del entorno de desarrollo.

Una vez tenemos las conexiones hechas, hay que instalar toda una serie de herramientas de software gratuitas que proporciona recopiladas en un CD Siemens (o Matrix Electrónica, el distribuidor oficial de Siemens en España). El entorno de desarrollo que voy a enseñar a instalar es el Eclipse, aunque su uso no es obligatorio. Puede utilizarse si se desea NetBeans (que yo no he probado) aunque casi todos los desarrolladores del módem Siemens TC65 (y del modem Siemens XT65) utilizan Eclipse.

La instalación no es compleja si se siguen estrictamente los pasos indicados. El no seguir estos pasos, sobre todo si no se tiene experiencia en Eclipse, es sinónimo de problemas, por lo que os recomiendo cierta atención en la instalación.

En el siguiente vídeo (9Mb) os muestro cómo instalar el entorno de desarrollo (haz click aquí o en la imágen siguiente para ver el vídeo). 

En breve pondré un vídeo de cómo crear, compilar y debugar nuestra primera aplicación en Java para los modems Siemens TC65 y XT65 utilizando Eclipse. Ya sabéis, la típica aplicación Hello World.

En breve pondré para los modems Siemens TC65 y XT65 utilizando Eclipse. Ya sabéis, la típica aplicación .

Espero que encontréis de interés este post