Comunicación entre automóviles vía radio utilizando...

Comunicación entre automóviles vía radio utilizando zigbee

TITULACIÓN: Ingeniería Técnica de Telecomunicaciones en Telemática

AUTORES: David Rodrigo Frasquier

DIRECTORES: Dr.Antoni Lázaro Guillen, Dr.Javier Maixè Altés

FECHA : Noviembre de 2008

2

Índice Páginas 1 Objetivo del proyecto 4 2 Introducción al ZigBee 5 2.1 Introducción 5 2.2 ZigBee Alliance 5 2.3 Bandas de operación 6 2.4 Modulación OQPSK 6 2.5 Tipos de dispositivos 7 2.5.1 Coordinador ZigBee (ZigBee Coordinator, ZC) 7 2.5.2 Router ZigBee (ZigBee Router, ZR) 8 2.5.3 Dispositivo final (ZigBee End Device, ZED) 8 2.6 Topología de red 9 2.7 Seguridad en las tramas 10 2.8 Arquitectura de ZigBee 10 2.8.1 Capa de aplicación 10 2.8.1.1 Subcapa de soporte de la aplicación (APS) 11 2.8.1.1.1 Estructura de aplicación 11 2.8.1.1.2 Fundamentos de comunicación de la capa de Aplicación 11 2.8.1.1.3 Descubrimiento 11 2.8.1.1.4 Enlace 12 2.8.1.1.5 Mensajes 12 2.8.1.1.6 Direccionamiento directo 12 2.8.1.1.7 Direccionamiento broadcast 12 2.8.1.2 La subcapa ZDO 13 2.8.1.2.1 Fundamentos de comunicación de la subcapa ZDO 13 2.8.1.2.1.1 Gestión de descubrimiento 13 2.8.1.2.1.2 Gestión de enlace 13 2.8.1.2.3 Gestión de seguridad 14 2.8.2 Capa de red 14 2.8.2.1 Servicio de datos 14 2.8.2.2 Servicio de Control 14 2.8.2.3 Tabla de primitivas 15 3 Especificaciones Técnicas del Kit ZigBee JENNIC JN5139-EK010 16 3.1 ZigBee Jennic 16 3.2 Hardware del módulo de control (coordinador) 16 3.2.1 Display 17 3.2.2 Sensor de luminosidad 17 3.2.3 Sensor de temperatura y Humedad 17 3.2.4 Conectores UART 18 3.2.5 Conector de expansión 19 3.2.6 Selector de alimentación J2 20 3.2.7 Modo programación 20

3

3.3 Hardware del módulo sensor (end device/router) 21 3.3.1 Sensor de luminosidad 21 3.3.2 Sensor de temperatura y Humedad 22 3.3.3 Conectores UART 22 3.3.4 Conector de expansión 23 3.3.5 Selector de alimentación J2 24 3.3.4 Modo programación 24 4 Data Sheet del JN5139 25 4.1 Wireless microcontroladores 25 4.2 Características del transciver 25 4.3 Diagrama de bloques 25 5 Comandos AT 27 5.1 Ejemplo de algunos comandos 28 6 Configuración y test de funcionamiento de la red ZigBee 31 6.1 Creación de una pequeña red 31 6.2 Comunicación wireless mediante pc’s 33 7 Programa de test 37 7.1 La opción test 37 7.2 La opción graph 41 7.3 La opción command 42 8 Estadísticas de comunicación wireless (para objetivo del proyecto) 43 8.1 Escenario 1 44 8.2 Escenario 2 51 8.3 Escenario 3 55 8.4 Escenario 4 62 8.5 Escenario 5 65 8.6 Escenario 6 66 9 Conclusiones generales del proyecto 72 10 Bibliografía 74

4

1 Objetivo del Proyecto

Este proyecto tiene como propósito demostrar la viabilidad de dos objetivos concretos: -El primer objetivo de este proyecto de final de carrera, nace de la necesidad de hacer

nuestras ciudades un poco menos ruidosas. Está claro que el tema de la contaminación ambiental está muy a la orden del día, así que se ha pensado en buscar una solución a uno de los problemas de contaminación acústica más importantes de las ciudades, que es el ruido que generan los vehículos de emergencias. Se ha estudiado una posible solución para atajar este problema.

Una de las soluciones más efectivas que se encuentran, es poder utilizar algún dispositivo vía radio que alertase a los propietarios de los vehículos privados de la proximidad de un vehículo de emergencia.

Los propósitos de la sirena de estos vehículos de emergencias, son alertar de su presencia a los conductores, para que estos les dejen vía libre y alertar también a los peatones.

Los peatones se darían cuenta de la presencia de un vehículo de emergencia tanto visualmente como con menos potencia de sonido. Entonces nos damos cuenta de que el elevado volumen de la sirena es para que los conductores de los vehículos se percaten de su presencia, ya que estos pueden estar escuchando música, manipulando el GPS, etc...

La idea es utilizar un dispositivo que alerte a los conductores de los vehículos de la presencia de ambulancias, coches de policía, bomberos, etc...

Este dispositivo tendría que enviar un mensaje vía radio dirigido desde los vehículos de emergencia al display del ordenador de a bordo de los vehículos privados. Esta aplicación es un ejemplo de lo que se conoce como comunicación inter-vehicular .

Habiendo estudiando las tecnologías inalámbricas que había en el mercado, recientemente ha aparecido una tecnología inalámbrica nueva, que originalmente estaba pensada para comunicaciones wireless de bajo consumo con baterías autónomas y con un radio de cobertura más amplio que por ejemplo el bluetooth.

Se decidió realizar un proyecto de viabilidad para comunicación wireless entre vehículos.

Esta tecnología inalámbrica WPAN esta basada en el estándar IEEE 802.15.4 [1] y comúnmente recibe el nombre de ZIGBEE.

-El segundo objetivo será demostrar el funcionamiento de los sensores de los módulos

ZigBee de Jennic. Estos módulos disponen de sensores de humedad, temperatura, luminosidad, etc.

Así que se comprobará la posibilidad de utilizar estos sensores en los vehículos. La intención es probar si sería viable, puesto que estos sensores no necesitan de conexiones por cable para enviar datos. En este caso sólo se demostrará el funcionamiento de estos sensores wireless en los vehículos. El siguiente paso para otro proyecto sería el estudio que se basaría en el ahorro que supondría la eliminación de los cables que unen los sensores con la centralita en los vehículos de hoy en día.

5

2 Introducción al ZigBee 2.1 Introducción

ZigBee, conocido con otros nombres como "HomeRF Lite", es una tecnología inalámbrica con velocidades de hasta 250 KB/s y rangos de cobertura de hasta 500 m.

Puede usar las bandas libres ISM de 2,4 GHz, 868 MHz (Europa) y 915 MHz (EEUU). Una red ZigBee puede estar formada por 64770 dispositivos/nodos, los cuales tienen

la mayor parte del tiempo el transceiver ZigBee dormido, con objeto de consumir menos que otras tecnologías inalámbricas.

Un módulo ZigBee puede estar alimentado con pilas de 1,5 V durante al menos 2 años, dependiendo de la potencias de trasmisión. Como comparativa la tecnología Bluetooth es capaz de llegar a 1 MB/s en distancias de hasta 10 m operando en la misma banda de 2,4 GHz,

Los módulos ZigBee son los transmisores inalámbricos más baratos jamás producidos de forma masiva. Con un coste estimado alrededor de 1 euro.

Al igual que Bluetooth, el origen del nombre es oscuro, pero la idea vino de una colmena de abejas pululando alrededor de su panal y comunicándose entre ellas. 2.2 ZigBee Alliance

ZigBee es una alianza sin ánimo de lucro de 25 empresas, la mayoría de ellas fabricantes de semiconductores, con el objetivo de auspiciar el desarrollo e implantación de una tecnología inalámbrica de bajo coste.

Destacan empresas como Invensys, Mitsubishi, Philips y Motorola que trabajan para crear un sistema estándar de comunicaciones, vía radio y bidireccional, para usarlo dentro de dispositivos de domótica, automatización de edificios (inmótica), control industrial, periféricos de PC y sensores médicos.

6

2.3 Bandas de Operación

Los dispositivos ZigBee operan en las bandas libres de 2,4 GHz, 858MHz para el continente Europeo y 915MHz para EEUU. Dado que no coinciden la banda europea y americana, y dado que se disponen de mayor ancho de banda en la de 2.4 GHz se prevé que esta última sea la banda mas utilizada en ZigBee.

Figura 1: Tecnologías en 2.4GHz

La banda de 2.4GHz usa la modulación OQPSK [2] de 2 bits por símbolo que equivale a referenciar 4 fases diferentes. A una velocidad de transmisión de 250Kbps. El valor de potencia máxima permitida en la banda libre (ISM) de los 2,4 GHz es de 20 dBm. 2.4 Modulación OQPSK

La modulación Offset-QPSK consiste en una modulación QPSK de pulsos rectangulares, en la que se ha limitado la máxima variación de fase instantánea. Así como en una modulación QPSK convencional se llegan a producir saltos de ±π rad. Entre dos símbolos consecutivos, en la modulación Offset-QPSK (OQPSK) estos saltos de fase instantánea se reducen a la mitad ±π/2 rad., evitando que la componente en fase y la componente en cuadratura cambien de signo simultáneamente.

