ECG por telemetría utilizando tecnología NEST148.206.53.84/tesiuami/UAMI13115.pdf · El ECG tiene...

1

ECG por telemetría utilizando tecnología NEST

Martín García Hernández Matricula 96321185

Asesor: M. en C. Agustín Suárez Fernández

Julio de 2006

2

Tabla de Contenidos Tabla de Contenidos ……………………………………………………………. 2 Lista de Figuras y Tablas …………………………………………………….. 4 Referencias y bibliografía ……………………………………………………..49 Apéndice A ……………………………………………………………………. 61 Capitulo 1. Presentación ……………………………………… 6 1.1 Antecedentes …………………………………………………………….. 6 1.2 Objetivos …………………………………………………………….. 6 1.3 Introducción ……………………………………………………………. 6 1.4 Acerca del ECG …………………………………………………….. 7

1.4.1 Usos del ECG …………………………………………………….. 7 1.4.2 Derivaciones …………………………………………………….. 7 1.4.3 El ECG Normal …………………………………………….. 8

1.3.4.1 El eje Eléctrico …………………………………….. 9 1.3.4.2 Onda P ……………………………………………. 9 1.3.4.3 QRS ……………………………………………………. 9 1.3.4.4 Onda T ……………………………………………. 9 1.3.4.5 Historia …………………………………………….. 9

Capitulo 2. Técnicas de Monitoreo de ECG Existentes …………… 10 2.1 Técnicas inalámbricas …………………………………………….. 10

2.1.2 LifeSync ECG …………………………………………….. 10 2.1.2 Módulo de ECG Bluetooth® …………………………………….. 12 2.1.3 Electrocardiógrafo Inalámbrico Basado En Bluetooth™ …….. 13

Capitulo 3. Tecnología NesT (Hardware) …………………………15 3.1 MPR400 ……………………………………………………………..15 3.2 MPR500 ……………………………………………………………..16 3.3 MIB510 ……………………………………………………………. 17 3.4 Otras Aplicaciones …………………………………………………….. 19

3.4.1 Antecedentes …………………………………………………….. 19 3.4.2 Aplicaciones Actuales ……………………………………...19

3.4.3 Monitoreo Remoto …………………………………….. 21 Capitulo 4. ECG sobre la Plataforma TinyOS Basada en Mica 22 4.1 Diagrama a Bloques del Sistema ……………………………………. 22 4.2 Mica2 y Mica2dot ……………………………………………………. 23

4.2.1 Aplicaciones ……………………………………………………. 23 4.2.2 Características Generales …………………………………….. 23

4.3 Arquitectura del Mica2 ……………………………………………. 24 4.3.1 Diagrama a bloques …………………………………………….. 24

4.4 Arquitectura del Mica2dot …………………………………………….. 25

3

4.4.1 Diagrama a Bloques …………………………………………….. 25 4.5 Entrada de módulos e interfaz Base …………………………………….. 26

4.5.1 Aplicaciones ……………………………………………………. 26 4.5.2 Características Generales MIB510CA ……………………. 26 4.5.3 Diagrama a Bloques …………………………………………….. 27

Capitulo 5. Transmisión y Recepción de un ECG basado en NEST...28 5.1 Arquitectura del Sistema …………………………………………….. 28 5.2 Software ……………………………………………………………. 29

5.2.1 Entorno de Programación …………………………………….. 29 5.2.1.1 Base.sh …………………………………………….. 29 5.2.1.2 Transmisor.sh …………………………………………….. 29 5.2.1.3 Serial.sh …………………………………………….. 30 5.2.1.4 Monitor.sh …………………………………………….. 30

5.2.2 Diseño sobre TinyOS …………………………………………….. 31 5.2.2.1 Programación para Nodo Base …………………….. 31 5.2.2.2.1.1 Compilación y programación para Mica2dot…. 31 5.2.2.2.1.2 Compilación y programación para Mica2…….. 32 5.2.2.2 Programación para Nodo transmisor …………………….. 33

5.2.2.2.1 Aplicación ECG …………………………….. 34 5.2.2.2.2 Componente ECG.nc ……………………... 35 5.2.2.2.2.1 Secciones de ECG.nc ……………... 36

5.2.2.3 Archivos de encabezado …………………………………….. 36 5.3 Programación del despliegue de ECG …………………………….. 37 5.4 Software de Diseño Final …………………………………………….. 40 Capitulo 6. Resultados Preliminares ……………………………….. 41 6.1 Primera Señal de ECG obtenida …………………………………………….. 41 6.2 Faltas en Prueba Preliminar ……………………………………………. 42 6.3 Deducciones de resultados prelimares …………………………………….. 43 Capitulo 7. Diseño Final ……………………………………… 44 7.1 Tarjeta se sensor “virtual” ecgsensor ……………………………………. 44

7.1.1 ECGsensor.nc ………………………….......................................... 45 7.1.2 ECGS.nc …………………………………………………….. 46

7.2 Frecuencia de Muestreo …………………………………………….. 46 7.3 Preescalamiento ……………………………………………………. 47

7.3.1 Consideraciones de Tiempos ……………………………………. 47 7.4 Hardware de diseño final ……………………………………………………. 47

7.4.1 MDA500CA para Mica2dot …………………………………….. 47 7.4.2. DF-9 ADC7 para Mica2 …………………………………….. 48

4

Capitulo 8. Resultados ……………………………………………. 49 8.1 Configuración Mote Mica2dot Transmisor - Mica2dot Receptor ……... 49 8.2 Configuración Mica2 Transmisor - Mica2dot Receptor …………….. 51 8.3 Prueba “in-situ” ……………………………………………………. 54 8.4 Conclusiones …………………………………………………………….. 58 Lista de Figuras Fig. 1 ECG Normal …………………………………………………………….. 7 Fig. 2 La Derivación II .................................................................................. 8 Fig. 3 Etiquetas de ondas e intervalos ……………………………………...8 Fig. 4 Monitor Tx/Rx …………………………………………………………….. 10 Fig. 5 Transmisor - Receptor …………………………………………………….. 10 Fig. 6 Transmisor – Receptor …………………………………………………….. 11 Fig. 7 Módulo de ECG Bluetooth …………………………………………….. 11 Fig. 8 Diagrama de bloques del dispositivo …………………………………….. 13 Fig. 9 Transmisión – Recepción …………………………………………….. 14 Fig. 10 Fotografía de la cara superior e inferior del ECG BT ……………... 14 Fig. 11 MPR400 ó también llamado MICA2 ……………………………... 15 Fig. 12 Conectores Hirose DF-9 …………………………………………….. 15 Fig. 13 MPR500 ó MICA2DOT …………………………………………….. 16 Fig. 14 MIB510 tarjeta de interfaz serial y de programación ……………... 17 Fig. 15 a Volcán Tungurahua …………………………………………….. 21 Fig. 15 b MICA2, utilizado en esta investigación ……………………………... 21 Fig. 16 Implementación del sistema de motes en el volcán …………………….. 21 Fig. 17 Diagrama a bloques del sistema ……………………………………. 22 Fig. 18 MPR400EB (MICA2) ……………………………………………. 24 Fig. 19 Diagrama a Bloques Mica2 …………………………………………….. 25 Fig. 20 MPR500 (MICA2DOT) ……………………………………………. 25 Fig. 21 Diagrama a Bloques Mica2dot ……………………………………. 25 Fig. 22 MIB510 ……………………………………………………………. 26 Fig. 23 Diagrama a Bloques MIB510 …………………………………….. 27 Fig. 24 Arquitectura del sistema ECG …………………………………….. 28 Fig. 25 Base.sh ……………………………………………………………..29 Fig. 26 Transmisor ……………………………………………………………..29 Fig. 27 Serial.sh ……………………………………………………………..30 Fig. 28 SerialForwarder ……………………………………………………..30 Fig. 29 Monitor.sh ……………………………………………………………. 30 Fig. 30 Esquema de dependencias de TOSBase.nc ……………………………... 31 Fig. 31 Pantalla de Compilación y Programación para Mica2 ……………... 31 Fig. 32 Pantalla de Compilación y Programación para Mica2dot …………….. 32 Fig. 33 Compilación y programación de trasmisor para mote Mica2 ………33 Fig. 34 Compilación y programación de trasmisor para mote Mica2dot ………33 Fig. 35 Aplicación ECG …………………………………………………….. 34

5

Fig. 36 Contenido de la carpeta ECG …………………………………….. 35 Fig. 37 Esquemas de dependencias de la aplicación ECG.nc …………….. 35 Fig. 38 carpeta monitor y su contenido …………………………………….. 37 Fig. 39 Despliegue de monitorECG bajo Linux …………………………….. 38 Fig. 40 Despliege de monitorECG bajo Windows XP .................................. 38 Fig. 41 Configuración inicial Mica3 Nodo Transmisor Mica2dot Nodo Base……41 Fig. 42 Aplicación “ECG” en el directorio apps y el Entorno de Programación….41 Fig. 43 Entrada y Salida de la primera Transmisión del ECG …………….. 42 Fig. 44 Detalle de ECG recuperado …………………………………………….. 43 Fig. 45 Tarjeta de sensor virtual “ecgsensor” …………………………….. 44 Fig. 46 contenido de sensorboards/ecgsensor …………………………….. 44 Fig. 47 Esquema de dependencias del componente ECGsensor.nc ……………... 45 Fig. 48 Esquemas de dependencias de ECGS.nc …………………………….. 46 Fig. 49 a. MDA500CA …………………………………………………….. 47 Fig. 49 b. MDA500CA con terminales soldadas …………………………….. 47 Fig. 50 Mica2 con DF-9 Pin ADC7 dedicado …………………………….. 48 Fig. 51 Mica2dot Transmisor - Mica2dot Receptor …………………………….. 49 Fig. 52 Mica2dot Tx - Mica2dot Rx ECG Simulado D-II 30 LPM …………….. 49 Fig. 53 Mica2dot Tx - Mica2dot Rx ECG Simulado D-II 60 LPM …………….. 50 Fig. 54 Mica2dot Tx - Mica2dot Rx ECG Simulado D-II 80 LPM …………….. 50 Fig. 55 Mica2dot Tx - Mica2dot Rx ECG Simulado D-II 90 LPM …………….. 51 Fig. 56 Mica2 Transmisor - Mica2dot Receptor …………………………….. 51 Fig. 57 Mica2 Tx - Mica2dot Rx ECG Simulado D-II 30 LPM …………….. 52 Fig. 58 Mica2 Tx - Mica2dot Rx ECG Simulado D-II 60 LPM …………….. 52 Fig. 59 Mica2 Tx - Mica2dot Rx ECG Simulado D-II 80 LPM …………….. 53 Fig. 60 Mica2 Tx - Mica2dot Rx ECG Simulado D-II 90 LPM ……………... 53 Fig. 61 a. EGC en los Lab. De Ing. Biomédica UAM-I …………………….. 54 Fig. 61 b. Toma de Derivaciones (Lab. De Biomédica UAM-I) ……………... 54 Fig. 62 Derivaciones tomadas en prueba de Laboratorio …………………….. 55 Fig. 63 Señal de ECG ……………………………………………………………. 55 Fig. 64 primera señal tomada ECG Real con interferencias …………………….. 56 Fig. 65 Señal antes de la Transmisión …………………………………….. 56 Fig. 66 Recuperación de la seña de ECG por mica2dot …………………….. 57 Tablas Tabla 1 script’s de programación …………………………………………….. 29 Tabla 2 Programación en NesC ……………………………………………. 34 Tabla 3 Paquetes H ……………………………………………………………. 36 Tabla 4 monitorECG.java ……………………………………………………. 37 Tabla 5 Panel de control de interfaz Java …………………………………….. 39

6

Capitulo. 1 Presentación 1.1 Antecedentes

En el año 2004, se inicio este proyecto de investigación con el propósito de sentar las bases para el desarrollo de una plataforma y así realizar la monitorización de cualquier tipo de parámetro biológico digitalizable (En este caso una señal de ECG) mediante la tecnología sin cables que proporciona NesT. Hoy, retomando esos infortunados intentos, con el apoyo del Departamento de Ingeniería Eléctrica en el área de Instrumentación Biomédica, con la asistencia y asesoría del Maestro en Ciencias Agustín Suárez Fernández, comenzamos a obtener los primeros frutos. 1.2 Objetivos

El objetivo de este proyecto es desarrollar e implementar un electrocardiógrafo inalámbrico de pequeñas dimensiones que permita la monitorización remota de pacientes. Para ello, hemos programado: el mote mica2 y mica2dot para dedicarlos al censado y acondicionamiento de la señal; La conversión analógica/digital; y el procesado de la señal. Las facilidades de transmisión las realizamos utilizando la plataforma proporcionada por NesT 1.3 Introducción

Existe una serie de señales que han de ser supervisadas de forma constante o periódica en los pacientes. Las más comunes son: la señal de concentración de oxígeno en la sangre, presión arterial no invasiva, el electrocardiograma (ECG), entre otras. El electrocardiograma es el registro de los potenciales recogidos en la superficie corporal, originados por la actividad eléctrica del corazón.

La aplicación de nuevas tecnologías inalámbricas, como NesT, hace posible el diseño de dispositivos de alto nivel de integración con estos fines. Se abre así la posibilidad de transmitir las señales de origen biomédico a dispositivos de visualización (pantalla, PDA, PC...) o centros de procesado, sin que se limite la movilidad del paciente.

Tradicionalmente, la monitorización se realiza mediante dispositivos de alto volumen, a los cuales están conectados los pacientes a través de cables. Esto limita en gran medida la movilidad del paciente y por lo tanto su bienestar durante la estancia hospitalaria. Las ventajas en este dispositivo no redundan solo en la eliminación de cables en los dispositivos actuales, sino que abre un abanico para su utilización en nuevos escenarios Al utilizar NesT y la existencia de todos los dispositivos que se implementan con esta tecnología, reduce el coste para desplegar una red con este tipo de dispositivos.

Mediante la comunicación del electrocardiógrafo con terminales móviles MPRXXX, se pueden implementar sistemas en los que el rango de monitorización es elevado, facilitando la monitorización incluso domiciliaria vía Ethernet.

Comentaremos brevemente las características fundamentales de un ECG.

7

1.4 Acerca del ECG

El electrocardiograma (ECG o también EKG , del alemán Elektrokardiogramm) es el gráfico que se obtiene con el electrocardiógrafo para medir la actividad eléctrica del corazón en forma de cinta gráfica continua. Es el instrumento principal de la electrofisiología cardiaca y tiene una función relevante en el cribado y la diagnosis de las enfermedades cardiovasculares.

El sistema de conducción debe transmitir el impulso eléctrico de las aurículas a los ventrículos. Se compone de los siguientes elementos, nodo senoauricular, nodo auriculoventricular y haz de His, con sus ramas derechas e izquierda.

Fig. 1 ECG Normal

1.4.1 Usos de ECG El ECG tiene una amplia gama de usos:

• Determinar si el corazón funciona de manera normal o sufre de anomalías (p. ej.: latidos extra o saltos – arritmia cardiaca).

• Indicar bloqueos coronarios arteriales (durante o después de un ataque cardiaco).

• Se puede utilizar para detectar alteraciones electrolíticas de potasio, calcio, magnesio u otras.

• Permitir detectar de anormalidades conductivas (bloqueo auriculo-ventricular, bloqueo de rama).

• Mostrar la condición física de un paciente durante un test de esfuerzo.

• Suministrar información sobre las condiciones físicas del corazón.

1.4.2 Derivaciones

El ECG se estructura en la medición del potencial eléctrico entre varios puntos corporales. Las derivaciones I, II y III se miden sobre los miembros: I va del brazo derecho al izquierdo, II del brazo derecho a la pierna izquierda y III del brazo izquierdo a la pierna izquierda. A partir de esto se obtiene el punto imaginario V, localizado en el centro del pecho, por encima del corazón. Hay otras nueve derivaciones provienen del potencial entre este punto y las tres derivaciones de los miembros (aVR, aVL y aVF) y las seis derivaciones precordiales (V1-6). Por lo tanto, hay doce derivaciones en total. Cada una registra información de partes concretas del corazón:

8

• Las derivaciones inferiores (I, II y aVF) detectan la actividad eléctrica desde el punto superior de la región inferior (pared) del corazón. Esta es la cúspide del ventrículo izquierdo.

• Las derivaciones laterales (I, aVL, V5 y V6) detectan la actividad eléctrica desde el punto superior de la pared lateral del corazón, que es la pared lateral del ventrículo izquierdo.

• Las derivaciones anteriores, V1 a V6 representan la pared anterior del corazón o la pared frontal del ventrículo izquierdo.

• aVR raramente se utiliza para la información diagnóstica, pero indica si los electrodos se han colocado correctamente en el paciente.

Los electrodos miden la actividad eléctrica media generada por la suma total de la capacidad cardiaca en un momento concreto.

Fig. 2 La Derivación II.

1.4.3 El ECG Normal

El trazado típico de un electrocardiograma registrando un latido cardiaco normal consiste en una onda P, un complejo QRS y una onda T. El Trazado típico de un electrocardiograma registra un latido cardiaco normal, e cual consiste en:

