blogElectronica.com

El otro día posteaba sobre el nuevo modelo de modem umts/hsdpa MTX-H15.  Si os acordáis, os dije que la conexión con este módem es necesario hacerla a través de un puerto USB, pues ese módem, por razones que atienden a la muy alta velocidad de transferencia de datos, no puede gestionarse con el habitual puerto RS232 con el que todos trabajamos normalmente con este tipo de dispositivos.  Por consiguiente el modem MTX-HC15 tampoco dispone de pila TCP/IP.

En ocasiones he oido que un modem tiene pila TCP/IP. ¿Qué significa esto de tener o no tener pila TCP/IP? ¿Cambia la forma de trabajar?

Cuando decimos que un modem dispone de pila tcp/ip (stack tcp/ip) significa que, hablando llanamente, el módem es capaz de, mediante comandos AT recibidos vía serie, establecer y gestionar los datos enviados y recibidos a través de una comunicación IP.

Cuando decimos que un modem es GPRS pero no dispone de pila tcp/ip, significa que para gestionar una comunicación IP es necesario disponer de un dispositivo (un sistema con procesador) que gestione el módem y que disponga de esa pila, es decir, de un dispositivo con cierta inteligencia que disponga de todas las funciones y librerías que forman lo que se conoce como pila o stack tcp/IP.
 
 
Muy bien, pero sigo sin entenderlo. ¿Algún ejemplo en concreto?

Por ejemplo, un módem Siemens TC65 o TC63 sí tienen pila TCP/IP. Esto significa que tan solo con un micro muy muy simple que únicamente tenga un puerto serie (por ejemplo algún PIC) podrá realizarse una comunicación TCP/IP a través de GPRS. Toda la complejidad de la gestión de las tramas IP será realizado por el propio módem. El micro, enviando simples comandos AT por el puerto serie, puede realizar conexiones IP a servidores remotos y enviar y recibir datos de los mismos. Por ejemplo, si ya tenemos un socket TCP conectado un servidor y nos ha enviado datos, simplemente enviando el comando “AT^SISR=0″ por el puerto serie, el modem nos devolverá los datos que tenga en el buffer de recepción del socket nº 0. Así de fácil.

Como he dicho antes, modems como por ejemplo el Siemens HC15 (umts) o un Siemens MC35iT (gprs) no disponen de pila tcp/ip por razones distintas (uno por razones de velocidad, otro simplemente por precio). Con estos modems realizar una conexión IP a través de GPRS no puede realizarse por un micro tan simple como el anterior sin pila TCP/IP, pues estos módems no contienen las funciones necesarias para gestionar las tramas recibidas. Actúan símplemente como modems. Estos módems deben ser controlados por procesadores con stack tcp/IP, que serán los que reciban “el chorro” de datos provinientes de los modems y analicen las cabeceras IP, los CRCs, etc etc.
 
 
¿Y cuando elegir un modem con pila TCP/IP o sin ella?

Pues depende. En ocasiones no se puede elegir debido a que no encontrarás modems con la pila, como el caso de modems UMTS/HSDPA. En caso en que sí puedas elegir, pues dependerá de si ya estás utilizando un micro que dispone de dicha pila o no. Si no dispone evidentemente deberás coger un módem con pila tcp/ip, y si dispone de ella pues tú eliges.  Personalmente yo siempre que pudiese eligiría un modem con stack tcp/IP, pues las aplicaciones normalmente te serán muchísimo más simples de implementar, sobre todo aquellas en las que no tengas que realizar envíos o recepciones masivas de datos. Si tienes que enviar montones de datos de forma masiva (aplicaciones de vídeo por ejemplo) pues sí, entonces mejor utilizar la pila tcp/IP del procesador, por cuestiones de velocidad.
 

Posiblemente ya sabías lo que significa en la práctica que un modem tenga stack tcp/ip o no. Si no es así, espero que este post te haya aclarado un poquito el concepto.

Vamos a hablar un poquito del sistema operativo Windows CE,  un sistema operativo en tiempo real (a diferencia de su homólogo ucLinux) de 32 bits diseñado para operar en dispositivos con mayores limitaciones que un PC convencional de sobremesa.