La limitación del máximo salto de fase instantánea es útil cuando la señal se amplifica mediante amplificadores de alta potencia, próximos a presentar un comportamiento no lineal. Como ejemplo, este tipo de amplificadores son frecuentes en los transponder de satélites.

Para evitar que ambas componentes cambien de signo simultáneamente en el transmisor, la componente en cuadratura se retarda temporalmente un tiempo equivalente a medio periodo de símbolo T/2 y, posteriormente en recepción con un filtro pasa bajo, se retarda la componente en fase temporalmente un tiempo equivalente a medio periodo de símbolo T/2 y, de este modo, quedan de nuevo las dos componentes sincronizadas.

7

Figura 2: diagramas de la modulación OQPSK 2.5 Tipos de Dispositivos

Las redes de ZigBee están compuestas por tres tipos de dispositivos: los coordinadores, los routers y los dispositivos finales (o end device). A continuación se explicará con detalle las características de cada uno. 2.5.1 Coordinador ZigBee (ZigBee Coordinator, ZC).

El tipo de dispositivo más completo. Debe existir uno por red. Sus funciones son las de encargarse de controlar la red y los caminos que deben seguir los dispositivos para conectarse entre ellos.

El coordinador ZigBee debe permitir que otros dispositivos se unan a la red basándose en sus parámetros de configuración, como pudieran ser la duración de la incorporación del dispositivo a la red o el número máximo de elementos que se pueden unir.

El coordinador ZigBee debe responder a cualquier dispositivo u operaciones del servicio de descubrimiento de su propio dispositivo o de cualquier dispositivo que tenga asociado y que esté dormido.

La aplicación del dispositivo debe asegurarse de que el número de entradas de enlace no excede de los indicados en los parámetros de configuración. Por tanto, el coordinador ZigBee tiene que soportar el control del proceso de incorporación a la red de cualquier dispositivo.

8

2.5.2 Router ZigBee (ZigBee Router, ZR).

Interconecta dispositivos separados en la topología de la red, además de ofrecer un nivel de aplicación para la ejecución de código de usuario.

El router debe permitir que otros dispositivos se unan a la red basándose en los parámetros de configuración que tiene el coordinator, como el número de elementos máximos o el tiempo en el que puede estar un elemento en la red.

Cuando un dispositivo nuevo se une a la red, la aplicación del dispositivo debe ser informada. Cuando se haya admitido en el PAN, el router debe indicarle la confirmación de la conexión. Si la seguridad está habilitada, el dispositivo debe informar al centro de validación. 2.5.3 Dispositivo final (ZigBee End Device, ZED).

Posee la funcionalidad necesaria para comunicarse con su nodo padre (el coordinador o un router), pero no puede transmitir información destinada a otros dispositivos. De esta forma, este tipo de nodo puede estar dormido la mayor parte del tiempo, aumentando la vida media de sus baterías.

Un ZED tiene requerimientos mínimos de memoria y es por tanto significativamente más barato.

9

2.6 Topología de Red

Como se sabe, los dispositivos ZigBee están basados en concepto WPAN. Así que para establecer las diferentes topologías de red genera un protocolo de comunicación, gestionado por capas, llamadas: capa de control de acceso (MAC), la capa física (PHY), la capa de red (NWK) y la capa de aplicación (APL). En la figura siguiente se ilustran las diferentes topologías de red ZigBee: figura (3).

Figura 3: topologías de red

ZigBee permite tres topologías de red:

• Topología en estrella: el coordinador se sitúa en el centro. • Topología en árbol: el coordinador será la raíz del árbol. • Topología de malla: al menos uno de los nodos tendrá más de dos conexiones.

La topología más interesante (y una de las causas por las que parece que puede triunfar

ZigBee) es la topología de malla. Ésta permite que si, en un momento dado, un nodo del camino falla y se cae, pueda seguir la comunicación entre todos los demás nodos debido a que se rehacen todos los caminos. La gestión de los caminos es tarea del coordinador.

En una red ZigBee pueden haber hasta 254 nodos, no obstante, según la agrupación que se haga, se pueden crear hasta 255 conjuntos/clusters de nodos, con lo cual se puede llegar ha tener 64770 dispositivos.

Se permite un encaminamiento o enrutamiento de saltos múltiples, también conocido como multi-hop , que permite que estas redes abarquen una gran superficie.

10

2.7 Seguridad en las Tramas

En cuanto a seguridad, ZigBee puede utilizar la encriptación AES [3] de 128 bits, que permite la autenticación y encriptación en las comunicaciones.

Además, existe un elemento en la red llamado Trust Center (Centro de validación) que proporciona un mecanismo de seguridad en el que se utilizan dos tipos de claves de seguridad, la clave de enlace y la clave de red. 2.8 Arquitectura de ZigBee

A continuación se describe la arquitectura ZigBee en capas y sus funciones: capa de aplicación y la capa de red.

La capa física (PHY) y la capa de control de acceso al medio (MAC) se obviaran puesto que son comunes para los dispositivos sujetos al protocolo del IEEE 802.15.4 2003 que operan en la banda libre, de los 2,4 GHz.

Figura 4: capas del dispositivo ZigBee 2.8.1 Capa de Aplicación La capa de aplicación del dispositivo esta dividida en subcapas llamadas:

• Subcapa de soporte de la aplicación (APS “application support sublayer”). • Subcapa de objetos de dispositivos ZigBee (ZDO “ZigBee device object”). • Subcapa de objetos de aplicación diseñados por cada fabricante.

11

2.8.1.1 Subcapa de Soporte de la Aplicación (APS)

La subcapa de soporte es la encargada de unir la capa de red (NWK) con la capa de aplicación (APL). La interfaz entre capas consta de una serie de servicios proporcionados por dos entidades:

• La entidad de datos • La entidad gestora

El conjunto de estas dos entidades hace posible la transmisión de datos, el transporte de

datos entre dispositivos de la misma red, proporciona un servicio de descubrimiento y enlace de dispositivos, así como una base de datos de los objetos (ZDO) y los diseñados por los fabricantes. 2.8.1.1.1 Estructura de Aplicación

El servicio de datos ofrecido por las entidades anteriormente descritas, incluye primitivas de confirmación, petición e indicación (request, confirm, indication) para la transferencia de datos.

• La primitiva request soporta la transferencia de datos entre pares de entidades objeto de aplicación.

• La primitiva confirm da los resultados de una llamada de la primitiva request. • La primitiva indication se usa para indicar la transferencia de datos desde un APS a la

entidad objeto de aplicación. 2.8.1.1.2 Fundamentos de Comunicación de la Capa de Aplicación

Son los servicios que ofrece la capa para la creación de una red tales como descubrir dispositivos, enviar mensajes para establecer la red etc... 2.8.1.1.3 Descubrimiento

El servicio de descubrimiento (Device Discovery), es el proceso por el cual un dispositivo ZigBee descubre otros dispositivos. Para ello, realiza preguntas/solicitudes que se envían por broadcast o unicast. Hay dos formas de realizar las peticiones de descubrimiento de servicios y dispositivos. La petición de dirección IEEE y la petición de dirección de NWK.

• La petición de IEEE es unicast y asume que la dirección NWK es conocida. • La petición de dirección NWK es por broadcast y lleva la dirección de IEEE como

datos de negociación de parámetros.

Las respuestas al elemento que ha realizado las peticiones broadcast o unicast de mensajes de descubrimiento pueden variar según provengan de un tipo de dispositivos lógicos u otros, como se indica a continuación:

12

• Terminal: responde a las peticiones de descubrimiento de dispositivos enviando su propia dirección IEEE o la dirección NWK (dependiendo de la petición).

• Coordinador: responde a la petición enviando su dirección IEEE o NWK y las direcciones IEEE o NWK que tiene asociadas como coordinador ZigBee (dependiendo del tipo de petición).

• Router: responde a peticiones enviando su dirección IEEE o NWK y las direcciones IEEE o NWK de todos los dispositivos que tiene asociados como router ZigBee (dependiendo de la petición).

2.8.1.1.4 Enlace

Se llama enlace al momento en que se crea un vínculo entre dispositivos de red ZigBee.

El coordinador es el que se encarga de crear un tabla de enlace para tener la red disponible en cualquier momento.

La gestión de estas tablas de enlace no está contemplada en el protocolo ZigBee así que las implementa en propio fabricante. 2.8.1.1.5 Mensajes Hay varios tipos de direccionamiento de mensajes pero en este caso sólo mencionaremos dos:

• Direccionamiento directo. • Direccionamiento broadcast

2.8.1.1.6 Direccionamiento directo

Una vez los dispositivos se han asociado, las instrucciones entre los elementos se pueden enviar y recibir, de forma que ya pueden ser enviadas de un dispositivo a otro. (Ver juego de pruebas). 2.8.1.1.7 Direccionamiento broadcast

Hay aplicaciones en las cuales se pueden enviar mensajes a todos los dispositivos, (también en el juego de pruebas se comenta).

13

2.8.1.2 La Subcapa ZDO Los ZDO son responsables de:

• Inicializar la subcapa de soporte de aplicación (APS), la capa de aplicación (NWK), y los servicios de especificación (SSS).

• La información de configuración desde la aplicación para determinar e implementar el descubrimiento y la gestión de la seguridad, red y enlace.