• P=onda P

• PR=segmento PR

• QRS=complejo QRS

• QT= intervalo QT

• ST=segmento ST

• T=onda T.

Fig. 3 Etiquetas de ondas e intervalos

9

1.3.4.1 El eje Eléctrico

El eje eléctrico es la dirección general del impulso a través del corazón. Normalmente se dirige hacia la parte inferior izquierda, aunque se puede desviar a la derecha dependiendo de cada persona.

1.3.4.2 Onda P La onda P es la señal eléctrica que corresponde a la contracción auricular. Ambas aurículas, derecha e izquierda, se contraen simultáneamente.

1.3.4.3 QRS El complejo QRS corresponde a la corriente eléctrica que causa la contracción de los ventrículos derecho e izquierdo, la cual es mucho más potente que la de las aurículas y compete a más masa muscular, produce de este modo, una mayor deflexión en el ECG.

1.3.4.4 Onda T La onda T representa la repolarización de los ventrículos. El complejo QRS oscurece generalmente la onda de repolarización auricular, por lo que la mayoría de las veces no se ve. Eléctricamente, las células del músculo cardiaco son como muelles cargados: un pequeño impulso las dispara, las despolariza y contrae. La recarga del muelle es la repolarización (también llamada potencial de acción).

1.3.4.5 Historia En el siglo XIX se hizo evidente que el corazón generaba electricidad. El primero en aproximarse sistemáticamente a este órgano bajo el punto de vista eléctrico fue Augustus Waller, quien trabajaba en el hospital St. Mary, en Paddington (Londres). En 1911 aún no se desarrollaban suficientes aplicaciones clínicas a su trabajo. El logro llegó cuando Willem Einthoven, que trabajaba en Leiden (Países Bajos), descubrió el galvanómetro de cuerda, mucho más exacto que el galvanómetro capilar que usaba Waller. Einthoven asignó las letras P, Q, R, S y T a las diferentes deflexiones y describió las características electrocardiográficas de gran número de enfermedades cardiovasculares. Recibió el Premio Nobel de Fisiología o Medicina en 1924 por su descubrimiento.

.

10

Capitulo 2. Técnicas de Monitoreo de ECG Existentes

2.1 Técnicas inalámbricas

Existe en el mercado gran cantidad de Electrocardiógrafos disponibles, tanto alambricos como inalámbricos, los cuales utilizan diferentes tecnologías y protocolos disponibles como Bluetooth para hacer la transmisión - recepción. Aquí exploramos algunos de ellos, disponibles ya en el mercado, después haremos algunas comparaciones respecto a la programación y los costos con la tecnología NesT

2.1.1 LifeSync ECG

El sistema sin hilos de LifeSync® ECG tiene una patente, elimina los alambres y los cables que conducen o transportan información entre los pacientes y los monitores de ECG, permitiendo la libertad movimiento a través del hospital. Utilizando un sistema Bluetooth®, el sistema de LifeSync® emplea radios de dos vías para recoger y para transmitir ECG. Presentamos sus tres unidades básicas.

Monitor de transmisor-receptor (Fig. 4)

Se toman en un monitor existente de ECG vía los alambres estándares de ECG. Recibe la respiración y datos de ECG inalámbrico del transmisor-receptor del paciente.

Fig. 4 Monitor Tx/Rx

Transmisor-receptor, paciente (Fig. 5)

Adquiere ECG y datos de la respiración mediante otro sistema llamado LeadWear® y los envía al transmisor -receptor del monitor mediante tecnología Bluetooth®. Este dispositivo se coloca en el brazo del paciente.

Fig. 5 Transmisor - Receptor

11

Electrodos LeadWear® (Fig. 6)

Los electrodos existentes unen de manera directa al sistema LeadWear®. Éste está disponible en tres tamaños para ajustarse a la mayoría de los adultos y de adolescentes.

Fig. 6 Transmisor - Receptor

2.1.2 CORSCIENCE Módulo de ECG Bluetooth® Corscience desarrolló el Módulo Bluetooth de ECG (Fig. 7) que cuenta con tecnología inalámbrica. Se basa en el estándar técnico inalámbrico “Bluetooth”, este dispositivo permite detectar y digitalizar la señal electrocardiográfica en el paciente, para luego transferir la señal digitalizada de manera inalámbrica a cualquier sistema de monitoreo relacionado. Tal sistema de monitoreo solo necesita un receptor inalámbrico que soporte el estándar Bluetooth, así que un simple computador con impresora puede funcionar como sistema de ECG.

Fig. 7 Módulo de ECG Bluetooth

12

Ventajas:

• Señal inalámbrica • Armado con los mejores algoritmos de detección de señal ECG disponibles en el

mercado • Uso de pilas corrientes tipo AA (duración mínima con 500 Hz y 12 canales: de

10 hrs) • Alcance de 25m en transferencia de señales ECG de 3, 6 o 12 canales • Tamaño compacto • Clip desmontable, permite colocar el dispositivo en ropa, cama, etc. • Pantalla integrada con señalización óptica de pulso, recepción telemetría • Señalización acústica

Funciones: Modos de ECG

• 3 – canales de ECG vía cable de 4 pines • 6 – canales de ECG vía cable de 4 pines • 12 – canales de ECG vía cable de 10 pines

Funciones básicas

• Medida continúa de ECG • Calculo de ritmo Cardiaco con señal acústica

Especificaciones Técnicas

• Alimentación con baterías 2 x AA • Consumo de corriente < 200 mA • Resolución: < 2.6 µV/Bit ECG, 18 Bit • Temperatura de operación 0 - 50 oC, < 95% RH • Dimensiones (H x B x T): 100 x 60 x 23 mm • Frecuencia de muestreo por canal de 00 Hz, 500 Hz, opcional 1000 Hz • Ancho de banda de: 0 Hz – 150 Hz • Precio: 2.898,84 € + 16 % IVA

13

2.1.3 Electrocardiógrafo Inalámbrico Basado En Bluetooth™ de la UNIVERSIDAD DE MALAGA Este dispositivo está compuesto por: adquisición y adecuación de la señal, conversión analógico/digital junto con su procesado y transmisión de la misma. Medida de la señal biomédica. Se utilizan cuatro sensores que se sitúan en el tórax del paciente. Con estos los electrodos, se obtienen las tres derivaciones bipolares de las extremidades y las tres monopolares de los miembros. Con seis electrodos más se obtendran las seis derivadas precordiales. La señal es acondicionada eléctricamente, amplificánda por un factor de mil, para su posterior procesado. En la Fig. 8 se muestra su diagrama a bloques.

Fig. 8 Diagrama de bloques del dispositivo

La corriente máxima fue limitada a 13,6µA para un valor de alimentación de 4,5 voltios. El ancho de banda de la señal de electrocardiografía se extiende desde los 0.05 Hz a los 100 Hz. Esto permite utilizar una frecuencia de muestreo de 250 muestras/segundo. Para realizar la digitalización de la señal y su posterior procesado, se utilizo un microcontrolador de bajo consumo (16 bits), el MSP430F149 de Texas Instruments. Dispone de ocho conversores de 12 bits, de los cuales se utilizan cuatro, uno por cada derivada.

14

Transmisión - Recepción (Fig. 9) Una vez digitalizados y procesados los datos correspondientes a las cuatro derivadas, se integra en el electrocardiógrafo la capacidad de comunicación con otros dispositivos BlueTooth estándar. Esto se implementa mediante la utilización de un módulo BlueTooth (cedido por Cetecom™) que transmite los datos agrupados en tramas lógicas.

Fig. 9 Transmisión - Recepción

La comunicación entre el microcontrolador y el módulo BlueTooth se realiza a través de una interfaz serie UART configurado a 57600bps y con datos de 8 bits, uno de parada y sin paridad. Resultados. Como resultado del diseño se obtuvo un electrocardiógrafo (Fig. 10) con un alto nivel de integración (38 x 47 mm), y con una alta capacidad de comunicación inalámbrica (hasta 100m de alcance). El consumo del dispositivo es lo suficientemente bajo (40mA en transmisión) para que con una batería comercial (1000mAhora) tenga una autonomía de 25 horas

Fig. 10 Fotografía de la cara superior e inferior del ECG BT

15

Capitulo 3. Tecnología NEST (Hardware)

3.1 MPR400 o Mica2

La tarjeta MICA2 corresponde al MPR400 (Fig. 11) que utiliza un microcontrolador Atmega 128L de 8 bits, cuenta con un cristal a una frecuencia máxima de 7.3827 MHz, con 128 Kbytes de memoria Flash, 4 Kbytes de memoria SRAM, y 4 Kbytes de memoria EEPROM, tiene un bus SPI y 2 UARTs, además cuenta con 8 canales para convertidores A/D de 10 bits, con un voltaje de operación de 2.7 a 5.5 V.

Fig. 11 MPR400 ó también llamado MICA2.

También cuenta con un radio transceptor a 916 MHz basado en un Chipcon

CC1000 que es un emisor-receptor de UHF diseñado para aplicaciones inalámbricas de muy baja potencia, alrededor de 16 mA para transmisión y 9 mA para recepción, con bandas de frecuencia de 315, 433, 868 y 915 MHz, pero puede ser programado para operar en otras frecuencias en el rango de 300 a 1000 MHz.

Otro aspecto importante de ésta tarjeta es la antena, pues es un componente

fundamental para la recepción-transmisión. Debemos considerar que el radio del MICA2 es capaz de operar en múltiples canales, dentro de la banda prevista de operación. El MPR400 puede operar en dos regiones de frecuencia: 868-870 MHz (hasta 4 canales) y 902-928 MHz (hasta 54 canales). El número real de canales posibles es más alto para todos los motes MICA2. Sin embargo, se recomienda que el espacio entre canales adyacentes deba ser por lo menos de 500 KHz para evitar interferencia entre canales contiguos de modo que se reduce el número de canales disponibles.

También cuenta con una interfaz de conectores, Hirose DF-9 (Fig. 12), de 51

terminales para las tarjetas de sensores (MTS 300) y la de programación (MIB 500). El conector incluye: interfaz para la fuente de voltaje y tierra, control de alimentación de la tarjeta de sensores periféricos, entradas del ADC para lectura de las salidas del sensor, que en nuestro caso las usaremos para ingresar la señal de ECG, también incluye una interfaz para la UART, entre otros.

Fig. 12 Conectores Hirose DF-9

16

El MICA2 tiene una referencia exacta del voltaje que puede ser utilizada para

medir el voltaje de la batería (Vbatt). Los 8 canales ADC del microcontrolador Atmega128 ADC utilizan el voltaje de la batería como escala de referencia, el máximo valor de la escala de voltaje del ADC cambia cuando el voltaje de la batería se modifica. Para calibrar el voltaje de la batería se requiere una referencia externa precisa del voltaje, el MICA2 utiliza un LM4041 para tal motivo, y cuya referencia es de 1.223 volts (Vref), este circuito esta unido al canal 7 del ADC. El MPR400 tiene además 3 leds programables y un puerto JTAG. Como pretendemos que esta unidad básica sea lo más autónoma posible, el consumo de potencia debe ser mínimo. Por lo tanto, la alimentación la proporcionan 2 baterías tipo AA y circuitos adicionales de aumento y regulación de voltaje. 3.2 MPR500 o Mica2dot

La tarjeta MPR500 denominada MICA2DOT, en la Fig. 13 se aprecia el reducido tamaño de la tarjeta, se compone fundamentalmente por los mismos elementos que el MPR400, tales como el microcontrolador Atmega L128, el emisor-receptor Chipcon CC1000 y la memoria flash externa AT45DB041B de 512 Kbytes. La descripción de estos dispositivos es la misma que hicimos para la tarjeta MICA2, salvo que la frecuencia de reloj para el microcontrolador Atmega L128 es de 4 MHz. La longitud de la antena del dispositivo corresponde a la longitud de la tarjeta anterior, pues la frecuencia a la que operan es la misma de 916 MHz, sólo que para esta tarjeta la antena está soldada directamente sin conector de por medio.

Fig. 13 MPR500 ó MICA2DOT

La interfaz para el MPR500 está constituida por una serie de 19 terminales espaciadas alrededor de la circunferencia del MPR500. Representan un subconjunto de las terminales disponibles en el MPR400. En esta interfaz se incluyen un sistema de control de energía, de canales del convertidor AD, de alimentación, de tierra, algunas terminales de entrada-salida (E/S) digital de propósito general y para el puerto de programación serial. En la tabla (1.4) se muestra una breve descripción de cada terminal. En aplicaciones que requieran más terminales de E/S digital, las terminales del ADC pueden volver a configurarse para utilizarlas como entrada-salida digital, pero no ambas.

17

Igual que la tarjeta anterior, el MPR500 cuenta con un sistema para monitorear el nivel de voltaje de la batería. Los 8 canales ADC del microcontrolador Atmega128 utilizan el voltaje de la batería como escala de referencia, el máximo valor de la escala de voltaje del ADC cambia cuando el voltaje de la batería se modifica. Para calibrar el voltaje de la batería se requiere una referencia externa precisa del voltaje (Vref). El MICA2DOT utiliza un diodo Schottky como referencia de voltaje.

El MPR500 también tiene un puerto JTAG como el MPR400 pero, sólo cuenta

con un led programable. La tarjeta fue diseñada para operar con una batería de litio, aunque puede funcionar con cualquier combinación de baterías (AAA, C, D, etc.) con la condición de que la salida esté en el entre 2.7 y 3.3 VDC. Otra manera de alimentar la tarjeta es por medio de la terminal correspondiente (TP6). Las consideraciones de potencia son las mismas que para la tarjeta anterior. 3.3 MIB510 Tarjeta Programadora La plataforma experimental que empleamos fue la MIB510 (Fig. 14), antes de describir este dispositivo es importante tener presente que los dispositivos a programar, en este caso MICA2 y MICA2DOT, no poseen diodos para conmutar entre un voltaje externo y el de la batería, por lo tanto, el interruptor debe estar en off, para el caso del MICA2, mientras que las baterías deben ser retiradas para el MICA2DOT ya que no posee interruptor.

La tarjeta MIB510 es una plataforma multipropósito que sirve de interfaz para los dispositivos MICA2 y MICA2DOT. También suministra energía a los dispositivos con un adaptador de energía externa y proporciona un interfaz para el MOTE con el puerto serial RS-232 y el puerto de la reprogramación.

El MIB510 tiene un sistema procesador (In System Processor, ISP) para

programar los MOTES. El código se descarga al ISP, por el puerto serial, y la ISP programa el código en el mote. El ISP y el mote comparten el mismo puerto serial. El ISP funciona en una velocidad fija de 115 kbaud. El ISP supervisa continuamente los paquetes seriales que entran para encontrar un patrón especial multibyte. Una vez que se detecte este patrón inhabilita la Rx y TX serial del mote y entonces toma el control del puerto serial.

Fig. 14 MIB510 tarjeta de interfaz serial y de programación.

18

El procesador del ISP tiene dos LEDs, el ‘SP PWR’ (verde) y el ‘ISP’ (rojo). El SP PWR se utiliza para indicar el estado del voltaje del MIB510. Si el LED ISP está encendido, el MIB510 tiene control del puerto serial. El LED parpadea cuando se activa el botón de RESET.

El MIB510 tiene conectores para el MICA2 y MICA2DOT, como se puede ver

en la figura (1.4). Para el MICA2 hay otro conector en el lado inferior del MIB510 para adaptarle la tarjeta de sensores. También, se pueden montar tarjetas MICA2DOT con conectores de batería en el lado inferior de la plataforma.

El MIB510 tiene un regulador de voltaje que acepta de 5 a 7 VDC y suministra

un voltaje regulado de 3 VDC a los dispositivos MPR400 y MPR500. La plataforma MIB510 se entrega con un adaptador externo de alimentación, es muy importante no aplicar más de 7 VDC al regulador lineal de la tarjeta por que se puede dañar, se recomienda no usar más que el adaptador proporcionado para la plataforma.

Cuenta, además, con un sistema incorporado para monitorear el nivel de tensión

que inhabilita la reprogramación si el voltaje de la fuente de alimentación es peligrosamente bajo. Cuando existe el voltaje de programación apropiado el led ISP PWR está encendido. Si el voltaje esta por debajo de 2.9 V, el led ISP PWR parpadea e inhabilitará el mote de cualquier transferencia directa de código. Si el voltaje está demasiado abajo del nivel de potencia del ISP entonces el led ISP PWR estará apagado.

19

3.4 Otras Aplicaciones

3.4.1 Antecedentes

En la primavera de 2002, el laboratorio de investigación de Intel en Berkeley, en colaboración con el Colegio del Atlántico en Bar Harbor y la Universidad de California comenzaron en la isla de Great Duck (en la costa norteamericana de Maine) un proyecto que utiliza redes de sensores para monitorear los microclimas y los nidos de un tipo de ave llamada Petrel de las tormentas y conocer, entre otras cuestiones, por qué prefieren ésta isla y no otras. Los investigadores tratan de observar el comportamiento de estos animales sin irrumpir de manera agresiva en su hábitat.

