Estructura y comunicaciones del PFC

Para poder continuar es necesario conocer la estructura final de la red. A continuación estudiaré las dos principales opciones. La parte común a ellas es la que comunica los sensores con un servidor; esto se hace mediante ZigBee porque es la tecnología con la que se puede formar una red con menor consumo eléctrico.

-Usando un servidor externo al sistema:

Ventajas:

  • La memoria puede ser un archivo en el PC.
  • Es un sistema simple y económico.

Inconvenientes:

  • Depende de un PC.

-Usando un servidor integrado en el sistema:
Ventajas:

  • Si lleva memoria integrada se convierte en un sistema autónomo.
  • Se puede conectar a cualquier dispositivo con WiFi o Bluetooth (depende de la opción elegida).

Inconvenientes:

  • Es mas costoso en componentes.
  • El sensor maestro tiene un consumo mayor.
  • El sensor maestro corre el riesgo de saturarse.

La desventaja de la primera alternativa tiene difícil solución, o mejor dicho, la solución es la segunda alternativa. Respecto a las desventajas de la segunda tenemos:

  • Precio: El módulo WiFi con menor consumo a 3.3V es el 831-1007-ND (o también 831-1008-ND). Su precio es de unos 31$. En el caso de usar Bluetooth se usaría el módulo 647-1009-2-ND cuyo precio es similar.
    Hay que añadir también la tarjeta de memoria que cuesta unos 10€.
  • Consumo: En el caso de la WiFi, su consumo es de 110 mA mientras que en el del Bluetooth es de 75 mA. Para las tarjetas de memoria MMC (que comparte el standard con SD) el consumo ronda los 60 mA.
  • Saturación: para ver como soportaría todas las comunicaciones el sensor maestro es necesario llevar a cabo un estudio mas exhaustivo.

Independientemente del modelo usado, será necesario que servidor con ZigBee soporte la transferencia de datos de todos los nodos. Como ya estudié en el primer artículo, cada nodo puede llegar a producir una tasa de datos de 96 Kbps y como mucho el sistema tendrá 11 nodos, así que el servidor tendrá que aguantar una carga constante de 1056 Kbps. El problema no acaba aquí, pues las comunicaciones inalámbricas, al igual que buses cableados como el I2C o el CAN, llevan bits/bytes de control. En el protocolo 802.15.4 (ZigBee) son necesarios 12 de estos bytes de control:

Esto supone que si cada nodo transmite 12 bytes por paquete (los 6 registros del sensor de movimiento) se desperdicia mas de la mitad de ancho de banda en datos de control (hay que tener en cuenta también algunos comandos que no comunican datos); en total el servidor tendría que aguantar una carga de más de 2112 Kbps, superando así el límite de 2Mbps que proporciona el ZigBee del controlador ATmega128RFA1. Sin querer abusar, se puede hacer que cada paquete recoja la información referente a 10 instantes, que haría un total de 120+12 bytes por paquete, (la carga máxima de datos que puede transportar un paquete es de 128 bytes). De esta forma cada nodo transmitiría a una velocidad de 105,6 Kpbs reales, generando un total de 1161 Kbps, que por el momento, y desde mi ignorancia, considero aceptable para el enlace de 2 Mbps.

Respecto a las comunicaciones con el sistema externo, en el primer caso no se tendrían problemas. En el segundo caso, ya sea un PC o un PDA, había propuesto 2 alternativas: WiFi y Bluetooth. Después de un breve estudio creo que es mas conveniente usar Bluetooth, a pesar de que esta mas limitado en velocidad (3Mbps el módulo anteriormente mencionado), porque permite un funcionamiento como esclavo sin la necesidad de intervenir para introducir contraseña como sucedería en una red WEP/WPA, tampoco hay que configurar IP y por último tiene un menor consumo.

Resumiendo, tenemos 2 enlaces inalámbricos, ambos con una transferencia de unos 1200 Kbps incluyendo los bits de control, uno de los enlaces es concast (o un multicast inverso), donde se usa ZigBee con una transferencia máxima soportada de 2 Mbps y el otro es unicast, en el cual se usa Bluetooth con una capacidad máxima de 3 Mbps.

El protocolo para comunicar el microcontrolador con el módulo Bluetooth puede ser USART, quedando limitado a 2 Mbps por el controlador, o usando SPI que estaría limitado a la mitad de la frecuencia de reloj del microcontrolador, esto seria 16Mhz/2 = 8MHz => 8 Mbps.

Hay que pensar en que estos cálculos están pensados para una frecuencia de actualización de 1 Khz por nodo, esto es una velocidad extremadamente rápida para una captura de movimiento, así que en caso de que faltase velocidad de red se descartaría esta frecuencia y se trabajaría con una mas baja, que no daría ningún problema.

Otro problema es que el buffer de E/S integrado en el microcontrolador es de 128 bytes, pero esto lo trataré en el siguiente artículo.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s