• Gestionan el descubrimiento de dispositivos (anteriormente mencionado). • Gestionan el enlace de dispositivos (anteriormente mencionado). • Gestionan la seguridad. (anteriormente mencionado).

2.8.1.2.1 Fundamentos de comunicación de la subcapa ZDO

Son los servicios que ofrece la capa (ZDO) para la creación de una red. Es la capa de gestionar los procesos. 2.8.1.2.1.1 Gestión de Descubrimiento

El descubrimiento se gestiona dependiendo de los objetos de aplicación. Cuando se solicita, la dirección IEEE de la petición del dispositivo tiene que ser devuelta (si el dispositivo es un dispositivo final) o bien con las direcciones de los dispositivos de todas las asociaciones (si el dispositivo es un dispositivo coordinador o router).Todo esto se produce por una aplicación que se encarga del descubrimiento de los dispositivos ZigBee. También sirve para proporcionar otros servicios que se pueden ofrecer a los dispositivos finales (end devices) definidos en el dispositivo por los objetos de aplicación que contiene.

Un dispositivo puede descubrir terminales activos, además puede descubrir servicios específicos que coincidan con un criterio dado (como pueden ser los identificadores de perfiles y de clusters). 2.8.1.2.1.2 Gestión de Enlace

La gestión del enlace la proporcionan los objetos de aplicación, de manera que estos objetos en cada uno de los dispositivos ZigBee puedan conectar todas las capas de la pila de protocolo a través de varias conexiones, que puedan proporcionar varios nodos en la red ZigBee. Las tablas de enlace se construyen y se publican en las peticiones de enlace y sus respuestas resultantes. Los dispositivos finales y las instrucciones tanto de enlace como de desenlace (abandono de la red) entre los dispositivos se soportan a través de los perfiles ZigBee mencionados anteriormente.

14

2.8.1.2.1.3 Gestión de seguridad La gestión de seguridad la proporcionan también los objetos de aplicación para

habilitar o deshabilitar la parte de seguridad en el sistema. Si está habilitada, la gestión de claves se lleva a cabo haciendo el uso de lo que se conoce como claves maestras (master keys), claves de red (Network keys) que permiten establecer una clave de enlace (link key). 2.8.2 Capa de Red

La capa de red (NWK) es necesaria para ofrecer servicios a la capa inmediatamente superior, (la capa de Aplicación), que permitan realizar operaciones sobre la capa inmediatamente inferior a la misma, (la sub-capa de MAC), definida en el IEEE 802.15.4-2003. Es decir, la capa de red hace de interfaz entre la capa de Aplicación y la de MAC. Para esto, la capa de red dispone en esta interfaz de dos servicios, con los que cubre las necesidades de la capa de Aplicación. Estos dos servicios se conocen como:

• Servicio de Datos • Servicio de Control

2.8.2.1 Servicio de Datos

Este servicio de interfaz, es también conocido con NLDE (Network Layer Data Entity). Es un servicio de datos, que permite a cualquier aplicación comunicarse con las mismas unidades de datos, con dos o más dispositivos. Obviamente todos los dispositivos que intervengan en esta comunicación deberán estar en la misma red de interconexión. Esta interfaz dispone de los siguientes servicios:

• Generación de la PDU de la capa de Red (NPDU). • Especificación de la topología de encaminamiento.

2.8.2.2 Servicio de Control

El también conocido como NLME (Network Layer Management Entity), es un servicio ofertado desde la capa de Red a la superior, que permite a la capa de interactuar o comunicarse con la pila directamente. Esta interfaz dispone de los siguientes servicios:

• Configuración de un nuevo dispositivo. Esto permitirá la inicialización de un dispositivo Coordinador, así como el descubrimiento de nuevos dispositivos dentro de la red de interconexión. • Inicialización de una nueva red. • Integración y salida de una red. • Direccionamiento. • Descubrimiento de vecinos. • Descubrimiento de ruta. • Recepción de control.

15

2.8.2.3 Tabla de Primitivas

Las primitivas de confirmación de la capa de red, suelen incluir parámetros encargados de informar acerca del estado de las solicitudes que genera la capa inmediatamente superior, la capa de aplicación. Estos parámetros son los que aparecen en la siguiente tabla.

Figura 5: tablas de primitivas

16

3 Especificaciones Técnicas del Kit ZigBee Jennic JN5139-EK010 3.1 ZigBee Jennic

Para este proyecto se ha utilizado el kit ZigBee de la marca Jennic modelo JN5139-EK010 802.15.4 compuesto por:

• 1 módulo controlador (coordinador) con conector SMA para antena. • 2 módulos sensor (router/end device) con antena integrada. • 2 módulos sensor (router/end device) con SMA. • 2 conectores antena SMA. • 2 cables USB/SERIE. • 1 pack de10 baterías del tipo AAA para los módulos. • 1 CD-ROM con documentación y software. • 2 módulos high power.

3.2 Hardware del módulo de control (coordinador) El módulo de control o coordinador viene con las siguientes características:

• 1 display 3”. • 4 led’s indicadores de estado. • 4 botones de conmutación. • 1 sensor de temperatura. • 1 sensor de humedad. • 1 sensor de luminosidad. • 1 EEPROM. • 1 interficie de comunicación UART. • 1 puerto de expansión para sensores adicionales. • 1 Jumper para selección de alimentación.

17

Figura 6: placa Jennic ZigBee co-ordinator 3.2.1 Display

El módulo contiene un display LCD de 128 x 64 píxeles. El display tiene una función de retroiluminación accionada mediante el jumper (J6). 3.2.2 Sensor de luminosidad

El módulo contiene un sensor de luz TAOS TSL2550. Se trata de un sensor de luz con salida de dos hilos. En este se combinan dos fotodiodos y una compresión analógica a digital (ADC) en un único circuito integrado CMOS.

Para ofrecer las mediciones de luz a través de un rango de 12 bits, con una respuesta similar a la del ojo humano. 3.2.3 Sensor de temperatura y Humedad

El módulo se suministra con un Sensirion SHT11 de un solo chip multi-sensor, para la medición de temperatura y humedad relativa. El dispositivo incluye dos micro-sensores, uno de temperatura y otro de humedad relativa, que están acoplados a un convertidor analógico-digital de 14 bits. La conversión puede ser programada con 8 ,12 o 14 bits de precisión, dependiendo de la solicitud de resolución o la velocidad. La humedad puede medirse en una escala de 0-100% de humedad relativa y el rango de temperatura es de -40 ° C hasta 85 ° C.

18

3.2.4 Conectores UART

El patillaje de los conectores UART de detalla en la siguiente tabla:

Detalle de conexión del cable UART-USB

19

3.2.5 Conector de expansión Patillaje del conector de expansión

20

3.2.6 Selector de alimentación J2 El jumper J2 se utiliza para seleccionar el tipo de alimentación que quieres:

• Posición 1-2 seleccionamos alimentación por pilas. • Posición 2-3 seleccionamos alimentación externa.

3.2.7 Modo programación

Para poner el módulo coordinador en modo programación se ejecutan unos pasos previos para poder programar cualquiera de las aplicaciones de ZigBee.

1. mantener apretado el botón reset (sw5). 2. mantener apretado el botón program (sw7). 3. soltar el botón reset. 4. soltar el botón program.

21

3.3 Hardware del módulo sensor (end device/router) La placa viene con las siguientes características:

• 4 led’s indicadores de estado. • 4 botones de conmutación. • 1 sensor de temperatura. • 1 sensor de humedad. • 1 sensor de luminosidad. • 1 EEPROM. • 1 interficie de comunicación UART. • 1 puerto de expansión para sensores adicionales. • 1 Jumper para selección de alimentación.

Figura 7: placa Jennic ZigBee End device 3.3.1 Sensor de luminosidad

El módulo contiene un sensor de luz TAOS TSL2550. Se trata de un sensor de luz con salida de dos hilos. En este se combinan dos fotodiodos y una compresión analógica a digital (ADC) en un único circuito integrado CMOS. Para ofrecer las mediciones de luz a través de un rango de 12 bits, con una respuesta similar a la del ojo humano.

22

3.3.2 Sensor de temperatura y Humedad

El módulo se suministra con un Sensirion SHT11 de un solo chip multi-sensor, para la medición de temperatura y humedad relativa. El dispositivo incluye dos micro-sensores, uno de temperatura y otro de humedad relativa, que están acoplados a un convertidor analógico-digital de 14 bits. La conversión puede ser programada con 8 ,12 o 14 bits de precisión, dependiendo de la solicitud de resolución o la velocidad. La humedad puede medirse en una escala de 0-100% de humedad relativa y el rango de temperatura es de -40 ° C hasta 85 ° C. 3.3.3 Conectores UART El patillaje de los conectores UART de detalla en la siguiente tabla:

Detalle de conexión del cable UART-USB

23

3.3.4 Conector de expansión Patillaje del conector de expansión

24

3.3.5 Selector de alimentación J2 El jumper J2 se utiliza para seleccionar el tipo de alimentación que quieres:

• Posición 1-2 seleccionamos alimentación por pilas. • Posición 2-3 seleccionamos alimentación externa.

3.3.4 Modo programación