En los jardines botánicos Huntington, en San Marino, California, donde se conservan quince mil especies de plantas raras, investigadores del Laboratorio de Propulsión a Chorro (JPL) de la NASA trabajan con una red de sensores web para controlar el calor, la humedad o el estado del suelo en el que viven las “Cicadias”, un tipo de planta que necesita unas condiciones muy específicas. Cada pocos minutos, los sensores se actualizan entre ellos y envían toda la información a los responsables de las plantas.

3.4.2 Aplicaciones Actuales

La multinacional de los microprocesadores Intel tiene abiertas varias líneas de experimentación, por ejemplo, la creación de sistemas en centros de atención médica para ayudar a pacientes con problemas de memoria y avisarles del momento en que deben alimentarse.

Los investigadores hablan ya de una nueva generación de sensores, capaces de organizarse así mismos y conectarse en red de manera inalámbrica, además podrían generar una revolución similar a la que tuvo la aparición de Internet en los años 70 del siglo pasado. Los expertos aseguran que estos sensores podrían generar redes que vigilarán gran parte del planeta: desde los modelos de compra de la gente hasta los movimientos de personas sospechosas. Si a eso unimos los avances realizados en Inteligencia Artificial, algunos expertos vaticinan que en los próximos cinco años podrían incluso crearse sensores con inteligencia compleja. "La mayoría del tráfico de datos ya no se realizará entre seres humanos, sino entre estas cucarachas de silicio", comenta Bob Metcalfe, investigador de la empresa Ember, con sede en Boston, quien trabaja en el desarrollo de este tipo de sensores.

La Agencia de Proyectos de Investigación Avanzados de Defensa (DARPA), la misma institución dependiente del Departamento de Defensa estadounidense que tuvo un papel determinante en la creación de la red de redes, está apostando por su creación y desarrollo, financiando este tipo de investigaciones. Los investigadores de DARPA trabajan en tecnologías con usos militares aunque, como en el caso de Internet, dichas tecnologías suelen adaptarse posteriormente en la vida civil.

20

En este caso, se trataría de seguir el concepto de "polvo inteligente", una idea desarrollada hace cinco años por investigadores de dicha agencia, que consiste en diseminar en el campo de batalla miles de diminutos sensores conectados por una red inalámbrica. Así, estos sensores controlan los movimientos de las tropas y los vehículos del enemigo sin alertarlos sobe su presencia. Al tratarse de una red autoorganizada e inteligente, los sensores filtran toda la información que reciben antes de enviar los descubrimientos importantes a la base central de operaciones. De esta manera, los mandos militares podrían evitar posibles bajas en sus tropas al detectar, por ejemplo, posibles amenazas de armas químicas o biológicas.

De hecho, el ejército de los Estados Unidos ha experimentado, en la vida real, con estos prototipos. Hace varios años, lanzaron desde un avión a una carretera de la ciudad californiana de Twentynine Palms varios tubos conteniendo entre 10 y 20 de los denominados sensores "Rene", que consiguieron establecer la velocidad y dirección de los vehículos que circulaban a partir de las vibraciones del suelo.

Este tipo de sensores inteligentes, conocidos como "motes", han contado para su creación con la colaboración de la Universidad de California en Berkeley y la empresa Intel, dentro del denominado Centro para la Investigación sobre Tecnología de la Información en Interés de la Sociedad (CITRIS). Los investigadores de este centro persiguen la creación de dispositivos inalámbricos de bajo coste que puedan llegar a ser tan diminutos como un grano de arena.

Para esta tecnología hay proyectos de aplicaciones comerciales, por ejemplo, la empresa York International realiza sistemas de ventilación para más de 60 mil clientes; planea para los próximos cinco años instalar sensores en red en sus aparatos para monitorear automáticamente las temperaturas y enviar los datos a la central. En este sentido, compañías como la cadena de supermercados británicos Tesco o la compañía petrolífera Shell han instalado sistemas de primera generación para controlar y monitorear el estado de los expendedores de gasolina en sus estaciones de servicio.

El tema no consiste sólo en conseguir datos, sino en responder a cuestiones específicas, aun quedan bastantes cuestiones tecnológicas que resolver, como la implantación de estándares de este tipo de sensores inalámbricos. Los investigadores trabajan con distintas frecuencias de radio para que los sensores se identifiquen. También existe el problema de la energía que los hace funcionar, para ello ya se barajan distintas soluciones de tipo solar o cinético, incluso se piensa en el desarrollo de diminutas baterías para estos minúsculos sensores. Y dado que se trata de elementos que utilizan componentes informáticos, la consolidación de un estándar para el software y el hardware de estos sensores se considera también esencial.

21

3.4.3. Monitoreo Remoto Otra aplicación importante, de reciente uso, es la realizada en Julio del 2004, en

la que se realizó una investigación en el Volcán Tungurahua, en el poblado de Baños en Ecuador, con investigadores de Harvard, UNH, IGEPN, y UNC. El volcán estuvo “dormido” alrededor de 80 años y empezaba a despertar; amenazaba con una erupción inminente. La población de Baños fue evacuada por el ejército ecuatoriano, aunque cabe señalar, que dicha erupción nunca ocurrió.

Fig. 15 a Volcán Tungurahua Fig. 15 b MICA2, utilizado en esta investigación

La investigación se hizo con Motes MICA2, la red consistió en cinco nodos; tres de ellos, equipados con un micrófono, construido especialmente para monitorear señales de baja frecuencia emanadas por la ventila volcánica durante erupciones (Fig. 15 b). Se monitoreo durante 54 horas y las señales fueron enviadas alrededor de 9 Km entre el volcán y el observatorio. Los tres motes que colectaron los datos traían un micrófono infrasónico (Panasonic BM-034Y) con su correspondiente circuiteria de amplificación y filtrado. La recepción fue hecha a través de un mote Mica2 colocado en una MIB600. El quinto Mote, fue usado como GPS. La implementación del hardware, se ve en la Fig. 16

Fig. 16 Implementación del sistema de motes en el volcán.

22

Capitulo 4. ECG sobre la Plataforma TinyOS Basada en Mica

En el presente apartado daremos una visión general sobre los diferentes bloques que utilizamos y de los que consta el modelo, indicando sus principales características técnicas. En capítulos posteriores se explicara con detalle la programación de cada uno de ellos. 4.1 Descripción a bloques del sistema

Una visión generalizada es el diseño de los bloques en los que se ha dividido la implementación del electrocardiógrafo y los subsistemas que componen este dispositivo (Fig. 17):

� Nodo Transmisor: MPR400 / MPR500: Se encarga de la recepción y adecuación de la señal que proviene de los electrodos, además se encargan conversión analógico/digital junto con su procesado y transmisión de la misma. Se utiliza uno de los dos motes, ya que están programados para trabajar con el mote que más se adecué, ya sea Mica2 o Mica2dot.

� Nodo Base: MPR400 / MPR500, Encargado de recibir la señal que proviene de

la transmisión. De igual forma que el nodo transmisor, aquí se puede utilizar el mote Mica2 o Mica2dot

� MIB510, Es el que hace la transmisión serial RS-232 entre el mote del Nodo

Base y la PC.

� PC, habilitada con la plataforma de Tinyos y con la interfaz grafica necesaria para la exhibición del ECG en la pantalla.

Fig. 17 Diagrama a bloques del sistema

Nota: Tanto en Nodo Base y en Nodo Transmisor se pueden utilizar ambos Motes, pues esta programado específicamente para elegir entre ambos motes. La configuración que utilizamos fue: Nodo Base: Mote Mica2dot y Nodo Transmisor: Mote Mica2dot; sin embargo se pueden programar los motes en las distintas configuraciones del modelo Transmisor-Base: Mica2-Mica2dot, Mica2dor-Mica2, Mica2-Mica2 y Mica2dot- Mica2dot.

23

Para cada Nodo (Base/Transmisor) utilizamos los módulos radio Procesadores mica llamados “motes”. Todo el sistema fue programado para trabajar con ambos motes Mica2 y mioca2dot (MPR400 y MPR500 respectivamente), mostraremos las características generales, Aplicaciones y funcionalidades. 4.2 Radio Procesadores Mica2 y Mida2dot: 4.2.1 Aplicaciones:

• Redes de sensores inalámbricos. • Seguridad, vigilancia y fuerte protección. • Control del medio ambiente. • Plataforma distribuida. • Telemetría. • Temperatura y control del medio ambiente • Registro de datos remoto • Etiquetar usuarios • Monitoreo de identificadores

4.2.2 Características Generales:

• Este mote pertenece a la tercera generación de módulos que se utilizan para permitir redes de sensores inalámbricos de baja potencia. El mote MICA2 ofrece mejores características que mote original.

• El sistema operativo es distribuido por TinyOS (TOS), mediante un software v1.0 y una plataforma mejorada para las redes de sensores que contiene mejores características que eliminan errores. TinyOS 1.0 es un pequeño sistema operativo de código abierto, software desarrollado por la universidad UC Berkeley el cual soporta gran escala de tarjetas inalámbricas permitiendo al usuario configurar estas redes sensores inalámbricas.

• Reprogramación de forma remota (inalámbrica). • Gran escala de redes inalámbricas (mas de 1000 puntos). • Diseñados específicamente para redes de sensores inalámbricos. • Amplia gama de tarjetas con sensores y adquisición de datos adicionales • Compatibilidad entre motes (MPR500) Mica2dot y (MPR400) Mica2

Los motes MPRxxx se basan en el Atmel ATmega128L. De ATmega128L. Es un

micro controlador de bajo poder, el cual trabaja bajo el sistema operativo TOS que es albergado en una memoria Flash interna. Si usamos TOS y una simple tarjeta MPR podemos lograr configuraciones capaces de funcionar al mismo tiempo con una aplicación de sensor y con el procesado de una red de radio comunicación

MPR series, soportan entradas análogas mediante conectores de expansión, así como interfaces digitales I/O, de I2C, de SPI y de UART, las interfaces facilitan la conexión con una amplia variedad de periféricos externos. Esta característica de expansión permite recibir la señal después de programar específicamente el canal ADC 7 para recibir las muestras adecuadamente de la señal de ECG

24

4.3 Radio Procesador MPR400EB (Fig. 18)

Fig. 18 MPR400EB (MICA2)

• Más de un año de vida útil con la batería AA. • Conector expansor para sensores de luz, temperatura, RH presión barométrica,

acelerómetro Sounder, y otras tarjetas de sensores Crossbow. • 315, 433, 868/916 MHz, 433 MHz o 315 MHz de transmisión - recepción,

multicanal de amplio rango. 4.3.1 Diagrama a bloques (Fig. 19)

Fig. 19 Diagrama a Bloques Mica2

El MICA2 soporta entradas análogas mediante un conector de expansión de 51 pines, así como interfaces digitales I/O, de I2C, de SPI y de UART,

25

4.4 Radio Procesador MPR400 (Fig. 20)

Fig. 20 MPR500 (MICA2DOT)

• Batería accionada con masa baja • Transmisor-Receptor de radio de varios canales de 433, 868/916, y 310 MHz

(compatible con la serie MICA2/MPR4xx) • El Mica2dot es similar al Mica2 excepto por su cuarto de tamaño (25 mm),

permite canales entrada / salida reducidos. Transmisor - receptor multi-canal de rango extenso, 868/916 MHz, 433 MHz o 315 MHz

• Contiene sensor de temperatura, monitor de batería y un LED 4.4.1 Diagrama a Bloques (Fig. 21)

Fig. 21 Diagrama a Bloques Mica2dot

El Mica2dot contiene una placa de expansión de 18 puntos de soldadura, pines para conectar 6 entradas análogas, I/O Digital e interfaz de comunicación serial o UART..

26

4.5 Entrada de módulos e interfaz Base MIB510 (Fig. 22)

Fig. 22 MIB510

• Estación base para redes de sensores inalámbricas • Programación por puerto serial para todas las plataformas de de hardware Mica • Soporta JTAG para eliminar errores de código • Circuito de detección de baja tensión.

4.5.1 Aplicaciones

• Interfaz De Programación • Entrada Serial RS-232 • Conectividad con MICAz, MICA2 y MICA2DOT

4.5.2 Características Generales MI B510CA

• Permite la programación de datos a la red de sensores inalámbricos mediante una PC y otras plataformas estándares de computadora

• Cualquier nodo: Micaz, Mica2 y Mica2dot; puede funcionar como estación base, si está acoplado a la tarjeta de interfaz serial MIB510CA

• Además de la transferencia de datos, el MIB510CA proporciona una interfaz de programación serial RS-232.

• El MIN510 contiene un procesador que programa las tarjetas Micaz, Mica2 y Mica2dot

• Este procesador, también verifica el voltaje que alimenta la tarjeta del MIB510CA e inhabilita la programación si el voltaje no está dentro de los límites requeridos.

• Dispone de dos zócalos de 51 pines conectados entre si, de esta manera permite que dos placas de sensores se unan para supervisar o desarrollar código.

• Compatible con el entorno de Atmel JTAG para el desarrollo del código.

27

4.5.3 Diagrama a Bloques (Fig. 23)

Fig. 23 Diagrama a Bloques MIB510

Especificaciones:

• Interfaz RS-232 • Baud Rates:

o MICAz/MICA2 definidas por el usuario (57.6k típica) o Programación: 115.2k (uisp controlado)

• Interfaz para el Mote

o Conectores: � 51 pines MICAz/MICA2 (2) � 19 pines MICA2DOT

• Indicadores: o LEDs Rojo, Verde, Amarillo Micaz/MICA2

• Interfaz De Programación

o Indicadores: � LED - Conectado a la energía (verde) y programación en marcha

(rojo) • Interruptores:

o Interruptor on./off. para inhabilitar la transmisión serial del mote o Interruptor temporal para resetear el procesador y el mote de

programación • Interfaz Jtag

o Conector de 10 pines macho • Energía

o 5V y 50mA usando la fuente de alimentación externa (incluida en la unidad)

o 3.3-2.7V y 50mA usando las baterías del MICAz/ MICA2.

28

Capitulo 5. Transmisión y Recepción de un ECG basado en NEST 5.1 Arquitectura Del Sistema La arquitectura propuesta para el proyecto ECG, esta compuesta de tres fases: Transmisión, Recepción y Visualización. La Fig. 24 muestra a manera de bloques esta arquitectura

Fig. 24 Arquitectura del sistema ECG

Las partes que integran la arquitectura son: Nodo transmisor.- (Nodo Transmisor) Este nodo es el encargado de hacer el sensado de la señal de ECG, los paquetes a enviar y la transmisión. El programa fuente que realiza estas operaciones y controla el nodo es el código NesC llamado “ECG.nc” Nodo Base.- (Nodo Receptor) Realiza la recepción adecuada de los paquetes enviados por el programa ECG.nc provenientes del nodo transmisor. El código fuente especializado en hacer la recepción es un código incluido en el árbol de TinyOS llamado TOSBase.nc PC.- (Etapa de Visualización) Para poder visualizar los datos del ECG en una interfaz grafica en línea es necesario ejecutar el programa SerialForwarder el cual nos permite leer paquetes de datos desde un puerto serial sobre un puerto de conexión, es decir asocia un puerto de comunicación a un puerto TCP concreto, Es una pasarela entre puertos, si recibo de uno lo envió por el otro y viceversa, Se puede ver como un gateway entre comm y TCP. Una vez teniendo los paquetes se hace el despliegue del ECG en si mediante la aplicación Java: monitorECG.java

29

5.2 Software 5.2.1 Entorno de Programación Antes de iniciar la programación de los motes, el usuario puede elegir la plataforma con la que va a trabajar, esto es posible gracias a cuatro scripts programados en el bash de linux completamente compatibles con el Cygwin para su funcionamiento sobre Windows. La Tabla 1 muestra estos bash.

Tabla 1 scripts de programación Scripts (bash)

base.sh transmisor.sh serial.sh monitor.sh Códigos Fuente en: Apéndice A

5.2.1.1 Base.sh Realiza la compilación y la programación del mote Receptor, se puede elegir entre la plataforma Mica2 y Mica2dot, para llamarlo basta con escribir en el prompt de linux/Cygwin el nombre del bash: sh Base.sh o bien ./Base.sh como se muestra en la Fig. 25. El Programa el cual este bash compila e instala en el mote seleccionado es TOSBase.nc

Fig. 25 Base.sh

5.2.1.2 Transmisor.sh Este script trabaja sobre el Nodo Transmisor, hace la compilación del programa ECG.nc y la programación del mote que se seleccione. De igual forma que para el Base.sh, es suficiente con escribir en la línea de comandos de linux/Cygwin: sh Transmisor.sh o bien ./Transmisor.sh como lo muestra la Fig. 26.

Fig. 26 Transmisor.

30

5.2.1.3 Serial.sh Para poder visualizar en el programa monitor el despliegue del ECG, es necesario inicializar primero la aplicación SerialForwarder. (Fig. 27)

Fig. 27 Serial.sh

SerialForwarder (Fig. 28) ejecutándose en condiciones normales.

Fig. 28 SerialForwarder