Windows CE es un sistema operativo bastante utilizado en procesadores embebidos (como pueden ser los módulos de Digi) y es por eso por lo que vamos a hablar un poco sobre él y sobre la evolución que ha tenido desde la versión Windows CE 1.0, nacida hace ya más de una década, hasta la última versión Windows CE 6.0 que apareció hace pocos meses.

Windows CE no nació en 1994 con ese nombre, sino con el nombre de “proyecto Pulsar”, el cual al final acabó convirtiéndose en este conocido Sistema Operativo.
 
 
Veamos un poquito de historia acerca de las distintas versiones de Microsoft Windows CE:

Windows CE 1.0.
 
Código fuente fue escrito desde cero y fue lanzado comercialmente en el año 1996.
Parcialmente compatible con el Windows tradicional pues soporta una parte de la famosa API Win32.
Independiente del hardware pues es compatible con las arquitecturas más comunes de  de 32 bits. 

Windows CE 2.0
 
Basado en la versión predecesora 1.0 vió la luz en 1997.
Se añadió soporte para procesadores Intel y AMD
Soporta pantallas con resolución de 24 bits
Conexión de red LAN
Soporte de tecnología ActiveX
Incorpora la máquina virtual java.
Soporte parcial MFC (Microsoft Foundatin Classes, una librería de clases en C++ para programación bajo Windows, incluida en MS. Visual C++)
Conectividad USB e infrarrojos
Soporte FAT e impresión
 

Windows CE 3.0
 
Esta versión salió al mercado en el año 2000 con el fin de comperir con el sistema operativo de PALM.
Incorporación de las interrupciones con prioridades.
Mayor eficiencia en la gestión de threats y en las comunicaciones entre procesos
Mayor capacidad de almacenamiento.
Es la base del sistema operativo PocketPC 2002, que se podía encontrar entonces en algunas PDA y teléfonos.
 

Windows CE 4.0

Esta nueva versión del sistema operativo apareció en Marzo del año 2002
Sistema operativo mucho más robusto y eficiente a nivel pultiproceso que la anterior versión.
Mayor grado de comunicación y sincronización con el sistema Windows tradicional.
De el nació en Junio del 2003 la conocida versión Windows Mobile 2003. Prácticamente fue un cambio de nombre y unas aplicaciones añadidas.
 

Windows CE 5.0

Penúltima versión de este sistema operativo lanzado en Mayo del año 2005.
Mejora del software ofimático y multimedia.
Mejoras en el stack bluetooth
De él nacio la versión Windows Mobile 5.0 disponible en multitud de teléfonos móviles y PDAs.
 

Windows CE 6.0

Última versión de este sistema operativo lanzado a principios de este año.
Un 30% superior en prestaciones a su predecesor Windows CE 5.0
Es posible acceder mediante API a un I/O en un ciclo de 100us
Los mayores cambios se encuentran en el Kernel.
La arquitectura del sistema operativo ha sido completamente revisada.
Cada proceso es capaz de direccionar 2GB (antes 32Mb)
El nº de procesos simultáneos han aumentado de 32 a 32.000

Espero que alguna vez pueda resultaros de utilidad esta breve historia sobre la evolución de Windows CE

Se acaban las vacaciones para todos. Muchos decimos, “ufff, vuelta a madrugar, vuelta a trabajar … a ver si tengo suerte y me toca la lotería … “. De hecho la recaudación por loterías aumenta siempre en Septiembre de forma cosiderable. Hoy me han enviado un email con un link a un flash de esos que no dejan indiferente. Lo podéis ver aquí. Tras ver ese flash uno puede darse cuenta realmente de la suerte que tiene por tener que madrugar, por tener que trabajar … en definitiva la suerte que tenemos de haber nacido donde hemos nacido y de lo insignificantes que realmente son la mayoría de nuestros problemas y pequeños sacrificios cotidianos en comparación con esa tragedia. Espero y deseo que algún día Internet pueda llevar el conocimiento gratuito a toda esa gente, que es la base imprescindible para poder prosperar.