En nuestro caso el kit viene un CD con un software programador llamado Flash Programmer [4]. Para poner los módulos en modo programación se ejecutan unos pasos previos para poder cargar cualquiera de las aplicaciones de ZigBee.

1. mantener apretado el botón reset (sw5). 2. mantener apretado el botón program (sw7). 3. soltar el botón reset. 4. soltar el botón program.

25

4 Data Sheet del JN5139 4.1 Wireless microcontroladores

Los JN5139 son una familia de microcontroladores wireless de baja potencia y bajo coste adecuando para aplicaciones ZigBee y protocolo IEEE 802.15.4. Cada dispositivo integra:

• Procesador RISC de 32 bits. • ROM de 192 KB. • RAM seleccionable desde 8 a 96 KB. • Periféricos analógico/digital.

4.2 Características del transceiver

• Compatible con IEEE 802.15.4 a 2,4GHz. • Sistema de encriptación AES 128-bits. • Gestor de potencian integrado y oscilador de modo dormido para baja potencia. • Consumo de corriente en modo dormido < 0,4 µA. • Consumo en Rx 37mA. • Consumo en Tx 38mA. • Sensibilidad del receptor -97dBm.[5] • Potencia de transmisión de 0 dBm.

4.3 Diagrama de bloques

Figura 8 : diagrama de bloques (1)

26

Figura 9: diagrama de bloques (2)

27

5 Comandos AT

A continuación se detalla el funcionamiento del proceso de comunicación de los dispositivos en Hyperterminal y algunos de los comandos AT que son más relevantes.

Como se ha explicado antes éstos módulos ZigBee están capacitados para tomar medidas de:

• Temperatura. • Luminosidad • Humedad, etc...

Pero también son capaces de enviar información y configuración interna del

funcionamiento todos los módulos como:

• Estado de los led’s (on/off). • Estado de las baterías. • Configurar en canal de radio enlace. • Enviar mensajes y visualizarlos en la pantalla de lcd o en un pc. • Configurar la potencia de emisión. • Enviar un paquete de información de prueba entre dispositivos.

La estructura de los comandos AT que se ejecutan desde el hyperterminal es la

siguiente:

Código de 3 caracteres ASCII

Uno a más números decimales o datos en hexadecimal

Valor opcional para algunas aplicaciones

28

5.1 Ejemplo de algunos comandos

31

6 Configuración y Test de Funcionamiento de la Red ZigBee

A continuación se detallan las pruebas realizadas con el kit ZigBee de Jennic. El fin de estas pruebas es demostrar el proceso de comunicación wireless mediante los dispositivos ZigBee en diferentes escenas.

Los datos recogidos procedían de la consola del HYPERTERMINAL de Windows mediante comandos AT.

Mediante los comandos AT se puede enviar información de diferentes pesos (bytes) y hacer una estadística en función del tiempo de respuesta los datos perdidos la potencia recibida etc... 6.1 Creación de una pequeña red

Se crea una pequeña red compuesta por un coordinado, un router y un end device. Esta red permitirá hacer pruebas de encendido a apagado de led’s remotamente en

todos los dispositivos, si las configuraciones se ha hecho bien se deberían encender y apagar los led’s de todos los dispositivos mediante los switches.

Figura 10: simulación de dispositivos en red Antes de todo se cargará el programa en los módulos mediante el programa de Jennic Flash Programmer (todos los programas deben estar previamente compilados).

Después se deberá configurar en el HYPERTERMINAL los valores de la comunicación como el puerto de comunicación.

32

Figura 11: configuración del puerto serie en hyperterminal.

Después se configurará el dispositivo PASO 1: Asegurarse de que todos los módulos están apagados. PASO 2: Seleccionar el módulo que vaya a ser el coordinador y hacer las siguientes acciones: a) mantener apretado el SW2 b) al mismo tiempo poner en on el dispositivo con el SW6 c) ahora soltar el SW2 Los led’s D9, D1, D2 deben estar encendidos PASO 3: Seleccionar la demo mediante los switches a) apretar el SW2 (el D2 se tiene que apagar) b) esperar a que el D1 se apague PASO 4: Encender el (end device) mediante el SW6, los led’s D9, D1, D2 deben estar encendidos.

33

PASO 5: Seleccionar la demo mediante los switches. a) apretar el SW2 (el D2 se tiene que apagar) b) esperar a que el D1 se apague Hasta aquí la configuración de la primera prueba (1ª prueba) PASO 6: Añadir el router a la red. (2ª prueba) Añadimos el router a la red. Seguir los mismos pasos del end device pero con el módulo router.

Esta pequeña prueba nos permite visualizar como se construye una pequeña red wireless y comprobar mediante los botones de los módulos SW1, SW2 como se encienden los led de un dispositivo a otro.

En la primera prueba se creará una red entre coordinator y end device después de haber seguido los pasos pertinentes, se harán las comprobaciones y encendemos los led del coordinator pulsando los SW1/2 del end device. Si pulsamos el SW1 del end device se enciende el led D1 del coordinator y si pulsamos en SW2 del end device se enciende el led D2 del coordinator.

En la segunda prueba cuando añadimos el router, hacemos las mismas comprobaciones que en la prueba anterior desde los dos módulos end device y router.

Pero con una diferencia, que cuando en la segunda prueba intentamos encender los led del coordinator desde el end device, los led del router parpadean durante unos milisegundos indicándonos que la información está siendo enrutada por él.

O sea que la información viaja desde el end device al router y éste la reenvía al coordinator 6.2 Comunicación wireless mediante pc’s

Para esta prueba hacen falta dos PC’s (o en su defecto) un PC abriendo dos HYPERTERMINALS y los módulos conectados a puertos diferentes del PC.

Esta prueba se basa en poder comunicar a dos PC’s vía wireless, que se encuentren a una distancia dentro del rango de cobertura de los módulos en función del entorno.

(Pruebas de potencia recibida en función de distancia más adelante).

Las pruebas realizadas han sido con un PC, configurando los módulos (coordinator y router) en puertos diferentes del PC.

34

Antes de todo debemos haber cargado la demo en los módulos mediante el programa de Jennic Flash Programmer (todas las demos deben estar previamente compiladas).

Figura 12: simulación gráfica de comunicación entre pc’s.

Ejecutamos los Hyperterminal para los dos puertos del PC en esta caso serán los puertos COM3 y COM 5.

Figura 13: configuración del puerto serie en hyperterminal.

35

También se tiene que configurar el envío en ASCII.

Figura 14: configuración hyperterminal. PASO 1: Asegurarse de que todos los módulos están apagados. PASO 2: Seleccionar el módulo que vaya a ser el coordinador y hacer las siguientes acciones: a) mantener apretado el SW2. b) al mismo tiempo poner en on el dispositivo con el SW6. c) ahora soltar el SW2. Los led’s D9, D1, D2 deben estar encendidos. PASO 3: Seleccionar la demo mediante los switches. a) apretar el SW2 (el D2 se tiene que apagar). b) esperar a que el D1 se apague. PASO 4: Encender el (router) mediante el SW6, los led’s D9, D1, D2 deben estar encendidos.

36

PASO 5: Seleccionar la demo mediante los switches. a) apretar el SW2 (el D2 se tiene que apagar). b) esperar a que el D1 se apague.

Esta prueba nos permite visualizar como se construye una pequeña red wireless y comprobar como se comunican PC’s entre si, mediante Hyperterminal.

Figura 15: imagen real de comunicación wireless.

37

7 Programa de Test

Es el programa utilizado para llevar a cabo las estadísticas de comunicación wireless, con el objetivo de poder capturar las gráficas que nos ayuden a demostrar el objetivo de éste proyecto.

Son una serie de rutinas de comunicación en lenguaje MATLAB, que ejecutan comandos AT.

Este programa mediante un entorno gráfico, ofrece posibilidad de poder configurar y enviar comandos AT a los dispositivos mediante un puerto de comunicación.

Hay diferentes posibilidades y opciones para poder enviar estos comandos.

Figura 16: vista general del programa A continuación explicaremos las opciones más relevantes. 7.1 La opción test Se compone de dos subopciones, la time test y la distance test:

La Subopción time test nos permite enviar el comando TCF con una serie de parámetros concretos, que nosotros introduciremos en una interfície gráfica, siguiendo la forma del comando en cuestión. Esta rutina ha sido pensada para que podamos situar los dispositivos a distancias diferentes en entornos diferentes, que detallaremos más adelante.

38

Figura 17: menú time test

Los cuatro primeros parámetros: Number Packets, ms, Length y Valor deben seguir

la misma estructura del comando TCF que detallamos más adelante. El parámetro File sirve para indicar la ruta del archivo donde quieres que se

guarden los datos obtenidos, que después visualizaremos en forma de gráficas. El parámetro comentario es una etiqueta que le pones al archivo.