5.2.1.4 Monitor.sh El script Monitor.sh, hace invoca y ejecuta el programa monitorECG.java que es la interfase grafica que muestra el despliegue en línea las muestras obtenidas en la trasmisión y recepción del ECG. La figura 29 muestra la ejecución del programa.

Fig. 29 Monitor.sh

31

5.2.2 Diseño sobre TinyOS 5.2.2.1 Programación para Nodo Base

El mote elegido para este propósito se le asigna el número de Nodo “0”, será el nodo base y se encargara de recibir todas las lecturas y paquetes transmitidos por el nodo transmisor. El programa compilado y descargado en los motes es el programa incluido en TinyOS para la recepción TOSBase.nc, el código fuente se incluye en el Apéndice A. en la Fig. 30 se presenta un esquema de correspondencias.

La aplicación TOSBase.nc Recibe los paquetes por la radio, los transmite a través de la UART en ambas direcciones, ya que ECG.nc utiliza la radio para enviar las lecturas tomadas, de esta forma es posible recibir las lecturas de todos los paquetes sin interrupción mientras se este ejecutando el sistema.

Fig. 30 Esquema de dependencias de TOSBase.nc

5.2.2.1.1 Compilación y programación para Mica2dot

Como sabemos se puede programar para mote mica2 y mica2dot como se ve en la Fig. 31, la programación del nodo base para las dos plataformas disponibles se realiza mediante el script base.sh, aquí eligiendo compilación e instalación para mote mica2.

Fig. 31 Pantalla de Compilación y Programación para Mica2

32

Primero Realiza la compilación del archivo TOSBase.nc

Segundo Hace la instalación del programa compilado al mote elegido

5.2.2.1.2 Compilación y programación para Mica2dot El procedimiento es el mismo en caso que se requiera el mote Mica2dot como receptor. Aquí el script de instalación Base.sh con opción 2 (Fig. 32)

Fig. 32 Pantalla de Compilación y Programación para Mica2dot

Primero de hace la compilación del código TOSBase.nc

Segundo se carga el programa compilado en el mote mica2dot

33

5.2.2.2 Programación para Nodo transmisor

Es posible elegir entre que plataforma de Mote se hace la complacían y programación del Nodo Transmisor, esto es posible gracias al script Transmisor.sh, que como ya mencionamos hace el compilado y cargado del componente ECG.nc. Aquí la programación de este componente para el mote Mica2 y Mica2dot respectivamente (Fig.33 y Fig. 34)

Fig. 33 Compilación y programación de trasmisor para mote Mica2

Fig. 34 Compilación y programación de trasmisor para mote Mica2dot

34

El programa central del sistema está programado para este Nodo. El nodo Transmisor se encarga de realizar el sensado de la señal, de empaquetarla y enviarla por RF al mote receptor. Los dos componentes principales para el funcionamiento del ECG están en el lenguaje de programación NesC (Tabla 2). Los componentes y módulos forman parte de la aplicación principal del proyecto cuya fuente se compila y es directamente programado en la memoria Flash del mote seleccionado en el entorno de programación.

Tabla 2 Programacion en NesC Componente ECG.nc ECGsensor.nc ECGS.nc Modulo ECGM.nc ECGsensorM.nc Códigos Fuente

en: Apéndice A El software de NesC se basa en una programación orientada a componentes, esto es, una aplicación se crea ensamblando componentes, por tanto dicho lenguaje proporciona ciertas características necesarias para poder realizar aplicaciones de una forma más cómoda para el programador. 5.2.2.2.1 Aplicación ECG Utilizamos componentes que ofrece de forma intrínseca el sistema operativo (componentes primitivos) y componentes proporcionados por nosotros (componentes complejos). El código fuente del componente principal es el llamado "ECG.mc", que recibe por el canal 7, Terminal TP2 ADC7, la señal de ECG y al mismo tiempo empaqueta y enviar todas las lecturas al mote receptor. Dentro de las aplicaciones de las aplicaciones de TinyOS “apps” se agrego la carpeta ECG con todo su entorno para ser compilada como cualquier aplicación de TinyOS. Fig. 35

Fig. 35 Aplicación ECG

35

Dentro de la Carpeta ECG (Fig. 36), está el componente principal ECG, su módulo ECGM y el archivo H que utiliza para definición de algunas constantes, también se agregaron las carpetas dentro del directorio build (mica2 y mica2dot) que son para hacer la programación del mote a elegir. El archivo Makefile es necesario para la compilación de ECG y ECGM ya que es el que se encarga de ligar los componentes con la tarjeta de sensores virtual que se creo para este fin. Mostramos aquí el contenido del archivo Makefile: COMPONENT=ECG PFLAGS=-I../ECG SENSORBOARD=ecgsensor include ../Makerules

Fig. 36 Contenido de la carpeta ECG

5.2.2.2.2 Componente ECG.nc

ECG.nc sigue la estructura del un programa en NesC, (Implementación, Configuración y Modulo), aquí verificamos cada sección de este componente. En la Fig. 37 se aprecian esquemáticamente las referencias a las conexiones con componentes primitivos y complejos.

Fig. 37 Esquemas de dependencias de la aplicación ECG.nc

36

5.2.2.2.2.1 Secciones de ECG.nc Implementación: se encarga de definir las conexiones que hay entre los diferentes componentes que utiliza nuestra aplicación. El componente ECG en su sección de implementación hace uso de los componentes primitivos siguientes: Main, TimerC, LedsC y GenericComm; y de componentes complejos ECGM y ECGS. Configuración: La semántica de NesC obliga a que este componente este obligatoriamente presente pero solo contendrá algo en el caso en el que se pretenda crear un componente no mediante su implementación de código directa (en la sección Module) sino mediante la composición de otros componentes ya creados, caso que no es el nuestro. “configuration ECG {}” Modulo: Es en la que realmente se programa el comportamiento que se desea realizar en la aplicación, a su vez esta dividida en tres subsecciones: Uses, Provide e Implementation. De Esta forma en la sub sección “uses {}” se definen la interfaz que utilizo. Igualmente en “provides {}” la interfaz que proporciono y en la “implementation{}”. El modulo del componente principal es el que contiene toda la programación en NesC para obtener la frecuencias de muestreo deseadas y que corresponden al ECG, aquí se aumento el pre escalamiento de la toma de muestras en los motes, esto es programado en la siguiente línea del archivo ECGM.nc call Timer.start(TIMER_REPEAT, 16); La referencias a ECG.nc y ECGsensor.nc que están dentro de a carpeta “ecgsensor” las vemos de manera detallada en el Capitulo 7. 5.2.2.3 Archivos de encabezado Archivos tipo H en los cuales están definidas las constantes que se requieren para el desempeño adecuado de los programas en NesC. Los archivos CC1000Cons.h, ADC.h y ADCcontrol.h pertenecen al sistema operativo de Tinyos. En la Tabla 3 se enlistan estos archivos asi como el archivo Osciloscopio.h necesario para definir el tamaño del buffer en el programa principal. Para conseguir la alta tarifa del muestreo, las interfaces a las que hace referencia el programa ECG (CC1000Cons.h, ADC.h y ADCcontrol.h) se han modificado. Sin embargo, la referencia se sigue haciendo de la misma forma predeterminada de TinyOS.

Tabla 3Paquetes H Paquetes tipo (.h) ADC.h CC1000Const.h Osciloscopio.h ADCcontrol.h Códigos fuente en: Apéndice A

37

5.3 Programación del despliegue de ECG Interfase Java. De manera única se programa solo un archivo en Java para al internas grafica y basado en el llamado OscillosopeRF de TinyOS. Este código se llama monitorECG.java (Tabla 4)

Tabla 4 monitorECG.Java Archivo Java monitorECG.java Código Fuente en:

Apéndice A Antes de hacer la inicialización del programa de despliegue del ECG, es necesario ejecutar el programa SerialForwarder con el script serial.sh, este bash va al directorio: /opt/tinyos-1.x/tools/java java net.tinyos.sf.SerialForwarder -comm serial@COM 1:19200

El programa que se encarga de mostrar la grafica en línea de los resultados es el código llamado monitorECG.java escrito en Java y compilado en Red Hat 9. (Fig. 38) Se basa en las librerías de oscilloscopeRF incluidas en TinyOS. Se le invoca mediante el scrtip Monitor.sh que invoca directamente el directorio: /opt/tinyos-1.x/tools/java y es llamado con la instrucción java: net.tinyos.monitor.MonitorECG

Fig. 38 carpeta monitor y su contenido

38

La pantalla completa de esta interfaz corre bajo sistema operativo Linux (Fig. 39) o bien bajo Windows XP. (Fig. 40), aquí se muestra sin ningún tipo de señal.

Fig. 39 Despliegue de monitorECG bajo Linux

Fig. 40 Despliege de monitorECG bajo Windows XP

Enlistaremos de manera breve las principales funciones y características que ofrece esta internas grafica para facilitar el despliegue del ECG.

39

Panel de Control

En el panel de control distinguimos diversos botones de control para la correcta visualización de la grafica de ECG y su manipulación. La Tabla 5 hace una pequeña descripción de algunos de ellos.

Tabla 5 Panel de control de interfaz Java

Con estos dos botones es posible hacer más chicos los intervalos en la escala en x (tiempo) así como aumentarla para una mejor visualización de la grafica

Al igual que para el eje x, es posible mover los intervalos del eje y (voltaje) con estos botones.

Muestra una leyenda en el lado inferior derecho a editar, por default escribe la leyenda “Canal 1 Mote 1”

Muestra la leyenda previamente editada

Limpia el grafico en pantalla

Une los puntos de la grafica del ECG o simplemente grafica los puntos de las muestras tomadas.

Realiza un acomodo en las cuatro direcciones del grafico.

Hace que el grafico se desplace de forma automática hacia la derecha conforme van fluyendo los datos, si se le deshabilita simplemente se quedara con la lectura que se halla tomado y para visualizar todos los datos será necesario navegar con el scroll.

Encabezado en la barra de información con la leyenda *** UAMI *** Despliegue de ECG.

40

5.4 Software de Diseño Final Software: Programación: Códigos: Descripción:

Base.sh Script para la programación del Nodo Receptor, se puede elegir entre Mica2 y Mica2dot

Transmisor.sh Script para la programación del Nodo Transmisor, se puede elegir entre Mica2 y Mica2dot

Serial.sh Script que ejecuta el programa SerialForwarder necesario para el despliegue grafico de ECG.

Entorno de Programación

Script en Shell de Linux

Monitor.sh Script que ejecuta a interfaz grafica en Java para la visualización del ECG.

ECG.nc Implementación del componente principal del ECG.

ECGM.nc Modulo del componente principal..

ECGS.nc Implementación complemento del componente ECGsensor.nc

ECGsensor.nc Implementación del componente « sensor Virtual »

ECGsensorM.nc Modulo del componente ECGsensor.nc

Componentes y Módulos

NesC

ADCcontrol.nc Implementacion del componente ADC

Oscioloscopio.h Paquete de constantes y definiciones del la aplicación principal ECG.nc

ADC.h Paquete de constantes y definiciones del componente ADCcontrol.nc

Paquetes H Encabezados

de C

CC1000Const.h Paquete con constantes y definiciones para el Modulo del CC1000

Archivo de Interfaz

Java monitorECG.java

Programa en Java que realiza la interfaz grafica para la graficación del ECG en línea.

Códigos Fuente de los Archivos en: Apéndice A

41

Capitulo 6. Resultados preliminares 6.1 Primera Señal de ECG obtenida La primera configuración que probamos en primera instancia fue la configuración con mote Mica2 como Nodo Transmisor y el Mica2dot como Nodo Base. (Fig.41)

Fig. 41 Configuración inicial Mica3 Nodo Transmisor Mica2dot Nodo Base

La entrada al mote Mica2 aun no es programada para ésta sénse por algún canal

de ADC, aquí sé está recibiendo la señal por medio a la tarjeta MTS310CA, la señal esta siendo recibida en e lugar que ocupa el sensor de luz, la foto celda fue previamente removida para este fin.

En estos momentos del progreso del proyecto ya ha sido desarrollado el entorno de programación y la Aplicación “ECG” que contiene la programación para el Nodo Transmisor (Fig. 42), y con estos avances obtuvimos la primera señal de ECG mediante un simulador de ECG conectado al mote Mica2 y a un osciloscopio para verificar la entrada de señal. En la Fig. 43 se muestran las señales que se obtuvieron con estas pruebas preliminares.

Fig. 42 Aplicación “ECG” en el directorio apps y el Entorno de Programación

Mica2 Transmisor

Mica2dot Receptor

42

Fig. 43 Entrada y Salida de la primera Transmisión del ECG

En el osciloscopio tenemos la señal de ECG que esta entrando al mote Mica2

(Nodo Trasmisor) y en el monitor de la PC la señal recibiendo el mote mica2dot (Nodo Receptor), transmitida por serial al computador y graficada por la interfaz Java monitorECG.java 6.2 Faltas en Prueba Preliminar

Es evidente que el modulo encargado de la recepción de ECG aun muestra algunas deficiencias, pues la señal presentada es nota con un claro filtrado (parte sombreada Fig. 234) que se repite de manera periódica cada tres pulsos de complejo QRS de ECG. Esta deficiencia en la trasmisión del ECG se debe a varios factores a mencionar:

• Las constantes aun no corresponden a los valores requeridos para el ECG, como mencionamos anteriormente estamos trabajando con una tarjeta de sensores y estos valores están definidos específicamente para el sensado de luz que da una limitante para la toma de muestras constantes, provocando el filtrado que se ve en la parte sombrada de la figura 32.