En fin … volviendo al temas más mundanos, hoy voy a empezar una serie de artículos relacionados con módulos embebidos (o embedded modules) bajo Linux embbeded. Los iré alternando con otros artículos de temática diversa. Como hay que basarse en algo, lo voy a hacer en módulos embebidos de Digi, concretamente en los modelos ConnectCore9C, ConnectCore9P o ConnectCoreWi9C. A aquellos que vayan a utilizar otra marca creo que también les puede servir, pues los conceptos son muy parecidos. Evidentemente a quien use los módulos de Digi (de los que he de reconocer que ha mejorado mucho la documentación) les resultará más útil e interesantes todos estos post. De hecho para estos capítulos me voy a basar en la documentación oficial de Digi.

¿Qué diferencias hay entre aplicaciones para PC convencional o para sistemas embebidos?

No es lo mismo desarrollar aplicaciones para un PC convencional que para un sistema embebido. El desarrollo de aplicaciones para sistemas embebidos implica tocar bastantes elementos además de la propia aplicación, como son el Sistema Operativo y sus posibles personalizaciones, los drivers, el sistema de ficheros, entre otros. Como he dicho antes nos vamos a basar en el S.O. Linux Embedded, muy extendido hoy en día en este tipo de dispositivos debido a la propia naturaleza de Linux, disponible para muchas arquitecturas de hardware que lo hacen un buen candidato para estos menesteres. Veamos algunos conceptos.
 

Cross-compilation  (compilación cruzada).

Siempre que desarrollemos el software para un dispositivo embebido en una plataforma con una arquitectura de procesador diferente, es necesario utilizar un entorno de desarrollo cruzado. Un compilador cruzado es un compilador que se ejecuta en el sistema de desarrollo, es decir, en  nuestro PC portátil o de sobremesa (Intel x86, por ejemplo) donde desarrollamos la aplicación para el módulo embebido, pero que el código que genera se ejecuta en otro procesador. En nuestro caso de los módulos de Digi, en procesadores ARM.
 
 
Boot loader.

El boot loader es un pequeño software que se ejecuta justo al encender un ordenador. Si hablamos de nuestro PC de sobremesa, este pequeño programa que reside en el MBR (Master Boot Record) de nuestro disco duro, se ejecuta una vez que la BIOS del ordenador ha inicializado todo el sistema. El boot loader entonces pasa información del sistema al Kernel, es decir, la partición del disco duro donde se montará la root y finalmente se ejecuta el propio kernel.

Pero si hablamos de sistemas embebidos esto es más complicado, ya que estos sistemas NO tienen BIOS que inicialicen el sistema y la inicialización del microprocesador, de los controladores de memoria, y en definitiva de todo el hardware de la placa debe hacerlo el programita de la boot antes de que se ejecute el Kernel del sistema.

Como mínimo el boot loader debe inicializar el hardware, especialmente los controladores de memoria y arrancar el sistema operativo con los parámetros adecuados, aunque también puede tener funcionalidades adicionales, como la lectura y escritura en memoria, y todas aquellas funcionalidades que permiten poder actualizar el firmware (sistema operativo, aplicaciones, …) en la memoria flash del equipo vía serie o ethernet.
 
 
El Kernel

El Kernel es la parte fundamental del sistema operativo, el núcleo del sistema. Es el responsable de la gestión de los recursos y las comunicaciones entre el harware y el software, proporcionando una abstracción de hardware y proporcionando una manera segura de acceder al sistema de memoria. También es el responsable del control de las interrupciones y de todas las operaciones de E/S (Entrada/Salida).
 
 
Modulos del Kernel.

Los módulos del kernel son pequeños programitas que son cargados y descargados por el kernel del sistema en función de las necesidades. A modo de ejemplo, un driver de un dispositivo lo podéis ver como un módulo del kernel, el cual permite a dicho kernel poder acceder al hardware conectado al sistema. Si no hubiera módulos tendrían que implementarse en el propio kernel y éste sería terriblemente largo y poco abierto. De esta manera cuando modifiquemos un módulo no tendremos la necesidad de recompilarlo todo de nuevo.
 
 
Root File System.

Como sabéis los Sistemas Operativos manejan ficheros y directorios.  El Root File System digamos que está en el techo del árbol de directorios y ficheros. Éste contiene ficheros y directorios críticos para las operaciones del sistema como pueden ser los programas de inicialización del sistema.
 
 
Aplicaciones.