Una vez rellenado los parámetros se pulsa el OK y se enviarán un número de paquetes determinados, del dispositivo (1) al dispositivo (2), con su correspondiente respuesta del dispositivo (2) al dispositivo (1). Toda la información de respuesta se guarda en al archivo que previamente hemos seleccionado. Este archivo en forma de gráfica nos servirá para estudiar la respuesta de los dispositivos colocados en diferentes distancias y entornos. El código es el siguiente: % ------------------------------------------------- ------------------- function TimeTest_Callback(hObject, eventdata, hand les) % hObject handle to TimeTest (see GCBO) % eventdata reserved - to be defined in a future v ersion of MATLAB % handles structure with handles and user data ( see GUIDATA) global DefaultSerialPort DefaultSerialPort S.Number_Packets={[1]}; S.Periode={[1000] 'ms' [100 65535]}; S.Length={[30] '' [1 50]}; S.Valor={[55] '' [0 255]}; S.File={ {'uiputfile(''*.mat'')'} }; S.Comentario={''}; S = StructDlg(S,'Time Test') if ~isempty(S) comando=['TCF,',int2str(S.Number_Packets),',',int2s tr(S.Periode),',',int2str(S.Length),',',int2str(S.Valor)]; s1 = serial(DefaultSerialPort, 'BaudRat e', 115200); %115200,N,8,1 (la resta esta per defecte) fopen(s1);

39

fprintf(s1,comando);

fgets(s1), %llegeixo OK

fgets(s1), %llegeixo ECO fgets(s1), %llegeixo ECO for i=1:S.Number_Packets, TLINE=fgets(s1) if isempty(TLINE),med=[0,0,0,0]; else Medida(i,:)=extractnum(TLINE); end pause(S.Periode/1000); end; fclose(s1); t=linspace(0,(S.Number_Packets-1)*S.Periode ,S.Number_Packets); Data.Tipo='time'; Data.Medida=Medida; Data.time=t; Data.Comentario=S.Comentario; Data.Struct=S; eval(['save ',S.File,' Data -mat']); end % ------------------------------------------------- -------------------

La Subopción distance test permite enviar un número determinado de paquetes

con la función TCF, a unas distancias determinadas y el resultado es una gráfica de todas las muestras. Estas distancias son entre dos puntos y los saltos entre distancias los implementas en Number Distances. Por ejemplo:

Con esta configuración se enviarán 10 paquetes con un tiempo entre paquetes de 1 segundo a 5 distancias diferentes que irán desde el metro 1 al 5. Con un total de paquetes enviados de 50 paquetes.

Figura 18: menú distance test

Esto permitirá obtener una gráfica con diferentes distancias en el mismo entorno, con lo que servirá para poder estudiar la atenuación de la señal en función de la distancia.

40

El código es el siguiente: % ------------------------------------------------- ------------------- function DistanceTest_Callback(hObject, eventdata, handles) % hObject handle to DistanceTest (see GCBO) % eventdata reserved - to be defined in a future v ersion of MATLAB % handles structure with handles and user data ( see GUIDATA) global DefaultSerialPort S.Number_Packets={[1]}; S.Periode={[1000] 'ms' [100 65535]}; S.Length={[30] '' [1 50]}; S.Valor={[55] '' [0 255]}; S.Number_Distances={[10]}; S.Start_Distance={[1] 'Start Distance (m)'}; S.Stop_Distance={[10] 'Stop Distance (m)'}; S.File={ {'uiputfile(''*.mat'')'} }; S.Comentario={''}; S = StructDlg(S,'Range Test') if ~isempty(S) for k=1:S.Number_Distances, disp(['Punto :',num2str(k),'... Pulse u na tecla para medir']); pause; comando=['TCF,',int2str(S.Number_Packets),',',int2s tr(S.Periode),',',int2str(S.Length),',',int2str(S.Valor)]; s1 = serial(DefaultSerialPort, 'BaudRat e', 115200); %115200,N,8,1 (la resta esta per defecte) fopen(s1); fprintf(s1,comando); fgets(s1);%llegeixo OK fgets(s1);%llegeixo ECO fgets(s1);%llegeixo ECO for i=1:S.Number_Packets, TLINE=fgets(s1) if isempty(TLINE),med=[0,0,0,0]; else med=extractnum(TLINE); end pause(S.Periode/1000); end; fclose(s1); Medida(k,:)=med;%Tomo la ultima medida end; d=linspace(S.Start_Distance,S.Stop_Distance,S. Number_Distances); Data.Tipo='distance'; Data.Medida=Medida; Data.distance=d; Data.Comentario=S.Comentario; Data.Struct=S; eval(['save ',S.File,' Data -mat']); end; % ------------------------------------------------- -------------------

41

7.2 La opción graph

Esta opción permite visualizar en forma de gráficos los resultados obtenidos, normalmente estas gráficas representarán el nivel de la señal recibida (LQI) en función de diferentes parámetros como la distancia o el entorno y el valor de paquetes perdidos porcentualmente (PER).

Figura 19: representación gráfica El código es el siguiente: % ------------------------------------------------- ------------------- function Graph_Callback(hObject, eventdata, handles ) % hObject handle to Graph (see GCBO) % eventdata reserved - to be defined in a future v ersion of MATLAB % handles structure with handles and user data ( see GUIDATA) global CurrentFile

Este pico indica en valor más alto de potencia de señal recibida

Este pico indica el valor más bajo de potencia recibida dentro de la escala

42

if ~isempty(CurrentFile),

load(CurrentFile,'-mat');

if strcmp(Data.Tipo,'time'), figure; PER=Data.Medida(:,3); LQI=Data.Medida(:,4); t=Data.time; subplot(211); plot(t/1000,PER); xlabel('t(s)'); ylabel('PER(%)'); subplot(212); plot(t/1000,LQI); xlabel('t(s)'); ylabel('LQI'); end; if strcmp(Data.Tipo,'distance'), figure; PER=Data.Medida(:,3); LQI=Data.Medida(:,4); d=Data.distance; subplot(211); plot(d,PER); xlabel('Range(m)'); ylabel('PER(%)'); subplot(212); plot(d,LQI); xlabel('Range(m)'); ylabel('LQI'); end; end; % ------------------------------------------------- -------------------

7.3 La opción command

Esta opción permite enviar cualquiera de los comandos AT por el módulo (1) y recibir respuesta por el módulo (2), en función del comando que hemos enviado.

La opción command se utilizará para poder medir la temperatura, luminosidad y humedad de los dispositivos colocados de forma estratégica en lugares del vehículo. Con el fin de poder demostrar la utilización de sensores inalámbricos en el interior de los vehículos.

Una de las posibles aplicaciones que se quiere demostrar es: Cambiar los sensores que hay en estos momentos en los vehículos que comunican con la centralita mediante cable, por sensores inalámbricos. En el siguiente punto se detallan las pruebas.

43

8 Estadísticas de Comunicación Wireless (para objetivo del proyecto)

Con esta aplicación se pretende demostrar la comunicación wireless entre dispositivos y poder estudiar la información que nos ofrecen los módulos ZigBee, en forma de valores estadísticos que se mostrarán por pantalla con el Programa test.

Para poder llevar a cabo el propósito explicado en el apartado (objetivo del proyecto) que se basa en el estudio de comunicar vehículos con una tecnología inalámbrica, se necesita utilizar los comandos AT, con el programa cargado en los ZigBee STARTER KIT.

Utilizando los comandos apropiados, en concreto el comando (TCF) se enviará desde el coordinator una trama de información con unas características determinadas de:

• Num: numero paquetes que se enviaran al dispositivo deseado. • Per: es el período de tiempo entre paquetes, la unidad es el milisegundo (ms). Que

va desde el rango mínimo de 100 ms hasta 655350 ms. • Len: es la longitud (o peso) del paquete que quieres enviar con un máximo de 50

bytes. • Data: son los datos que se insertan cada paquete.

La forma del comando de envío es la siguiente: TCF, <num>, <per>, <len>, <data>

La respuesta (TPR) del dispositivo que se mostrará por Hyperterminal será de la siguiente manera:

• Packet ID: corresponde al último paquete enviado. • Missed packets: identifica el número de paquetes perdidos o que se han alterado

por mala comunicación, desde el inicio del test. • PER: es el valor en porcentaje de packet error rate. • Signal strength: es el nivel de señal en forma de LQI (Link Quailiti Index ), que va

desde el rango 0 hasta 255.

La forma del comando de respuesta es la siguiente: TPR, <packet ID>, <missed packets>, <PER>, <signal strength>

El juego de pruebas se realizará en diferentes escenarios en función de nuestro criterio, para poder comunicar los vehículos, tanto en outdoor como en indoor. Como la demostración se pensó para comunicar estos vehículos dentro de las ciudades. En principio las pruebas de envío de paquetes con los vehículos en movimiento sólo se harán con una velocidad máxima de unos 50 Km/h.

Los dispositivos también se pondrán en diferentes puntos de los vehículos para estudiar cual sería el mejor caso para la transmisión de información.

La topología de red para estás pruebas será la más sencilla. Un co-ordinator conectado al PC mediante un puerto serie y otro dispositivo end device ubicado a una distancia y comunicándose mediante wireless.

44

En la siguiente tabla se resumen los escenarios:

Escenario 1 Entorno con obstáculos y dispositivos a diferentes distancias.

Escenario 2 Dispositivos en el interior del vehículo. Escenario 3 Dispositivos dentro de los vehículos y estos a diferentes

distancias. Escenario 4 Dispositivos dentro de los vehículos y estos a distancias

de 20 a 40 metros en pasos de 0,5 metros. Escenario 5 Vehículos a diferentes distancias y sin obstáculos. Escenario 6 Vehículos en movimiento.

8.1 Escenario 1