• El preescalamiento del Timer en el modulo ECGM.nc (call

Timer.start(TIMER_REPEAT, 32) es demasiado alto para la toma de un ECG, teniendo en cuenta el reloj interno del Mica2. (433MHz).

43

• La Frecuencia muestreo definida como 7 en ADC.h correspondiente a 480 µs, frecuencia aun insuficiente para muestrear un ECG que es llamada directamente por la tarjeta sensores dentro del directorio “sensorboards\micasb\ PhotoTemp” .

Una vista más detallada del monitor con el ECG desplegado (Fig. 44) donde se

aprecia más claramente el mal muestreo en la recepción.

Fig. 44 Detalle de ECG recuperado

6.3 Deducciones de resultados prelimares

• Es necesaria una tarjeta de sensores específicamente para muestrear el ECG.

• Para muestrear un ECG es necesaria una frecuencia de muestro mínima de 300 µs neta y de esta forma no perder muestra alguna.

• El preescalamiento del Timer es necesario dejarlo en 16 repeticiones.

44

Capitulo 7. Diseño Final 7.1 Tarjeta se sensor “virtual” ecgsensor

Al saber necesario una tarjeta de sensores específicamente para muestrear el ECG se realizo la programación de una tarjeta de sensor “virtual” de ECG llamada “ecgsensor” dentro del directorio /opt/tinyos-1.x/tos/sensorboards del árbol de TinyOS (Fig. 45) y que es la carpeta contenedora de todas las tarjetas de sensores que soportan las plataformas Mica2 y Mica2dot.

Fig. 45 Tarjeta de sensor virtual “ecgsensor”

Dentro de esta tarjeta de sensor se encuentran los componentes programados

para este fin y que son utilizados por el programa y componente principal del proyecto ECG.nc desde el cual son llamados por el MakeFile. La tarjeta de sensor se compone de dos componentes y de un modulo. ECGS.nc, ECGsensor.nc y ECGsensorM.nc (Fig. 46).

Es posible ahora recibir por el canal 7 del ADC. Con el componente ECGSensorM.nc y con ECGSensor.nc, los cuales son el cuerpo de la tarjeta de sensores virtual similar a la micasb cuyo sensor de luz es leído por la aplicación OscilloscopeRF. En nuestro caso creamos esta tarjeta de sensores “Virtual” que es leida por a aplicación ECG.nc

Fig. 46 contenido de sensorboards/ecgsensor

45

7.1.1 ECGsensor.nc

Se encuentra dentro de la carpeta de sensores “ecgsensor” y aquí es donde se programa el puerto ADC a censar, en nuestro caso programamos para que reciba de manera constante por el canal 7 Terminal TP2 ADC7 de la tarjeta de adquisición MDA500CA. En la Fig. 47 se muestran todas sus correspondencias de este componente.

Fig. 47 Esquema de dependencias del componente ECGsensor.nc

En la implementación de este componente es donde se manda a llamar

directamente el puerto a sensar. ECGSensor.nc Implementation {

ECGsensorM.InternalECGSADC -> ADCC.ADC[7]; // PUERTO ADC A SENSAR CANAL 7

} Este valor es controlado por el ADC pero es llamado por medio del modulo de éste componente (ECGsensorM.nc) en el cual es donde se logra la alta frecuencia de muestreo necesaria para tomar la señal de un ECG. Mostramos aquí parte de esta implementacion. ECGSensorM.nc Implementation {

// ADCControl.bindPort(Puerto del ADC, Puerto Real del ADC) call ADCControl.bindPort(7,7); // Canal ADC 7 // Implementamos la Frecuencia de Muestreo desde e l ADCControl

call ADCControl.setSamplingRate(TOS_ADCSample1920us );

}

46

7.1.2 ECGS.nc

Otra dependencias del modulo de ECG.nc es la que hace mediante el archivo H por medio de ADC.h que va directamente a ECGS.nc. Este es el componente principal de la tarjeta de sensores “virtual” ecgsensor y que directamente llama a ECGsensor.nc. Aquí las dependencias de ECGS.nc (Fig. 48)

Fig. 48 Esquemas de dependencias de ECGS.nc

ECGS.nc hace referencia directa de ECGsensor.nc que es el encargado de tomar

las muestras correspondientes a una determinada frecuencia. 7.2 Frecuencia de Muestreo y sincronización del ADC

Una modificación importante al archivo ADC.h, el cual controla el Sampling Rate, es decir el intervalo de muestreo del canal ADC del mote, consiste en agregar un par de constantes a la frecuencia de muestro y se muestra a continuación:

enum { TOS_ADCSample3750ns = 0, TOS_ADCSample7500ns = 1, TOS_ADCSample15us = 2, TOS_ADCSample30us = 3, TOS_ADCSample60us = 4, TOS_ADCSample120us = 5, TOS_ADCSample240us = 6, TOS_ADCSample480us = 7, TOS_ADCSample960us = 8, TOS_ADCSample1920us = 9 };

Al agregar estas dos líneas, aumentamos la frecuencia de muestreo del mote, con

esto es posible recuperar la señal del ECG con precisión.

47

7.3 Preescalamiento

En el modulo del componente principal es donde se hace referencia al preescalamiento del Timer en este caso el Timer quedo de la siguiente forma

ECGM.nc Implementation { call Timer.start(TIMER_REPEAT, 16); // Preescala miento del Timer 16

} 7.3.1 Consideraciones de Tiempos

Se programó el archivo CC1000Const.h, el cual maneja todas las constantes involucradas con la transmisión y recepción a través de la UART al compilar los archivos, modificando la línea correspondiente a la frecuencia a la que trabajarían los motes. La línea modificada de dicho archivo, es:

#define CC1K_DEF_PRESET (CC1K_914_077_MHZ)

7.4 Hardware de diseño final 7.4.1 MDA500CA para Mica2dot

Sobre la tarjeta de propósito general MDA500CA (Fig. 49 a) a la cual se le programo la tarjeta se sensores virtual “ecgsensor” para la plataforma Mica2dot y teniendo en cuenta el sensado por e canal ADC7 y una referencia a tierra se llego a la siguiente configuración de software. (Fig. 49 b).

Fig. 49 a. MDA500CA Fig. 49 b. MDA500CA con terminales soldadas

48

7.4.2. DF-9 ADC7 para Mica2

Para la plataforma Mica2 no se requirió de tarjeta de sensores adicional, ya que esta posee un puerto de Conectores Hirose DF-9 y en el pin correspondiente a la terminal ADC7 se le coloco un conector soldado (Fig. 50) así como su referencia a tierra.

Fig. 50 Mica2 con DF-9 Pin ADC7 dedicado

49

Capitulo 8. Resultados 8.1 Configuración Mote Mica2dot Transmisor - Mica2dot Receptor

La primera configuración tomada con la que se realizaron las pruebas de ECG simulado es: el Mote Mica2dot de en el Nodo Transmisor y e Mote Mica2dot en el Nodo Receptor (Fig. 51).

Fig. 51 Mica2dot Transmisor - Mica2dot Receptor

Se realizaron tres situaciones a distintos latidos por minuto (LPM) de la

derivación D-II, se muestra aquí el RITMO SINUSAL REGULAR que es el ritmo más común en el adulto con pulsaciones entre 60-100 LPM. El complejo QRS es casi siempre estrecho y la onda P es positiva en la derivación-2. Se hicieron simulaciones para 30 LPM (Fig. 52), 60 LPM (Fig. 53), 80 LPM (Fig. 54) y 90 LPM (Fig. 55).

Fig. 52 Mica2dot Transmisión - Mica2dot Recepción ECG Simulado D-II 30 LPM

50



51


8.2 Configuración Mica2 Transmisor - Mica2dot Receptor

Como los programas de instalación y compilación de los componentes a los Nodos son multiplataforma (Mica2 y Mica2dot) aquí la siguiente configuración tomada: como Nodo Transmisor e Mote Mica2 y como Nodo Receptor e Mote Mica2dot (Fig. 56)

Fig. 56 Mica2 Transmisor - Mica2dot Receptor

De igual forma que en la configuración anterior mostramos el ritmo sinusal

regular de la derivación D-II a 30 LPM (Fig. 57), 60 LPM (Fig. 58), 80 LPM (Fig. 59) y 90 LPM (Fig. 60).

52

Fig. 57 Mica2 Transmisión - Mica2dot Recepción ECG Simulado D-II 30 LPM


53



54

8.3 Prueba “in-situ”

Después de realizar las situaciones con las dos configuraciones anteriores, elegimos la configuración formada por Mote Mica2dot Transmisor - Mica2dot Receptor que es la que mostró mejor rendimiento en cuando a frecuencias altas. Con esta configuración realizamos un ECG (Fig. 61 a y b) en los laboratorios de ingeniería Biomédica de la Universidad Autónoma Metropolitana Iztapapala.

Fig. 61 a. EGC en los Lab. De Ing. Biomédica UAM-I

Fig. 61 b. Toma de Derivaciones (Lab. De Biomédica UAM-I)

55

El ECG resultante de esta prueba se muestra en el monitor del aparato de ECG de los laboratorios de Ingeniería Biomédica del departamento de ingeniería eléctrica de la Universidad Autónoma Metropolitana Iztapalapa. En la Fig. 62 se muestra un detalle de las tres derivaciones tomadas en esta prueba.

Fig. 62 Derivaciones tomadas en prueba de Laboratorio

|Esta seña además de ser tomada y mostrada en el monitor del ECG del laboratorio, es llevada a un osciloscopio (Fig. 63) para hacer la comparación y transmisión de ECG por telemetría por medio de los dispositivos con motes ya presentados.

Fig. 63 Señal de ECG

56

Aquí presentamos a primera transmisión de la seña de ECG en un perímetro de 10 metros con la configuración Mica2 de Transmisor y Mica2dot de receptor. (Fig. 64) se ve claramente en esta imagen la enorme interferencia con la que la señal es contaminada.

Fig. 64 primera señal tomada ECG Real con interferencias

Realizamos la siguiente configuración y eliminamos algunas posibles fuentes de interferencia como los aparatos propios del laboratorio y probamos con a siguiente configuración de motes del sistema: Mica2dot en Nodo Transmisor y Mica2dot en Nodo Receptor, así la señal antes de a transmisión se muestra en la Fig. 65

Fig. 65 Señal antes de la Transmisión

57

Con esta configuración y eliminando las fuentes de interferencia, se logro recuperar una señal optima, casi sin ruido y casi con exactitud igual a la seña antes de ser transmitida. Fig. 66

Fig. 66 Recuperación de la seña de ECG por mica2dot

De esta forma se esta comprobando la efectividad y la viabilidad de hacer a telemetría de ECG por estos motes, ya que la señal recuperada ya no muestra casi interferencia ni inconvenientes con el muestreo.

58

8.4 Conclusiones

• La transmisión y recepción de señales electrocardiográficas mediante tecnología NEST, es viable.

• La esencia de la tecnología NEST es tener un gran número de sensores que

formen una red local que se conecte al red Internet, esto permite el monitoreo de diferentes señales en forma muy remota.

• La transmisión y recepción de señales de ECG mediante tecnología NEST, da

amplias posibilidades para la transmisión y recepción de señales de interés clínico.

• El hecho de utilizar una red de sensores, permite compensar la baja potencia y

por lo tanto, alcance de la transmisión recepción de las señales de interés.

• La posibilidad de obtener datos clínicos en forma remota, es muy favorecida por el empleo de esta tecnología.

• Los niveles de voltaje que emplean los componentes de la tecnología NEST, no

representan ningún riesgo eléctrico para el paciente.

59

Referencias y Bibliografía

1. Crossbow. MTS/MDA Sensor and Data Adquisiction Boards User’s Manual. Rev. A, April 2004. Document. 7430-0020-03.

2. Crossbow. MPR – Mote Processor Radio Board MIB- Mote

Interface/Programing Board, User’s Manual. Rev. A, August, 2004Document. 7430-0021-06

3. Crossbow, Tinyos Getting started guide. Rev. B, August 2004 Document,

7430-0022-05.

4. Hernández, S., Marcos, Lima, C. David. Evaluación de la Tecnología NEST. Reporte de Proyecto , División de Ciencias Básicas E Ingeniería UAM-Iztapalapa, 2004.

5. Malan, D., Welsh, M., Fulford-Jones, T, División de Ingeniería y Ciencias

Aplicadas, Universidad de Harvard.

6. Oppenheim, A.V., Willsky, A. Señales y Sistemas. Segunda edición. Editorial Prentice Hall.

7. Mainwaring, A., Polastre, J., Szewczyck R., Culler, E.D., Anderson J. Wireless

Sensor Networks for Habitat Monitoring.

8. Gay, D., Levis, P., Von Behren, R., Welsh, M., Brewer, E., Culler, D. The nesC Language: A Holistic Approach to Networked Embedded Systems.

9. Chen, B., Jamieson, H., Balakrishnan, H, Morris, S. SPAN: An energy-efficient

coordination algorithm for topology maintenance in ad hoc wireless networks. Proceeedings of the 7th ACM Internacional Conference on Mobile Computing and Nteworking. 85- 96. Rome Italy, July 2001.

10. Hill, J., Culler, E.D. A wireless embedded sensor architecture for system level

optimization. In UC Berkeley Technical Report, 2002. [6] Cerpa, A., Elson, D., Girod, M., Hamilton, M., Zhao, J. Habitat Monitoring: Application driver for wireless communications technology. 2001 ACM SIGCOMM Workshop on Data Communications in Latin America and the Caribbean. San José Costa Rica. 2001.

11. Estrin, D., Girod, L., Pottie, G., Sristava, M. Instrumenting the world with

wireless sensors networks. Conference on Acoustics Speech, and Signal Processing (ICAASSP 2001), Salt Lake City, UT. 2001.

12. Estrin, D., Govindan, R. Heidemann, J. Kumar S. Next century challenges:

Scalable coordination in sensor networks. In Mobile Computing and networking. 263- 270. 1999.

60

Fuentes de Internet:

13. http://www.xbow.com/

14. http://www.tinyos.net/

15. http://www.eecs.harvard.edu/~mdw/proj/codeblue/

16. http://www.eecs.harvard.edu/~werner/projects/volcano/

17. Fall, K. Delay-tolerant networking for extreme enviroment. http://www.cs.berkeley.edu/kfall/extreme-talk.pdf. Nov. 2001. Presentation at USD.

61

Apéndice A 1. Entorno de Programación …………………………………………………… 61

1.1 Base.sh ……………………………………………………………..61 1.2 Transmisor.sh ……………………………………………………. 64 1.2 Serial.sh ……………………………………………………………. 66 1.2 Monitor.sh ……………………………………………………. 67

2. Componentes y Módulos …………………………………………………….. 68

2.1 ECG.nc …………………………………………………………….. 68 2.2 ECGM.nc ……………………………………………………………. 69 2.3 ECGS.nc ……………………………………………………………. 72 2.4 ECGsensor.nc ……………………………………………………. 73 2.5 ECGsensorM.nc ……………………………………………………. 74 2.6 ADCcontrol.nc …………………………………………………….. 77

3. Paquetes H …………………………………………………………………….. 79

3.1 Oscioloscopio.h …………………………………………………….. 79 3.2 ADC.h ……………………………………………………………. 80 3.3 CC1000Const.h ……………………………………………………. 81

4. Archivo de Interfaz Java …………………………………………………….. 91

4.1 monitorECG.java …………………………………………………….. 91 1 Entorno de Programación

1.1 Base.sh #!/bin/bash # Script Base.sh # realiza la compilación y la carga del programa TO SBase.nc # en el Mote Seleccionado. # Programado en el Shell de Linux # Por: Martín García Hernández echo " " echo " PROYECTO ECG UAMI" echo " ====================== ===" echo " " echo " [1] COMPILAR E INSTALAR BASE PARA MICA2 (MPR400)" echo " [2] COMPILAR E INSTALAR BASE PARA MICA2DOT (MPR500)"

62

echo " [ ENTER PARA SALIR ]" echo Elige opción read entrada case $entrada in 1) echo "" echo " ###" echo " ###" echo " ###" echo " ###" echo " ###" echo " ###" echo " ###" echo " ###" echo " ### Instalacon de TOSBas e en nodo 0 para mote: mica2" echo " ###" echo " ### Proyect o ECG *** UAMI ***" echo " ###" echo " ### mica2 (MPR400) en -> TARJET A DE INTERFACE SERIAL (MIB510)" echo " ###" echo " ### .## /# " echo " ### ##############- " echo " ### #@####@@#######. " echo " ####. /#####@@@@@@@#######. " echo " ############@@@@@@@########. " echo " @###############@@@@@@@@######### " echo " ################@@@#@@@@########## " echo " ###### ########@@@@@@@############," echo " ##### ############@######////####" echo " ########################////########" echo "-###################/////###########" echo "#################///##############" echo "#############////####################" echo "#########////########################" echo ".####################################" echo " ################################@@##" echo " #############################@HH### " echo " #########################@HHHH#### " echo " ####### ###############HHHH##### " echo " # -#################@#@########/ " echo " # #### ########@H########### " echo " # ##########@HHH########; " echo " # ### #@@@HHH######: " echo " ## ##@@@@HH######. " echo " ##@#@####### " echo " -########/ " echo " #####/ " echo " " echo " " cd /opt/tinyos-1.x/apps/TOSBase echo " Compilando ........" PFLAGS=-DCC1K_MANUAL_FREQ=914077000 make mica2 echo " " echo " COMPILACION CONCLUIDA" date ECHO " Instalando ......."

63

MIB510=/dev/ttyS0 make mica2 install echo " FIN DEL PROCESO" date ;; 2) echo "" cd /opt/tinyos-1.x/apps/TOSBase echo " ##" echo " ##" echo " ## Instalaco n de TOSBase " echo " ## en nodo 0 para mote: mica2dot" echo " ## Proyecto ECG *** UAMI ***" echo " ##" echo " ## mica2dot ( MPR500)en -> (MIB510)" echo " ## " echo " ## " echo " ## ## " echo " ########## ## " echo " ### ##### #### ## " echo " #######@@@@## ## ## " echo " ### ####@@@@###### ## " echo " ########@@###### #### " echo " ##################### " echo " ### ############### ## " echo " ###################### " echo " ####### ## ### " echo " #######Crossbow## ### " echo " ####### 433 ######## " echo " ## #### MHz ## ### " echo " ###################### " echo " ###################### " echo " ### #####@@@@@@@@ ## # " echo " #################### " echo " ################# ## " echo " ### ############## " echo " ############# ## " echo " ############## " echo " ####### ## " echo " ##### " echo " " echo " Compilando ........" PFLAGS=-DCC1K_MANUAL_FREQ=914077000 make mica2dot echo " " echo " COMPILACION CONCLUIDA" date ECHO " Instalando ......." MIB510=/dev/ttyS0 make mica2dot install echo " FIN DEL PROCESO" date ;; esac

64

1.2 Transmisor.sh #!/bin/bash # Script Transmisor.sh # realiza la compilación y la carga del programa EC G.nc en el # Mote Seleccionado. # Programado en el Shell de Linux # Por: Martín García Hernández echo " " echo " PROYECTO ECG UAMI" echo " =========================" echo " " echo " [1] COMPILAR E INSTALAR ECG-TRANSMISOR PARA MICA2" echo " [2] COMPILAR E INSTALAR ECG-TRANSMISORB ASE PARA MICA2DOT" echo " [CUALQUIER TECLA PARA SALIR]" echo Elige opción read entrada case $entrada in 1) echo " " echo " Instalacon de OscilloscopeRF en mote: Mica 2" echo " " echo " Proyecto ECG *** UAMI *** " echo " " cd /opt/tinyos-1.x/apps/ECG echo " " echo "Compilando......." PFLAGS=-DCC1K_MANUAL_FREQ=914077000 make mica2 echo " " echo "Compilacion completa" echo "Instalando......" MIB510=/dev/ttyS0 make mica2 install echo " FIN DE PROCESO" date ;; 2) echo " " echo "Instalacon de OscilloscopeRF en mote: mica2do t" echo " " echo " Proyecto ECG *** UAMI *** " echo " " cd /opt/tinyos-1.x/apps/ECG PFLAGS=-DCC1K_MANUAL_FREQ=914077000 make mica2dot echo " " echo "Compilacion completa" echo "Instalando......" MIB510=/dev/ttyS0 make mica2dot install

65

echo " FIN DEL PROCESO" date ;; esac

66

