Sistema de telemetría vía Ethernet

PROJECTE DE FI DE CARRERA TÍTOL DEL PFC: Sistema de telemetría vía Ethernet TITULACIÓ: Enginyeria de Telecomunicació (segon cicle) AUTOR: Ricard Moraleda Gareta DIRECTOR: Roberto Casas Nebra DATA: febrero de 2005 Títol: Sistema de telemetría vía Ethernet Autor: Ricard Moraleda Gareta Director: Roberto Casas Nebra Data: febrero de 2005 Resum El propósito de este documento es capturar el diseño e implementación de varios sistemas de telemetría vía Ethernet. Uno de ellos es un sistema de conversión de protocolos RS-232 a Ethernet y viceversa. Este sistema se puede aplicar a una aplicación de telemedicina, en el cual se toman las constantes vitales de un paciente y en un PC remoto a través de la red de área local se adquieren. El otro, más importante, es un sistema de transmisión de voz sobre IP (VoIP), en el cual dos usuarios pueden mantener una conversación a través de Ethernet. La idea es juntar los dos sistemas anteriores, de datos y de voz, e implementar un único sistema de telemedicina, aplicable en hospitales, donde el médico puede invitar al paciente a tomarse las constantes vitales mediante voz, mantener una conversación en tiempo real y recibir los datos biomédicos en un PC remoto. Para la realización de estos sistemas se ha utilizado TINI (Tiny InterNet Interface), un dispositivo embebido con capacidad de comunicación Ethernet. Se ha diseñado el software de TINI para ser utilizado como servidor de datos y ser controlado vía web, para realizar las funciones de pasarela entre los protocolos RS-232 y Ethernet. Para el sistema de VoIP, se ha diseñado e implementado un circuito de voz, el cual toma señales de voz y las convierte en datos RS-232 para comunicarse con TINI. El TINI es responsable de recibir datos del circuito de voz y transmitirlos por Ethernet a otro TINI en otro extremo, que cogerá estos datos y los mandará a otro circuito de voz para reproducir las señales de voz. De esta manera se consigue una conversación de voz bidireccional a través de una red IP con una plataforma embebida, de tamaño pequeño y de bajo coste. Title: Telemetry system via Ethernet Author: Ricard Moraleda Gareta Director: Roberto Casas Nebra Date: February, 2005 Overview The purpose of this document is to capture the design and implementation of several telemetry systems via Ethernet. One of them is a protocol conversion system of the RS-232 to the Ethernet and vice versa. This system can be applied to a telemedicine application, in which the vital constants of a patient are taken and are acquired in a remote PC through the local area network. The other one, the most important, is a voice over IP (VoIP) transmission system, in which two users can have a conversation through the Ethernet. The idea is to join the previous two systems, of data and voice, and implement only one system of telemedicine, applicable to hospitals, where the doctor can offer the patient to take the vital constants by means of the voice, to have a conversation in real time and to receive the biomedical information in a remote PC. For the accomplishment of these systems I have used TINI (Tiny InterNet Interface), an embedded device with capacity to communicate through the Ethernet. TINI's software has been designed to be used as data server and to be web controlled, to realise the gateway functions between the RS-232 and the Ethernet protocols. For VoIP's system, I have designed and implemented a voice circuit, which takes voice signals and turns them into RS-232 data in order to communicate with the TINI. The TINI is in charge of receiving data of the voice circuit and of transmitting it to another TINI in another end through the Ethernet, which will take these data and order it to another voice circuit so as to reproduce the voice signals. Hereby a bi-directional voice conversation is obtained through an IP network with an embedded platform, of small size and very cheap. Agradecimientos Primero, agradecer a mi director de proyecto de fin de carrera (PFC), Roberto Casas Nebra, por sus conocimientos, dirección, y paciencia que constantemente me ha proporcionado durante la realización de este proyecto. También agradecer a mi segundo director de proyecto, Óscar Casas y al técnico de laboratorio, Francis López, por proporcionarme los medios materiales para llevar acabo este proyecto. Sin ellos todo se hubiera hecho cuesta arriba. Agradecer también a profesores, como Toni Oller y José Ramón Piney y a compañeros como Manel Mendoza, Jesús Rubio y Alexis Porro por mostrarme sus grandes conocimientos en Java. Doy las gracias también a todos mis compañeros de clase de segundo ciclo de Ingeniería de Telecomunicación por crear un ambiente fantástico y poder disfrutar de las clases. Finalmente, a mi novia Vanessa, a mi familia y a mi amiga Sandra por darme todo su apoyo moral durante el tiempo de realización de este proyecto. ¡¡A todos, muchas gracias!! ÍNDICE INTRODUCCIÓN ............................................................................................... 1 CAPÍTULO 1. POSIBLES SOLUCIONES TÉCNICAS...................................... 2 1.1. Plataforma PC .................................................................................................................... 2 1.2. Sistemas embebidos......................................................................................................... 2 1.3. Justificación de la solución escogida............................................................................. 3 1.4. Visión general de dispositivos embebidos Ethernet..................................................... 4 CAPÍTULO 2. PLATAFORMA TINY INTERNET INTERFACE (TINI) ............... 7 2.1. Aplicaciones TINI...............................................................................................................7 2.2. TINI SIMM Hardware.......................................................................................................... 8 2.3. TINI SIMM Software ......................................................................................................... 10 2.3.1. TINI JVM............................................................................................................... 11 2.3.2. TINI API ................................................................................................................ 11 2.3.3. TINI Métodos Nativos........................................................................................... 12 2.3.4. TINI OS................................................................................................................. 12 CAPÍTULO 3. UN CONVERSOR SERIE ÅÆ ETHERNET............................. 14 3.1. Introducción........................................................................................................................ 14 3.2. Sistema de conversión de protocolos ............................................................................. 15 3.2.1. Cliente...................................................................................................................... 15 3.2.2. Servidor ................................................................................................................... 17 3.2.3. Funcionamiento del sistema.................................................................................... 18 3.2.4. Aplicación Serial2Ethernet ...................................................................................... 19 CAPÍTULO 4. VOZ SOBRE IP A TRAVÉS DE TINI........................................ 24 4.1. Introducción........................................................................................................................ 24 4.2. TINI en VoIP......................................................................................................................... 25 4.2.1. Cliente...................................................................................................................... 25 4.2.2. Servidor ................................................................................................................... 26 4.2.3. Funcionamiento del sistema.................................................................................... 27 4.2.4. Aplicación Serial2Ethernet ...................................................................................... 28 4.3. Circuito de voz en VoIP ..................................................................................................... 31 4.3.1. Codec CMX639 ....................................................................................................... 31 4.3.2. PIC 16F873A........................................................................................................... 32 4.3.3. MAX 232..................................................................................................................34 4.3.4. Amplificadores operacionales TL072 y etapa de potencia ES-5............................. 35 4.3.5. Sistema conjunto..................................................................................................... 36 4.4. Análisis de tiempos y diseño de parámetros del sistema ............................................. 38 4.4.1. Diseño de parámetros del sistema.......................................................................... 38 4.4.2. Análisis de tiempos a 15625 bps............................................................................. 40 4.4.3. Análisis de tiempos a 31250 bps............................................................................. 45 4.4.4. Análisis de tiempos a 62500 bps............................................................................. 48 4.4.5. Conclusiones ........................................................................................................... 49 CAPÍTULO 5. LÍNEAS FUTURAS Y MEJORAS EN EL SISTEMA ................ 50 CAPÍTULO 6. CONCLUSIONES ..................................................................... 51 BIBLIOGRAFÍA ............................................................................................... 52 ANEXOS .......................................................................................................... 54 1. Manual puesta en marcha TINI............................................................................................. 54 2. Instalación Tynamo Web Server (servlets) en TINI............................................................ 62 3. Diagramas secuencia Serial2Ethernet TCP/UDP............................................................... 64 Introducción 1 INTRODUCCIÓN La telemetría es un conjunto de procedimientos para medir magnitudes físicas desde una posición distante al lugar donde se producen los fenómenos. Los equipos de telemetría obtienen la información mediante transductores que transforman las magnitudes físicas a medir en señales eléctricas equivalentes, que son enviadas al punto de observación mediante buses de datos para su recogida y análisis. Actualmente se suelen utilizar buses como RS-485 para extensiones largas u otros a nivel industrial como medio de transmisión. Hoy en día, con el auge de las redes IP y sobretodo a nivel local de Ethernet, se propone realizar un sistema de telemetría cuyo enlace no sean los buses actuales, sino una red de área local como es Ethernet. Esto permite alcanzar longitudes impensables a nivel mundial, todo si la red local tiene acceso al mundo Internet. También se garantizan velocidades muy altas, del orden de decenas de megabits por segundo. Normalmente los dispositivos comerciales utilizados para tomar medidas tienen un puerto serie estándar, como por ejemplo, RS232, RS485, 1-wire, CAN, I2C, SPI, etc. Por este motivo y debido a que la telemetría se hace a través de Ethernet es necesario un dispositivo que haga de puente entre los dos protocolos, serie y Ethernet. Para ello se ha realizado una comparativa de placas microcontroladoras comerciales en las que se pueda desarrollar una aplicación que realice de puente entre los dos protocolos y formar un sistema embebido. Se ha buscado una solución de bajo coste, de tamaño pequeño y programable a alto nivel. Como se verá más adelante, esta solución es TINI (Tiny InterNet Interface). En este proyecto se han diseñado e implementado dos sistemas de telemetría vía Ethernet. El primer sistema se ha centrado, únicamente, en la plataforma TINI. Se ha querido implementar un sistema de conversión de protocolos, por lo que se ha desarrollado una aplicación Java que realiza una conversión de RS-232 a Ethernet y viceversa. Además, esta aplicación permite ser configurada y controlada vía web, lo que da más potencia al sistema de telemetría. Este desarrollo en TINI permite aplicarse en multitud de aplicaciones, como por ejemplo telemetría medioambiental, telemedicina, etc. La plataforma TINI se ha aplicado a una aplicación de telemedicina, telemetría de constantes vitales. En este sistema se ha utilizado un dispositivo comercial con salida RS-232 que mide el nivel de oxígeno en la sangre y el pulso cardíaco de un paciente. Los datos se obtienen en un PC remoto a través de la red de área local Ethernet. El segundo sistema se ha centrado en la transmisión de voz sobre IP (Ethernet). Para ello se han utilizado dos plataformas TINI y se ha diseñado e implementado un circuito de voz con salida RS-232. De esta manera de ha implementado un sistema de VoIP, tanto a nivel hardware como software. 8 Sistema de telemetría vía Ethernet ¾ Conversión de protocolos. Sistemas basados en TINI pueden ser utilizados para conectar dispositivos serie a redes Ethernet. ¾ Monitorización medioambiental. Aplicaciones basadas en TINI pueden interrogar una red de sensores medioambientales y reportar datos en tiempo real a PC remotos. 2.2. TINI SIMM Hardware El microcontrolador de TINI es el DS80C390 de 8 bits de Dallas Semiconductor. TINI tiene incorporado puertos serie, paralelo, 1-wire, I2C (Inter-Integrated Circuit) y CAN (Controller Area Network), con pines extra para controlar dispositivos opcionales. Contiene un 1MB de memoria SRAM que contiene el área de datos de sistema, el colector de basura de Java y almacena los datos de sistema de archivos y 1MB de memoria Flash EEPROM, que almacena el entorno de ejecución de TINI, guarda los datos incluso en ausencia de alimentación y es reprogramable. TINI también dispone de interfaz RS-232, un reloj de tiempo real, una dirección MAC única y una batería (simple celda de litio) de backup para la memoria RAM y reloj, destinada a guardar los datos del sistema de archivos y hacer funcionar el reloj en ausencia de alimentación. El controlador Ethernet soporta interconexionado 10 BaseT (10 Mbps sobre par trenzado) y permite habilitar a Internet a muchas aplicaciones. La memoria Flash ROM contiene el firmware de TINI, la Máquina Virtual de Java (JVM) y las librerías de Java. La siguiente tabla muestra la lista de componentes de TINI, así como los modelos y sus fabricantes. Tabla 2.1. Lista de componentes de TINI Función ID Fabricante CPU DS80C390 Dallas Semiconductor Flash ROM Am29F040B Advanced Micro Devices Ethernet Interface LAN91C96 Standard MicroSystems Corporation HM628512BLTT5 Hitachi Semiconductor M5M5408BTP-55L Mitsubishi Semiconductors SRAM KM684000CLT-5L Samsung Semiconductor Real-Time Clock DS1315 Dallas Semiconductor 1-Wire Interface DS2480 Dallas Semiconductor SRAM Non-Volitizer DS1321 Dallas Semiconductor Unique ID & Ethernet Address DS2502-UNW Dallas Semiconductor Ethernet Filter Module PM-1006 Premier Magnetics Inc. RS232 Interface DS232A Dallas Semiconductor Plataforma Tiny Internet Interface (TINI) 9 Vistos los componentes que constituyen TINI, en la figura 2.2 se muestran cada uno de ellos situados en la propia SIMM TINI. Se proporciona el anverso y reverso de TINI para la vista global de todos los componentes. Figura 2.2. Componentes de TINI (anverso y reverso) Todos los componentes básicos de TINI están interconectados con el microcontrolador y además lo están a través de buses de direcciones y de datos (paralelo), como se puede apreciar en la figura 2.3. Figura 2.3. Implementación del hardware de TINI 10 Sistema de telemetría vía Ethernet 2.3. TINI SIMM Software El entorno de ejecución TINI proporciona una entera infraestructura software necesaria para programar aplicaciones de red para microcontroladores preparados para el mundo IP. El entorno de ejecución proporciona una completa pila de protocolos TCP/IP v4/v6 cumpliendo los estándares de Internet. La pila de red está manejada por un sistema operativo multitarea (TINI OS). Esta pila incluye los siguientes protocolos de red: ¾ PPP ¾ IP v4/v6 ¾ TCP ¾ UDP ¾ ICMP ¾ SMTP ¾ DHCP ¾ FTP ¾ HTTP ¾ TELNET También soporta los siguientes protocolos de entrada/salida: ¾ Serie (RS232/485) ¾ SPI ¾ Paralelo ¾ I2C ¾ 1-Wire ¾ CAN Si otro protocolo de entrada/salida fuese requerido, es posible programar una API para este protocolo en Java, C o ensamblador 8051. Las rutinas de lenguaje ensamblador son accesibles desde Java y permite respuestas en un estricto tiempo real a eventos o altas velocidades de entrada/salida. El software que comprende el entorno de ejecución de TINI puede ser dividido en dos categorías: código nativo ejecutado directamente por el microcontrolador y una API (Application Program Interface) interpretada como bytecodes por la Máquina Virtual de Java (JVM). El código de las aplicaciones es escrito en Java y utiliza la API para explotar las capacidades de la ejecución nativa y los recursos hardware. También es posible escribir librerías nativas que pueden ser cargadas desde dentro de una aplicación para obtener un estricto tiempo real. Plataforma Tiny Internet Interface (TINI) 11 Figura 2.4. Entorno de ejecución de TINI 2.3.1. TINI JVM El firmware de TINI incluye una Máquina Virtual de Java (JVM) y una API. Los programas que serán escritos en Java utilizarán la API para acceder a las capacidades de los recursos hardware de TINI. La JVM y la API incluyen soporte total de hilos de ejecución y de todos los tipos primitivos de datos y strings. La JVM proporciona acceso a los paquetes de Java siguientes: java.lang, java.io, java.net y java.util y también proporciona acceso a un número de clases específicas de TINI que permiten acceder a la capa hardware y recursos de TINI. La versión de firmware con la que se ha trabajado en el presente proyecto es la 1.13, pero Dallas Semiconductor actualiza estas versiones cada cierto tiempo y pueden obtenerse en [6]. 2.3.2. TINI API La API de TINI es un conjunto de paquetes (clases y métodos) que realizan de interfaz entre el hardware de TINI y la Máquina Virtual de Java (JVM). En otras palabras, éstas son el conjunto de clases Java que se utilizará para programar características específicas de TINI que no son parte de la JVM. Para la realización del presente proyecto se han utilizado los siguientes paquetes de la API: Incluidas en el firmware TINI 1.13: ¾ java.lang ¾ java.io ¾ java.net ¾ java.util ¾ com.dalsemi.comm ¾ com.dalsemi.fs ¾ com.dalsemi.io ¾ com.dalsemi.system ¾ com.dalsemi.tininet 12 Sistema de telemetría vía Ethernet No incluidas: ¾ javax.comm (Sun’s Java Communications API) ¾ javax.servlet (Servlet 2.2 API) 2.3.3. TINI Métodos Nativos La capa nativa representa la colección de métodos nativos que soportan la API exponiendo la infraestructura proporcionada por el TINI OS. Ésta incluye acceso a la pila de protocolos y drivers, tanto de red como de dispositivos de entrada/salida. También incluye métodos para configurar y acceder a los recursos del sistema tales como el watchdog timer y el reloj de tiempo real. Las aplicaciones que requieran métodos nativos pueden proporcionar una librería nativa que puede ser cargada en el sistema en su ejecución utilizando el método loadLibrary definido en la clase java.lang.Runtime. 2.3.4. TINI OS Es la capa más baja del entorno de ejecución. Es responsable de gestionar todos los recursos incluyendo acceso a la memoria, planificar múltiples procesos e hilos de ejecución y de interactuar con componentes hardware internos y externos. Este sistema operativo está compuesto de los siguientes tres componentes: • Planificadores de procesos e hilos de ejecución • Subsistema de gestión de memoria • Subsistema de gestión E/S El firmware proporcionado, incluye también una shell para el TINI OS. Se llama Slush y la proporciona Dallas Semiconductor. Es similar a una sencilla shell Unix. Slush se carga en la memoria flash ROM y además se ejecuta cuando se alimenta a TINI. Figura 2.5. Aspecto de la shell de TINI OS (Slush) Esta shell proporciona una serie de comandos útiles para gestionar el subsistema de archivos, arrancar y parar procesos, configurar parámetros de TINI, etc. La figura 2.6 muestra una lista de éstos. Plataforma Tiny Internet Interface (TINI) 13 Figura 2.6. Lista de comandos que proporciona Slush Para permitir el acceso a la shell del sistema operativo, el TINI OS proporciona tres tipos de servidores. Estos son: FTP, Telnet, Serial. De esta forma se puede acceder al TINI OS (Slush) mediante el puerto serie, una conexión de FTP al puerto 21 o una sesión de Telnet al puerto 23. Normalmente se utilizará el puerto serie para configurar todos los parámetros desde cero, es decir, la primera vez o en caso de fallos, y una vez configurados los parámetros de red, se establecerán sesiones de telnet, ya que aporta mayor flexibilidad al mundo IP. 14 Sistema de telemetría vía Ethernet CAPÍTULO 3. Un conversor Serie ÅÆ Ethernet 3.1. Introducción La finalidad de esta aplicación es la de dar conectividad a dispositivos con sólo salida RS-232 a la red de área local (Ethernet) e Internet. Se ha diseñado y desarrollado una aplicación JAVA, para la plataforma TINI, que implementa un puente entre protocolos RS-232 (serie) y 802.3 (Ethernet), de manera bidireccional. Se ha diseñado e implementado un sistema, no enfocado a una aplicación en concreto, sino válido para cualquier dispositivo serie con cable RS-232. Normalmente los dispositivos serie, proporcionan puerto RS-232 y disponen de un software para PC para realizar el control y monitorización de los datos que envía éste. Por ejemplo una aplicación de pulso-oximetría. Véase la figura 3.1. Figura 3.1. Esquema de conexión de un dispositivo serie a PC Los datos que proporciona el dispositivo serie, sólo se pueden obtener y visualizar en el PC donde esté conectado el dispositivo, es decir, en local. Esto no da flexibilidad de movimiento y además limita en distancia. El objetivo del siguiente sistema es extender ese enlace serie a través de la red IP, el cual proporciona una mayor flexibilidad, ya que se podrían obtener los datos del dispositivo en cualquier parte del mundo, siempre y cuando se disponga de conexión a Internet. Hasta ahora la única manera era a través de un PC, el cual hacía de puente entre los dos protocolos. La idea actual es sustituir el PC por el dispositivo TINI, lo que permite seguir disfrutando de las mismas funciones y con un tamaño y coste muy reducidos, dando mucha potencia para trabajar con sistemas embebidos. La extensión del enlace entre el sensor y el PC de monitorización se refleja como muestra la figura 3.2. Se ha pasado de un enlace RS-232, con limitación Un conversor Serie ÅÆ Ethernet 15 de distancia, a un enlace a través de una red local o Internet sin limitación de ésta. Figura 3.2. Conexión de un dispositivo serie en red a través de TINI 3.2. Sistema de conversión de protocolos A continuación se explicarán todas las partes que componen este sistema y los requisitos necesarios para el correcto funcionamiento de la aplicación. El sistema de compone de un cliente, en el cual se obtendrán y visualizarán los datos y un un servidor, al cual se le conectará el sensor a monitorizar y hará la conversión de datos RS-232 a Ethernet. 3.2.1. Cliente El cliente está basado en PC, el cual ha de disponer de las siguientes aplicaciones: 1. Navegador web (por ejemplo Internet Explorer). 2. Software control y monitorización del dispositivo serie a conectar al sistema. 3. Software redirector de puertos TCP/IP a serie. - El navegador web permite la interacción entre el cliente y el servidor para configurar y controlar la aplicación Serial2Ethernet, previa autenticación. En el apartado 3.2.4 se describen los casos de uso del cliente con la aplicación Serial2Ethernet (servidor) a través del navegador web (Figura 3.3). Un adelanto de éstos es la configuración, tanto del puerto serie como parámetros de red, la puesta en marcha y parada de la aplicación. 16 Sistema de telemetría vía Ethernet Figura 3.3. Interfaz web de la aplicación Serial2Ethernet servida por el TINI - El software de control y monitorización del dispositivo serie a conectar al sistema. Viene incluido con el dispositivo serie a utilizar. La mayoría de éstos, sólo tienen conectividad a los puertos serie COM1 y COM2 del PC. Tiene el protocolo de envío de datos del dispositivo serie para recibirlos correctamente y representarlos gráficamente. - El Redirector de puertos TCP/IP a serie es un software que crea un puerto COM virtual en el PC y lo redirecciona a una dirección IP y puerto TCP, que en este caso sería la del servidor (TINI). Lo que realiza es un túnel para que todos los datos recibidos por la interficie Ethernet se conviertan en datos serie por el COM virtual y viceversa. Este software permite a la aplicación de control y monitorización del dispositivo serie tener acceso a una red TCP/IP. En la figura Figura 3.4 se muestra el entorno visual de la aplicación HW Virtual port manager que permite introducir una dirección IP destino y un puerto TCP (del servidor, en este caso, TINI) y el puerto serie COM virtual a crear. Un conversor Serie ÅÆ Ethernet 17 Figura 3.4. Aplicación HW Virtual port manager (freeware) 3.2.2. Servidor El servidor está basado en la plataforma TINI, el cual ha de disponer de las siguientes aplicaciones: 1. Servidor web con soporte de servlets (Tynamo web Server 1.0) 2. Aplicación Serial2Ethernet - El servidor web Tynamo [11] soporta HTTP/1.1 y Servlet 2.2. Es un servidor de uso libre para fines docentes y es en el que se incluirá el aplicativo Serial2Ethernet para hacer funcionar la aplicación final. Para ver más detalles de éste, véase el anexo 2. Existe otro de libre distribución, TiniHttpServer [12], pero no está actualizado a la versión de firmware que se ha utilizado en el proyecto (1.13). - La aplicación Serial2Ethernet permite un control y configuración vía web y realiza la conversión de protocolos RS-232 a Ethernet y viceversa de manera bidireccional. Ha sido programada en Java y contiene servlets para proporcionar una herramienta de control de la aplicación vía web. Esto permite a cualquier usuario sin conocimientos de sistemas operativos ni de aplicaciones de conexión remota a hacer funcionar la aplicación de manera muy intuitiva. Como protocolo de transporte se elige TCP (Transmisión Control Protocol), ya que es orientado a la conexión, una característica de esta aplicación, de modo que el usuario decide cuando quiere recibir datos, tan solo con realizar una conexión TCP al servidor TINI. Para saber más sobre TCP en Java y en TINI y sobre servlets y el servidor Tynamo, consultar [3]. 24 Sistema de telemetría vía Ethernet CAPÍTULO 4. Voz sobre IP a través de TINI 4.1. Introducción La finalidad de esta aplicación es la de intercambio de voz de manera fullduplex sobre una red IP a través de dispositivos embebidos como TINI. Se ha diseñado el sistema completo, tanto software como hardware. Desde el software que correrá en el TINI hasta el circuito de voz (codec+PIC) que se conecta a éste. El PIC es un componente esencial en el circuito de voz, ya que es el encargado de sacar datos asíncronos (RS-232) del circuito de voz. El esquema de bloques de la aplicación diseñada es la siguiente: Figura 4.1. Esquema de bloques de la aplicación VoIP a través de TINI Consta de dos servidores (TINI) idénticos, tanto en hardware como en software, y un cliente. El entorno de aplicación será el que un usuario (maestro) tenga un PC y un TINI, con el circuito de voz incluido, y un usuario (esclavo) tenga sólo un TINI, también con el circuito de voz incluido. El maestro y esclavo podrán hablarse y escucharse en tiempo real de manera igual, pero el único que puede configurar, arrancar y parar los servidores es el maestro. Una aplicación sería el sistema de voz de una aplicación de telemedicina, donde el médico sería el usuario maestro y el paciente el usuario esclavo. El esquema mostrado es el que se ha implementado finalmente de entre dos posibiblidades. La otra posibilidad es simplificar el circuito de voz quitando el PIC, de manera que la salida síncrona del codec la trate directamente el TINI. De esta manera la aplicación Serial2Ethernet cambia, ya que no leería datos RS-232 sino datos síncronos de una entrada digital. Voz sobre IP a través de TINI 25 Esta es una solución muy elegante, ya que todo lo que pueda hacer el microcontrolador del TINI ayuda a la eliminación de hardware adicional. La justificación de la no elección de esta solución es la siguiente. El codec envía datos síncronos a una velocidad de 15625 bps (según modo configurado). Esto es que el TINI tendría que acceder a la entrada digital para realizar su lectura cada 64 µs. El problema está en el lenguaje de programación. Java, debido a la Máquina Virtual de Java (JVM) no permite leer una entrada digital a esta velocidad. La JVM en un microcontrolador de 8 bits necesita entre 1,7 y 2,3 ms para ejecutar una lectura de un pin, por lo que no se consigue un estricto tiempo real para la aplicación de voz. Con estos tiempos se necesitarían velocidades muy lentas del codec, como son 500 bps, TINI ofrece la solución de poder crear librerías en otro lenguaje que no sea Java, como puede ser C o Ensamblador. Gracias a la capa de métodos nativos del entorno de ejecución de TINI, se puede programar una librería en estos lenguajes e importarla desde una aplicación de Java. De este modo las lecturas de las entradas digitales se realizarían en tiempo real, ya que se evitaría la JVM de Java. En definitiva, la solución contemplada debería ser la programación de una librería nativa en Ensamblador e importarla desde una nueva aplicación Serial2Ethernet en Java. De este modo se podría conectar directamente el codec al TINI de manera efectiva. Debido a carencias de software y de conocimientos en lenguaje ensamblador, se opta por la solución de convertir la salida síncrona del codec en RS-232 con un PIC, ya que se tienen mayores conocimientos de lenguaje C. De este modo la aplicación Serial2Ethernet no variará mucho de la aplicación que se realizó en la aplicación del capítulo anterior, únicamente la forma de transmisión/recepción de datos por la red Ethernet, es decir, pasar de trabajar con sockets TCP a sockets UDP (ver justificación en 4.2.2). 4.2. TINI en VoIP A continuación se explicarán todas las partes que componen este sistema y los requisitos necesarios para el correcto funcionamiento de la aplicación. El sistema de compone de un cliente, el cual configurará, arrancará y parará la aplicación de los servidores y dos servidores, a los cuales se les conectará el circuito de voz diseñado y harán la transmisión/recepción de voz a través de la red local Ethernet. 4.2.1. Cliente El cliente está basado en PC, el cual ha de disponer de la siguiente aplicación: 1. Navegador web. 26 Sistema de telemetría vía Ethernet - El navegador web permite la interacción entre el cliente y el servidor para configurar y controlar la aplicación Serial2Ethernet. Se describen los casos de uso del cliente con la aplicación Serial2Ethernet (servidor) a través del navegador web (Figura 4.2). Éstos son idénticos a los de la aplicación del capítulo anterior, por lo que se pueden ver en el apartado 3.2.4. Para configurar, poner en marcha y parar la aplicación Serial2Ethernet (UDP) es necesario conectar un PC a la LAN con un navegador web, como en el caso anterior, ya que el TINI dispondrá de un servidor web con un contenedor de servlets. La diferencia de la aplicación UDP con la de TCP, es un ligero cambio en la interfaz web a nivel de parámetros, pero el funcionamiento sigue siendo el mismo. Figura 4.2. Interfaz web de la aplicación Serial2Ethernet servida por el TINI 4.2.2. Servidor El servidor está basado en la plataforma TINI, el cual ha de disponer de las siguientes aplicaciones: 1. Servidor web con soporte de servlets (Tynamo web Server 1.0) 2. Aplicación Serial2Ethernet (UDP). - El servidor web Tynamo [11] soporta HTTP/1.1 y Servlet 2.2. Ver Anexo 2. Voz sobre IP a través de TINI 27 - La aplicación Serial2Ethernet (UDP). Es bastante similar a la aplicación diseñada del capítulo anterior, puesto que es la misma pero particularizada para el sistema de VoIP. Una de las diferencias con la aplicación anterior es que ésta trabaja con el protocolo de transporte UDP (User Datagram Protocol). Esto es no orientado a la conexión, una característica de las aplicaciones de voz, en definitiva de las aplicaciones que requieren tiempo real (streaming), ya que no tiene sentido retransmitir paquetes una vez perdidos, como lo hace TCP. Los dos dispositivos TINI correrán la misma aplicación, por lo que se tratan igual ambas partes del sistema. Para saber más sobre UDP en Java y en TINI y sobre servlets y el servidor Tynamo, consultar [3]. 4.2.3. Funcionamiento del sistema Una vez vistas las necesidades requeridas tanto para el cliente como para el servidor, se procede a entrar más en detalle en el sistema diseñado. Se explicará como operan todas las partes del sistema entre sí, con un ejemplo de puesta en marcha de la aplicación y toda una serie de diagramas UML (clases, flujo y secuencia) para entender más a fondo el diseño de la aplicación Serial2Ethernet (UDP). El sistema completo opera de la siguiente manera (ver Figura 4.3): 1. El cliente se autentifica a los servidores (TINI) para poder acceder a la aplicación. 2. El servidor recibe la petición y la manda al contenedor de servlets para la validación. 3. Un servlet comprueba la validez del usuario. 4. El servidor web obtiene la validación del usuario y conforma una respuesta al cliente. 5. El servidor web envía una página web con el menú principal de la aplicación Serial2Ethernet si el usuario es correctamente validado. 6. El cliente recibe la interfaz web de la aplicación que le permitirá configurar, arrancar y parar la aplicación. 7. El cliente ejecuta la operación deseada, en este caso, arrancar la aplicación (una vez configurada) y la envía al servidor web. 8. El servidor atiende la petición. 9. El servidor reenvía la petición al servlet (controlador). 10. Se arranca la aplicación. 11. Se transmiten datos por el puerto RS-232. 12. La aplicación Serial2Ethernet lee datos del puerto serie y los envía directamente por un socket UDP. 13. La aplicación Serial2Ethernet lee datos del socket UDP y los envía directamente por el puerto RS-232. 14. Se reciben datos por el puerto RS-232. La aplicación quedaría en este punto de intercambio de datos RS-232 a Ethernet y viceversa en los números (11, 12, 13 y 14), hasta que se parara la aplicación Serial2Ethernet vía web. En este caso se volvería a 6. 28 Sistema de telemetría vía Ethernet Figura 4.3. Sistema de operación de la aplicación Serial2Ethernet UDP 4.2.4. Aplicación Serial2Ethernet Una vez visto el sistema de operación, se procede a ver en detalle cómo está constituida la aplicación Serial2Ethernet. La aplicación programada para el sistema de VoIP es prácticamente igual que la anterior, pero con la diferencia del modo de transmisión, es decir, se utilizan sockets UDP como protocolo de transporte. Se compone, igualmente, de cinco clases. A la clase de configuración se le cambian los parámetros de TCP por lo de UDP, que son, el puerto UDP y la dirección IP destino y se le añaden los parámetros que indican los límites de llenado y vaciado de los búferes de entrada y salida de datos (SerialCountIn y SerialCountOut, respectivamente). A la clase principal Serial2Ethernet se le quita el funcionamiento TCP, esto era, que creaba un socket y esperaba una petición TCP para empezar el intercambio de datos. Al ser UDP, las clases SerialReader y SerialWriter toman la responsabiblidad de enviar o no los paquetes de datos. La clase SerialReader es la que forma el paquete UDP con el puerto UDP, la dirección IP destino y los datos recibidos almacenados en el búfer de entrada. Cuando el campo de datos tenga el tamaño deseado se enviará automáticamente, sin necesidad de ninguna petición del otro extremo (no orientado a la conexión). Por otro lado, la clase SerialWriter obtendrá los datos del paquete UDP y los enviará por el puerto serie. Voz sobre IP a través de TINI 29 Figura 4.4. Diagrama UML de clases de Serial2Ethernet UDP El diagrama de flujo detallado en la figura 4.5, muestra la intervención de todos los procesos de la aplicación Serial2Ethernet UDP. El primer paso para la puesta en marcha de la aplicación es la autenticación del cliente en el servidor. Si los datos son correctos entra en el menú web de configuración del puerto serie y UDP. Selecciona la configuración adecuada al sensor a conectar al sistema y la envía al servidor. Seguidamente se envía la orden de arranque del conversor S2E y el servidor inicializa los puertos con la configuración pasada por el cliente. Automáticamente, la aplicación está lista para comenzar el intercambio de datos de serie a Ethernet y viceversa. Para un mayor rendimiento de la red (ver 4.4.1) se ha de evitar el byte-banging. Para ello son necesarios búferes, que almacenarán los bytes de entrada que luego se transmitirán en forma de paquetes de un tamaño considerable. Referente a los búferes, los parámetros de la aplicación son cuatro. El tamaño de los búferes (PIC-TINI y TINI-PIC), que serán los mismos, y unos límites de llenado y vaciado de los mismos. Los valores de cada parámetro están justificados en el apartado 4.4.1, por lo que en este punto se explicará cada parámetro con los valores seleccionados como ejemplo, con el objetivo de aclarar aún más la explicación. 30 Sistema de telemetría vía Ethernet En el proceso de llenado (SerialReader), es decir, de PIC a TINI, se configura el parámetro SerialCountIn. Éste valor se corresponde a los bytes que el TINI recibe del PIC. Como para este sistema el PIC envía bloques de 70 bytes al TINI, el búfer se irá llenando a razón de 70 bytes, que será el valor de SerialCountIn hasta llegar al tamaño del búfer que será cuando se transmita el paquete UDP. En el proceso de vaciado (SerialWriter), es decir, de TINI a PIC, se configura el parámetro SerialCountOut. Éste valor se corresponde a los bytes que el TINI envía al PIC. Como para este sistema el TINI envía bloques de 35 bytes al PIC, el búfer se irá vaciando a razón de 35 bytes por el puerto serie, que será el valor de SerialCountOut hasta llegar a vaciarlo completamente que será cuando se reciba otro paquete UDP. En este proceso se considera una cosa muy importante. El TINI no envía 35 bytes al PIC de manera síncrona, sino cuando éste le pide datos. Con este método se evita que en el PIC se produzca un desbordamiento de búfer, ya que es un componente muy limitado en memoria. Para más detalle, ver Anexo 3, donde se muestra un diagrama de secuencia (intervención cronológica) de todas las clases que componen la aplicación. Autenticación Usuario válido? Configuración puerto serie y sockets Comienza Serial2Ethernet Thread Comienzan SerialReader y SerialWriter Threads Espera datos de entrada de usuario y comienza el intercambio de datos STOP SI NO ERROR Serial2Ethernet UDP SerialReader Lee 70 bytes de datos serie y los almacena en buffer Buffer = 1470 bytes? Envía paquete UDP de 1470 bytes de datos NO SI SerialWriter Recibe paquete UDP de 1470 bytes de datos y los almacena en buffer PIC pide datos? Escribe 35 bytes por el puerto serie NO SI Se han enviado por el puerto serie todos los bytes del paquete UDP? NO SI START Figura 4.5. Diagrama de flujo de Serial2Ethernet UDP Voz sobre IP a través de TINI 31 4.3. Circuito de voz en VoIP A continuación se detalla el circuito de voz diseñado: Figura 4.6. Partes del circuito de voz El circuito de voz se compone básicamente de dos grandes bloques: un codec de audio y un microcontrolador PIC. A parte se ha necesitado de un micrófono electret, un altavoz (auriculares) y componentes básicos de electrónica para conjuntar el sistema completo. Figura 4.7. Diagrama de bloques del circuito de voz 4.3.1. Codec CMX639 El codec elegido es el CMX639 PDIP (22 pins) de CML microcircuits [16]. El CMX639 es un codec full-duplex con modulación CVSD (Continuously Variable Slope Delta). Las tasas de datos y de muestreo de reloj se comprenden entre 8 kbps y 128 kbps. Además tiene la posibilidad de que el reloj programable se genere internamente, con la ayuda de un cristal de cuarzo o se conecte uno externo. Para el siguiente proyecto se ha optado por generar el reloj internamente para alcanzar velocidades de 16 y 32 kbps. De esta manera se quiere optimizar el ancho de banda utilizado para voz en la red de transmisión Ethernet. Las funciones del codec son las siguientes: ¾ Codifica la señal de audio analógica según la modulación CVSD en una señal digital síncrona en serie. Se obtienen datos codificados a 8, 16, 32 o 64 kbps. 32 Sistema de telemetría vía Ethernet ¾ Descodifica la señal digital síncrona en una señal de audio analógica. Figura 4.8. Esquemático codec CMX639 Los parámetros de diseño del codec de audio son los siguientes: ¾ Cristal de cuarzo de 1 MHz para general el reloj internamente. ¾ Algoritmo de compresión y expansión de 3 bits. Esto permite reducir los niveles de ruido y de crosstalk en el receptor. ¾ Modo de reloj a: @ f/64 y @ f/32. Tabla 4.1. Modos de reloj del codec CMX639 Clock Mode 1 Clock Mode 2 Tasa reloj Frecuencia cristal a 1 MHz Ejemplo para f = 1 MHz 0 0 Reloj externo Reloj externo 0 1 Reloj interno @ f/16 62,500 Kbps 1 0 Reloj interno @ f/32 31,250 Kbps 1 1 Reloj interno @ f/64 15,625 Kbps 4.3.2. PIC 16F873A El PIC elegido es el 16F873A de 20 MHz de Microchip [15]. Es un microcontrolador de 8 bits RISC (Reduced Instruction Set Computer). Sus características son las siguientes: ¾ Memoria de programa: 4K palabras de 14bits tipo Flash ¾ EEPROM: 128 bytes ¾ RAM: 192 bytes ¾ Líneas E/S digitales: 22 (6 puerto A, 8 Puerto B, 8 Puerto C) ¾ Alimentación (Vdd): entre 2 y 5,5 V. ¾ Frecuencia de trabajo máxima: 20 MHz. Voz sobre IP a través de TINI 33 Las funciones del microcontrolador PIC son las siguientes: ¾ Convertir la salida digital síncrona del codec de audio a RS-232. De esta manera se conectará directamente al TINI, convirtiendo niveles de tensión con el MAX232, para enviar los datos de voz sobre la red de área local ethernet. ¾ Recuperar los datos de RS-232 y enviarlos sincronizadamente al codec de audio para su descodificación en señales analógicas. Figura 4.9. Esquemático PIC 16F873A Para la realización de estas funciones se ha desarrollado un software que se incluirá en el mismo PIC. El código se ha programado en C con el compilador CCS C. Para su traspaso al PIC se ha utilizado el programador TM-A48 Universal Programmer Top Max de EETOOLS. Para entender el funcionamiento del software del PIC se detalla un diagrama de flujo (ver Figura 4.10). Este software se compone de una función principal (main()) y dos interrupciones. Una que se produce cada pulso de reloj en el flanco de bajada (de alto a bajo), #INT_EXT (externa) y la otra que se produce al recibir algún dato por el puerto serie, #INT_RDA. Igual que la aplicación Serial2Ethernet, por el mismo motivo, son necesarios búferes de entrada y salida. En el proceso de llenado (codec a PIC), se almacenan todos los bits recibidos del codec en un búfer, en este caso de 70 bytes. Luego éstos se enviarán por RS-232 hacia el TINI. En el proceso de vaciado (PIC a codec), se almacenan todos los bytes serie recibidos del TINI en un búfer de 35 bytes. Luego éstos se envían bit a bit sincronizadamente al codec. En este proceso, cuando el PIC ha enviado al codec todos los datos que guarda en un búfer de 35 bytes, vuelve a pedir datos al TINI. Como se ha comentado antes, si no se hiciera así podría producirse desbordamiento en el búfer del PIC, ya que éste tiene mucha limitación de memoria. 40 Sistema de telemetría vía Ethernet Figura 4.18. Estructura del campo de datos de la trama Ethernet 4.4.2. Análisis de tiempos a 15625 bps Dicho esto, se pasa a mostrar las velocidades de transmisión de cada bloque y los tiempos concretos que luego se calcularán analíticamente para justificar la transferencia de información en su totalidad en todo el proceso, desde el micrófono hasta el auricular. Sólo se dibuja un sentido de la comunicación, pero el otro es análogo. Figura 4.19. Velocidades y tiempos de cada bloque del sistema de VoIP Voz sobre IP a través de TINI 41 A continuación se mostrará la explicación de los tiempos obtenidos empíricamente y se demostrará analíticamente el correcto funcionamiento del sistema. La gráfica de la figura 4.20, muestra el flujo de bits desde el codec origen hasta el PIC destino. En amarillo están representados los bits que envía el codec origen. Son cada 64 µs, es decir a una velocidad de 15625 bps. En azul están representados bloques de 70 bytes a 115200 bps que envía el PIC al TINI cada 35,84 ms (ida). En fucsia están representados bloques de 35 bytes a 115200 bps que recibe el PIC del TINI (vuelta) cada 17,92 ms. En verde está representado el pin ASK_DATA del PIC, con el cual pide 35 bytes al TINI poniéndolo a 1. Se puede apreciar un cierto retardo desde que el PIC pone este pin a 1, es decir pide 35 bytes al TINI, hasta que le empiezan a llegar. Este retardo es de 2,28 ms. Esto se debe a la programación del TINI en Java, ya que la JVM en un microcontrolador de 8 bits necesita entre 1,7 y 2,3 ms para hacer la lectura de una entrada digital. Figura 4.20. Gráfica de tiempos de las partes más significantes del sistema 64µs clock 35,84 ms 70 bytes 35 bytes 17,92 ms 2,28 ms PIC a TINI TINI a PIC codec a PIC 42 Sistema de telemetría vía Ethernet Se puede comprobar que todos los bytes que envía el PIC al TINI para transmitirlos por la red, le llegan debidamente sincronizados, ya que envía 70 bytes cada 35,84 ms y dentro de este tiempo recibe 2 bloques de 35 bytes previa petición con ASK_DATA. Respecto a los tiempos entre llegadas de paquetes UDP por Ethernet se han obtenido los siguientes resultados. Se han capturado los paquetes UDP de 1470 bytes de datos que envía el TINI por Ethernet. Figura 4.21. Captura de paquetes UDP con Ethereal Se han cogido 18 paquetes consecutivos como muestra para calcular el tiempo medio de llegada entre paquetes UDP de 1470 bytes de un TINI al otro TINI, en condiciones de tráfico real. Tabla 4.2. Cálculo tiempo medio entre paquetes y desviación estándar PAQUETE TIEMPOS DE LLEGADA (s) TIEMPOS ENTRE LLEGADAS (ms) 1 31,734165 2 32,486459 752,294 3 33,239134 4 33,991813 752,679 5 34,744314 6 35,497095 752,781 7 36,249270 8 37,002455 753,185 9 37,754571 10 38,506055 751,484 11 39,258709 12 40,012033 753,324 13 40,764700 14 41,517519 752,819 15 42,270013 16 43,021985 751,972 17 43,774126 18 44,527476 753,35 MEDIA (ms) 752,654 DESVIACIÓN ESTÁNDAR (ms) 0,634712 Voz sobre IP a través de TINI 43 De este modo se puede decir que el tiempo medio entre paquetes es de 752,654 ms. Este tiempo coincide exactamente con el tiempo que tarda el TINI en formar un paquete de 1470 bytes a base de 70 en 70 bytes y enviarlo por la red. 33 1064,7521084,35 70 1470 −− ⋅=⋅× Con todos estos tiempos obtenidos empíricamente, se procede al cálculo analítico de todos los parámetros del sistema para justificar la transferencia de información en su totalidad en todo el proceso, desde el micrófono hasta el auricular. Siguiendo la Figura 4.19, y para ver el número de bytes que salen y llegan se considera una ventana temporal de 752,654 ms (tiempo medio entre paquetes UDP de 1470 bytes de datos) CODEC a PIC Se envían datos a 15625 bps, en 752,654 ms se envían 1470 bytes, 147010654,752 8 15625 3=⋅× − PIC a TINI Se envían y se reciben bloques de 70 bytes a 115200 bps cada 35,84 ms, en 752,654 ms se envían 1470 bytes, 147070 10·84,35 10654,752 3 3 =× ⋅ − − TINI a TINI Se envían paquetes UDP de 1470 bytes de datos y se reciben cada 752,654 ms. TINI a PIC Se envían y se reciben bloques de 35 bytes a 115200 bps cada 17,92 ms, en 752,654 ms se reciben 1470 bytes 147035 10·92,17 10654,752 3 3 =× ⋅ − − 44 Sistema de telemetría vía Ethernet PIC a CODEC Se reciben datos a 15625 bps, en 752,654 ms se reciben 1470 bytes. 156258 10·92,17 35 3=× − Vistos los tiempos perfectamente sincronizadosy el correcto traspaso de bits de un lado hacia el otro, se muestra la calidad de salida para una señal analógica de entrada. Se ha realizado la prueba de introducir al sistema una señal sinusoidal de 500 Hz y este es el resultado (Figura 4.22), una señal sinusoidal bastante aproximada a la de entrada, de la misma frecuencia aunque también puede estar desfasada. Figura 4.22. Señales sinusoidales de entrada y salida del sistema La señal obtenida a la salida es de muy buena calidad, por lo que se puede decir que la reconstrucción ha sido casi perfecta. Se obtienen ciertos retardos en la señal de salida, debido a los búferes del TINI, pero esto no influye en la calidad de la señal. Como el sistema va a transmitir y recibir voz, se han realizado pruebas cogiendo la entrada del micrófono electret y obteniendo la salida con los auriculares. La siguiente gráfica refleja la señal de voz de entrada en azul y la señal de voz de salida en verde. Ésta última, debido al ineficaz sistema de amplificación propuesto contiene la señal de voz en el instante, que se cuela por la alimentación de la etapa de potencia ES-5, debido a que se utiliza un mismo circuito de voz para transmitir y recibir señales y la señal buena que le llega tras haber pasado por todo el sistema. Esta señal llega con un retardo de unos 564 ms, con la red local con tráfico real. Siguiendo el estándar de VoIP, el retardo máximo en un sentido de la comunicación es 150 ms. Este retardo de 564 ms sobrepasa al máximo permitido, pues no se podría considerar éste un sistema de estándar de VoIP. Pero no se ha diseñado con el objetivo de cumplirlo, sino de tratar de enviar voz sobre la red IP. No se descarta en un trabajo futuro tratar de reducir este retardo. IN OUT Voz sobre IP a través de TINI 45 Figura 4.23. Señales de voz de entrada y salida del sistema 4.4.3. Análisis de tiempos a 31250 bps Igual que en el apartado anterior, las señales de la gráfica de la Figura 4.24, son las mismas pero con la diferencia de velocidad del codec. Se incrementa la velocidad de entrada de bits al sistema y se comprueba si es correcto todo el traspaso de información hacia el otro extremo y la calidad de las señales a la salida del sistema. Figura 4.24. Gráfica de tiempos de las partes más significantes del sistema 564 ms IN OUT 70 bytes 35 bytes 12 ms 21,6 ms 4 ms 64µs clock 32µs PIC a TINI TINI a PIC Se acopla señal de entrada (espúreo) 46 Sistema de telemetría vía Ethernet Se puede apreciar que en determinados instantes, todos los bytes que entran al sistema no salen sincronizadamente. Por ejemplo, desde el PIC al TINI se envían 70 bytes y en recepción (desde el TINI al PIC) se aprecia que no llegan ni 35 bytes. En otros muchos instantes, sí. Todo lo que entra, sale correctamente. Todo esto, repercute en los búferes hardware de entrada del TINI, que ha de almacenar esta información que no se envía y que luego produce un retardo en la señal de llegada. Cuantos más bytes almacene, mayor será el retardo. Por todos estos motivos, la calidad de la señal de salida a esta velocidad será peor que a 15625 bps. Para ver el número de bytes que salen y llegan se considera una ventana temporal de 453,6 ms (tiempo medio entre paquetes UDP de 1470 bytes de datos). 33 106,453106,21 70 1470 −− ⋅=⋅× CODEC a PIC Se envían datos a 31250 bps, en 453,6 ms se envían 1771 bytes, lo que excede de los 1470 bytes, por lo que hay información que se pierde. Para que no se perdiera información, el TINI tendría que enviar un paquete UDP cada 376,32 ms, ya que el codec en ese tiempo y a esa velocidad habría enviado 1470 bytes. Esto se produce a causa del PIC, que no envía los bloques de 70 bytes suficientemente rápido. Los debería enviar cada 17,92 ms y no cada 21,6 ms. PIC a TINI Se envían y se reciben bloques de 70 bytes a 115200 bps cada 21,6 ms, en 453,6 ms se envían 1470 bytes, 147070 10·6,21 106,453 3 3 =× ⋅ − − TINI a TINI Se envían paquetes UDP de 1470 bytes de datos y se reciben cada 453,6 ms. TINI a PIC Se envían y se reciben bloques de 35 bytes a 115200 bps en tiempos variables (se puede apreciar observando la señal ASK_DATA). El tiempo mínimo es 12 ms y el máximo 17,6 ms. En 453,6 ms se reciben 1498 ó 902 bytes. El resto de bytes se almacenan en el búfer hardware del propio TINI. El tiempo de envío de Voz sobre IP a través de TINI 47 datos del TINI al PIC debería ser 8,96 ms, por esto se produce un incremento del retardo. 132335 10·12 106,453 3 3 =× ⋅ − − 90235 10·6,17 106,453 3 3 =× ⋅ − − PIC a CODEC Se reciben datos a 23333 bps, en 453,6 ms se reciben 1323 bytes. 233338 10·12 35 3=× − Vistos los tiempos y el traspaso de bits de un lado hacia el otro, se muestra la calidad de salida para una señal analógica de entrada. Se ha realizado la prueba de introducir al sistema una señal sinusoidal de 500 Hz y este es el resultado (Figura 4.25), una señal sinusoidal bastante aproximada a la de entrada en determinados tiempos, de la misma frecuencia aunque también puede estar desfasada. Hay tiempos que la señal de salida no se reconstruye bien debido a la pérdida de información en el sistema. Figura 4.25. Señales sinusoidales de entrada y salida del sistema Como el sistema va a transmitir y recibir voz, se han realizado pruebas cogiendo la entrada del micrófono electret y obteniendo la salida con los auriculares. Como se ha comentado, se obtienen ciertos retardos en la señal de salida, debido a los búferes del TINI. Esta señal llega con un retardo de unos 2,8 s, con la red local con tráfico real. Esto es debido a que el TINI guarda mucha más información en búferes que cuando el sistema funciona a 15625 bps, debido a que funciona más rápido. IN OUT 48 Sistema de telemetría vía Ethernet Figura 4.26. Señales de voz de entrada y salida del sistema 4.4.4. Análisis de tiempos a 62500 bps Igual que en los apartados anteriores, las señales de la gráfica de la Figura 4.27, son las mismas pero con la diferencia de velocidad del codec. Se incrementa la velocidad de entrada de bits al sistema y se comprueba si es correcto todo el traspaso de información hacia el otro extremo y la calidad de las señales a la salida del sistema. Se puede apreciar que en todos los instantes, todos los bytes que entran al sistema no salen sincronizadamente. Por ejemplo, desde el PIC al TINI no se llegan a envíar 70 bytes y en recepción (desde el TINI al PIC) se aprecia que no llegan ni 35 bytes. Todo esto, hace que los datos no lleguen de un extremo al otro y no se pueda reconstruir la señal de entrada. Se ha probado de inyectar señales sinusoidales y de voz al sistema y no se ha obtenido respuesta. Se puede apreciar en los bloques donde debería haber 70 y 35 bytes de la Figura 4.27, hay menos, es decir, ya no se envían correctamente bloques de 70 bytes del PIC al TINI. Esto es debido a que 115200 bps que es la velocidad serie del PIC y del TINI, no es suficiente como para llenar los búferes a tiempo y por este motivo se pierden datos, lo que hace que no se pueda reconstruir la señal de entrada a la salida. 2,8 s IN OUT Se acopla señal de entrada (espúreo) Voz sobre IP a través de TINI 49 Figura 4.27. Gráfica de tiempos de las partes más significantes del sistema 4.4.5. Conclusiones Como conclusión de las pruebas ralizadas, se extrae que la velocidad ideal del codec para el correcto funcionamiento del sistema es 15625 bps. A esta velocidad y con la red Ethernet poco sobrecargada se obtienen unos tiempos estrictamente sincronizados. De este modo las señales de entrada son reconstruidas satisfactoriamente en la salida. Por lo tanto, se afirma que la velocidad de datos máxima del codec es 15625 bps, según reloj de 1MHz. 64µs clock 16µs Casi 35 bytes 12 ms 19,4 ms Casi 70 bytes PIC a TINI TINI a PIC ASK_DATA siempre a 1 56 Sistema de telemetría vía Ethernet Ahora el TINI ya dispone de un entorno de ejecución y el paso siguiente es actualizar la versión tini1.02g a tini1.13. Entrar de nuevo al TINI (con versión 1.02g) [login:root y password:tini]. Configurar los parámetros de red del TINI según se indica en el apartado Configuración de red (más adelante). Cargar los siguientes ficheros LoaderLoader.tini, loaderloader.tlib y tini113- bank0.tbin2 (versión 1.02g) a través de FTP. Una vez cargados los ficheros, ejecutar lo siguiente: java LoaderLoader.tini tini113-bank0to2.tbin Apretar el botón de Reset Anexos 57 Ya se ha instalado el TINI Boot Loader 1.13. Ahora cargar los ficheros slush.tbin y tini113-bank1to6.tbin (de la versión 1.13) con File>Load File. Una vez la carga se ha completado poner en el prompt: BANK 18 y apretar Enter, después FILL 0 y Enter y E y Enter para correr el nuevo firmware. 58 Sistema de telemetría vía Ethernet Aparecerán las siguientes pantallas: Enter para entrar login y password. [login:root y password: tini] Anexos 59 Configuración de red TINI /> ipconfig –a 147.83.113.13 –m 255.255.255.0 (IP y máscara de subred) TINI /> ipconfig –g 147.83.113.1 (gateway) TINI /> ipconfig –p 147.83.117.10 –s 147.83.2.3 (DNS primario y secundario) Con estos parámetros el TINI ya está en red. TINI /> ping www.google.es o desde otro PC en red, ping 147.83.113.13 y se verá que está conectado. Ahora ya se puede acceder al TINI mediante TELNET o FTP (para cargar ficheros o para configurar el TINI en red, sin necesidad de utilizar el JavaKit ni el cable serie). TELNET 60 Sistema de telemetría vía Ethernet FTP Programación clases Para la programación y compilación de las clases de java, se utilizará el IDE eclipse 3.0. Para la realización de ciertas clases (TINI), es necesario la importación de las librerías siguientes: modules.jar y tiniclasses.jar. Esto se hace desde Project>Properties>Java Build Path>Libraries>Add External JARs y seleccionar los JARs anteriores. Una vez programado y compilado, se generará un fichero con extensión .class si no ha dado errores. En este momento seguir las siguientes instrucciones para pasar el fichero .class a .tini (imagen binaria que se puede ejecutar en TINI). Anexos 61 Los ficheros que se han de tener son: tini.jar (indicado en el classpath; contiene la aplicación TINIConvertor), el fichero .class a convertir y el tini.db. Ejemplo de sentencia para convertir el fichero: C:\ java TINIConvertor –f e:\HelloWorld.class –d e:\tini.db –o HelloWorld.tini –i Una vez se tenga el fichero .tini, cargarlo al TINI mediante FTP (por ejemplo). Es recomendado hacer una carpeta que contenga estas aplicaciones. Para ejecutar la aplicación: TINI /aplicaciones> java HelloWorld.tini &. El parámetro & es para que se ejecute en background. Para esta aplicación no hace falta, pero si se ejecuta una de tiempo continuo, se recomienda para poder seguir trabajando. Para ver qué procesos están corriendo en el TINI, hacer: TINI /> ps. Si queremos parar alguno hacer: TINI /> kill (nº proceso). 62 Sistema de telemetría vía Ethernet 2. Instalación Tynamo Web Server (servlets) en TINI http://tynamo.qindesign.com/ ¿Qué se necesita? ¾ ANT 1.6.2 Æ extraer en una carpeta el fichero apache-ant-1.6.2 en C:\ ¾ TiniAnt 1.2.0 Æ TiniAnt.jar ¾ Jakarta Commons/Net (librería) 1.2.2 Æ Commons-net-1.2.2.jar ¾ Tynamo-tini-1.0 (ficheros) Æ extraer donde se quiera (será directorio de trabajo) Aparte de tener instalado j2sdk1.4.2_04 y Tinisdk (1.13) Configuración variables de entorno Inicio> Panel de Control> Sistema>Opciones avanzadas>variables de entorno: Usuario: ANT_HOME Æ C:\apache-ant-1.6.2 (directorio) JAVA_HOME Æ C:\j2sdk1.4.2_04 (directorio; ya incluido antes) Sistema: Path Æ C:\apache-ant-1.6.2\bin (directorio) Configuración ANT Poner TiniAnt.jar y commons-net-1.2.2.jar en C:\apache-ant-1.2.6\lib Dentro de la carpeta creada de tynamo-tini-1.0 -Crear una carpeta “src” Æ donde irán nuestros propios servlets creados -Tocar el fichero “deploy.properties” Ej. deploy.server=147.83.113.13 (IP del TINI donde se hará el deploy del servidor y servlets) deploy.userid=root deploy.password=tini deploy.rootdir=/web startserver.userid=userid startserver.password=passwd startserver.command=source /web/bin/WebServer (commando para poner en marcha el servidor) -Tocar el fichero “build.properties” Ej. tini.path=D:/Usuaris/Ricard Moraleda/TINI/FIRMWARE/tini1.13 Anexos 63 src.paths=C:/Documents and Settings/ricard moraleda/Escritorio/tynamotini-1_0/src src.files=*.java (o el nombre del fichero java a compilar) include.servletReloading=true include.loaderServlet=true reflect.classes=HelloWorld,\TiniInfoServlet,\....(nombre de las clases separadas por ,\) Dentro de la carpeta creada de tynamo-tini-1.0\tini -En la carpeta http-root Æ ubicar los ficheros .html e imágenes a servir. -En la carpeta bin Æ -borrar el fichero webserver.tini que viene por defecto -tocar el fichero “servlets.props” Ej. TiniInfoServlet.mapping=/servlet/TiniInfoServlet TiniInfoServlet.class=TiniInfoServlet HelloWorld.mapping=/servlet/HelloWorld HelloWorld.class=/HelloWorld Para compilar (build) todo el servidor con los servlets propios -Ir a la carpeta root de tynamo-tini-1_0 y poner “ant”. Esto hace lo siguiente: - compila los ficheros de la carpeta “/src” y crea las clases en “/classes” - crea en \tini\bin (carpeta de tynamo) el fichero webserver.tini -Después poner “ant deploy”. Esto hace el volcado de los ficheros del servidor y servlets al TINI (por FTP). Arrancar el servidor del TINI -Mediante telnet acceder al TINI e ir a /web/bin/ y poner “source WebServer”. WebServer es un script que contiene la siguiente sentencia: java /web/bin/webserver.tini /web/bin/webserver.props & -Para que se arranque el servidor nada más arrancar el TINI insertar la siguiente sentencia en el fichero .startup de la carpeta etc de TINI: ######## #Autogen'd slush startup file setenv FTPServer enable setenv TelnetServer enable setenv SerialServer enable ## #Add user calls to setenv here: ## initializeNetwork ######## #Add other user additions here: java /web/bin/webserver.tini /web/bin/webserver.props & -Para ejecutar el servlet desde un navegador web poner en la url: http://<ip tini>/servlet/HelloWorld http://<ip tini>/servlet/TiniInfoServlet 64 Sistema de telemetría vía Ethernet 3. Diagramas secuencia Serial2Ethernet TCP/UDP Este diagrama corresponde a la aplicación Serial2Ethernet sobre TCP. Explica la participación cronológica de cada clase y los parámetros que se pasan de una a otra. Una vez autenticado y devuelta la página web del menú de la aplicación, el usuario introduce la configuración del sistema y la envía al servidor. El servidor mediante un servlet sabrá, según la petición HTTP que clases y métodos instanciar. En este caso creará la instancia de la clase ConfigManager y le pasará los parámetros serie y TCP configurados. Al usuario, una vez hecha la actualización de los parámetros del sistema, le aparecerá una página para poder arrancar la aplicación. Cuando se pulse el botón de START, se crea la instancia de la clase principal y se lanza el thread Serial2Ethernet que a su vez cogerá la instancia de la clase de configuración ConfigManager con los parámetros ya actualizados para poder inicializar los puertos correctamente. Seguidamente se abrirá un socket TCP para poder recibir una conexión de un cliente. Cuando ésta se efectúa, la clase Serial2Ethernet lanza dos threads, SerialReader y SerialWriter, y comienza el intercambio de datos. Después de haber pulsado el botón START, al usuario se le envía una página para poder parar la aplicación. Cuando el usuario pulsa el botón de STOP, se vuelve a coger la instancia de la clase Serial2Ethernet y se llama al método finish(), que cerrará todos los sockets abiertos, eliminará la instancia de la misma clase y se pararán los threads SerialReader y SerialWriter. Anexos 65 Este diagrama corresponde a la aplicación Serial2Ethernet sobre UDP. Explica la participación cronológica de cada clase y los parámetros que se pasan de una a otra. Una vez autenticado y devuelta la página web del menú de la aplicación, el usuario introduce la configuración del sistema y la envía al servidor. El servidor mediante un servlet sabrá, según la petición HTTP que clases y métodos instanciar. En este caso creará la instancia de la clase ConfigManager y le pasará los parámetros serie y UDP configurados. Al usuario, una vez hecha la actualización de los parámetros del sistema, le aparecerá una página para poder arrancar la aplicación. Cuando se pulse el botón de START, se crea la instancia de la clase principal y se lanza el thread Serial2Ethernet que a su vez cogerá la instancia de la clase de configuración ConfigManager con los parámetros ya actualizados para poder inicializar los puertos correctamente. Seguidamente la clase Serial2Ethernet lanza dos threads, SerialReader y SerialWriter, y comienza el intercambio de datos. Después de haber pulsado el botón START, al usuario se le envía una página para poder parar la aplicación. Cuando el usuario pulsa el botón de STOP, se vuelve a coger la instancia de la clase Serial2Ethernet y se llama al método finish(), que eliminará la instancia de la misma clase y se pararán los threads SerialReader y SerialWriter.