La siguiente prueba se realizará en un entorno con obstáculos: casas alrededor, coches, ruido, etc. Y los dispositivos a distancias diferentes.

Utilizaremos la subopción time test para poder recrear el escenario deseado. La idea es capturar los resultados de calidad de señal en función de diferentes distancias. La potencia de transmisión Tx = 0 dBm. Se utilizarán también los comandos AT para obtener la temperatura, luminosidad y humedad.

Figura 20: configuración de la transmisión

La configuración de la transmisión se hará de la siguiente manera:

• Number of Packets = 100. • Time en Ms = 100. • Length = 30. • Valor = 55.

45

La figura 21 representa la estadística del comando TCF a 1 metro de distancia en el entorno antes mencionado.

Figura 21: LQI y PER a 1 m

La figura 22 representa la estadística del comando TCF a 5 metros de distancia en

el entorno antes mencionado.

1 METRO

5 METROS

46

Figura 22: LQI y PER a 5m

La figura 23 representa la estadística del comando TCF a 10 metros de distancia

en el entorno antes mencionado.


10 METROS

47

La figura 24 representa la estadística del comando TCF a 15 metros de distancia en el entorno antes mencionado.


La figura 25 representa la estadística del comando TCF a 20 metros de distancia

en el entorno antes mencionado.

15 METROS

20 METROS

48


Las figuras 26 y 27 representa la estadística del comando TCF a 30 metros de en el entorno antes mencionado. Se han realizado 2 pruebas consecutivas:


30 METROS

49


Gráfico de resumen de los niveles de LQI y de PER en función de los resultados de las pruebas del escenario 1.

Figura 28: resumen niveles de LQI y PER

“Este gráfico sólo contempla una grafica de los 30 metros”.

50

Conclusiones:

Se observa en la figura 21 que el nivel de calidad de la señal oscila entre los 222 y 216 LQI y el número de paquetes erróneos (PER) es del 0%. La conclusión que se saca es que la comunicación es segura a 1metro: 100 paquetes en 10 segundos 0 perdidos.

De otra forma es la figura 22 en la cual se puede observar como a lo largo del tiempo, la comunicación mantiene los valores de PER y LQI fijos, estos son: 0% y 156 respectivamente, la conclusión que se saca es que la comunicación es segura a los 5 metros: 100 paquetes en 10 segundos 0 perdidos.

En la figura 23 que corresponde a una comunicación a una distancia de 10 metros, se observa como el PER sigue al 0% y el LQI tiene su valor más alto en 120 y el más bajo a 90, a lo largo de la comunicación se observa la estabilización de la señal LQI en torno a 105. La comunicación sigue siendo segura: 100 paquetes en 10 segundos 0 perdidos.

La figura 24 mantiene un PER del 0%, un nivel de LQI de 115 en su valor más alto y 107 en su valor más bajo, la distancia en esta ocasión no ha atenuado mucho el nivel de señal con respecto a la anterior gráfica. Se valora que es una comunicación segura a 15 metros: 100 paquetes en 10 segundos 0 perdidos.

La siguiente figura 25 correspondiente a una distancia de 20 metros, su nivel de LQI tiene una media de 60 y el PER es 0%, lo cual nos indica que la comunicación es segura a 20 metros: 100 paquetes en 10 segundos 0 perdidos.

En la figuras 26 y 27 que corresponden a los dispositivos situados a 30 metros, se observa como el nivel de calidad de la señal baja drásticamente, hasta tener un valor de alrededor de los 10 LQI en la figura 29 y de 5 en la figura 30. En esta prueba no se superan los niveles mínimos de LQI, aconsejados por el fabricante. Que no asegura una comunicación con un nivel de LQI por debajo de los 40.

Se puede observar como el PER aumenta exponencialmente en los primeros segundos de comunicación, hasta llegar a una tasa de paquetes perdidos del 25% en la figura 26 y 10% en la figura 27. “Se han realizado diferentes pruebas entre los 20 y 30 metros y el PER en 0% y el LQI por encima de los 40, se mantenía hasta los 25 metros. Se concluye que en las pruebas realizadas en el escenario 1, son que: se puede garantizar una comunicación perfecta hasta los 25 metros con una Pt de 0 dBm, puesto que cuando recibimos un nivel de LQI por debajo de 40 estamos rozando el limite de sensibilidad de los dispositivos, situado en -97 dBm”.

Las pruebas realizadas para obtener los valores de humedad, temperatura y luminosidad son satisfactorias hasta en el caso de mantener una distancia de 30 metros. Se han realizado pruebas hasta 80 metros y la comunicación para obtener estos valores es correcta en un 100%.

51

8.2 Escenario 2

El siguiente escenario se realizará en el interior del vehículo y los dispositivos situados en diferentes zonas del mismo. El número de paquetes enviados es el mismo que en el escenario anterior. Esta prueba nos permitirá saber cual es la calidad de la señal de la transmisión cuando los dispositivos se encuentran envueltos de chapa metálica (chasis del vehículo) y cristales con cromo. Prueba con el motor encendido y apagado. El fin de estas pruebas es demostrar el funcionamiento de los sensores que llevan los dispositivos integrados, dentro del mismo vehículo. Se enviarán paquetes de información para saber los niveles de LQI y PER. Se enviarán también comandos AT para recibir la información de los sensores.

En la figura 29 y 30 tenemos los dispositivos colocados de la siguiente forma: El co-ordinator esta situado en el asiento del conductor y el end device en un hueco de dentro del capó de motor. Motor apagado figura 29 y motor encendido figura 30:

Figura 29: motor apagado

CO-ORDINATOR

END DEVICE

52

Figura 30: motor encendido

La siguiente figura 31 representa el encendido del motor en medio de una transmisión y sin variar la configuración:

Figura 31: motor de 0-5 off y de 5-10 on

53

La siguiente figura 32 representa el LQI y el PER con el co-ordinator en la zona del conductor y el end device en el maletero con el motor encendido:

Figura 32: end device en el maletero motor on

CO-ORDINATOR

END DEVICE

54

Gráfico de resumen de los niveles de LQI y de PER en función de los resultados de las pruebas del escenario 2. (Figura 33 y 34).

LQI (ESCENARIO 2)

0

20

40

60

80

100

120

140

160

180

29 30 31 32

Gráficas

Níveles

de

LQI

Más alto

Más bajo

Figura 33: Resumen de los niveles de LQI según gráficas

PER (ESCENARIO 2)

00,10,20,30,40,50,60,70,80,9

1

29 30 31 32

Gráficas

% P

ER Más alto

Más bajo

Figura 34: Resumen de los niveles de PER según gráficas

Conclusiones:

Las conclusiones que se obtienen de las figuras 29 y 30 es que el nivel de LQI y el PER son prácticamente iguales para las dos pruebas. Tanto la prueba con el motor apagado, como para la prueba del motor encendido, tienen un 0% de paquetes perdidos y una media de nivel de LQI de 150, con lo cual se deduce una comunicación excelente.

Las pruebas realizadas de obtener los datos mediante los sensores son de un 100% de efectividad tanto en la medición de luminosidad, temperatura, y humedad.

55

Ejemplos de medida de temperatura en los dos dispositivos con el comando: NTG NTG, 0 (Obtener la temperatura del co-ordinator desde el mismo co-ordinador). OK (La información se ha enviado correctamente). PKS (Confirmación de la comunicación). NTR, 0,31 (Respuesta del sensor de temperatura del co-ordinator). NTG, 1 (Obtener la temperatura del end device desde co-ordinator). OK (La información se ha enviado correctamente). PKS (Confirmación de la comunicación). NTR, 1, 35 (Respuesta del sensor de temperatura del end device). (Estás pruebas se han realizado varias veces y en varias ubicaciones diferentes de los dispositivos en el vehículo. También se han realizado las pruebas con el coche en movimiento).

En la figura 31 se observa como afecta de un modo muy ligero el encendido de un motor en medio de la comunicación, no obstante la comunicación es 100% segura.

El nivel de calidad en la figura 32 baja un poco en relación a la ubicación de los dispositivos puesto que en este caso el dispositivo end device se ha colocado en el maletero del vehículo.

Las figuras 33 y 34 son un resumen de los niveles obtenidos de las gráficas. “Las aplicaciones que se querían demostrar en este caso son satisfactorias, ya que uno de los objetivos de este proyecto era probar la funcionalidad de sensores wireless en los vehículos.” 8.3 Escenario 3

En el escenario 3 se demostrará la comunicación de los dispositivos entre vehículos y a diferentes distancias, todas las pruebas realizadas en el escenario 3, son con los vehículos parados, en una vía urbana sin tráfico, y la configuración de envío de información igual que en el escenario anterior. Los dispositivos se colocan en el asiento del conductor.

El fin de esta prueba es demostrar la comunicación inter-vehicular, con el envío de paquetes de información.

DISTANCIA

CO-ORDINATOR END DEVICE

56

En las siguientes figuras 35 y 36 se capturan las gráficas correspondientes a una comunicación inter-vehicular con una distancia de 5 metros. La figura 35 motor apagado y la figura 36 motor encendido.

Figura 35: dispositivos dentro vehículo a 5 m y motor off

Figura 36: dispositivos dentro vehículo a 5 m y motor on

5 METROS


57