1.3 Serial.sh #!/bin/bash # Script Transmisor.sh # Este script Abre el SerialForwardder # Programado en el Shell de Linux # Por: Martín García Hernández cd /opt/tinyos-1.x/tools/java echo " " echo " *** Se esta ejecutando SerialForwarder ***" echo " " echo " BaudRate: 19200 Port: 9001" echo " " echo " Proyecto ECG *** UAMI **" echo " " echo " Precione Crt + C para Terminar" java net.tinyos.sf.SerialForwarder -comm serial@COM 1:19200

67

1.4 Monitor.sh #!/bin/bash # Script Transmisor.sh # Este script Abre el Monitor de JAVA # Programado en el Shell de Linux # Por: Martín García Hernández cd /opt/tinyos-1.x/tools/java echo " " echo "Se esta ejecutando *** MonitorECG ***" echo " " echo "Proyecto ECG *** UAMI **" echo " " echo "Precione Crt + C para Terminar" java net.tinyos.oscope.monitorECG

68

2. Componentes y Modulos

2.1 ECG.nc // $Id: ECG.nc 17/03/2006 Componente ECG (Configu racion e Implementaciòn del Componente ECG) /* * UNIVERSIDAD AUTONOMA METROPOLITANA - IZTAPALAPA * Av. San Rafael Atlixco N° 186 * Col. Vicentina C.P. 09340 * Iztapalapa, México D.F. * Tel. 01(55)58044600 Ext. 2045 * PROYECTO TERMINAL DE INGENIERIA EN ELECTRONICA Y COMUNICACIONES */ /* Autor: Martino Garcia Hernandez * Asesor: M. en C. Agustin Suarez F. * UAM-I * Ultima modificaciòn: 05/04/2006 */ includes Osciloscopio; configuration ECG { } implementation { components Main, ECGM, TimerC, LedsC, ECGS, Gener icComm as Comm; Main.StdControl -> ECGM; Main.StdControl -> TimerC; ECGM.Timer -> TimerC.Timer[unique("Timer")]; ECGM.Leds -> LedsC; ECGM.SensorControl -> ECGS; ECGM.ADC -> ECGS; ECGM.CommControl -> Comm; ECGM.ResetCounterMsg -> Comm.ReceiveMsg[AM_OSCOPE RESETMSG]; ECGM.DataMsg -> Comm.SendMsg[AM_OSCOPEMSG]; }

69

2.2 ECGM.nc // $Id: ECGM.nc 17/03/2006 Componente ECG (Modulo ) /** * UNIVERSIDAD AUTONOMA METROPOLITANA - IZTAPALAPA * Av. San Rafael Atlixco N° 186 * Col. Vicentina C.P. 09340 * Iztapalapa, México D.F. * Tel. 01(55)58044600 Ext. 2045 * PROYECTO TERMINAL DE INGENIERIA EN ELECTRONICA Y COMUNICACIONES */ /* Autor: Martino Garcia Hernandez * Asesor: M. en C. Agustin Suarez F. * UAM-I * Ultima modificaciòn: 05/04/2006 */ includes Osciloscopio; /** * Este Modulo Implementa el componente ECG * toma las lecturas de ECGsensor y las envia * de manera periodica sobre la UART. * Buffer_SIZE define el numero de lecturas * enviadas en un solo paquete (BUFFER_SIZE=10) * y esta definico en el la libreria Osciloscopio.h * el LED amarillo destella cada que un nuevo paque te es enviado * y el LED rojo cada que la lectura esta en un val or constante */ module ECGM { provides interface StdControl; uses { interface Timer; interface Leds; interface StdControl as SensorControl; interface ADC; interface StdControl as CommControl; interface SendMsg as DataMsg; interface ReceiveMsg as ResetCounterMsg; } } implementation { uint8_t packetReadingNumber; uint16_t readingNumber; TOS_Msg msg[2]; uint8_t currentMsg; //Inicializaciòn de Este componente command result_t StdControl.init() { call Leds.init(); call Leds.yellowOff(); call Leds.redOff(); call Leds.greenOff();

70

call SensorControl.init(); call CommControl.init(); atomic { currentMsg = 0; packetReadingNumber = 0; readingNumber = 0; } dbg(DBG_BOOT, "OSCOPE initialized\n"); return SUCCESS; } // Inicializa los controles de SensorControl y Comm Control // siempre retornan SUCESS command result_t StdControl.start() { call SensorControl.start(); call Timer.start(TIMER_REPEAT, 16); // Prees calamiento del Timer 16 call CommControl.start(); return SUCCESS; } // Detiene los controles de SensorControl y CommCon trol command result_t StdControl.stop() { call SensorControl.stop(); call Timer.stop(); call CommControl.stop(); return SUCCESS; } task void dataTask() { struct OscopeMsg *pack; atomic { pack = (struct OscopeMsg *)msg[currentMsg].da ta; packetReadingNumber = 0; pack->lastSampleNumber = readingNumber; } pack->channel = 1; pack->sourceMoteID = TOS_LOCAL_ADDRESS; // Si se intenta enviar un paquete que no esta en c ola marcara error if (call DataMsg.send(TOS_BCAST_ADDR, sizeof(st ruct OscopeMsg), &msg[currentMsg])) { atomic { currentMsg ^= 0x1; } call Leds.yellowToggle(); } } /** * Avisa cuando los datos estan listo en el ADC, ha ce una lectura * y la pone en el paquete actual que se han tomado de BUFFER_ZISE * y regresa EXITO (SUCESS)

71

*/ async event result_t ADC.dataReady(uint16_t data) { struct OscopeMsg *pack; atomic { pack = (struct OscopeMsg *)msg[currentMsg].da ta; pack->data[packetReadingNumber++] = data; readingNumber++; dbg(DBG_USR1, "data_event\n"); if (packetReadingNumber == BUFFER_SIZE) { post dataTask(); } } if (data > 0x0300) call Leds.redOn(); else call Leds.redOff(); return SUCCESS; } // Señala cuando ya se ha enviado el paquete anteri or event result_t DataMsg.sendDone(TOS_MsgPtr sent, result_t success) { return SUCCESS; } // Señala cada que concluyen los impulsos de relo j (16) // regresa el resultado a llamar al ADC.getData() . event result_t Timer.fired() { return call ADC.getData(); } // Señala cuando se recibe el contador de mensaje de reajuste // regresa libre a TOS_MsgPtr. event TOS_MsgPtr ResetCounterMsg.receive(TOS_MsgP tr m) { atomic { readingNumber = 0; } return m; } }

72

2.3 ECGS.nc // $Id: ECGS.nc 17/03/2006 Interfaz ECGS (Configu racion e Implementaciòn de ECGS) /** * UNIVERSIDAD AUTONOMA METROPOLITANA - IZTAPALAPA * Av. San Rafael Atlixco N° 186 * Col. Vicentina C.P. 09340 * Iztapalapa, México D.F. * Tel. 01(55)58044600 Ext. 2045 * PROYECTO TERMINAL DE INGENIERIA EN ELECTRONICA Y COMUNICACIONES */ /* Autor: Martino García Hernández * Asesor: M. en C. Agustín Suárez F. * UAM-I * Ultima modificaciòn: 05/04/2006 */ configuration ECGS { provides interface ADC as ECGSADC; provides interface StdControl; } implementation { components ECGsensor; StdControl = ECGsensor.ECGSStdControl; ECGSADC = ECGsensor.ExternalECGSADC; }

73

2.4 ECGsensor.nc // $Id: ECGsensor.nc 17/03/2006 Interfaz ECGsenso r (Configuracion e Implementaciòn de ECG) /* * UNIVERSIDAD AUTONOMA METROPOLITANA - IZTAPALAPA * Av. San Rafael Atlixco N° 186 * Col. Vicentina C.P. 09340 * Iztapalapa, México D.F. * Tel. 01(55)58044600 Ext. 2045 * PROYECTO TERMINAL DE INGENIERIA EN ELECTRONICA Y COMUNICACIONES */ /* Autor: Martín García Hernández * Asesor: M. en C. Agustín Suárez F. * UAM-I * Última modificación: 05/04/2006 */ configuration ECGsensor { provides interface ADC as ExternalECGSADC; provides interface StdControl as ECGSStdControl; } implementation { components ECGsensorM, ADCC; ECGSStdControl = ECGsensorM.ECGSStdControl; ExternalECGSADC = ECGsensorM.ExternalECGSADC; ECGsensorM.InternalECGSADC -> ADCC.ADC[7]; // PU ERTO ADC A SENSAR CANAL 7 ECGsensorM.ADCControl -> ADCC; }

74

2.5 ECGsensorM.nc // $Id: ECGsensorM.nc 17/03/2006 Interfaz ECGsens or (Modulo) /* * UNIVERSIDAD AUTONOMA METROPOLITANA - IZTAPALAPA * Av. San Rafael Atlixco N° 186 * Col. Vicentina C.P. 09340 * Iztapalapa, México D.F. * Tel. 01(55)58044600 Ext. 2045 * PROYECTO TERMINAL DE INGENIERIA EN ELECTRONICA Y COMUNICACIONES */ /* Autor: Martino Garcia Hernandez * Asesor: M. en C. Agustin Suarez F. * UAM-I * Ultima modificaciòn: 05/04/2006 */ module ECGsensorM { provides interface StdControl as ECGSStdControl; provides interface ADC as ExternalECGSADC; uses { interface ADCControl; interface ADC as InternalECGSADC; } } implementation { enum{ IDLE = 1, BUSY = 2, CONTINUOUS = 3 }; int state; command result_t ECGSStdControl.init() { // ADCControl.bindPort(Puerto del ADC, Puerto Real del ADC) call ADCControl.bindPort(7,7); // Canal ADC 7 atomic { state = IDLE; } dbg(DBG_BOOT, "ECG initialized.\n"); return call ADCControl.init(); } command result_t ECGSStdControl.start() { // Implementamos la Frecuencia de Muestreo desde el ADCControl call ADCControl.setSamplingRate(TOS_ADCSample1920us ); // AQUI ESTAN LOS VALORES DEL ADCcontrol

75

/** * TOS_ADCSample3750ns = 0, * TOS_ADCSample7500ns = 1, * TOS_ADCSample15us = 2, * TOS_ADCSample30us = 3, * TOS_ADCSample60us = 4, * TOS_ADCSample120us = 5, * TOS_ADCSample240us = 6, * TOS_ADCSample480us = 7, * TOS_ADCSample960us = 8, * TOS_ADCSample1920us = 9 * / ---> MUESTREO A 1920 micro segundos maximo mu estreo permitido por el ADC control atomic { TOSH_SET_ECGS_CTL_PIN(); TOSH_MAKE_ECGS_CTL_OUTPUT(); } return SUCCESS; } command result_t ECGSStdControl.stop() { atomic { TOSH_CLR_ECGS_CTL_PIN(); TOSH_MAKE_ECGS_CTL_INPUT(); } return SUCCESS; } async command result_t ExternalECGSADC.getData(){ uint8_t oldState; atomic { oldState = state; if (state == IDLE) { state = BUSY; } } if (oldState == IDLE){ TOSH_SET_ECGS_CTL_PIN(); TOSH_MAKE_ECGS_CTL_OUTPUT(); return call InternalECGSADC.getData(); } return FAIL; } async command result_t ExternalECGSADC.getContinu ousData(){ uint8_t oldState; atomic { oldState = state; if (state == IDLE) { state = CONTINUOUS; } } if (oldState == IDLE){ TOSH_SET_ECGS_CTL_PIN(); TOSH_MAKE_ECGS_CTL_OUTPUT(); return call InternalECGSADC.getContinuousData (); } return FAIL; }

76

default async event result_t ExternalECGSADC.data Ready(uint16_t data) { return SUCCESS; } async event result_t InternalECGSADC.dataReady(ui nt16_t data){ uint8_t oldState; atomic { oldState = state; if (state == BUSY) { state = IDLE; } } if (oldState == BUSY){ return signal ExternalECGSADC.dataReady(data); }else if (oldState == CONTINUOUS){ int ret; ret = signal ExternalECGSADC.dataReady(data); if (ret == FAIL){ atomic { state = IDLE; } } return ret; } return FAIL; } }

77

2.6 ADCControl.nc // $Id: ADCControl.nc 17/03/2006 Interface ADC /** * UNIVERSIDAD AUTONOMA METROPOLITANA - IZTAPALAPA * Av. San Rafael Atlixco N° 186 * Col. Vicentina C.P. 09340 * Iztapalapa, México D.F. * Tel. 01(55)58044600 Ext. 2045 * PROYECTO TERMINAL DE INGENIERIA EN ELECTRONICA Y COMUNICACIONES */ /* Autor: Martino Garcia Hernandez * Asesor: M. en C. Agustin Suarez F. * UAM-I * Ultima modificaciòn: 07/04/2006 */ /** * Controla algunos aspectos del ADC * autor: Martin Garcia Hernandez */ interface ADCControl { //Inicializa la esructura de ADCControl command result_t init(); /** * Aqui de fija el indice de muestreo * que son los tres bits bajos del registro ADCSR * en el microprocesador * El parametro del muestreo puede utilizar * los siguientes valores de periodo * en este caso utilizaremos uno que hemos agregado * para alcanzar el alto mustreo necesario para un ECG * TODOS DEFINIDOS EN EL ARCHIVO H ADC.h*/ /** * TOS_ADCSample3750ns = 0 * TOS_ADCSample7500ns = 1 * TOS_ADCSample15us = 2 * TOS_ADCSample30us = 3 * TOS_ADCSample60us = 4 * TOS_ADCSample120us = 5 * TOS_ADCSample240us = 6 * TOS_ADCSample480us = 7 * TOS_ADCSample960us = 8 * * <<<< Aqui el valor de muestreo maximo para el C C100 >>>> * * TOS_ADCSample1920us = 9 * * el muestreo 2^rate del parametro es el factor de l prescalador ADC.

78

* El índice del ADC se toma del cristal y la frecu encia aprescaler, * o XTAL * 2^rate = 32kHz * 2^rate. */ command result_t setSamplingRate(uint8_t rate); /** * Aqui se pide el puerto ADC donde se va a muestr ear * se manda a llamar en ECGSensorM.nc con ADCContr ol.bindPort(7,7); */ command result_t bindPort(uint8_t port, uint8_t a dcPort); }

79

3 Paquetes H

3.1 Osciloscopio.h // $Id: Osciloscopio.h 17/03/2006 Archivo de encab ezado H (Definicion de Variables y Constantes) /* * UNIVERSIDAD AUTONOMA METROPOLITANA - IZTAPALAPA * Av. San Rafael Atlixco N° 186 * Col. Vicentina C.P. 09340 * Iztapalapa, México D.F. * Tel. 01(55)58044600 Ext. 2045 * PROYECTO TERMINAL DE INGENIERIA EN ELECTRONICA Y COMUNICACIONES */ /* Autor: Martino Garcia Hernandez * Asesor: M. en C. Agustin Suarez F. * UAM-I * Ultima modificaciòn: 01:26 a.m. 06/04/2006 */ enum { // Aqui esta definido el Tamaño del Buffer BUFFER_SIZE = 10 }; struct OscopeMsg { uint16_t sourceMoteID; uint16_t lastSampleNumber; uint16_t channel; uint16_t data[BUFFER_SIZE]; }; struct OscopeResetMsg { /* Vacio Necesario */ }; enum { AM_OSCOPEMSG = 10, AM_OSCOPERESETMSG = 32 };

80

3.2 ADC.h // $Id: ADC.h 17/03/2006 Archivo de encabezado H /** * UNIVERSIDAD AUTONOMA METROPOLITANA - IZTAPALAPA * Av. San Rafael Atlixco N° 186 * Col. Vicentina C.P. 09340 * Iztapalapa, México D.F. * Tel. 01(55)58044600 Ext. 2045 * PROYECTO TERMINAL DE INGENIERIA EN ELECTRONICA Y COMUNICACIONES */ /* Autor: Martino Garcia Hernandez * Asesor: M. en C. Agustin Suarez F. * UAM-I * Ultima modificaciòn: 03:42 p.m. 07/04/2006 */ /* * Define la frecuencias de muestreo: sampling scal e * Valores preescalables */ enum { TOS_ADCSample3750ns = 0, TOS_ADCSample7500ns = 1, TOS_ADCSample15us = 2, TOS_ADCSample30us = 3, TOS_ADCSample60us = 4, TOS_ADCSample120us = 5, TOS_ADCSample240us = 6, TOS_ADCSample480us = 7, TOS_ADCSample960us = 8, // valor de muestreo maximo para el CC100 TOS_ADCSample1920us = 9 };

81