Esto es lo que más conocéis todos, pues son los programas que utilizan los recursos de un procesador para realizar tareas. Las aplicaciones hacen uso de los dispositivos hardware, como hemos dicho a través de los drivers, los cuales son parte del kernel.
 
 
Espero que os haya resultado interesante esta primera introducción.

Tal vez en alguna ocasión hemos tenido que diseñar algún circuito en el que entre en juego el uso de la línea telefónica convencional. Un ejemplo puede ser un sistema de seguridad para llamadas de voz. Por ejemplo, imaginemos que queremos diseñar un equipo que nos permita realizar llamadas de voz utilizando la línea telefónica convencional y, automáticamente, en el caso de la caída de esta, que las llamadas de voz salgan a través de la línea GSM. Aplicación también útil para sistemas de alarmas, por ejemplo.

Hay dos formas de llevar a cabo esta aplicación. Una sería el diseño por nosostros mismos de los circutos de telefonía, lo que requiere de ciertos conocimientos específicos en la materia, de tiempo de diseño de los circuitos, de los pcb, de las pruebas, de las certificaciones, en definitiva, de una cantidad de requerimientos que se traducen en tiempo y dinero.

Y la otra forma, la más fácil y rápida, es utilizar dispositivos que existen ya en el mercado para estos menesteres, como son los interfaces de línea. Silver Telecom dispone de dichos interfaces. Podríamos clasificarlos en dos grupos. Por un lado tendríamos los SLIC, que serían unos dispositivos que digamos emularían la línea telefónica y por otro lado los COIC, que emularían a lo que serían los teléfonos conectados a la línea telefónica.

Hoy voy a comentar rápidamente los SLIC, otro día hablaré de los COIC y finalmente pondré un circuito ejemplo real de aplicación del uso combinado de ambos dispostivos.

El SLIC más utilizado de Silver Telecom es el ag1170. Podéis verlo en la fotografía superior.  Es un pequeño dispositivo que como decía anteriormente emula lo que sería la línea telefónica. Es decir, genera, a partir de los 5V (o 3.3V) de alimentación, todas las tensiones que genera la línea telefónica, generando por tanto el tono de espera, el ring (75V), etc …

Estas señales pueden generarse fácilmente a través de los pines de entrada del dispositivo (ver datasheet), que pueden ser controlados fácilmente desde cualquier microprocesador básico. También convierte de los dos hilos con los que digamos emula la línea telefónica (llamados TIP y RING) y a los cuales podríamos conectar cualquier teléfono convencional que tengamos por casa (o a una distancia de hasta 3Km ), a cuatro hilos. Dos serían de entrada de audio y dos de salida de audio. Por supuesto, todo el tema de adaptación de impedancias puede programarse y es muy simple de implementar, pues basta utilizar unos pocos componentes externos, siguiendo las instrucciones del fabricante.

Todo el tema de protecciones también lo tiene resuelto el ag1170 de Silver Telecom. Por ejemplo, protecciones térmicas para el caso de cruce de las líneas TIP y RING, caso en el que el conversor interno DC/DC del dispositivo se encargaría de limitar, o protecciones contra sobrevoltajes.

Cuando hablemos del coic y veáis un ejemplo de aplicación final, seguro que quedará todo más claro y veréis mejor la utilidad. Y es que desde mi punto de vista hoy en día la tendencia es a utilizar cada vez más módulos ya diseñados, pues el tiempo de colocación de un producto en el mercado es crucial. Nadie se pone a diseñar hoy en día un módem GSM (ni uno analógico) se compran módulos hechos y los integramos en nuestros diseños. Con los interfaces de línea ocurre cada vez más.

Espero que os pueda resultar interesante en algún momento este post.

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.

El lector de este blog que use habitualmente dispositivos RF sabrá que una de las características más importantes de cualquier dispositivo de transmisión / recepción RF es el alcance de las comunicaciones.

En el catálogo de cualquier fabricante de módulos RF, como pueden ser Maxstream, Coronis, Jennic, Nordic, etc, etc, etc encontraréis que siempre se indica la máxima distancia a la que se pueden comunicar un equipo emisor y receptor.

Los datos que nos indican en los catálogos son ciertos, pero tenemos que saberlos interpretar para no llevarnos sorpresas desagradables. Los datos proporcionados por los fabricantes de alcance máximo RF son siempre bajo ciertas condiciones idóneas. Estas condiciones idóneas son básicamente:

1.- Utilización de antenas correctas. No vale utilizar una antena de 868Mhz para un dispositivo de 2.4Ghz.
2.- Ausencia de condiciones climatológicas adversas (en el caso de comunicaciones outdoor (exteriores)).
3.- Visión directa entre dispositivos radio, es decir, sin obstáculos entre medio.
4.- Altura correcta donde se colocarán las antenas para respetar la primera zona de Fresnel.

Es este importantísimo punto nº4, relativo a las zonas de Fresnel, un tanto desconocido, es del que voy a hablar un poco.
 
 
¿Y qué son las zonas de Fresnel?

Hablando un poco académicamente “zona de Fresnel se le llama al volumen de espacio entre emisor y receptor RF de manera que el desfase entre las ondas en dicho volumen no supere los 180º.”  Uffffff

Es decir, cuando transmitimos algo en tierra (es decir, no estamos en el espacio) tenemos rebotes en el suelo. Los rebotes pueden contribuir positivamente a la recepción de la señal en el caso de que lleguen en fase y negativamente si llegan en contrafase.

Fresnel definió una zona que hay que tener en cuenta además de tener, como indicaba en el punto 3), visibilidad directa entre antenas. Realmente definió una serie de zonas. La zona 1 contribuye positivamente a la propagación de la onda, la segunda negativamente, la tercera positivamente, la cuarta negativamente, y así sucesivamente. Es decir, las impares contribuyen positivamente y las pares negativamente. Además, la primera zona concentra el 50% de la potencia de la señal  por lo que debemos procurar que llegue lo más integra posible al receptor.
 
 
¿Y cómo puedo llevar a la práctica la teoría de Fresnel para conseguir el máximo alcance de mis dispositivos RF?

Pues es sencillo. Debemos mantener despejado, al menos, el 80% de la primera zona de Fresnel. Fijémonos en el siguiente dibujo:

En color gris se representa a la primera zona de fresnel. Es decir para conseguir comunicarnos a una distancia D con una señal portadora de frecuencia f, debemos conseguir que la altura r de la primera zona de Fresnel (o al menos el 80% de r) esté libre de obstáculos. 

O visto desde otro escenario, imáginemos que estamos en el desierto en ausencia de cualquier tipo de edificio, árbol u obstaculo entre emisor y receptor. El fabricante nos dice que el alcance máximo de un dispositivo son X metros. ¿Cual es la distancia respecto al suelo a la que hemos de colocar las antenas para conseguir no entorpecer al menos el 80% de la primera zona de fresnel y conseguir el máximo alcance?

Pues si aplicamos la fórmula de ahí arriba (D en Km, r en metros, f en Ghz) nos sale que si un fabricante nos dice que la distancia máxima de su dispositivo que trabaja por ejemplo a 2.4Ghz es de:

300 metros, implica que las antenas tienen que estar como mínimo a 2.45 metros de altura respecto al suelo.
1.6 kilómetros, implica que las antenas tienen que estar por lo menos a 5.65 metros de altura respecto al suelo.
8 kilómetros, implica que las antenas tienen que estar por lo menos a 12.64 metros de altura respecto al suelo.
16 kilómetros, implica que las antenas tienen que estar por lo menos a 17.88 metros de altura respecto al suelo.

Espero que encontréis de utilizadad este post para vuestros diseños RF

Ayer Sábado hablaba de la tecnología ETX para PCs industriales. En el post de hoy voy a hablar de la evolución de ETX, que es XTX (eXtended Technology for ETX).

XTX es una evolución del muy conocido y usado estandard ETX, al cual se le añaden toda una serie de nuevas tecnologías de Entradas/Salidas. A día de hoy el bus ISA apenas se usa, es una tecnología podríamos decir ya obsoleta (posiblemente la mayoria de los lectores de este blog no tengan ya ninguna tarjeta ISA instalada en su PC, y si no es así, deberías ir pensando en cambiar de PC … ;-)  ). Si dáis un vistazo al post anterior podréis ver que en el conector X2 estaban todas las señales E/S del bus ISA. Pues bien, con XTX este conector X2 cambia de función. De esta manera se han podido añadir un gran número de buses de alta velocidad, como pueden ser los buses PCIExpress y Serial ATA (abajo tenéis las definiciones de qué son estos buses).