En la siguientes figuras 37 y 38 capturamos las gráficas correspondientes a una comunicación inter-vehicular con la configuración que hemos utilizado para todas las pruebas. La distancia es de 15 metros. La figura 37 motor apagado y la figura 38 motor encendido.


15 METROS


58


Las siguientes gráficas 39 y 40, corresponden a la comunicación de los dispositivos a una distancia de 20 metros, como en el caso de las demás en está también se harán con el motor de los vehículos apagado y encendido. La figura 39 corresponde a la comunicación con el motor apagado y la figura 40 con el motor encendido.

20 METROS


59



60

Las siguiente gráfica corresponden a la comunicación de los dispositivos a una distancia de 30 metros, como en el caso de las demás, en está también se harán con el motor de los vehículos apagados y encendidos. La figura 41 corresponde a la comunicación con el motor apagado. La comunicación a 30 metros con el motor encendido no se pudo realizar.


30 METROS


61

Gráfico de resumen de los niveles de LQI y de PER en función de los resultados de las pruebas del escenario 2.

LQI (ESCENARIO 3)

0

20

40

60

80

100

120

140

35 36 37 38 39 40 41

Gráficas

Níveles

de

LQI

Más alto

Más bajo

Figura 42: Resumen de los niveles de LQI según gráficas

PER (ESCENARIO 3)

0

0,5

1

1,5

2

2,5

3

3,5

4

4,5

35 36 37 38 39 40 41

Gráficas

% P

ER Más alto

Más bajo

Figura 43: Resumen de los niveles de PER según gráficas

Conclusiones:

Las conclusiones que se obtienen del escenario 3 son que para figuras 35 y 36, los niveles de LQI son los mismos, de unos 108 a 114. Se concluye que no afecta a la comunicación que el motor esté encendido o apagado cuando tenemos un buen nivel de LQI. Se mantiene en los dos casos un 0% de paquetes perdidos.

Las figuras 37 y 38 corresponden a las mediciones a una distancia de 15 metros. La distancia ha afectado a los niveles de calidad de la señal que ahora están entre los 35 y 65, no se aprecian grandes diferencias en la gráfica, tanto para los coches con el motor apagado o encendido. Aunque el PER es de 0%, el nivel de LQI ha llegado al umbral de sensibilidad de los dispositivos, que está por debajo de los 40 LQI.

62

Se encuentra diferencia en las figuras 39 y 40 cuya distancia entre coches es de 20 metros. En el caso del motor encendido se muestra como el nivel de señal baja hasta los 10 LQI. Aunque el nivel de paquetes perdidos es de 0% hemos sobrepasado el umbral de sensibilidad marcado por el fabricante de -97 dBm y que corresponde a 40 LQI.

En el caso de la distancia de 30 metros sólo ha sido posible realizar la prueba del motor apagado (figura 41). En esta figura se observa como el nivel LQI está entre los 30 y 10, la forma de la señal es muy cambiante y con muchos picos lo cual indica inestabilidad, pero el PER a mitad de la transmisión sube hasta el 4% de información perdida.

El hecho de que la comunicación se haya perdido en la prueba del motor encendido es que la señal que se recibía era inferior a -97 dBm.

“Se han realizado diferentes pruebas entre los 20 y 30 metros, y el Per en 0% y LQI por encima de 40 se mantenía hasta los 20 metros y el motor encendido. La conclusión del escenario 3, es que se puede garantizar una comunicación segura entre vehículos parados en una vía urbana hasta los 20 metros, con Pt de 0dBm.” 8.4 Escenario 4

En este escenario se ha utilizado la sub-opción distance test para capturar los niveles de LQI. La configuración de la comunicación es igual que en el escenario anterior, pero las muestras que se tomarán serán cada 0,5 metros. Las distancias irán de 20 a 30 metros en divisiones de 0,5 y de 30 a 40 metros en divisiones de 0,5 metros. Los resultados son los siguientes:

Gráfica correspondiente al resumen de los valores obtenidos de LQI en la prueba de distancia de los 20 a 30 metros.

DISTANCE TEST

0

20

40

60

80

100

20

20,5 21

21,5 22

22,5 23

23,5 24

24,5 25

25,5 26

26,5 27

27,5 28

28,5 29

29,5 30

METROS

LQI Más alto

Más bajo

Figura 43: Resumen de los niveles de LQI según valores recibidos

63

Gráfica correspondiente al resumen de los valores obtenidos de PER en la prueba de distancia de los 20 a 30 metros

PER

0

10

20

30

40

50

20

20,5 21

21,5 22

22,5 23

23,5 24

24,5 25

25,5 26

26,5 27

27,5 28

28,5 29

29,5 30

METROS

% P

ER

Más alto

Más bajo

Figura 44: Resumen de los niveles de PER según valores recibidos

Gráfica correspondiente al resumen de los valores obtenidos de LQI en la prueba de distancia de los 30 a 40 metros.

DISTANCE TEST

0

10

20

30

40

50

60

70

80

30

30,5 31

31,5 32

32,5 33

33,5 34

34,5 35

35,5 36

36,5 37

37,5 38

38,7 39

39,5 40

METROS

LQI Más alto

Más bajo


64

Gráfica correspondiente al resumen de los valores obtenidos de PER en la prueba de distancia de los 30 a 40 metros.

PER

0

20

40

60

80

100

120

30

30,5 31

31,5 32

32,5 33

33,5 34

34,5 35

35,5 36

36,5 37

37,5 38

38,7 39

39,5 40

METROS

% P

ER

Más alto

Más bajo


Conclusiones:

Las conclusiones que se obtienen de esta prueba son que como se observa en las gráficas (43, 44, 45,46), A partir de los 25,5, metros el nivel de señal decae hasta el umbral de 40 LQI, que es cuando comienza a elevarse el número de paquetes perdidos, El nivel de paquetes perdidos se mantiene entre el 10% y 60 % hasta llegar a los 36 metros que es donde la señal recibida baja de los -97 dBm. Se observa que de los 28 a los 33 metros hay un aumento del LQI que es debido a los rebotes multipath [*] de la señal que en este caso le afecta positivamente y ganamos unos metros de cobertura.

“Los rebotes producidos por los obstáculos que rodean el entorno de la prueba

pueden afectar al LQI de la señal recibida. A parir de 25,5 metros no se puede asegurar una comunicación segura en una vía urbana”. Multipath: es un fenómeno que ocurre cuando una señal rebota en las superficies y alcanza el destino final por varios

caminos, con efecto positivo o negativo sobre la potencia de señal recibida difíciles de controlar.

65

8.5 Escenario 5

Para el siguiente escenario se han hecho las mismas pruebas que en el escenario anterior pero variando la configuración de paquetes enviados: 10 paquetes de 30 bytes con un tiempo entre paquetes de 1 segundo. Y las distancias están comprendidas entre los 20 y los 85 metros en un espacio libre y sin obstáculos.


En este resumen de resultados representados en la gráfica 48, se puede ver como se han alcanzado distancias de hasta 74 metros con un nivel de LQI de 40 y un PER del 0%. A partir de esta distancia el nivel de PER era 0 pero la comunicación se cortaba, lo cual indica que se ha sobrepasado al limite de la sensibilidad de los dispositivos que es -97 dBm.

DISTANCE TEST

0102030405060708090

20 23 26 29 32 35 38 41 44 47 50 53 56 59 62 65 68 71 74 77 80 83

METROS

LQI Mas alto

Más bajo


66

Conclusiones:

Las conclusiones que se obtiene de hacer las pruebas en las condiciones del escenario 5 son que se asegura una comunicación hasta los 74 metros. Puesto que los vehículos estaban situados en un entorno sin obstáculos partir de esta distancia los módulos perdían la comunicación debido a la sensibilidad de los dispositivos que se encuentra en -97 dBm.

“En un entorno sin efecto multipath producidos por los mismos obstáculos, con una Pt de 0 dBm se pueden alcanzar distancias de 74 metros manteniendo los niveles de LQI aconsejados por el fabricante”. 8.6 Escenario 6

En este escenario se pretende poner a prueba a los dispositivos en entornos con más interferencias. Las pruebas que se han realizado, son con el fin de demostrar la comunicación de los dispositivos en entornos con movimiento o con obstáculos en movimiento. Los escenarios son los típicos que nos podríamos encontrar en nuestras ciudades.

Los siguientes resultados se han obtenido de colocar los dispositivos dentro de los vehículos en la zona del conductor, y los vehículos aparcados en una vía urbana sin obstáculos entre los dispositivos separados a una distancia de 20 metros y con una carretera transitada en medio (prueba 1).

20 METROS


67

Se ha utilizado la sub-opción time test para esta prueba y se han enviado 1000 paquetes de 30 bytes con un tiempo entre paquetes de 1 segundo, lo que hacen un total de 16,6 minutos de comunicación.

El escenario se sitúa en una calle urbana con un tráfico moderado. Los coches están situados a 25 metros hay árboles y casas en el entorno. La configuración de la transmisión queda de la siguiente manera:


Los dispositivos han estado en comunicación unos 16,6 minutos en dicho escenario, y los resultados obtenidos con la sub-opción time test son los representados el la figura 50 (prueba 1).

Figura 50: niveles de LQI y PER durante la transmisión

68