3.3 CC1000Const.h // $Id: CC1000Const.h,v 2 2006-07-19 00:48:29 Archi vo de Encabezado H /** * UNIVERSIDAD AUTONOMA METROPOLITANA - IZTAPALAPA * Av. San Rafael Atlixco N° 186 * Col. Vicentina C.P. 09340 * Iztapalapa, México D.F. * Tel. 01(55)58044600 Ext. 2045 * PROYECTO TERMINAL DE INGENIERIA EN ELECTRONICA Y COMUNICACIONES */ /* Autor: Martino Garcia Hernandez * Asesor: M. en C. Agustin Suarez F. * UAM-I * Ultima modificaciòn: 03:42 p.m. 07/04/2006 */ #ifndef _CC1KCONST_H #define _CC1KCONST_H #include <avr/pgmspace.h> /* Constants defined for CC1K */ /* Register addresses */ #define CC1K_MAIN 0x00 #define CC1K_FREQ_2A 0x01 #define CC1K_FREQ_1A 0x02 #define CC1K_FREQ_0A 0x03 #define CC1K_FREQ_2B 0x04 #define CC1K_FREQ_1B 0x05 #define CC1K_FREQ_0B 0x06 #define CC1K_FSEP1 0x07 #define CC1K_FSEP0 0x08 #define CC1K_CURRENT 0x09 #define CC1K_FRONT_END 0x0A //10 #define CC1K_PA_POW 0x0B //11 #define CC1K_PLL 0x0C //12 #define CC1K_LOCK 0x0D //13 #define CC1K_CAL 0x0E //14 #define CC1K_MODEM2 0x0F //15 #define CC1K_MODEM1 0x10 //16 #define CC1K_MODEM0 0x11 //17 #define CC1K_MATCH 0x12 //18 #define CC1K_FSCTRL 0x13 //19 #define CC1K_FSHAPE7 0x14 //20 #define CC1K_FSHAPE6 0x15 //21 #define CC1K_FSHAPE5 0x16 //22 #define CC1K_FSHAPE4 0x17 //23 #define CC1K_FSHAPE3 0x18 //24 #define CC1K_FSHAPE2 0x19 //25 #define CC1K_FSHAPE1 0x1A //26 #define CC1K_FSDELAY 0x1B //27 #define CC1K_PRESCALER 0x1C //28 #define CC1K_TEST6 0x40 //64

82

#define CC1K_TEST5 0x41 //66 #define CC1K_TEST4 0x42 //67 #define CC1K_TEST3 0x43 //68 #define CC1K_TEST2 0x44 //69 #define CC1K_TEST1 0x45 //70 #define CC1K_TEST0 0x46 //71 // MAIN Register Bit Posititions #define CC1K_RXTX 7 #define CC1K_F_REG 6 #define CC1K_RX_PD 5 #define CC1K_TX_PD 4 #define CC1K_FS_PD 3 #define CC1K_CORE_PD 2 #define CC1K_BIAS_PD 1 #define CC1K_RESET_N 0 // CURRENT Register Bit Positions #define CC1K_VCO_CURRENT 4 #define CC1K_LO_DRIVE 2 #define CC1K_PA_DRIVE 0 // FRONT_END Register Bit Positions #define CC1K_BUF_CURRENT 5 #define CC1K_LNA_CURRENT 3 #define CC1K_IF_RSSI 1 #define CC1K_XOSC_BYPASS 0 // PA_POW Register Bit Positions #define CC1K_PA_HIGHPOWER 4 #define CC1K_PA_LOWPOWER 0 // PLL Register Bit Positions #define CC1K_EXT_FILTER 7 #define CC1K_REFDIV 3 #define CC1K_ALARM_DISABLE 2 #define CC1K_ALARM_H 1 #define CC1K_ALARM_L 0 // LOCK Register Bit Positions #define CC1K_LOCK_SELECT 4 #define CC1K_PLL_LOCK_ACCURACY 3 #define CC1K_PLL_LOCK_LENGTH 2 #define CC1K_LOCK_INSTANT 1 #define CC1K_LOCK_CONTINUOUS 0 // CAL Register Bit Positions #define CC1K_CAL_START 7 #define CC1K_CAL_DUAL 6 #define CC1K_CAL_WAIT 5 #define CC1K_CAL_CURRENT 4 #define CC1K_CAL_COMPLETE 3 #define CC1K_CAL_ITERATE 0 // MODEM2 Register Bit Positions #define CC1K_PEAKDETECT 7 #define CC1K_PEAK_LEVEL_OFFSET 0 // MODEM1 Register Bit Positions #define CC1K_MLIMIT 5 #define CC1K_LOCK_AVG_IN 4

83

#define CC1K_LOCK_AVG_MODE 3 #define CC1K_SETTLING 1 #define CC1K_MODEM_RESET_N 0 // MODEM0 Register Bit Positions #define CC1K_BAUDRATE 4 #define CC1K_DATA_FORMAT 2 #define CC1K_XOSC_FREQ 0 // MATCH Register Bit Positions #define CC1K_RX_MATCH 4 #define CC1K_TX_MATCH 0 // FSCTLR Register Bit Positions #define CC1K_DITHER1 3 #define CC1K_DITHER0 2 #define CC1K_SHAPE 1 #define CC1K_FS_RESET_N 0 // PRESCALER Register Bit Positions #define CC1K_PRE_SWING 6 #define CC1K_PRE_CURRENT 4 #define CC1K_IF_INPUT 3 #define CC1K_IF_FRONT 2 // TEST6 Register Bit Positions #define CC1K_LOOPFILTER_TP1 7 #define CC1K_LOOPFILTER_TP2 6 #define CC1K_CHP_OVERRIDE 5 #define CC1K_CHP_CO 0 // TEST5 Register Bit Positions #define CC1K_CHP_DISABLE 5 #define CC1K_VCO_OVERRIDE 4 #define CC1K_VCO_AO 0 // TEST3 Register Bit Positions #define CC1K_BREAK_LOOP 4 #define CC1K_CAL_DAC_OPEN 0 /* * CC1K Register Parameters Table * * This table follows the same format order as the CC1K register * set EXCEPT for the last entry in the table which is the * CURRENT register value for TX mode. * * NOTE: To save RAM space, this table resides in p rogram memory (flash). * This has two important implications: * 1) You can't write to it (duh!) * 2) You must read it using the PRG_RDB(addr) macr o. IT CANNOT BE ACCESSED AS AN ORDINARY C ARRAY. * * Add/remove individual entries below to suit your RF tastes. * */ #define CC1K_433_002_MHZ 0x00 #define CC1K_915_998_MHZ 0x01

84

#define CC1K_434_845_MHZ 0x02 #define CC1K_914_077_MHZ 0x03 #define CC1K_315_178_MHZ 0x04 #ifdef CC1K_DEFAULT_FREQ #define CC1K_DEF_PRESET (CC1K_DEFAULT_FREQ) #endif #ifdef CC1K_MANUAL_FREQ #define CC1K_DEF_FREQ (CC1K_MANUAL_FREQ) #endif #ifndef CC1K_DEF_PRESET #define CC1K_DEF_PRESET (CC1K_914_077_MHZ) #endif #define CC1K_LPL_STATES 7 #define CC1K_LPL_PACKET_TIME 16 // duty cycle max packets effective throughput // ----------------- ----------------- ---------- ------- // 100% duty cycle 42.93 packets/sec 12.364kbps // 35.5% duty cycle 19.69 packets/sec 5.671kbps // 11.5% duty cycle 8.64 packets/sec 2.488kbps // 7.53% duty cycle 6.03 packets/sec 1.737kbps // 5.61% duty cycle 4.64 packets/sec 1.336kbps // 2.22% duty cycle 1.94 packets/sec 0.559kbps // 1.00% duty cycle 0.89 packets/sec 0.258kbps static const prog_uchar CC1K_LPL_PreambleLength[CC1 K_LPL_STATES*2] = { 0, 28, //28 0, 94, //94 0, 250, //250 0x01, 0x73, //371, 0x01, 0xEA, //490, 0x04, 0xBC, //1212 0x0A, 0x5E //2654 }; static const prog_uchar CC1K_LPL_ValidPrecursor[CC1 K_LPL_STATES] = { 5, 2, 2, 2, 2, 2, 2 }; static const prog_uchar CC1K_LPL_SleepTime[CC1K_LPL _STATES*2] = { 0, 0, //0 0, 20, //20 0, 85, //85 0, 135, //135 0, 185, //185 0x01, 0xE5, //485 0x04, 0x3D //1085 }; static const prog_uchar CC1K_LPL_SleepPreamble[CC1K _LPL_STATES] = { 0,

85

8, 8, 8, 8, 8, 8 }; static const prog_uchar CC1K_LPL_SquelchInit[CC1K_L PL_STATES] = { 0xAE, 0xEF, 0xEF, 0xEF, 0xEF, 0xEF, 0xEF }; static const prog_uchar CC1K_Params[6][31] = { // (0) 433.002 MHz channel, 19.2 Kbps data, Manch ester Encoding, High Side LO { // MAIN 0x00 0x31, // FREQ2A,FREQ1A,FREQ0A 0x01-0x03 0x58,0x00,0x00, // FREQ2B,FREQ1B,FREQ0B 0x04-0x06 0x57,0xf6,0x85, //XBOW // FSEP1, FSEP0 0x07-0x08 0X03,0x55, // CURRENT (RX MODE VALUE) 0x09 (also see bel ow) ((4<<CC1K_VCO_CURRENT) | (1<<CC1K_LO_DRIVE)), // FRONT_END 0x0a ((1<<CC1K_IF_RSSI)), // PA_POW 0x0b ((0x0<<CC1K_PA_HIGHPOWER) | (0xf<<CC1K_PA_LOWPO WER)), // PLL 0x0c ((12<<CC1K_REFDIV)), // LOCK 0x0d ((0xe<<CC1K_LOCK_SELECT)), // CAL 0x0e ((1<<CC1K_CAL_WAIT) | (6<<CC1K_CAL_ITERATE)), // MODEM2 0x0f ((0<<CC1K_PEAKDETECT) | (28<<CC1K_PEAK_LEVEL_OF FSET)), // MODEM1 0x10 ((3<<CC1K_MLIMIT) | (1<<CC1K_LOCK_AVG_MODE) | ( 3<<CC1K_SETTLING) | (1<<CC1K_MODEM_RESET_N)), // MODEM0 0x11 ((5<<CC1K_BAUDRATE) | (1<<CC1K_DATA_FORMAT) | ( 1<<CC1K_XOSC_FREQ)), // MATCH 0x12 ((0x7<<CC1K_RX_MATCH) | (0x0<<CC1K_TX_MATCH)), // FSCTRL 0x13 ((1<<CC1K_FS_RESET_N)), // FSHAPE7 - FSHAPE1 0x14-0x1a 0x00,0x00,0x00,0x00,0x00,0x00,0x00, // FSDELAY 0x1b 0x00, // PRESCALER 0x1c 0x00, // CURRENT (TX MODE VALUE) 0x1d ((8<<CC1K_VCO_CURRENT) | (1<<CC1K_PA_DRIVE)), // High side LO 0x1e (i.e. do we need to inver t the data?)

86

TRUE }, // (1) 914.9988 MHz channel, 19.2 Kbps data, Manc hester Encoding, High Side LO { // MAIN 0x00 0x31, // FREQ2A,FREQ1A,FREQ0A 0x01-0x03 0x7c,0x00,0x00, // FREQ2B,FREQ1B,FREQ0B 0x04-0x06 0x7b,0xf9,0xae, // FSEP1, FSEP0 0x07-0x8 0x02,0x38, // CURRENT (RX MODE VALUE) 0x09 (also see bel ow) ((8<<CC1K_VCO_CURRENT) | (3<<CC1K_LO_DRIVE)), //0x8C, // FRONT_END 0x0a ((1<<CC1K_BUF_CURRENT) | (2<<CC1K_LNA_CURRENT) | (1<<CC1K_IF_RSSI)), //0x32, // PA_POW 0x0b ((0x8<<CC1K_PA_HIGHPOWER) | (0x0<<CC1K_PA_LOWPO WER)), //0xff, // PLL 0xc ((8<<CC1K_REFDIV)), //0x40, // LOCK 0xd ((0x1<<CC1K_LOCK_SELECT)), //0x10, // CAL 0xe ((1<<CC1K_CAL_WAIT) | (6<<CC1K_CAL_ITERATE)), //0x26, // MODEM2 0xf ((1<<CC1K_PEAKDETECT) | (33<<CC1K_PEAK_LEVEL_OF FSET)), //0xA1, // MODEM1 0x10 ((3<<CC1K_MLIMIT) | (1<<CC1K_LOCK_AVG_MODE) | ( 3<<CC1K_SETTLING) | (1<<CC1K_MODEM_RESET_N)), //0x6f, // MODEM0 0x11 ((5<<CC1K_BAUDRATE) | (1<<CC1K_DATA_FORMAT) | ( 1<<CC1K_XOSC_FREQ)), //0x55, // MATCH 0x12 ((0x1<<CC1K_RX_MATCH) | (0x0<<CC1K_TX_MATCH)), //0x10, // FSCTRL 0x13 ((1<<CC1K_FS_RESET_N)), //0x01, // FSHAPE7 - FSHAPE1 0x14..0x1a 0x00,0x00,0x00,0x00,0x00,0x00,0x00, // FSDELAY 0x1b 0x00, // PRESCALER 0x1c 0x00, // CURRENT (TX MODE VALUE) 0x1d ((15<<CC1K_VCO_CURRENT) | (3<<CC1K_PA_DRIVE)), //0xf3, // High side LO 0x1e (i.e. do we need to inver t the data?) TRUE },

87

// (2) 434.845200 MHz channel, 19.2 Kbps data, Ma nchester Encoding, High Side LO { // MAIN 0x00 0x31, // FREQ2A,FREQ1A,FREQ0A 0x01-0x03 0x51,0x00,0x00, // FREQ2B,FREQ1B,FREQ0B 0x04-0x06 0x50,0xf7,0x4F, //XBOW // FSEP1, FSEP0 0x07-0x08 0X03,0x0E, // CURRENT (RX MODE VALUE) 0x09 (also see bel ow) ((4<<CC1K_VCO_CURRENT) | (1<<CC1K_LO_DRIVE)), // FRONT_END 0x0a ((1<<CC1K_IF_RSSI)), // PA_POW 0x0b ((0x0<<CC1K_PA_HIGHPOWER) | (0xf<<CC1K_PA_LOWPO WER)), // PLL 0x0c ((11<<CC1K_REFDIV)), // LOCK 0x0d ((0xe<<CC1K_LOCK_SELECT)), // CAL 0x0e ((1<<CC1K_CAL_WAIT) | (6<<CC1K_CAL_ITERATE)), // MODEM2 0x0f ((1<<CC1K_PEAKDETECT) | (33<<CC1K_PEAK_LEVEL_OF FSET)), // MODEM1 0x10 ((3<<CC1K_MLIMIT) | (1<<CC1K_LOCK_AVG_MODE) | ( 3<<CC1K_SETTLING) | (1<<CC1K_MODEM_RESET_N)), // MODEM0 0x11 ((5<<CC1K_BAUDRATE) | (1<<CC1K_DATA_FORMAT) | ( 1<<CC1K_XOSC_FREQ)), // MATCH 0x12 ((0x7<<CC1K_RX_MATCH) | (0x0<<CC1K_TX_MATCH)), // FSCTRL 0x13 ((1<<CC1K_FS_RESET_N)), // FSHAPE7 - FSHAPE1 0x14-0x1a 0x00,0x00,0x00,0x00,0x00,0x00,0x00, // FSDELAY 0x1b 0x00, // PRESCALER 0x1c 0x00, // CURRENT (TX MODE VALUE) 0x1d ((8<<CC1K_VCO_CURRENT) | (1<<CC1K_PA_DRIVE)), // High side LO 0x1e (i.e. do we need to inver t the data?) TRUE }, // (3) 914.077 MHz channel, 19.2 Kbps data, Manch ester Encoding, High Side LO { // MAIN 0x00 0x31, // FREQ2A,FREQ1A,FREQ0A 0x01-0x03 0x5c,0xe0,0x00, // FREQ2B,FREQ1B,FREQ0B 0x04-0x06 0x5c,0xdb,0x42, // FSEP1, FSEP0 0x07-0x8 0x01,0xAA, // CURRENT (RX MODE VALUE) 0x09 (also see bel ow) ((8<<CC1K_VCO_CURRENT) | (3<<CC1K_LO_DRIVE)), //0x8C, // FRONT_END 0x0a

88