El resto de conectores, X1, X3 y X4 que comenté ayer se mantienen invariables, es decir, cumplen el estandard ETX (Rev 2.7) y por tanto son compatibles con la tecnología anterior ETX. De hecho si algún día queremos utilizar un módulo XTX en lugar de un ETX nos servirá la placa base que ya tengamos diseñada. Eso sí, siempre que no utilicemos (lo más normal) el bus ISA, que como decía, ya no existe en XTX.

Si se está utilizando un PC embebido ETX y estamos usando el BUS ISA y queremos evolucionar a XTX tenemos dos opciones.  Una, utilizar un bridge PCI-ISA que tendríamos que incluir en el diseño de nuestra placa base (donde insertaremos el módulo embebido XTX). La otra opción (si la anterior es muy cara de implementar por implicar rediseño) puede ser utilizar el bus LPC (Low Pin Count) que corresponde aproximadamente a un bus ISA serializado.

¿Pero qué nuevos buses tenemos en el conector X2?

Pues tenemos buses PCIExpress, ExpressCard, Serial ATA, USB, Interfaz de Audio digital y un bus LPC.
Veamos ahora en qué consisten estos buses.
 

PCI Express.

XTX dispone de 4 líneas para PCI Express. Estas líneas que pueden configurarse como 4×1, 2×2, 1×4 permiten conectar hasta 4 dispositivos externos. El ancho de banda de cada una de estas líneas es de 2.5Gbps. Con estas 4 líneas PCI Express pueden utilizarse dispositivos periféricos que requieran de un gran ancho de banda, como puede ser un dispositivo Gigabyte Ethernet.
 
 
Serial ATA.

XTX ofrece 4 buses Serial ATA. Serial ATA es una evolución del bus ATA paralelo, el cual mejora en velocidad. Serial ATA tiene una velocidad de 150 MBytes/seg y puede ser aumentada hasta 600Mbytes/seg para futuros desarrollos. Serial ATA es completamente compatible a nivel de software con parallel ATA.
 
 
ExpressCard.

XTX soporta hasta dos expressCard, que es el sucesor de PCMCIA, con un menor tamaño.
 
 
Bus LPC.

Este bus, como comentaba antes, se suministra como substituto al bus ISA, pues corresponde aproximadamente a un bus ISA serializado pero con un número muy reducido de señales.
 
 
Bus USB.

XTX ofrece dos buses USB 2.0 adicionales, lo que permite el poder conectar hasta 6 dispositivos USB 2.0 a nuestro equipo.
 
 
Interfaz digital de audio.

Además de el soporte para audio estandard (Line-in, Line-out, Mic) XTX ofrece las siguientes características: Audio DVD, Capacidad multistreaming, VoIP para telefonía, Dolby 5.1/6.1/1.1, etc …
Si necesitáis más información sobre XTX, podéis visitar www.xtx-standard.org o leer directamente el PDF del estandard XTX en el siguiente link.
 
 
Espero que os haya resultado de interés
 

Voy a iniciar una serie de posts para hablar de los PCs industriales. Cada vez son más los ingenieros que utilizan este típo de módulos para sus diseños, especialmente en el sector de los videojuegos, recreativos, control de maquinaria industrial, etc etc, es decir, en aquellas aplicaciones en las que sea preciso desarrollar software bajo plataformas con alta capacidad de procesado, ya sea matemático, de audio, de imágen, etc …

Las empresas que desarrollan este tipo de plataformas no lo hacen con diseños propietarios, es decir, no diseñan a su libre albedrío, sino que siguen ciertos estandars. Estos estandars reunen un cierto número de características comunes que deben cumplir los diseños de los PCs embebidos. De esta manera no nos casaremos con ningún fabricante en nuestros diseños, y siempre podremos encontrar alternativas en el caso de que un fabricante nos falle, no nos guste, obsolete un equipo o cualquier otro problema que podamos encontrar.