Los siguientes resultados han sido obtenidos en una vía urbana, al poner un coche aparcado y el otro cruzándose a distintas velocidades, durante 5 minutos. Las velocidades que se han alcanzado son de hasta los 50 Km/h. El circuito tiene un radio de unos 100 metros. El recorrido durante la comunicación esta coloreado de rojo en el siguiente mapa:

Figura 51: Mapa de Tarragona (vall de l’Arrabassada)

Las siguiente figura 52 muestra los resultados de LQI y PER de la comunicación inter-vehicular durante el circuito, uno parado y el otro en movimiento (prueba 2).

Figura 52: LQI y PER de un coche aparcado y el otro cruzándose

69

Los siguientes resultados se han obtenido de poner dos vehículos circulando simultáneamente por un circuito urbano (el mismo que el anterior) a diferentes velocidades el uno del otro. En algunos momentos los coches se cruzaban a velocidades de 50 Km/h cada uno. Lo que hace una velocidad de 100 Km/h (prueba 3).

Figura 53: LQI y PER de dos coches cruzándose simultáneamente.

Los siguientes resultados corresponden a realizar un circuito urbano los dos coches, uno detrás del otro a diferentes distancias y velocidades. Es un circuito urbano de un recorrido de 6 Km. La velocidad máxima alcanzada es de unos 50 a 60 Km/h.

Figura 54: Mapa de Tarragona (vall de l’Arrabassada)

70

Los niveles de LQI y PER obtenidos en este recorrido son los siguientes (prueba 4):

Figura 55: LQI y PER del recorrido

Los siguientes resultados corresponden a un trayecto de los dos vehículos a diferentes distancias y velocidades, durante 16 minutos.

El trayecto está comprendido entre la zona de la vall de l’Arrabassada y el pueblo del Catllar, pasando por tramos urbanos, interurbanos y comarcales. Las velocidades oscilan entre los 20 a 60 Km/h. El trayecto esta coloreado de rojo en el siguiente mapa (prueba 5):

Figura 56: Mapa de tarragona

71

Figura 57: LQI y PER del recorrido Conclusiones:

Los resultados obtenidos en la figura 50 muestran como los vehículos que atraviesan la comunicación provocan atenuaciones del nivel de señal, hasta situarse a los 40 LQI. Se observa que cuanto mayor es la atenuación es por que mayor es el vehículo que se ha cruzado entre los dispositivos. El PER es de 0 en toda la comunicación.

Los datos obtenidos en la figura 52 muestran una media de LQI de unos 75. Los momentos que este nivel de LQI bajan drásticamente vienen dados por un fenómeno llamado efecto Doppler [*] . La forma en que este fenómeno afecta a la señal es de ráfagas de pérdida de señal repentinas. Los resultados de la figura 52 muestran un PER del 0%.

Los datos obtenidos en la figura 53 son bastante distintos a los de la prueba anterior puesto que en este caso el efecto Doppler se acentúa ya que los vehículos se llegan a cruzar a una velocidad de unos 50 Km/h cada uno, lo que hacen una velocidad total de 100 Km/h. se recuerda que el efecto Doppler es directamente proporcional a la velocidad. Los momentos en que el PER es más alto corresponden a cuando los vehículos estaban más cerca pero se cruzaban a más velocidad. Se puede observar en la figura 55 el nivel de LQI está casi todo el tiempo por debajo del límite de sensibilidad. La comunicación de los 2 vehículos en un entorno urbano a velocidades de unos 50 Km/h no es correcta y el PER es casi constante. Los datos obtenidos en la figura 57 se refieren a una comunicación prácticamente sin obstáculos puesto que el recorrido más largo es una vía interurbana sin muchos edificios ni obstáculos donde pueda rebotar la señal y afectarnos negativamente.

Doppler: Alteración de la frecuencia (o la longitud de onda) producida por el movimiento relativo entre la fuente emisora y el detector. Llamado así en honor del físico austriaco C. Doppler, quien demostró este efecto en el sonido.

72

9 Conclusiones Generales del Proyecto

En el escenario 1 se concluye que el efecto multipath afecta cada vez más a la calidad de la señal puesto que cuando aumentamos la distancia entre dispositivos, este efecto se acentúa y afecta negativamente al LQI y PER. No se puede garantizar una comunicación al 100% a partir de los 27 metros en un entorno urbano. La conclusión general que se extrae del escenario 2, es que todas la pruebas realizadas, son satisfactorias en cuanto al nivel de LQI y PER. Por lo que queda demostrado uno de los objetivos de este proyecto: la comunicación utilizando este tipo de sensores wireless en vehículos es viable. En el escenario 3 las pruebas realizadas de LQI nos dan unos resultados satisfactorios hasta los 20 metros, a partir de esta distancia los niveles de LQI sobrepasan negativamente el umbral descrito por el fabricante que garantiza una correcta comunicación. Se ha comprobado como el entorno del vehículo ya sean cristales cromados, chapa, etc., atenúa la señal y reducen el campo de acción de los dispositivos. Se asegura que, hasta 20 metros y en este escenario, la comunicación inter-vehicular es correcta. En el escenario 4 se observa como a partir de los 25,5 metros el nivel de calidad está en torno a los 40 LQI. En algunos momentos, entre los 28 y los 33 metros, se observa un aumento en el LQI producido por el efecto multipath, que en este caso afecta positivamente. Se puede asegurar, hasta los 25,5 metros, una correcta comunicación en el escenario 4. Las conclusiones del escenario 5 son que en un entorno sin obstáculos podemos garantizar una correcta comunicación inter-vehicular hasta los 74 metros, puesto que la señal no se ve afectada por el efecto multipath. En las pruebas realizadas en el escenario 6 que son las que corresponden a la demostración de uno de los objetivos de este proyecto, tenemos que los resultados son diversos: puesto que en la prueba 1, se observa como una comunicación entre dos dispositivos situados dentro del vehículo y éstos a una distancia de unos 20 metros, los niveles son de una media de 100 LQI. El hecho de que en algunos momentos el nivel de calidad de la señal disminuya se debe a atenuaciones producidas por el efecto del paso de otros vehículos; en la prueba 2, también se obtienen resultados satisfactorios y se garantiza una comunicación segura; en la prueba 3, los resultados no son satisfactorios puesto que el efecto Doppler y multipath distorsionan y atenúan la señal y el PER se eleva hasta el 10%; la prueba 4, tampoco es positiva puesto que los efectos Doppler y multipath atenúan la señal y disparan el PER; en la prueba 5, se concluye que, como el trayecto está libre de obstáculos que pudieran interferir en la calidad de la señal, el resultado es satisfactorio, manteniendo durante todo el trayecto un nivel de LQI correcto y un PER en 0%. Por tanto, se puede afirmar que el hecho de que los datos de la pruebas realizadas en un medio urbano sean, en cuanto a LQI y PER, peores que los registrados en un medio interurbano se debe a que a estos dispositivos el efecto multipath les afecta considerablemente. Asimismo, se observa que a los módulos ZigBee les afecta en mayor grado el efecto multipath que el efecto Doppler, por lo que se concluye que en un medio urbano no es posible garantizar una comunicación inter-vehicular segura.

73

“Los datos obtenidos de todas las pruebas nos indican que sólo se ha podido demostrar satisfactoriamente uno de los dos principales objetivos: el de sensores wireless para vehículos.

El otro objetivo fijado no es satisfactorio, puesto que los resultados más importantes que son los obtenidos en las zonas urbanas, nos revelan que no se puede garantizar una correcta comunicación.

Se deja la posibilidad de poder realizar pruebas similares pero con módulos ZigBee de más potencia, en futuros proyectos”.

74

10 Bibliografía

• Theodore S. Rappaport, Prentice Hall, 2002. ISBN 0-13-042232-0. • User Guide JN5139-EK020 802.15.4/JenNet 3 April 2008. • Luís Ruíz Maya, Estadística editorial AC 2000. ISBN 84 7288 1598. • Jorge Ramió Aguirre, Seguridad informática y criptografía, 2006.

75

Acrónimos AES: Advanced Encryption Standard API: Application Programming Interface APS: Application Support Sub-layer MAC: Media Access Control NWK: Network Layer PAN: Personal Area Network WPAN: Wireless Personal Area Network RF: Radio Frequency ZDO: ZigBee Device Object UART: Universal Asynchronous Receiver Transmitter PHY: Physical LED: Light Emitting Diode O-QPSK: Offset Quadrature Phase Shift Key AF: Application Framework USB: Universal Serie Bus IEEE: Institute of Electrical and Electronics Engineers LQI: Link Quailiti Index

76

Referencias [1]: IEEE organismo regulador. Estándar IEEE 802.15.4. (http://www.ieee.org/portal/site). [2] OQPSK, sistema de modulación digital. Theodore S. Rappaport, Prentice Hall, 2002. ISBN 0-13-042232-0. [3]: AES, algoritmo de encriptación de datos. Seguridad informática y criptografía, Jorge Ramió Aguirre, 2006. [4]: Flash Programmer aplicación para cargar los programas en los módulos. (http://www.jennic.com/support). [5]: Sensibilidad del receptor estipulada por el fabricante que se corresponde a un nivel de señal de -97 dBm que equivalen a un nivel de 40 LQI. (http://www.jennic.com/support).

Comunicación entre automóviles vía radio utilizando...

Documents

Transcript of Comunicación entre automóviles vía radio utilizando...