((1<<CC1K_BUF_CURRENT) | (2<<CC1K_LNA_CURRENT) | (1<<CC1K_IF_RSSI)), //0x32, // PA_POW 0x0b ((0x8<<CC1K_PA_HIGHPOWER) | (0x0<<CC1K_PA_LOWPO WER)), //0xff, // PLL 0xc ((6<<CC1K_REFDIV)), //0x40, // LOCK 0xd ((0x1<<CC1K_LOCK_SELECT)), //0x10, // CAL 0xe ((1<<CC1K_CAL_WAIT) | (6<<CC1K_CAL_ITERATE)), //0x26, // MODEM2 0xf ((1<<CC1K_PEAKDETECT) | (33<<CC1K_PEAK_LEVEL_OF FSET)), //0xA1, // MODEM1 0x10 ((3<<CC1K_MLIMIT) | (1<<CC1K_LOCK_AVG_MODE) | ( 3<<CC1K_SETTLING) | (1<<CC1K_MODEM_RESET_N)), //0x6f, // MODEM0 0x11 ((5<<CC1K_BAUDRATE) | (1<<CC1K_DATA_FORMAT) | ( 1<<CC1K_XOSC_FREQ)), //0x55, // MATCH 0x12 ((0x1<<CC1K_RX_MATCH) | (0x0<<CC1K_TX_MATCH)), //0x10, // FSCTRL 0x13 ((1<<CC1K_FS_RESET_N)), //0x01, // FSHAPE7 - FSHAPE1 0x14..0x1a 0x00,0x00,0x00,0x00,0x00,0x00,0x00, // FSDELAY 0x1b 0x00, // PRESCALER 0x1c 0x00, // CURRENT (TX MODE VALUE) 0x1d ((15<<CC1K_VCO_CURRENT) | (3<<CC1K_PA_DRIVE)), //0xf3, // High side LO 0x1e (i.e. do we need to inver t the data?) TRUE }, // (4) 315.178985 MHz channel, 38.4 Kbps data, Ma nchester Encoding, High Side LO { // MAIN 0x00 0x31, // FREQ2A,FREQ1A,FREQ0A 0x01-0x03 0x45,0x60,0x00, // FREQ2B,FREQ1B,FREQ0B 0x04-0x06 0x45,0x55,0xBB, // FSEP1, FSEP0 0x07-0x08 0X03,0x9C, // CURRENT (RX MODE VALUE) 0x09 (also see bel ow) ((8<<CC1K_VCO_CURRENT) | (0<<CC1K_LO_DRIVE)), // FRONT_END 0x0a ((1<<CC1K_IF_RSSI)), // PA_POW 0x0b ((0x0<<CC1K_PA_HIGHPOWER) | (0xf<<CC1K_PA_LOWPO WER)),

89

// PLL 0x0c ((13<<CC1K_REFDIV)), // LOCK 0x0d ((0xe<<CC1K_LOCK_SELECT)), // CAL 0x0e ((1<<CC1K_CAL_WAIT) | (6<<CC1K_CAL_ITERATE)), // MODEM2 0x0f ((1<<CC1K_PEAKDETECT) | (33<<CC1K_PEAK_LEVEL_OF FSET)), // MODEM1 0x10 ((3<<CC1K_MLIMIT) | (1<<CC1K_LOCK_AVG_MODE) | ( 3<<CC1K_SETTLING) | (1<<CC1K_MODEM_RESET_N)), // MODEM0 0x11 ((5<<CC1K_BAUDRATE) | (1<<CC1K_DATA_FORMAT) | ( 0<<CC1K_XOSC_FREQ)), // MATCH 0x12 ((0x7<<CC1K_RX_MATCH) | (0x0<<CC1K_TX_MATCH)), // FSCTRL 0x13 ((1<<CC1K_FS_RESET_N)), // FSHAPE7 - FSHAPE1 0x14-0x1a 0x00,0x00,0x00,0x00,0x00,0x00,0x00, // FSDELAY 0x1b 0x00, // PRESCALER 0x1c 0x00, // CURRENT (TX MODE VALUE) 0x1d ((8<<CC1K_VCO_CURRENT) | (1<<CC1K_PA_DRIVE)), // High side LO 0x1e (i.e. do we need to inver t the data?) TRUE }, // (5) Spare { // MAIN 0x00 0x31, // FREQ2A,FREQ1A,FREQ0A 0x01-0x03 0x58,0x00,0x00, // FREQ2B,FREQ1B,FREQ0B 0x04-0x06 0x57,0xf6,0x85, //XBOW // FSEP1, FSEP0 0x07-0x08 0X03,0x55, // CURRENT (RX MODE VALUE) 0x09 (also see bel ow) ((8<<CC1K_VCO_CURRENT) | (4<<CC1K_LO_DRIVE)), // FRONT_END 0x0a ((1<<CC1K_IF_RSSI)), // PA_POW 0x0b ((0x0<<CC1K_PA_HIGHPOWER) | (0xf<<CC1K_PA_LOWPO WER)), // PLL 0x0c ((12<<CC1K_REFDIV)), // LOCK 0x0d ((0xe<<CC1K_LOCK_SELECT)), // CAL 0x0e ((1<<CC1K_CAL_WAIT) | (6<<CC1K_CAL_ITERATE)), // MODEM2 0x0f ((1<<CC1K_PEAKDETECT) | (33<<CC1K_PEAK_LEVEL_OF FSET)), // MODEM1 0x10 ((3<<CC1K_MLIMIT) | (1<<CC1K_LOCK_AVG_MODE) | ( 3<<CC1K_SETTLING) | (1<<CC1K_MODEM_RESET_N)), // MODEM0 0x11 ((5<<CC1K_BAUDRATE) | (1<<CC1K_DATA_FORMAT) | ( 1<<CC1K_XOSC_FREQ)), // MATCH 0x12 ((0x7<<CC1K_RX_MATCH) | (0x0<<CC1K_TX_MATCH)), // FSCTRL 0x13 ((1<<CC1K_FS_RESET_N)), // FSHAPE7 - FSHAPE1 0x14-0x1a

90

0x00,0x00,0x00,0x00,0x00,0x00,0x00, // FSDELAY 0x1b 0x00, // PRESCALER 0x1c 0x00, // CURRENT (TX MODE VALUE) 0x1d ((8<<CC1K_VCO_CURRENT) | (1<<CC1K_PA_DRIVE)), // High side LO 0x1e (i.e. do we need to inver t the data?) TRUE }, }; #endif /* _CC1KCONST_H */

91

4. Archivo de Interfaz Java

4.1 MonitorECG.java // $Id: MonitorECG.java,v 1.7 05:17 p.m. 19/07/2006 Archivo Java /** * UNIVERSIDAD AUTONOMA METROPOLITANA - IZTAPALAPA * Av. San Rafael Atlixco N° 186 * Col. Vicentina C.P. 09340 * Iztapalapa, México D.F. * Tel. 01(55)58044600 Ext. 2045 * PROYECTO TERMINAL DE INGENIERIA EN ELECTRONICA Y COMUNICACIONES */ /* Autor: Martino Garcia Hernandez * Asesor: M. en C. Agustin Suarez F. * UAM-I * Ultima modificaciòn: 03:42 p.m. 07/04/2006 */ package net.tinyos.oscope; import net.tinyos.util.*; import java.io.*; import java.util.*; import java.awt.*; import java.applet.Applet; import java.awt.event.*; import javax.swing.*; import javax.swing.event.*; import java.sql.Time; public class oscilloscope extends JPanel implements ActionListener, ItemListener, ChangeListener { Button timeout = new Button("Panel de Control") ; Button move_up = new Button("^"); Button move_down = new Button("v"); Button move_right = new Button(">"); Button move_left = new Button("<"); Button zoom_out_x = new Button("Acercar X"); Button zoom_in_x = new Button("Alejar X"); Button zoom_out_y = new Button("Acercar Y"); Button zoom_in_y = new Button("Alejar Y"); Button reset = new Button("Acomodar"); Button save_data = new Button("Salvar Dato"); Button load_data = new Button("Leer Dato"); Button editLegend = new Button("Editar Leyenda" ); Button clear_data = new Button("Borrar Datos"); Button acercade = new Button("Acerca de .."); / /ESTE ES EL ACERCA DE...... Checkbox showLegend = new Checkbox("Mostrar Ley enda", true);

92

Checkbox connect_points = new Checkbox("Conecta r Puntos de Datos", true); Checkbox YAxisHex = new Checkbox("Eje Y en Hex. ", false); Checkbox scrolling = new Checkbox("Desplazar", false); JSlider time_location = new JSlider(0, 100, 100 ); public JTextField legendEdit[]; public JCheckBox legendActive[]; public JLabel high_pass_val= new JLabel("5"); public JLabel low_pass_val = new JLabel("2"); public JLabel cutoff_val = new JLabel("65"); public JSlider high_pass= new JSlider(0, 30, 5) ; public JSlider low_pass = new JSlider(0, 30, 2) ; public JSlider cutoff = new JSlider(0, 4000, 65 ); GraphPanel panel; Panel controlPanel; public void init() { time_location.addChangeListener(this); setLayout(new BorderLayout()); panel = new GraphPanel(this); add("Center", panel); controlPanel = new Panel(); add("South", controlPanel); Panel x_pan = new Panel(); x_pan.setLayout(new GridLayout(5,1)); x_pan.add(zoom_in_x); x_pan.add(zoom_out_x); x_pan.add(save_data); x_pan.add(editLegend); x_pan.add(clear_data); x_pan.add(acercade); //este es el ac erca de....... zoom_out_x.addActionListener(this); zoom_in_x.addActionListener(this); save_data.addActionListener(this); editLegend.addActionListener(this); clear_data.addActionListener(this); controlPanel.add(x_pan); Panel y_pan = new Panel(); y_pan.setLayout(new GridLayout(5,1)); y_pan.add(zoom_in_y); y_pan.add(zoom_out_y); y_pan.add(load_data); y_pan.add(showLegend); y_pan.add(connect_points); zoom_out_y.addActionListener(this); zoom_in_y.addActionListener(this); load_data.addActionListener(this); showLegend.addItemListener(this); connect_points.addItemListener(this); controlPanel.add(y_pan); Panel scroll_pan = new Panel(); move_up.addActionListener(this); move_down.addActionListener(this);

93

move_right.addActionListener(this); move_left.addActionListener(this); reset.addActionListener(this); GridBagLayout g = new GridBagLayout(); GridBagConstraints c = new GridBagConstraints(); scroll_pan.setLayout(g); c.gridx = 1; c.gridy = 0; g.setConstraints( move_up, c ); scroll_pan.add(move_up); c.gridx = 0; c.gridy = 1; g.setConstraints( move_left, c ); scroll_pan.add(move_left); c.gridx = 1; c.gridy = 1; g.setConstraints( reset, c ); scroll_pan.add(reset); c.gridx = 2; c.gridy = 1; g.setConstraints( move_right, c ); scroll_pan.add(move_right); c.gridx = 1; c.gridy = 2; g.setConstraints( move_down, c ); scroll_pan.add(move_down); controlPanel.add(scroll_pan); acercade.addActionListener(this);//esta parte es m ia Panel pp = new Panel(); pp.setLayout(new GridLayout(4, 1)); pp.add(YAxisHex); YAxisHex.addItemListener(this); pp.add(scrolling); scrolling.addItemListener(this) ; pp.add(timeout); controlPanel.add(pp); //controlPanel.add(timeout); timeout.addActionListener(this); Panel p = new Panel(); p.setLayout(new GridLayout(4, 1)); p.add(YAxisHex); YAxisHex.addItemListener(this); p.add(scrolling); scrolling.addItemListener(this); p.add(time_location);//Mote 1 Canal 1 Intencidad L uminosa p.add(timeout); controlPanel.add(p); panel.repaint(); repaint(); legendEdit = new JTextField[panel.NUM_CHANNELS]; for( int i=0;i<panel.NUM_CHANNELS;i++ ) legendEdit[i] = new JTextField(128); legendActive = new JCheckBox[panel.NUM_CHANNELS]; for( int i=0;i<panel.NUM_CHANNELS;i++ ) legendActive[i] = new JCheckBox("Grafica: "+(i +1)); } public void destroy() {

94

remove(panel); remove(controlPanel); } public void start() { panel.start(); } public void stop() { panel.stop(); } public void actionPerformed(ActionEvent e) { Object src = e.getSource(); for( int i=0;i<panel.NUM_CHANNELS;i++ ) { if( legendEdit[i] == src ) { panel.dataLegend[i] = legendEdit[i].getText(); panel.repaint( 100 ); } } if (src == zoom_out_x) { panel.zoom_out_x(); panel.repaint(); } else if (src == zoom_in_x) { panel.zoom_in_x(); panel.repaint(); } else if (src == zoom_out_y) { panel.zoom_out_y(); panel.repaint(); } else if (src == zoom_in_y) { panel.zoom_in_y(); panel.repaint(); } else if (src == move_up) { panel.move_up(); panel.repaint(); } else if (src == move_down) { panel.move_down(); panel.repaint(); } else if (src == move_right) { panel.move_right(); panel.repaint(); } else if (src == move_left) { panel.move_left(); panel.repaint(); } else if (src == reset) { panel.reset(); panel.repaint(); } else if (src == load_data) { panel.load_data(); panel.repaint(); } else if (src == clear_data) { panel.clear_data(); panel.repaint(); } else if (src == save_data) { panel.save_data(); panel.repaint(); } else if (src == editLegend) { JFrame legend = new JFrame("Editar Leyenda"); legend.setSize(new Dimension(200,300)); legend.setVisible(true);

95

Panel slp = new Panel(); slp.setLayout(new GridLayout(10,2)); for( int i=0;i<panel.NUM_CHANNELS;i++ ) { legendActive[i].setSelected( panel.legendActive[i ] ); slp.add( legendActive[i] ); legendActive[i].addChangeListener(this); legendEdit[i].setText( panel.dataLegend[i] ); slp.add( legendEdit[i] ); legendEdit[i].addActionListener(this); } legend.getContentPane().add(slp); legend.pack(); legend.repaint(); } else if (src == timeout) { JFrame sliders = new JFrame("Control de Filtro s"); sliders.setSize(new Dimension(300,30)); sliders.setVisible(true); Panel slp = new Panel(); slp.setLayout(new GridLayout(3,3)); slp.add(new Label("Pasa Altas:")); slp.add(high_pass); slp.add(high_pass_val); slp.add(new Label("Pasa Bajas:")); slp.add(low_pass); slp.add(low_pass_val); slp.add(new Label("Cortar en:")); slp.add(cutoff); slp.add(cutoff_val); high_pass.addChangeListener(this); low_pass.addChangeListener(this); cutoff.addChangeListener(this); sliders.getContentPane().add(slp); sliders.pack(); sliders.repaint(); } // CODIGO PARA LA VENTANA DEL ACERCA DE........ else if (src == acercade) { JFrame info = new JFrame("UNIVERSIDAD AUTONOMA METROPOLITANA - IZTAPALAPA"); info.setSize(new Dimension(400,400)); info.setVisible(true); Panel slp = new Panel(); slp.add(new Label(" ")); slp.add(new Label(" UNIVERSIDAD AUTONOMA ME TROPOLITANA - IZTAPALAPA ")); slp.add(new Label(" CBI ")); slp.add(new Label(" Ing. Martino Garcia Hernandez ")); slp.add(new Label("Asesor: Maestro en Ciencias Agustin Suarez Fernandez ")); slp.add(new Label(" ")); info.getContentPane().add(slp); //Panel slp = new Panel(); // slp.add(new Label("Ing. Martino Garcia Herna ndez")); // System.out.println("MARTINO GARCIA HERNANDEZ ");

96

//public static void main(String arg[]){ // System.out.println("MARTINO GARCIA HERNANDEZ") ; //Panel slp = new Panel(); //slp.add(new Label("Ing. Martino Garcia Hernandez")); // slp.add(new Label("Ing. Reinaldo")); // slp.add(new Label("Asesor: Agustin suarez Fe rnandez")); } } public void itemStateChanged(ItemEvent e) { Object src = e.getSource(); boolean on = e.getStateChange() == ItemEvent.SELEC TED; if (src == scrolling) { panel.sliding = on; } else if (src == showLegend) { panel.legend = on; panel.repaint(100); } else if (src == connect_points) { panel.connectPoints = on; panel.repaint(100); } else if (src == YAxisHex) { panel.yaxishex = on; panel.repaint(100); } } public void stateChanged(ChangeEvent e){ Object src = e.getSource(); if(src == time_location) { double percent = (time_location.getValue() / 100 .0); int diff = panel.end - panel.start; panel.end = panel.minimum_x + (int)((panel.maxim um_x - panel.minimum_x) * percent); panel.start = panel.end - diff; } high_pass_val.setText("" + high_pass.getValue()); cutoff_val.setText("" + cutoff.getValue()); low_pass_val.setText("" + low_pass.getValue()); for( int i=0;i<panel.NUM_CHANNELS;i++ ) if( src == legendActive[i] ) panel.legendActive[i] = legendActive[i].isSelecte d(); panel.repaint( 100 ); } static oscilloscope app; static Frame mainFrame; // If specified as -1, then reset messages will only work properly // with the new TOSBase base station static int group_id = -1; public static void main(String[] args) throws I OException { if (args.length == 1) { group_id = (byte) Integer.parseInt(args[0]); System.err.println("oscilloscope: Using group ID "+group_id);

97

System.err.println("Note: group id should not be specified if you're using a TOSBase base station"); } mainFrame = new Frame("*** UAMI *** Despliege de E CG"); app = new oscilloscope(); app.init(); mainFrame.setSize( app.getSize() ); mainFrame.add("Center", app); mainFrame.show(); mainFrame.repaint(1000); app.panel.repaint(); mainFrame.addWindowListener ( new WindowAdapter() { public void windowClosing ( WindowEvent w event ) { System.exit(0); } } ); app.start(); } public Dimension getSize() { return new Dimension(600, 600); } }

ECG por telemetría utilizando tecnología NEST148.206.53.84/tesiuami/UAMI13115.pdf · El ECG tiene...

Documents

Transcript of ECG por telemetría utilizando tecnología NEST148.206.53.84/tesiuami/UAMI13115.pdf · El ECG tiene...