Empezaré hablando de la tecnología ETX para PCs embebidos. Estas siglas siginifican Embedded Technology eXtended. Son unos módulos pequeños, con unas dimensiones de 114mm x 95mm x 12mm. Como decía antes ETX es un estandard, lo que implica que todos los módulos de todos los fabricantes deben de tener las mismas dimensiones y la misma distribución de conectores comunes. De esta forma los ingenieros podrán crear sus diseños de placas base para “pinchar” estos módulos ETX, independientemente del fabricante que se los suministre.

Los módulos ETX incluyen los periféricos comunes que también tenemos en nuestros propios ordenadores personales, como son USB, puertos serie, puertos para gráficos (VGA), puertos paralelos, ratón, teclado, ethernet, audio, buses IDE, etc. El ingeniero que diseñe la placa base donde insertar el módulo ETX, será quien decida qué periféricos le interesa utilizar, y podrá llevar los conectores (por ejemplo DB9, USB, …) a la zona de la placa base que estratégicamente más le interese en su equipo final.

Otra cosa importante. Imáginemos que un ingeniero quiere diseñar un dispositivo ISA o PCI para utilizarlo con un PC embebido. Pues tendría dos opciones. Una, posicionar un conector de bus ISA o PCI en la placa base para insertar, además del módulo ETX, su dispositivo ISA o PCI; o dos, “embeber” ese dispositivo ISA o PCI dentro del diseño de su placa base, con el correspondiente ahorro de espacio y costes de fabricación.

Una vez un ingeniero tenga diseñada una placa base, podrá insertar el módulo ETX con las prestaciones que mejor se adapten a sus necesidades (módulos con microprocesadores más rápidos, con más o menos memoria, … ).
 
 
¿Y cuales son los conectores y buses comunes de los módulos ETX?

Son cuatro y queda muy claro en el siguiente gráfico:

En el conector x1 principalmente tenemos las señales del Bus PCI , cuatro buses USB 2.0, y las señales de audio, como son la entrada de línea y de micrófono y la salida de audio stereo.

En el conector x2 tenemos todas las señales del bus ISA (en los siguientes días hablaré de la evolución de la tecnología ETX a XTX, donde la fucionalidad ISA de este bus ha sido substituida por otras mucho más interesantes)

En el conector x3 están las IO gráficas de VGA y LCD (LVDS), los puertos serie COM, el bus de infrarrojos irDA y el puerto paralelo.

Finalmente en el conector x4 están los buses IDE, ethernet, SM, un bus I2C de hasta 400Khz, las lineas del buzzer, y las señales de control de alimentación.
 
Como os decía, en los siguientes post iré comentando tecnologías más avanzadas de módulos PC embebidos, como es XTX y COM Express.
 
Espero que os resulten estos posts de utilidad a quienes no conocéis bien el mundo de los PC embedded

Este es un breve artículo para quien le interese optimizar sus dispositivos Wifi, entre ellos, por supuesto y principalmente, los Routers WiFi ADSL que tenemos todos en casa u oficina.
 
Como podéis ver en vuestro router de casa, siempre que sea WiFi claro, podéis elegir entre 11 canales. El espectro en frecuencia para cada uno de los canales WiFi, que como sabéis trabaja en la banda de 2.4Ghz, puede representarse por el siguiente gráfico:

Como véis únicamente los canales 1, 6 y 11 tienen los lóbulos principales no superpuestos.
 

¿Esto que implica?

Pues implica que en el caso de que tú estés trabajando en tu casa con el canal1 y tu vecino con el canal6 no habrá colisiones, es decir, no habrá que hacer reintentos de envíos de paquetes, lo que se traduce que las comunicaciones wifi serán mucho más rápidas.
 

¿Y cómo elegir el canal óptimo?
 
Como consejo decir que muchos routers por defecto trabajan en el canal 1 y nadie lo suele cambiar. Es muy fácil ver comunidades de vecinos enteras (como la mía) con 6 ó 7 redes wifi todas trabajando en el mismo canal 1 “dandose codazos” para poder enviar paquetes.

Yo tengo configurado mi router en el canal 11 donde nunca está trabajando ningún otro router (ni tampoco me afectan los armónicos de los que están utilizando el canal 1, la mayoría) y por lo tanto no tengo colisiones con las redes de los vecinos y puedo navegar plácidamente.

Espero que os sea útil este pequeño artículo.