ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA...

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA

UNIVERSIDAD DE SEVILLA

Ingeniería de Telecomunicación

Proyecto fin de carrera

Desarrollo e implementación del firmware y la interfaz de usuario de un

lector RFID para la activación y lectura de un sensor inalámbrico de

señales biomédicas compatible con el protocolo EPC Class-1

Generation-2

Autor del proyecto:

Jesús Montalvo Fernández

Tutor del proyecto:

Dr. Óscar Guerra Vinuesa

Directores del proyecto:

Dr. Alberto Rodríguez Pérez

Dr. José Antonio Rodríguez Rodríguez

Departamento de Electrónica y Electromagnetismo

Sevilla, Septiembre 2014

Índice de contenido

Capítulo 1 - Introducción.......................................................................................................1

1.1. Introducción a los sistemas de identificación basados en radiofrecuencia...............1

1.2. Objetivos y alcance del proyecto................................................................................8

Capítulo 2 - Flujo de comunicación personalizado compatible con el estándar EPC C1

Gen2.....................................................................................................................................11

2.1. Introducción al protocolo EPC C1 Gen2...................................................................11

2.1.1. Comandos........................................................................................................11

2.1.2. Comunicación Lector a Tag..............................................................................11

2.1.3. Comunicación Tag a Lector..............................................................................14

2.2. Flujo de comunicación estándar...............................................................................15

2.2.1. Temporización del flujo de comunicación.........................................................16

2.2.1.1. T2...............................................................................................................17

2.2.1.2. Tiempo de respuesta al comando Write....................................................18

2.3. Particularidades para el tag sensor de señales biomédicas....................................18

2.3.1. Temporización..................................................................................................18

2.3.2. Comandos implementados...............................................................................18

2.3.2.1. Comandos obligatorios..............................................................................19

2.3.2.2. Comandos personalizados........................................................................21

2.3.2.2.1. Comando ClockCalibration.................................................................21

2.3.2.2.2. Comando SensorCalibration..............................................................21

Capítulo 3 - Plataforma de test...........................................................................................22

3.1. Arquitectura...............................................................................................................22

3.1.1. Circuito Integrado AS3992...............................................................................23

3.1.1.1. Registros de configuración usados............................................................24

3.1.1.1.1. IRQ and status....................................................................................24

3.1.1.1.2. FIFO status.........................................................................................24

3.1.2. Microcontrolador...............................................................................................25

3.1.3. PC.....................................................................................................................25

3.1.4. Tag....................................................................................................................25

3.2. Interconexión de componentes................................................................................25

Capítulo 4 - Firmware..........................................................................................................27

- I -

4.1. Introducción..............................................................................................................27

4.2. Capas de comunicación...........................................................................................27

4.3. Firmware proporcionado por el fabricante................................................................29

4.3.1. Modificación de la ISR......................................................................................29

4.3.2. Validación de la función as399xWaitForResponseTimed................................30

4.4. Firmware EPC Gen2 desarrollado............................................................................31

4.5. Protocolo personalizado de comunicación entre microcontrolador y PC.................31

4.5.1. Comandos implementados...............................................................................31

4.5.2. Flujo de los comandos.....................................................................................33

4.5.2.1. Comando GetConfiguration.......................................................................33

4.5.2.2. Comando SetConfiguration........................................................................34

4.5.2.3. Comando StoreRN16.................................................................................34

4.5.2.4. Comando SingleRead................................................................................35

4.5.2.5. Comando CompleteSense.........................................................................35

4.5.2.6. Comando TestClockCalibration..................................................................36

4.6. Firmware para comunicación USB...........................................................................37

4.7. Función main del firmware.......................................................................................38

Capítulo 5 - Interfaz de usuario...........................................................................................40

5.1. Introducción..............................................................................................................40

5.2. Desarrollo de la GUI.................................................................................................40

5.2.1. Configuración del AS3992................................................................................41

5.2.2. Test...................................................................................................................42

5.2.3. Operación.........................................................................................................43

Capítulo 6 - Esquema demodulador...................................................................................44

6.1. Motivación.................................................................................................................44

6.2. Teoría básica de modulación y demodulación.........................................................44

6.2.1. Modulación.......................................................................................................44

6.2.2. ASK...................................................................................................................45

6.2.3. Demodulación...................................................................................................48

6.3. Esquema...................................................................................................................49

Capítulo 7 - Programas y periféricos utilizados..................................................................58

7.1. Introducción..............................................................................................................58

7.2. Silicon Labs IDE.......................................................................................................58

7.3. Keil 8051 Tools..........................................................................................................58

- II -

7.4. USBXpress...............................................................................................................59

7.5. Visual Basic 2010 Express Edition...........................................................................60

7.6. Osciloscopio..............................................................................................................60

Conclusiones y trabajo futuro.............................................................................................61

1. Conclusiones..............................................................................................................61

2. Trabajo futuro..............................................................................................................62

- Bibliografía........................................................................................................................63

- Anexos..............................................................................................................................66

1. Código fuente de la interfaz de usuario......................................................................66

1.1. USBXpress.vb.....................................................................................................66

1.2. Form1.vb.............................................................................................................67

- III -

Introducción

Capítulo 1 Introducción

1.1. Introducción a los sistemas de identificación basados enradiofrecuencia

Los procedimientos de identificación automática (Auto-ID) son muy populares en

muchas actividades relacionadas con campos tales como servicios, logística de compras

y distribución, industria o sistemas de flujo de materiales [1]. Estos procedimientos de

identificación automática sirven para proporcionar información acerca de personas,

animales y productos.

Las omnipresentes etiquetas de códigos de barra resultan actualmente inadecuadas

en cada vez más casos. En particular, sus principales limitaciones son su nula capacidad

de almacenamiento y la dificultad de leer identificadores debido a la proximidad y posición

en la que se deben poner los lectores.

Una solución es almacenar los datos en un chip de silicio. La forma más común de

aplicar esta solución es el uso de las tarjetas inteligentes (smart card). Esta tarjeta se

introduce en un lector, en el que se produce una conexión galvánica con las superficies de

contacto de la tarjeta. Sin embargo, este contacto mecánico es a menudo poco práctico,

lo que hace deseable una transferencia de información sin contacto entre el dispositivo

que contiene los datos y el lector, en aras de una mayor flexibilidad. Este tipo de sistemas

de identificación sin contacto se denominan sistemas RFID (Radio Frequency

IDentification, identificación por radiofrecuencia) [1].

En la Tabla 1.1 se comparan diversas tecnologías que se usan en los sistemas de

identificación automática, mostrando sus ventajas y desventajas.

RFID es un sistema de identificación por radiofrecuencia que está compuesto de 2

elementos:

• El transpondedor o tag, que se sitúa en el objeto que se quiere identificar (a partir

de ahora se le denominará tag).

Departamento de Electrónica y Electromagnetismo Página 1

Introducción

• El interrogador o lector, que dependiendo del diseño y la tecnología usada será un

dispositivo de lectura o de lectura/escritura (a partir de ahora se le denominará

lector, independientemente de si solo lee datos o si también tiene la capacidad de

escribirlos).

En la Figura 1.1 se muestra el esquema de un sistema RFID.

El lector típicamente contiene un módulo de radiofrecuencia (transmisor y receptor),

una unidad de control y un elemento de acoplamiento (bobina, antena) para comunicarse

con el tag, y opcionalmente para alimentarlo. Adicionalmente, muchos lectores también

disponen de una interfaz adicional (RS 232, USB, etc.) que les permita reenviar los datos

recibidos a otro sistema (PC, sistema de control robótico, etc.).

El tag, que es el dispositivo que almacena los datos de identificación en un sistema

RFID, normalmente consiste en un elemento de acoplamiento y un microchip.

Un lector recibe información de un tag transmitiendo una señal de radiofrecuencia al

tag. El tag responde o bien modulando el coeficiente de reflexión de su antena, enviando

así de vuelta una señal de información al lector (a este procedimiento de enviar

información al lector modificando el coeficiente de reflexión de la antena se le denomina

backscattering [12], y se muestra en la Figura 1.2); o bien usando su propio sistema de

transmisión, dependiendo del tipo de tag empleado, como se comentará más adelante. El

tipo de comunicación entre lector y tag es maestro-esclavo, también denominado ITF

(Interrogator-Talks-First) en el ámbito de RFID. Es decir, un tag solo responde cuando ha

sido interrogado por un lector.


Figura 1.1: El lector y el transpondedor son los componentes principales de un sistema RFID

Parámetros Código debarras

OCR Reconocimiento devoz

Biometría Smart card Sistemas RFID

Cantidad de datos(bytes)

1-100 1-100 - - 16-64k 16-64k

Densidad de los datos Baja Baja Alta Alta Muy alta Muy alta

Capacidad de lecturaautomática

Buena Buena Costosa Costosa Buena Buena

Capacidad de lecturapor personas

Limitada Simple Simple Difícil Imposible Imposible

Influencia desuciedad / humedad

Muy alta Muy alta - - Posible(contactos)

Ninguna

Influencia de coberturaóptica (visión directa)

Total Total - Posible - Ninguna

Influencia de direccióny posición

Baja Baja - - Unidireccional Ninguna

Degradación /desgaste

Limitado Limitado - - Contactos Ninguno

Coste (electrónica delectura)

Muy bajo Medio Muy alto Muy alto Bajo Medio

Costes de operación(ej: impresión)

Bajo Bajo Ninguno Ninguno Medio(contactos)

Ninguno

Copia/modificación noautorizada

Ligero Ligero Posible (cinta deaudio)

Imposible Imposible Imposible

Velocidad de lectura Baja ~4s Baja ~3s Muy baja >5s Muy baja >5-10s Baja ~4s Muy baja ~0,5s

Máxima distancia entrelector y tag

0-50 cm <1cm(escáner)

0-50 cm Contacto directo (huellasdactilares)

Contacto directo 0-5m,microondas

Tabla 1.1: Comparación de diferentes sistemas de identificación automática [1]

Introducción

La modulación más empleada en la comunicación es un esquema ASK (Amplitude

Shift Keying, modulación por desplazamiento de amplitud), ya que facilita la demodulación

de los datos [4].

Los distintos tipos de sistemas RFID se distinguen principalmente por la frecuencia

de las ondas de radiofrecuencia que se emplean, por la forma en que se proporciona

alimentación eléctrica a los tags, y por el protocolo que usan para comunicarse el lector y

el tag [2].

La mayor parte de la actividad de los sistemas RFID se concentra en ciertas bandas

de frecuencia establecidas por las distintas autoridades reguladoras. Las más habituales

son las de 125/134 kHz (en la zona del espectro denominada LF, Low Frequency, baja

frecuencia), 13,56 MHz (en la zona HF, High Frequency, alta frecuencia), 860-960 MHz y

2,4-2,45 GHz (en la zona UHF, Ultra High Frequency, frecuencia ultra alta) [2].

En los sistemas LF y HF la longitud de onda de la radiación electromagnética es

mucho mayor que el tamaño de la antena. En estas condiciones, casi toda la energía

emitida por la antena del lector está contenida en una región cercana a la antena y

comparable a esta en tamaño. A medida que el tag se aleja de la antena del lector, la

potencia que alcanza al tag decae rápidamente. En este caso, se dice que el lector y el

tag están acoplados inductivamente: el tag actúa como un transformador magnético,

proporcionando acoplamiento entre la corriente que fluye por el lector y la tensión en el

tag. Estos sistemas también se denominan near-field (campo cercano).

En los sistemas UHF la longitud de onda es comparable en tamaño a la antena. En

este caso se dice que existe acoplamiento radiativo entre lector y tag: el lector envía una


Figura 1.2: Esquema de comunicación con tag pasivo [13]

Introducción

señal al tag y este responde enviando de vuelta una onda distinta. La potencia decae más

lentamente con la distancia que en el caso inductivo. Estos sistemas también se

denominan far-field (campo lejano).

Se pueden resumir las consecuencias de la elección de una u otra frecuencia de

trabajo de la siguiente manera:

• El rango de alcance de los lectores LF y HF es comparable al tamaño de la antena;

en los sistemas UHF el rango viene dado por la potencia de transmisión.

• Las zonas de lectura en los sistemas acoplados inductivamente (LF y HF) es

pequeña pero simple; las zonas de lectura en los sistemas acoplados

radiativamente son mayores pero más complejas y a menudo discontinuas, y

lectores cercanos pueden interferir entre ellos.

• Los tags LF usan bobinas con muchas vueltas como antena. Los tags HF necesitan

menos vueltas. Los tags UHF usan antenas simple de tipo dipolo.

• La radiación LF penetra en el agua y materiales acuosos una distancia mucho

mayor que el rango de lectura de un sistema típico. La radiación HF penetra una

distancia comparable al rango de lectura, y en lo sistemas UHF la penetración en el

agua es despreciable.

• La radiación LF puede penetrar capas finas de material conductivo. Las radiaciones

HF y UHF son apantalladas incluso por láminas finas de material metálico.

• Los tags LF proporcionan una tasa binaria inferior a los tags HF. Los tags UHF

pueden operar a velocidades más altas aún.

Las diferentes características asociadas con cada banda de frecuencia hace que las

aplicaciones óptimas varíen de una banda a otra.

Los sistemas RFID LF son particularmente apropiados para identificación de

animales y humanos. Los lectores y tags no se ven afectados por la presencia de agua,

sal o similar. Por tanto, los tags pueden colocarse en la oreja de un animal, ser insertados

en el estómago o implantarse debajo de la piel. Estos sistemas también son populares

para el control de acceso a edificios o instalaciones. Un rango de lectura pequeño (un

metro o menos) es aceptable. La baja tasa de datos no es problemática, ya que no existe

la necesidad de identificar rápidamente un número elevado de tags.


Introducción

Los tags HF se usan ampliamente en tarjetas inteligentes sin contacto, para

transacciones financieras seguras. Las operaciones criptográficas requieren una energía

considerable, que se consigue a costa de reducir el rango de lectura. Esta reducción del

alcance también ayuda a evitar interceptaciones y uso involuntario de los tags presentes

en las tarjetas. La mayor tasa de datos permite un intercambio de información

relativamente complejo, necesario en sofisticadas transacciones financieras. Los tags HF

también se pueden usar, al igual que los LF, en el control de acceso a edificios. Asimismo,

se usan cada vez más en pasaportes con funcionalidad RFID. También se emplean en el

seguimiento de activos y gestión de suministros: la disponibilidad de alta energía (a corto

alcance) permite que los tags HF soporten amplios espacios de memoria, lo que se puede

usar para grabar una importante cantidad de información en los tags sobre el terreno.

Los tags UHF se benefician del amplio rango de lectura de estos sistemas.

Asimismo, la simplicidad de la antena de estos tags reduce su coste. Se usan

ampliamente en peajes automáticos para automóviles y seguimiento de vagones, casos

en los que el alcance de varios metros añade flexibilidad a la instalación. Se usan cada

vez más en la gestión de cadenas de suministro, seguimiento del transporte de equipaje y

seguimiento de activos, campos en los que el bajo coste es importante, y en los que el

largo alcance también añade flexibilidad. Un tag UHF equipado con una pila puede

alcanzar rangos de decenas o centenas de metros, y se puede usar para el seguimiento

de contenedores de transporte y para localizar activos concretos en grandes

instalaciones.

Según la forma en que se proporciona alimentación eléctrica a los tags, estos se

clasifican en pasivos, activos y semi-pasivos [2][4]:

• Tag activo: Se abastece de energía mediante una batería interna de larga

duración, y dispone de un transmisor propio. De esta forma se consiguen las

mayores coberturas, pero como contrapartida aumentará el coste del tag.

• Tag pasivo: No necesita ninguna batería para operar, ya que aprovechará la

energía electromagnética emitida por el lector y la acondicionará mediante una

transformación de tensión alterna a continua para poder generar las tensiones de

alimentación en el tag. No dispone de transmisor propio, por lo que para enviar

información de vuelta al lector usará backscattering.

• Tag semi-pasivo: Es una solución híbrida entre uno pasivo y uno activo, ya que

con la potencia que obtiene de la señal RF procedente del lector alimentará gran

parte de la circuitería del tag, pero los bloques más demandantes de corriente


Introducción

serán alimentados por una batería. Al igual que el pasivo, no dispone de transmisor

propio y usará backscattering para enviar información al lector.

En cuanto a los protocolos RFID que siguen para comunicarse los lectores y tags, en

la Tabla 1.2 se muestran algunos de ellos, clasificados en función de la frecuencia de

trabajo y del tipo de tag que contemplan. Los diversos protocolos especifican distintos

requerimientos físicos y lógicos para la comunicación, como los símbolos y la codificación

empleada, la modulación que se utiliza y el procedimiento de resolución de colisiones (por

ejemplo, en el caso de que haya múltiples tags en la zona de acción de un lector).

Por ejemplo, los protocolos ISO 11784 [14] y 11785 [15], y su versión actualizada

ISO 14223 [16], están diseñados para la identificación de ganado. ISO 14443 [18] soporta

tarjetas inteligentes en la frecuencia de 13,56 MHz. ISO 15693 [19] también soporta

tarjetas inteligentes a 13 MHz, pero usa esquemas distintos para las comunicaciones

entre lectores y tags y para la resolución de colisiones. El protocolo Title 21 [20] fue

diseñado para los sistemas de peaje para automóviles de California.

El organismo de estandarización de sistemas RFID EPCGlobal también ha

desarrollado diversos estándares describiendo protocolos de comunicación entre lectores

y tags. Los primeros que lanzó fueron dos protocolos en la banda UHF para tags de Clase

0 (solo lectura y con memoria programada en el momento de la fabricación) y Clase 1

(solo lectura y con memoria no volátil programable una sola vez), con el objetivo de que

se empezara a comercializar la tecnología EPC [21], consistente en un sistema de

numeración universal para la identificación de productos. Posteriormente EPCGlobal

lanzó la segunda generación de sus protocolos, HF EPC Class-1 Generation-2 (HF EPC

C1 Gen2) y UHF EPC Class-1 Generation-2 (UHF EPC C1 Gen2), que permitieron

compatibilidad con la serie ISO 18000 (el protocolo UHF EPC C1 Gen2 ha sido aprobado

por ISO como el estándar ISO 18000-6C). Además, esta generación permitió la escritura y

lectura de los tags de Clase 1, y se añadieron opciones de seguridad como la

autentificación de usuarios y bloqueo de determinadas zonas de memoria, y un arbitraje

eficiente para poblaciones de tags.

La tecnología EPC es la dominante en la actualidad [4].

A partir de los comandos enviados por el lector, el tag seleccionado proporciona la

información solicitada. En los llamados tags de sensado (sensory tags) esta información

puede consistir no solo en datos de identificación, sino también en lecturas de variables

del entorno (por ejemplo, temperatura, presión, variables ópticas o químicas,...) obtenidas

a partir de una interfaz de sensado embebida [3]. En este trabajo nos interesa la


Introducción

posibilidad que ofrecen estos tags de sensado de ser usados en aplicaciones biomédicas,

en las que el tag estaría adherido a un paciente, y mediante su etapa de sensado podría

obtener los valores de variables de interés relacionadas con la salud, bajo la dirección del

lector. Los datos medidos por el tag y recibidos por el lector podrían ser transmitidos a

otro sistema para su procesamiento.

Tipo de tag Frecuencia

125/134 kHz 5-7 MHz 13,56 MHz 303/433MHz

860-960MHz

2,45 GHz

Pasivo ISO11784/5,14223ISO18000-2HiTag

ISO10536iPico DF/iPX

MIFAREISO14443Tag-ITISO15693ISO18000-3TIRISIcode

ISO18000-6A,B,CEPC class 0EPC class 1IntellitagTitle 21AAR S918Ucode

ISO18000-4Intellitagµ-chip

Semi-pasivo AAR S918Title 21EZPassIntelleflexMaxim

ISO18000-4Alien BAP

Activo ANSI 371.2ISO18000-7RFCode

ISO18000-4ANSI 371.1

Tabla 1.2: Resumen de los protocolos más empleados en la actualidad, ordenados en función deltipo de tag y su frecuencia de trabajo [2]

1.2. Objetivos y alcance del proyecto

En este caso en particular estamos interesados en programar un lector que tiene

como objetivo comunicarse con un tag pasivo diseñado para la medida de temperatura y

pulso cardiaco en un paciente.

Este tag sensor de señales biomédicas ha sido diseñado para ser compatible (con

algunas especificidades, como se comentará más adelante) con el protocolo UHF EPC

Class-1 Generation-2 (en adelante EPC Class 1 Gen 2 o simplemente EPC Gen2), que es

un protocolo específico para sistemas RFID, operando en el rango de frecuencias de 860

a 960 MHz, y que define unos requerimientos físicos y lógicos para lectores y tags. Este

protocolo solo contempla tags pasivos.

El tag fue diseñado con la idea de ser adherido a un paciente, y poder ser

interrogado por un lector presente en la misma habitación, por lo que el rango típico de la


Introducción

comunicación podría estar entre 1 y 3 metros. Para conseguir esta cobertura se eligió

como banda de operación la de UHF. Asimismo, para aumentar el confort del paciente y

disminuir el precio del tag, se optó por diseñar un tag pasivo. De entre los protocolos

disponibles para la banda UHF y que contemplen tags pasivos, dado que también se

pretendía hacer el sistema compatible con el protocolo más utilizado para la banda

elegida, y que el tag tuviera cierta proyección en el ámbito de la industria, se eligió el

protocolo UHF EPC C1 Gen2 [4].

El tag fue diseñado en paralelo a este trabajo, por lo que aún no estaba disponible

cuando se programó el lector. Se han usado tags pasivos con capacidad básica de lectura

y escritura con fines de depuración.

Como se verá más adelante, el tag requiere una temporización ligeramente distinta a

la que especifica el protocolo EPC Gen2, y la implementación de algunos comandos y

operaciones específicos en el lector, tanto para la calibración y test del tag como para

obtener medidas biomédicas una vez que se esté usando. Se necesita poder controlar y

ordenar estas operaciones desde una interfaz de usuario en un PC, que estará conectado

al lector.

Por tanto, se hace necesario usar un lector que permita un alto grado de

personalización. La mayoría de los lectores comerciales [5][6][7][8] implementan funciones

simples de lectura y escritura de tags, y resulta complicado personalizar los tiempos de

respuesta del lector e incluso la forma en que se accede a los tags.

Para este trabajo se ha partido del kit de demostración “ROGER” [9] - UHF RFID

Reader System del fabricante austriamicrosystems, que consiste en una placa de circuito

impreso que incluye, en la versión usada, el chip lector RFID AS3992 [10], de la misma

compañía, que ofrece gran flexibilidad para su programación y soporta el protocolo EPC

Gen2. Asimismo, como se verá más adelante, se ha comprobado que este lector permite

comunicarse con el tag cumpliendo la temporización requerida por este.

La placa también dispone de un microcontrolador, que se encarga de manejar el chip

lector de acuerdo con las instrucciones de su programa. Al programa que ejecuta el

microcontrolador se le denomina en adelante firmware.

Asimismo, el microcontrolador dispone de una interfaz USB, por lo que es posible

conectar un PC por USB a la placa para interactuar con el microcontrolador para que el

lector lleve a cabo con el tag las operaciones que se le indiquen.

El fabricante del lector usado proporciona el código de algunas funciones básicas,


Introducción

que se han usado como base para desarrollar las funciones, comandos y operaciones que

requiere el tag sensor de señales biomédicas.

Por tanto, este trabajo consiste en la programación del lector mencionado y la

elaboración de una interfaz de usuario en el PC para operar el lector.


Flujo de comunicación personalizado compatible con el estándar EPC C1 Gen2

Capítulo 2 Flujo de comunicación personalizado compatible con el estándar EPC C1 Gen2

2.1. Introducción al protocolo EPC C1 Gen2

2.1.1. Comandos

Según el protocolo EPC Class-1 Generation-2 UHF RFID [11] (para comunicaciones

en el rango 860 MHz – 960 MHz) la comunicación entre el lector y el tag (o los tags) se

realiza mediante un flujo de comandos, que se relacionan en la Tabla 2.1. En este

protocolo la comunicación RFID se divide en 3 fases llamadas Selección, Inventario y

Acceso. Por tanto, los comandos existentes corresponderán a alguna de estas 3 fases de

la comunicación. En primer lugar se usa un comando de la categoría de Selección, para

elegir de entre la población de tags presentes dentro del rango del lector aquél o aquellos

con los que se quiera establecer la comunicación. A continuación se utilizan comandos de

la categoría de Inventario para realizar el procedimiento mediante el cual el lector

identifica a los tags: el lector envía un comando, al que en general responderá un solo tag

(se usa un algoritmo de arbitraje para intentar evitar que varios tags respondan a la vez; si

a pesar de ello varios tags responden simultáneamente el lector puede o bien intentar

resolver la colisión o bien enviar otro comando de Inventario para intentar que responda

un solo tag). El lector detecta la respuesta del tag y solicita su código de identificación

(llamado EPC, Electronic Product Code, en el protocolo EPC Class-1 Generation-2). Por

último, se realiza el acceso (lectura o escritura) al tag identificado anteriormente, mediante

el uso de comandos de la categoría Acceso.

2.1.2. Comunicación Lector a Tag

Un lector se comunica con un tag modulando una portadora de radiofrecuencia

usando una modulación digital en amplitud.

La codificación de los datos que se usa es PIE (Pulse-Interval Encoding). En la



Figura 2.1 se muestran los símbolos binarios usando la codificación PIE.

Tari es el intervalo temporal de referencia para las comunicaciones de lector a tag, y

coincide con la duración de un 0 binario. El valor de Tari debe estar comprendido entre

6,25 y 25 µs.

El protocolo especifica los rangos de valores que deben cumplir los tiempos de

subida y bajada de las señales y PW (Pulse Width).

Todos los comandos que el lector envíe al tag estarán precedidos o bien de una

trama denominada preámbulo o bien de una señal denominada frame-sync.

El preámbulo antecede al primer comando que se envía en la fase de Inventario (es

decir, al comando Query). Su estructura se muestra en la Figura 2.2.


Figura 2.1: Símbolos PIE

Figura 2.2: Preámbulo (Lector a Tag)


Categoría Comando Descripción

Selección Select Permite seleccionar de entre la población de tags presentesaquéllos con los que se quiere establecer la comunicación.

Inventario

Query Inicia el procedimiento de identificación de los tags. Especificaparámetros de la comunicación tag a lector, elige qué tags puedenresponder con su identificación y especifica la probabilidad de quelos tags respondan. Tiene como parámetros:• DR: determina, junto con la longitud del símbolo TRcal, como severá más adelante, la frecuencia de la comunicación tag a lector.• M: determina el tipo de codificación en la comunicación tag alector, eligiendo entre FM-0 y varias posibilidades de Sub-Portadora Miller.• TRext: determina el tipo de preámbulo que se enviará en elenlace tag a lector.• Sel, Session y Target: definen cómo será realizada la fase deInventario de los tags.• Q: determina el valor máximo de la población de tags, de formaque el máximo número de etiquetas que podrá arbitrar el algoritmode anti-colisión presente en el estándar será 2Q.

QueryAdjust Se usa para modificar el parámetro Q (es decir, para variar lapoblación máxima de tags). Solo es útil cuando se trabaja con másde un tag.

QueryRep Se usa repetidas veces hasta que responda un tag. Solo es útilcuando se trabaja con más de un tag.

ACK Se usa para singularizar un tag concreto, con el que a continuaciónse realizarán las operaciones de Acceso.

NAK Se usa para devolver los tags al estado en el que esperan unQuery.

Acceso

Req_RN Se usa para solicitar al tag el envío de un nuevo número aleatoriode 16 bits (RN16).

Read Se utiliza para leer una parte específica de la memoria del tag.

Write Se usa para escribir una palabra de 16 bits en la memoria del tag.

Kill Se utiliza para inhabilitar un tag permanentemente. Esta operaciónes irreversible.

Lock Permite restringir las operaciones de lectura/escritura endeterminada región de la memoria del tag. Esta operación esreversible.

Access Se usa para poner al tag en el estado en que el que se permite la ejecución de los comandos Lock y BlockPermalock.

BlockWrite Permite escribir múltiples palabras en la memoria de un tag con unsolo comando.

BlockErase Permite borrar múltiples palabras de la memoria de un tag con unsolo comando.

BlockPermalock Permite bloquear permanentemente la escritura en parte de lamemoria del tag.

Tabla 2.1: Comandos EPC Gen2



El preámbulo incluye un símbolo de calibración de lector a tag, denominado RTcal

(Reader to Tag calibration), y un símbolo de calibración de tag a lector, denominado TRcal

(Tag to Reader calibration).

• RTcal: La mitad de RTcal se denomina pivot, y se utilizará por el tag para

decodificar los símbolos como ceros o unos. Si un símbolo tiene una duración

mayor al pivot, se corresponderá con un uno lógico, y si es menor, con un cero

lógico.

• TRcal: Este símbolo especifica, junto con el parámetro DR (Divide Ratio) del

comando Query, la frecuencia de la comunicación en el sentido tag a lector

(denominada BLF, Backscatter Link Frequency). La relación entre estos parámetros

se especifica en la ecuación (1).

BLF=DR

TRcal (1)

La frecuencia BLF coincide con el régimen binario de la comunicación tag a lector o

bien es 2, 4 u 8 veces el régimen binario, dependiendo de la codificación utilizada.

La trama frame-sync antecede al resto de comandos. Su estructura se muestra en la

Figura 2.3.

2.1.3. Comunicación Tag a Lector

Un tag se comunica con un lector alternando el coeficiente de reflexión de su antena

entre dos estados, de acuerdo con el dato que se esté enviando (a esta comunicación

variando el coeficiente de reflexión se le denomina backscattering).


Figura 2.3: Frame-Sync


El tag elige el formato de la modulación. El lector especifica la codificación y el

régimen binario usando el comando Query.

La modulación que se utiliza en la comunicación de tag a lector es en amplitud (ASK)

o en fase (PSK, Phase Shift Keying, modulación por desplazamiento de fase).

La codificación es o bien FM0 (bi-phase space) en banda base o bien una

codificación Miller en la que la señal en banda base se multiplica por una subportadora

que consiste en una señal cuadrada con una frecuencia que es 2, 4 u 8 veces el régimen

binario (esta frecuencia sería BLF).

BLF puede variar entre entre 40 y 640 kHz.

2.2. Flujo de comunicación estándar

El flujo completo de una comunicación típica entre un lector y un tag podría ser el

mostrado en la Figura 2.4.

En primer lugar se transmite el comando Select (el único comando de la categoría de

Selección).

A continuación se usa el comando Query, el primero de la categoría de Inventario,

que especifica algunos parámetros de la comunicación en ambos sentidos entre lector y

tag. Al comando Query pueden responder uno o más tags. La respuesta de los tags

consiste en un número aleatorio de 16 bits, al que se denomina RN16 (Random Number

16 bits, número aleatorio de 16 bits). El lector detecta la respuesta de uno de los tags (si

hay más de una respuesta el lector puede usar un procedimiento de resolución de

colisiones). A continuación se envía el comando ACK (ACKnowledge, confirmar), usando

como parámetro el RN16 con el que respondió el tag. De esta forma se singulariza un

único tag (caso de que hubiera más de uno presente). El tag responde al ACK con su

identificación: PC (Protocol-Control, que incluye la longitud del EPC), EPC (Electronic

Product Code, que es la identificación del objeto al que irá unido el tag) y un CRC de 16

bits calculado por el tag y almacenado en su memoria denominado StoredCRC16.

En la fase de Acceso se usa en primer lugar el comando Req_RN (Request Random

Number, solicitar número aleatorio), ante el cual el tag responde con un nuevo número

aleatorio de 16 bits, llamado handle, y que se usa como parámetro en los otros comandos

de acceso. A continuación se ha usado el comando Write, para escribir datos en la

memoria del tag, y por último el comando Read para leer datos de la memoria del tag.



2.2.1. Temporización del flujo de comunicación

El protocolo EPC Gen2 establece unos requisitos temporales para la transmisión y

recepción de comandos entre lector y tag, como se muestra en la Figura 2.5.

La descripción y los valores de los parámetros que establecen la temporización de la

comunicación se expresan en la Tabla 2.2.

Tpri es el periodo de la comunicación en el sentido tag a lector. Se define como 1/BLF.

FT es la tolerancia en frecuencia, también establecida por el protocolo.


Figura 2.4: Ejemplo de flujo decomunicación entre lector y tag


Parámetro Mínimo Nominal Máximo Descripción

T1MAX(RTcal,10Tpri) x

(1-|FT|)-2µsMAX(RTcal,

10Tpri)MAX(RTcal,10Tpri) x

(1+|FT|)+2µs

Tiempo desde latransmisión del lector hastala respuesta del tag.

T2 3.0Tpri 20.0Tpri

Tiempo de respuesta dellector requerido si el tagtiene que demodular laseñal del lector.

T3 0.0Tpri

Tiempo que el lectorespera, tras T1, antes detransmitir otro comando.

T4 2.0 RTcalTiempo mínimo entre doscomandos del lector.

Tabla 2.2: Parámetros de temporización de la comunicación entre lector y tag

2.2.1.1. T2

Dado que en este trabajo se programa un lector, el parámetro más crítico es T2, que

especifica el tiempo en que tiene que enviar el siguiente comando el lector tras recibir la

respuesta del tag. En el desarrollo del trabajo, como se verá en el Capítulo 4, se prestará

una especial atención al cumplimiento de la temporización establecida por este


Figura 2.5: Temporización de la comunicación entre lector y tag


parámetro.

2.2.1.2. Tiempo de respuesta al comando Write

Asimismo el protocolo, cuando describe los distintos comandos, indica que si el

lector, tras enviar el comando Write, no obtiene una respuesta por parte del tag en 20ms,

el comando Write no se ha completado satisfactoriamente.

2.3. Particularidades para el tag sensor de señales biomédicas

2.3.1. Temporización

En el caso que se está tratando (comunicación entre el lector y el tag para la lectura

de señales biomédicas), el flujo de comandos que se propone es igual al comentado

anteriormente: se selecciona e identifica el tag, se escribe en la memoria del tag unos

datos predeterminados (en función de si queremos que el tag realice el sensado de

temperatura, ECG o ambos) y a continuación se lee la memoria del tag, donde se habrá

almacenado la lectura de las señales biomédicas elegidas.

Sin embargo, el comportamiento del tag en el caso en que estamos interesados

consiste en medir la señal biomédica cuando recibe el comando Write, y una vez que la

ha obtenido, responder con el handle, como se observa en la Figura 2.6.

El tiempo estimado para que el tag obtenga la medida de la señal biomédica (que es

de varios segundos, hasta un máximo de 10s [4]) excede con mucho del que el protocolo

especifica para la respuesta del tag al comando Write (20ms), por lo que a la hora de

programar el dispositivo habrá que tener en cuenta esta temporización, y considerar

satisfactoria la respuesta del tag aunque se produzca pasados los 20ms.

2.3.2. Comandos implementados

A continuación se describen los comandos EPC Gen2 implementados en este

trabajo.



2.3.2.1. Comandos obligatorios

Los lectores y tags que cumplan el protocolo EPC Gen2 deben implementar una

serie de comandos, denominados comandos obligatorios.

Para la aplicación que se está tratando, se han implementado en el lector solo

aquellos comandos obligatorios que son necesarios para la comunicación con el tag

sensor de señales biomédicas, como se muestra en la Tabla 2.3.


Figura 2.6: Flujo de comunicación propuestopara la medición de señales biomédicas


Categoría Comando Implementado

Selección Select SÍ

Inventario

Query SÍ

QueryAdjust NO

QueryRep NO

ACK SÍ

NAK Proporcionado por el fabricante

Acceso

Req_RN Proporcionado por el fabricante

Read SÍ

Write SÍ

Kill NO

Lock SÍ

Tabla 2.3: Comandos obligatorios implementados

Los comandos QueryAdjust y QueryRep se usan para gestionar las respuestas de

los tags cuando hay más de uno. En este caso solo se ha contemplado la comunicación

con un único tag, por lo que no se han implementado estos comandos.

El comando NAK (Negative AcKnowledgment) se puede usar en cualquier momento

para terminar las comunicaciones con el tag. El tag vuelve al estado en el que permanece

a la espera de recibir un comando Query, denominado estado arbitrate. El protocolo EPC

Gen2 recomienda que antes de quitar la alimentación los lectores finalicen la

comunicación con el tag, dejándolo en este estado. El comando NAK está soportado

nativamente por el lector AS3992, y no requiere ningún parámetro, por lo que se ha usado

la versión proporcionada por el fabricante.

El comando Req_RN está soportado nativamente por el lector AS3992. Siempre usa

como parámetro el último RN16 recibido, que el lector AS3992 almacena

automáticamente. Por lo tanto se ha usado la versión proporcionada por el fabricante.

El comando Lock se puede usar para permitir o impedir la escritura en la memoria

del tag. El comando Lock no se usa en las operaciones desarrolladas en este trabajo para

el tag pero se ha implementado por si se considera oportuno su uso futuro.

El comando Kill se puede usar para deshabilitar un tag permanentemente. No es

necesario implementarlo para la comunicación con el tag desarrollada en este trabajo.



2.3.2.2. Comandos personalizados

El protocolo EPC Gen2 contempla la posibilidad de implementar lo que llama custom

commands (comandos personalizados). Para ello el protocolo reserva un rango de

códigos de comando (concretamente el código de comando de los comandos

personalizados debe tener 16 bits y comenzar por 1110).

El tag sensor de señales biomédicas requiere que el lector que se use para

comunicarse con él implemente dos comandos personalizados en concreto. Estos

comandos se han denominado ClockCalibration y SensorCalibration [4].

2.3.2.2.1. Comando ClockCalibration

El tag hace uso de este comando para la calibración del reloj. Su estructura se

muestra en la Tabla 2.4.

Código calWord

Número de bits 16 8

Descripción 1110 0000 0000 0000 Palabra de calibración

Tabla 2.4: Comando ClockCalibration

El único parámetro de este comando es un byte cuyo contenido se usará para la

calibración.

2.3.2.2.2. Comando SensorCalibration

El tag hace uso de este comando para la calibración del sensor. Su estructura se

muestra en la Tabla 2.5.

Código numBits

Número de bits 16 7 80 + numBits

Descripción 1110 0000 0000 0001 Número de 0s paratransmitir

000...0

Tabla 2.5: Comando SensorCalibration

En este comando, tras el código del mismo, se transmite un número de 0s lógicos

marcado por el parámetro numBits. Se transmiten 80 + numBits 0s, por lo que, dado que

el valor de numBits puede oscilar entre 0 y 127, el número de 0s que se transmitirá

oscilará entre 80 y 207.


Plataforma de test

Capítulo 3 Plataforma de test

3.1. Arquitectura

En la Figura 3.1 se muestran los distintos componentes de la plataforma de test que

se ha utilizado, con indicación de los lugares en que se ha desarrollado software.

La parte más importante de la plataforma es el AS399x UHF RFID Reader System

Demo Kit (ROGER) del fabricante austriamicrosystems. Este demo kit incluye una placa

de circuito impreso cuyo componente principal es el chip AS3992, que hace funciones de

lector RFID y soporta el protocolo EPC Gen 2. La placa dispone asimismo de un

microcontrolador, concretamente el C8051F340 del fabricante Silicon Labs (Silabs), que

se encargará de controlar el lector.

El microcontrolador se programará haciendo uso del dispositivo USB Debug Adapter


Figura 3.1: Esquema de la plataforma de test

Plataforma de test

de Silabs [22]. En la documentación del ROGER se indica cómo conectar el USB Debug

Adapter a la placa y cómo configurar la aplicación para PC Silicon Labs IDE para volcar al

micro el firmware desarrollado con dicha aplicación.

Asimismo, dado que el microcontrolador soporta comunicación por USB y la placa

ROGER dispone de dicha conexión, se ha desarrollado una GUI (Graphical User

Interface, Interfaz Gráfica de Usuario) en el PC, usando Microsoft Visual Basic 2010

Express, para poder controlar diversas operaciones de comunicación por RFID desde el

ordenador.

3.1.1. Circuito Integrado AS3992

El chip AS3992 UHF Gen2 Reader soporta el uso de los protocolos ISO 18000-6c

(EPC Gen2) e ISO18000-6a,b usados en sistemas RFID. Dispone de un front-end

analógico de radiofrecuencia y de un controlador digital que gestionará las

comunicaciones con el microcontrolador externo y que proporciona las funciones

necesarias en el protocolo EPC Gen2.

La configuración del lector se consigue configurando varios registros de control, que

permiten especificar con precisión los diversos parámetros de operación.

El sistema de transmisión del lector soporta la generación automática de las señales

de control FrameSync y Preámbulo, así como del CRC, a la hora de enviar comandos

EPC Gen2.

El sistema receptor comprueba el CRC y organiza los datos en bytes. El

microcontrolador puede acceder a los datos recibidos a través de un registro de 24 bytes

de tipo FIFO.

La comunicación entre el circuito integrado AS3992 y el microcontrolador se puede

efectuar de dos modos distintos:

• Modo normal: los datos que se transmiten y se reciben son transferidos usando el

registro FIFO, y todo el procesamiento de los datos del protocolo se realiza

internamente (generación de FrameSync y Preámbulo, comprobaciones de

CRC,...).

• Modo directo: la señal de banda-base utilizada en la transmisión se introduce

directamente en el AS3992 y este la modulará.


Plataforma de test

En este caso se va a usar el modo normal, ya que facilita la generación de los

comandos del protocolo y no existe la necesidad de controlar en mayor medida las

señales.

3.1.1.1. Registros de configuración usados

3.1.1.1.1. IRQ and status

Este registro muestra la causa de una interrupción que se haya producido, y el

estado de la transmisión o recepción. Su contenido se muestra en la Tabla 3.1.

Bit Nombre Función Comentarios

B7 Irq_txInterrupción por el finde la TX

B6 Irq_srxInterrupción por elinicio de la RX

B5 Irq_fifo

Interrupción debida aque la FIFO tienemenos de 6 o más de18 bytes

B4 Irq_err1Interrupción por errorde CRC

B3 Irq_header

Interrupción por erroren el bit header

El bit header se activaen la respuesta del taga un comando deacceso cuando elmismo no se ha podidocompletar.

B2 Irq_err2

Interrupción por erroren la cuenta en RX

Indica almicrocontrolador que larecepción fue máscorta de lo esperado.

B1 Irq_err3Interrupción por erroren la detección delPreámbulo

B0 Irq_norespInterrupción por norespuesta del tag

Tabla 3.1: Descripción del registro IRQ and status

3.1.1.1.2. FIFO status

Este registro muestra el número de bytes recibidos y las flags que indican el estado

de la FIFO. Su contenido se muestra en la Tabla 3.2.


Plataforma de test

Bit Nombre Función Comentarios

B7 Fhil Nivel alto de la FIFO Indica que ya hay 18bytes en la FIFO (paraRX)

B6 Flol Nivel bajo de la FIFO Indica que solo quedan6 bytes en la FIFO(para TX)

B5 Fove Error dedesbordamiento de laFIFO

B4 Fb4 Bytes en la FIFO fb[4]

Cuántos bytes en laFIFO no se han leídotodavía





Tabla 3.2: Descripción del registro FIFO Status

3.1.2. Microcontrolador

El microcontrolador que incluye la placa ROGER es el C8051F340 del fabricante

Silicon Labs. De entre las prestaciones que ofrece las más destacadas para este trabajo

son su soporte para USB y la posibilidad de programación y depuración incluso si, como

es el caso, el chip está instalado en el sistema.

3.1.3. PC

Se ha usado un PC con Windows 7 para gestionar la programación del

microcontrolador y para ejecutar la GUI.

3.1.4. Tag

Se han utilizado 3 tags con fines de depuración, para realizar las diversas pruebas

de identificación, lectura y escritura.

3.2. Interconexión de componentes

El PC se comunica con la placa ROGER de dos maneras:

• Por un lado con la interfaz USB del microcontrolador, para enviar y recibir datos

relacionados con la operación del lector AS3992.


Plataforma de test

• Por otro lado, también usando una interfaz USB, con el dispositivo USB Debug

Adapter, el cual a su vez se conecta a la placa haciendo uso de la interfaz llamada

C2 del microcontrolador, que permite la programación del microcontrolador y la

ejecución del firmware en modo debug. El conector procedente del USB Debug

Adapter es un conector de 10 pines, de los cuales solo hacen falta 3 pines para la

comunicación usando la interfaz C2 [22], que son los que se conectan a la placa.

El microcontrolador se conecta con el AS3992 haciendo uso de la interfaz de

comunicación paralela que ofrece el lector, y que es el modo de comunicación normal

(también es posible la comunicación en modo serie si se requiere).

El conector para la antena del que dispone la placa ROGER es del tipo MMCX.

La comunicación entre la antena y el tag consiste, obviamente, en el intercambio de

comandos RFID del protocolo EPC Gen 2.


Firmware

Capítulo 4 Firmware

4.1. Introducción

El kit ROGER incluye una memoria USB que contiene un software de demostración,

documentación acerca del sistema y, como se vio en el Capítulo 3, el código fuente de

una serie de funciones escritas en C pensadas para ser usadas en la programación del

microcontrolador (es decir, una API) y que permiten realizar diversas operaciones con el

lector AS3992.

Todo el firmware se ha realizado utilizando como base estas librerías ofrecidas por

austriamicrosystems. A partir de ellas se ha desarrollado el firmware que permite enviar

diversos comandos EPC Gen 2 y el firmware que permite realizar diversas operaciones de

interés en la comunicación con el tag sensor de señales biomédicas.

4.2. Capas de comunicación

En la Tabla 4.1 se indican las capas en las que están estructuradas las funciones

proporcionadas por austriamicrosystems como parte del demo kit ROGER para programar

el microcontrolador de la placa.

En este caso se pretenden implementar diversos comandos de utilidad para la

aplicación de la plataforma a la medida de señales biomédicas. Las funciones de la

librería gen2 proporcionada por el fabricante están orientadas al programa de

demostración y no presentan la flexibilidad necesaria para poder ser usadas con facilidad

para esta aplicación, ya que cada una de ellas implica un flujo concreto de comandos

EPC Gen2 y usan una estructura de datos para almacenar la información del tag

predefinida, por lo que se escribirán nuevas funciones haciendo uso de las capas

inferiores interface y as399x, que proporcionan la funcionalidad básica para manejar el

lector a nivel de comandos individuales EPC Gen2, y de la capa genérica as399x_public,

para la inicialización del sistema.


Firmware

application codeCapa superior en la que se ejecuta laaplicación.

gen2 iso6b as399x_public

Capa de protocolo en que se hace laejecución.• as399x_public

◦ Definición de una estructura de datospara almacenar la información de un tag◦ Inicialización y reseteo del AS3992◦ Activación de la antena◦ Medida RSSI

• gen2◦ Funciones para diversas operacionesRFID: búsqueda de tags en el entorno,configuración, escritura y lectura de lostags...

as399x

Procedimientos específicos del dispositivolector.• Definiciones de códigos de comandos delAS3992• Envío y lectura de un comando RFID• Lectura y escritura de la FIFO para enviar yrecibir datos

interface

Capa de interfaz para la comunicación con elchip lector.• Definiciones de pines del µC• Inicialización de la interfaz de comunicaciónparalela• Configuración de modo normal o directo

Tabla 4.1: Capas de las librerías para el AS3992 proporcionadas por el fabricante

Asimismo, dado que la plataforma se va a manejar desde una GUI que se ejecutará

en el PC, se escribirán las funciones adecuadas para interpretar y gestionar los datos

recibidos por el microcontrolador desde el PC a través de la interfaz USB y para enviar a

la GUI la información que se requiera según la operación que se esté realizando con la

plataforma.

Por tanto, el software para esta aplicación quedaría estructurado como se describe

en la Figura 4.1 (se han sombreado las capas que se han implementado en este trabajo).


Firmware

En la capa Firmware EPC Gen2 estarían incluidas las funciones que se han escrito

para enviar comandos EPC Gen2 simples, y en la capa de Protocolo personalizado se

incluirían una serie de comandos, cada uno de los cuales puede constar de varios

comandos EPC Gen2, y que se corresponden con operaciones que resultan de interés

para la aplicación de la plataforma al tag de medida de señales biomédicas.

4.3. Firmware proporcionado por el fabricante

Se ha hecho uso de las capas inferiores de la API proporcionada para el fabricante

para escribir otras funciones, pero también en algún caso ha habido que modificar y

analizar las propias funciones de la API, como se comenta a continuación.

4.3.1. Modificación de la ISR

Un pin de entrada del microcontrolador (el P0.3) se configura como interrupción

externa, y a él está conectado el pin de salida IRQ del chip AS3992, que se activa cuando

se cumple alguna condición relacionada con la operación del lector (fin de transmisión,

inicio de recepción, FIFO llena o vacía, error de CRC, recepción más corta de lo

esperado, error de preámbulo, no respuesta,...). Cuando esto ocurre, se ejecuta en el

microcontrolador la ISR (Interrupt Service Routine, rutina de servicio de la interrupción)

correspondiente, que es proporcionada por el fabricante en la capa as399x (fichero

as399x.c) del firmware.

Esta ISR inicialmente lee el registro IRQ and status del AS3992, y comprueba la

causa de la interrupción, y almacena en una variable global volátil (as399xResponse) los

valores del registro de interrupciones y del registro FIFO status del AS3992. Esta variable


Figura 4.1: Capas de software para esta aplicación

Firmware

global se usa como una flag para indicar una recepción de datos: las funciones que se

usan para comprobar si se han recibido o enviado datos al tag (también incluidas en el

fichero as399x.c) son as399xWaitForResponse y as399xWaitForResponseTimed, que

hacen timeout cuando agotado un contador o pasado un tiempo determinado,

respectivamente, la ISR no ha escrito un valor en la variable as399xResponse.

Como se vio en el Capítulo 2, el protocolo EPC Gen2 especifica unos requisitos de

temporización relativamente estrictos. En particular, el tag debe responder a los

comandos Query y ACK del lector en un tiempo T2, ya que de lo contrario el tag vuelve al

estado arbitrate y no podría continuar el flujo normal de la comunicación.

En las diversas pruebas que se han realizado, se ha comprobado que a la hora de

implementar un flujo normal no era posible cumplir la temporización, por lo que se ha

modificado la ISR añadiendo una variable global, que se activará cuando se vaya a enviar

uno de estos dos comandos, y que se comprobará en la ISR para que en el caso de que

se haya activado la interrupción de recepción y la variable mencionada esté activada, se

vuelva inmediatamente de la ISR sin hacer más comprobaciones. Asimismo se ha

implementado la función as399xWaitForResponseToQueryOrACK para esperar las

respuestas a los comandos en estos dos casos concretos.

4.3.2. Validación de la función as399xWaitForResponseTimed

Como se vio en el Capítulo 2, el protocolo EPC Gen2 especifica que la respuesta del

tag al comando Write debe producirse en 20 ms como máximo, mientras que para el caso

del tag sensor de señales biomédicas la tardanza de esta respuesta se estima en unos 10

s. Por tanto, habrá que comprobar que el firmware que se va a ejecutar en esta aplicación

permite la comunicación con un tag que tarde más tiempo en responder al Write del

especificado por el protocolo.

En este caso, tras enviar el Write al tag se ejecuta la función

as399xWaitForResponseTimed, que espera durante el tiempo en ms que se le pase como

parámetro a que se produzca una interrupción (en este caso la interrupción que se espera

es la de recepción de datos). Si se sobrepasa el tiempo especificado, y se escribe en la

variable as399xResponse el valor que indica que no se ha obtenido respuesta y se

resetea el dispositivo.

El parámetro que indica el tiempo que se va a esperar la respuesta antes de hacer

timeout es una variable del tipo u16 (unsigned int16), es decir, un número de entero de 16

bits. Por tanto puede almacenar un valor entero desde 0 hasta 65535, que se


Firmware

correspondería, dado que la unidad que expresa el parámetro son milisegundos, con un

tiempo de espera a la respuesta desde 0 hasta 65 segundos, lo que es tiempo más que

suficiente para que el tag sensor obtenga la medida biomédica y responda al Write, por lo

que podemos usar esta función que proporciona el fabricante sin ninguna modificación.

No se disponía de un tag que se comportara como está previsto que lo haga el tag

sensor de señales biomédicas, ya que todos los tags incluidos en el demo kit ROGER

cumplen el tiempo de respuesta al Write especificado por el protocolo. Sin embargo, se ha

hecho la prueba de enviar un dato de control desde el microcontrolador al PC, a

continuación llamar a la función as399xWaitForResponseTimed con un parámetro del

orden de 10000 (es decir, 10 segundos) y al hacer timeout la función por no obtener

respuesta volver a enviar un dato de control al PC. Se ha comprobado que el tiempo

transcurrido ha sido el esperado (aproximadamente 10 segundos), y se puede concluir

que si se hubiera recibido una interrupción durante ese tiempo (aun excediendo en mucho

de los 20ms especificados por el protocolo) debido a la respuesta del tag al Write se

habría detectado y se habría podido procesar y continuar el flujo de comandos previsto.

4.4. Firmware EPC Gen2 desarrollado

Se han escrito una serie de funciones haciendo uso de las capas inferiores de las

librerías proporcionadas por el fabricante, que se relacionan en la Tabla 4.2.

4.5. Protocolo personalizado de comunicación entre microcontrolador yPC

Se han definido varios comandos personalizados de comunicación que resultan de

utilidad para el caso del tag sensor de señales biomédicas al que se refiere este trabajo.

El protocolo personalizado compuesto por estos comandos se implementa tanto en

la GUI que se ejecuta en el PC como en el firmware que se ejecuta en el

microcontrolador. Por tanto, cada comando implica un flujo de comunicación entre el PC,

el microcontrolador de la placa ROGER, el chip lector AS3992 y el tag.

4.5.1. Comandos implementados

Los comandos que componen el protocolo personalizado de comunicación se

muestran en la Tabla 4.3.


Firmware

Función Descripción Parámetros

send_Select Envía un comando Select delprotocolo EPC Gen2.

- (en este caso se usanparámetros por defecto

especificados manualmente)

send_Query Envía un comando Query delprotocolo EPC Gen2.

Array de 2 bytes (con losparámetros que especifica elprotocolo para este comando)

send_ACK Envía un comando ACK delprotocolo EPC Gen2.

- (se usa la capacidad delAS3992 de enviar el ACK

automáticamente)

send_Write Envía un comando Write delprotocolo EPC Gen2.

• 1 byte (parámetro WordPtr)• Array de 2 bytes (datos que se van a escribir)• Array de 2 bytes (handle)

send_Read Envía un comando Read delprotocolo EPC Gen2.

• 1 byte (parámetro MemBank)• 1 byte (parámetro WordPtr)• 1 byte (parámetro WordCount)• Array de 2 bytes (handle)

send_Lock Envía un comando Lock delprotocolo EPC Gen2.

• Array de 3 bytes (parámetro Payload)• Array de 2 bytes (handle)

send_CustomCommand1 Envío del comandopersonalizado para estaaplicación ClockCalibration.

1 byte (parámetro calWord)

send_CustomCommand2 Envío del comandopersonalizado para estaaplicación SensorCalibration.

1 byte (parámetro numBits)

as399xWaitForResponseToQueryOrACK

Para esperar la respuesta deltag a los comandos Query yACK y poder continuar el flujode comunicación cumpliendolas especificacionestemporales del protocolo.

-

Tabla 4.2: Funciones escritas para el firmware


Firmware

Comando Descripción Parámetros

GetConfiguration Obtención del estado de configuración del chip.

-

SetConfiguration Establecer la configuración del chip.

11 bytes (valores para escribiren los registros de

configuración del AS3992)

StoreRN16 Almacenar un número aleatoriode 16 bits (RN16).

1 byte (que define el tiempoque el tag tiene y no tiene

alimentación)

SingleRead Lectura simple (de temperaturao ECG).

1 byte (tipo de lectura: ECG otemperatura)

CompleteSense Sensado completo. • 1 byte (usar ClockCalibrationo no, tipo de lectura)• 1 byte (parámetro numBits del comando SensorCalibration)• 1 byte (parámetro calWord del comando ClockCalibration)

TestClockCalibration Testeo de la calibración del reloj.

1 byte (parámetro calWord delcomando ClockCalibration)

Tabla 4.3: Comandos implementados

4.5.2. Flujo de los comandos

4.5.2.1. Comando GetConfiguration

El flujo de comunicación del comando GetConfiguration se muestra en la Figura 4.2.

Este comando se usa para obtener la configuración del AS3992.


Figura 4.2: Flujo de comunicación del comandoGetConfiguration

Firmware

4.5.2.2. Comando SetConfiguration

El flujo de comunicación del comando SetConfiguration se muestra en la Figura 4.3.

Este comando se usa para especificar la configuración del AS3992.

4.5.2.3. Comando StoreRN16

El flujo de comunicación del comando StoreRN se muestra en la Figura 4.4. Este

comando se usa para enviar un determinado número de comandos Query al tag y

almacenar en un fichero los RN16 recibidos en respuesta.


Figura 4.3: Flujo de comunicación del comandoSetConfiguration

Figura 4.4: Flujo de comunicación del comandoStoreRN16

Firmware

4.5.2.4. Comando SingleRead

El flujo de comunicación del comando SingleRead se muestra en la Figura 4.5. Este

comando se usa para obtener una medida de ECG o temperatura.

4.5.2.5. Comando CompleteSense

El flujo de comunicación del comando CompleteSense se muestra en la Figura 4.6.

Este comando se usa para ejecutar el flujo completo de comunicación entre el AS3992 y

el tag.


Figura 4.5: Flujo de comunicación del comando SingleRead

PC μC AS3992 TAG

~10s

PC μC AS3992 TAG

Firmware

4.5.2.6. Comando TestClockCalibration

El flujo de comunicación del comando TestClockCalibration se muestra en la Figura

4.7. Este comando se usa para enviar el comando personalizado ClockCalibration con

todo el rango de valores posibles de su parámetro.


Figura 4.6: Flujo de comunicación del comando CompleteSense

PC μC AS3992 TAG

~10s

PC μC AS3992 TAG

Firmware

4.6. Firmware para comunicación USB

Para el firmware que se ejecuta en el microcontrolador para la comunicación de

datos por USB con el PC, se ha usado la solución USBXpress, que consiste en una API

que ofrece Silicon Labs para la comunicación con los microcontroladores

C8051F32x/34x/38x a través de USB.

USBXpress proporciona la API tanto para el software del host (en este caso la GUI

que se ejecuta en el PC) como para el firmware del dispositivo (en este caso el

microcontrolador C8041F340). El flujo de datos de USBXpress se muestra en la Figura

4.8.

La API de firmware para el microcontrolador de USBXpress consta de funciones para

inicializar y deshabilitar la interfaz USB, activar y desactivar las interrupciones y leer y

escribir datos a través de USB.


Figura 4.7: Flujo de comunicación del comandoTestClockCalibration

Firmware

Esta API se proporciona como un archivo de librería precompilado usando el tool

chain Keil C51. El firmware para hacer uso de la API se debe desarrollar usando el tool

chain Keil C51.

Esta API se utiliza mediante el uso de interrupciones. Para el microcontrolador

C8041F340, se requiere que se implemente una ISR en la posición de memoria 0x008B

(código de interrupción 17) para atender las interrupciones relacionadas con la interfaz

USB. Una vez dentro de la ISR, se hace uso de la función Get_Interrupt_Source para

determinar la causa de la interrupción.

4.7. Función main del firmware

En el firmware que se ejecuta en el microcontrolador en primer lugar se definen

diferentes variables que se usan durante la comunicación. Después se inicializan el


Figura 4.8: Flujo de datos deUSBXpress

Firmware

microcontrolador, el AS3992 y la interfaz USB. A continuación se ejecuta un bucle infinito,

en el que mediante un switch se comprueba si se ha recibido algún comando del

protocolo personalizado.

Al ejecutar en el PC el programa en Visual Basic (la GUI) se intenta establecer la

comunicación con el microcontrolador por USB. Cuando se inicia o se realiza alguna

acción en la GUI, se envía el comando personalizado correspondiente al microcontrolador.

Esto genera una interrupción, en cuya ISR se escribe en la variable que controla el switch

el código del comando personalizado recibido, tras lo cual en el bucle infinito el switch

pasará a ejecutar el trozo de código que se corresponda con el comando personalizado.


Interfaz de usuario

Capítulo 5 Interfaz de usuario

5.1. Introducción

La interfaz gráfica de usuario (GUI) se ha implementado usando Microsoft Visual

Basic 2010 Express. Se ha escogido esta aplicación debido a que las funciones de la

solución USBXpress para el programa del PC se pueden usar en C++ o en Visual Basic, y

se ha elegido esta última opción por la simplicidad en la elaboración de la GUI.

La librería de funciones de USBXpress para el PC se proporciona en la forma de una

DLL (Dynamic Link Library) para Windows. La DLL se comunica con dispositivo USB (el

microcontrolador en este caso) haciendo uso del driver USBXpress y de la pila USB del

sistema operativo.

Esta librería incluye funciones para monitorizar el número de dispositivos USB

conectados y sus descriptores, abrir la conexión con un dispositivo concreto y cerrarla,

enviar y recibir datos y algunas otras funciones de gestión de la interfaz USB.

5.2. Desarrollo de la GUI

La GUI desarrollada implementa el protocolo de comunicación personalizado para

esta aplicación compatible con EPC C1 Gen2.

La DLL que proporciona USBXpress para el PC se sitúa en la misma carpeta que los

archivos del proyecto Visual Basic que se ha creado para desarrollar la GUI. Una vez

hecho esto, es posible declarar las funciones de USBXpress en el proyecto y utilizarlas en

el código.

Se usan 2 archivos de código en el proyecto Visual Basic:

• USBXpress.vb: declara las funciones USBXpress referenciando la DLL, y define

constantes de utilidad para indicar los distintos errores y respuestas que pueden

devolver las funciones USBXpress y para gestionar la comunicación por USB.


Interfaz de usuario

• Form1.vb: contiene el código asociado al formulario que constituye la GUI. Consta

de diversas rutinas, cada una de las cuales se ejecuta cuando se elige la opción

correspondiente en el formulario.

Las distintas opciones disponibles en el formulario se corresponden con los diversos

comandos del protocolo personalizado.

5.2.1. Configuración del AS3992

La parte de la GUI relacionada con la configuración se muestra en la Figura 5.1 (a) y

(b).

Aquí se reflejan los valores de los distintos parámetros de configuración del chip

AS3992. Se implementan los comandos del protocolo personalizado GetConfiguration y


Figura 5.1: Captura de la GUI - Configuración

Interfaz de usuario

SetConfiguration.

Cuando se inicia la aplicación en el microcontrolador y en el PC, en la GUI primero

se comprueba si hay algún dispositivo USB conectado. Si se encuentra, se abre una

conexión con ese dispositivo (que en este caso sería el microcontrolador) y se ejecuta la

rutina GetConfiguration, que en primer lugar define las variables oportunas para

almacenar la configuración del AS3992, a continuación envía el comando

GetConfiguration del protocolo personalizado al microcontrolador y después se queda en

un bucle comprobando si se han recibido datos por USB. El comando enviado provocará

una interrupción USB en el microcontrolador, y en la ISR correspondiente se determina el

código del comando recibido y sus parámetros. En este caso el microcontrolador leería los

datos almacenados en los distintos registros de configuración del AS3992 y enviaría estos

valores por USB al PC. En la GUI se detectaría que se han recibido datos y se saldría del

bucle, y a continuación se leerían los datos recibidos por USB, y con estos datos se

actualizan los valores de los distintos botones y controles de la GUI.

Si se desea cambiar la configuración del AS3992 basta con elegir los valores de los

parámetros en la GUI y pulsar el botón Enviar Configuración. El microcontrolador escribirá

en los registros de configuración del AS3992 los valores indicados. Así se implementa, por

tanto, el comando del protocolo personalizado SetConfiguration.

5.2.2. Test

Esta parte de la GUI se muestra en la Figura 5.2.

Por un lado, se implementa el comando del protocolo personalizado StoreRN16. En

la GUI se especifica el número de RN16 que se quiere obtener (es decir, el número de


Figura 5.2: Captura de la GUI - Test

Interfaz de usuario

comandos Query que se van a enviar) y el tiempo que se mantiene el tag con y sin

alimentación entre cada obtención de RN16. El código de la GUI crea un archivo de texto

y almacena en una línea distinta cada RN16 recibido.

Por otro lado, se implementa el comando del protocolo personalizado

TestClockCalibration. Al pulsar el botón Clock Calibration se inicia el envío de comandos

ClockCalibration. Se envía al microcontrolador el código del comando

TestClockCalibration del protocolo personalizado y el valor del parámetro calWord del

comando ClockCalibration. Se itera el valor del parámetro mediante un bucle for entre 0 y

255, por lo que el AS3992 enviará al tag 256 comandos ClockCalibration, recorriendo

todos los valores posibles de su parámetro.

5.2.3. Operación

Esta parte de la GUI se muestra en la Figura 5.3.

Se implementan los comandos del protocolo personalizado SingleRead y

CompleteSense. Mediante dos checkbox se elige si se desea medir temperatura, ECG o

ambos. Se especifican los valores de los parámetros de los comandos SensorCalibration

y ClockCalibration. El envío del ClockCalibration es opcional y se elige mediante otro

checkbox. Por último, se especifica el tiempo durante el cual se debe esperar la respuesta

del tag sensor de señales biomédicas (antes de interpretar que no ha habido respuesta).


Figura 5.3: Captura de la GUI - Operación

Esquema demodulador

Capítulo 6 Esquema demodulador

6.1. Motivación

Para validar que los comandos implementados se envían correctamente y para

comprobar la temporización de la comunicación en distintos casos se hace necesario

visualizar las señales que envían el lector y el tag.

Para ello, se ha implementado un esquema demodulador para recibir y mover a

banda base las señales y visualizarlas en un osciloscopio.

6.2. Teoría básica de modulación y demodulación

6.2.1. Modulación

La modulación consiste en preparar una señal de información para su transmisión a

través de un canal de comunicaciones de la forma más adecuada. El procedimiento

clásico de modulación analógica usa la modificación continua de una señal sinusoidal,

denominada portadora, en función de los datos que se quieren transmitir [23]. La señal

portadora sinusoidal se puede representar como se muestra en la ecuación (2).

s( t)=A( t)⋅cos (ωc t+ϕ(t)) (2)

A(t) es la amplitud, ωc es la frecuencia angular ( ωc=2π f c , donde fc es la

frecuencia de la portadora) y φ(t) es la fase. En función de cuál de estos 3 parámetros se

modifica, podemos distinguir entre modulación en amplitud (Amplitude Modulation, AM),

modulación en frecuencia (Frequency Modulation, FM) y modulación en fase (Phase

Modulation, PM).

En la modulación analógica la señal de datos original puede tomar un número infinito

de valores para modular el parámetro que se esté modificando de la portadora, y la

variación del parámetro es continua en el tiempo de acuerdo con la variación de la señal

analógica original. En la modulación digital se trata de transmitir un flujo de bits, por lo que


Esquema demodulador

solo hay un número limitado de símbolos digitales que la variación del parámetro de la

portadora debe representar, y el cambio del parámetro solo ocurre en el límite del

intervalo que dura cada símbolo digital. Las modulaciones digitales correspondientes a las

modulaciones analógicas comentadas anteriormente se denominan ASK (Amplitude Shift

Keying, modulación por desplazamiento de amplitud), FSK (Frequency Shift Keying,

modulación por desplazamiento de frecuencia) y PSK (Phase Shift Keying, modulación

por desplazamiento de fase) [24].

6.2.2. ASK

En este caso la señal portadora que se trasmite tiene una frecuencia y fase

constante y varía su amplitud de acuerdo con los símbolos binarios que se pretenden

comunicar. La señal transmitida se puede expresar como se ve en la ecuación (3), donde

m(t) es la señal moduladora que representa los datos binarios originales.

s( t)=m( t )⋅cos (ωc t) (3)

En la Figura 6.1 se representa m(t) como una señal cuadrada ideal que varía entre

dos estados. Usando la codificación PIE como en el estándar EPC Gen2 esta señal

representa los datos binarios 010. Las bruscas transiciones de la señal cuadrada implican

un ancho de banda de la señal muy elevado, por lo que lo habitual es suavizar las

transiciones [25], como se observa en la Figura 6.2.


Figura 6.1: Ejemplo de señal moduladora ideal

Esquema demodulador

Para obtener la señal modulada s(t) que se transmite se multiplica m(t) por una

senoide de alta frecuencia, como se muestra en la Figura 6.3. Para ello se usa un

mezclador RF, que es un dispositivo de radiofrecuencia que multiplica 2 señales, lo que en

el dominio de la frecuencia se corresponde con un desplazamiento. Su funcionamiento se

describe en la Figura 6.4. Un mezclador dispone de 3 puertos; dos de entrada y uno de

salida. Los 3 puertos se denominan Oscilador local (LO, Local Oscillator),

Radiofrecuencia (RF, Radio Frequency) y Frecuencia intermedia (IF, Intermediate

Frequency). El puerto LO es de entrada y se alimenta típicamente con una señal

sinusoidal. Los otros dos puertos, RF e IF, se pueden intercambiar como segunda entrada

y salida, dependiendo de la aplicación. Si la frecuencia de salida deseada es menor que la

frecuencia de la segunda entrada, el proceso es una conversión a una frecuencia inferior,

y el puerto RF es de entrada y el puerto IF es de salida. Si la frecuencia de salida

deseada es mayor que la frecuencia de la segunda entrada, el proceso es una conversión

a frecuencia superior, y el puerto IF es de entrada y el puerto RF es de salida [26].


Figura 6.3: Esquemabásico de modulación

Figura 6.2: Ejemplo de señal moduladora real

Esquema demodulador

La señal s(t) resultante se muestra en la Figura 6.5. Así se desplaza mediante el

mezclador el espectro en frecuencia de la señal original m(t) a las frecuencias ωc y -ωc,

como se ve en la Figura 6.6.


Figura 6.4: Ejemplo de funcionamiento de un mezclador

Figura 6.5: Ejemplo de señal modulada

Esquema demodulador

6.2.3. Demodulación

Al recibir la señal transmitida se puede optar por un método de demodulación o bien

síncrono o coherente (si se utiliza una señal sincronizada en frecuencia y fase con la

señal portadora usada en la modulación) o bien no coherente (si el receptor no contempla

ninguna forma de recuperar la fase de la señal portadora original). Al no implementar

ningún mecanismo para recuperar la señal portadora, el receptor no coherente es menos

costoso que el coherente, a costa de un menor rendimiento en cuanto a tolerancia al ruido

[27].

En la Figura 6.7 se muestra el esquema de un demodulador coherente simple [27].

La señal recibida s(t) se multiplica por una señal de oscilador local, que es una senoide

sincronizada en frecuencia y fase con la senoide portadora original. Como se observa en

la Figura 6.8 esto tiene el efecto de desplazar el espectro de la señal recibida una

cantidad ωc y -ωc, por lo que el espectro de la señal moduladora original aparece en las

frecuencias 0, 2ωc y -2ωc (ignorando constantes multiplicativas). El filtro paso de baja

(LPF, Low Pass Filter) permite eliminar las bandas de las frecuencias 2ωc y -2ωc,

obteniendo la señal de información original. Por último, en un sistema digital se necesita la

funcionalidad de interpretar cada intervalo de la señal demodulada como un símbolo

digital (1 ó 0 en el caso binario), de lo que se encarga el bloque Dispositivo de decisión.


Figura 6.6: Ejemplo de espectro original desplazado

Esquema demodulador

6.3. Esquema

En nuestro caso solo nos interesa poder visualizar las señales enviadas por el lector

y el tag de manera cualitativa: no importan posibles desviaciones del valor DC ni se

necesita visualizar las señales con la misma amplitud y forma que las originales;

simplemente se pretende poder distinguir los 1s y 0s lógicos y cuándo está transmitiendo

datos el lector y cuándo el tag. Por tanto, se ha implementado el montaje más simple

posible y se ha comprobado que cumple el objetivo propuesto.

El esquema demodulador se muestra en la Figura 6.9 y en la Figura 6.10.


Figura 6.7: Esquema básico de demodulador coherente

Figura 6.8: Ejemplo ilustrativo del desplazamiento del espectro en el demodulador

Esquema demodulador

La señal mr(t) es la señal en banda base, con codificación PIE, que contiene la

información que pretende transmitir el lector. En este caso suponemos que se quieren

transmitir los símbolos binarios 010. La señal se representa en la Figura 6.11 (a), y su

espectro se representa en la Figura 6.11 (b). El lector usa la modulación ASK para

transmitir los datos, lo que se traduce en mezclar mr(t) con una senoide (cos(ωct)) con una

frecuencia comprendida dentro del rango establecido por el protocolo EPC Gen 2, es

decir, entre 860 y 960MHz. En este trabajo se ha usado para las diferentes pruebas la


Figura 6.10: Modelo de demodulación

Figura 6.9: Esquema del demodulador

Esquema demodulador

frecuencia de fc=912MHz ( ωc=2π f c ). Esta señal modulada mr(t)cos(ωct) se representa

en la Figura 6.12 (a), y su espectro en frecuencia equivale a desplazar el espectro de m r(t)

una cantidad ωc y -ωc, como se muestra en la Figura 6.12 (b).

La señal procedente del lector se conecta a la entrada de un divisor RF, que entrega

la misma señal (atenuada) en cada una de sus dos salidas. Una de las salidas alimenta

una antena, que envía los comandos RFID al tag y le proporciona la alimentación

eléctrica, y recibe los comandos enviados por el tag. La otra salida se usa como señal de

oscilador local en la demodulación, como se verá más adelante.


Figura 6.11: Ejemplo de señal de información dellector en banda base: (a) Representación temporal,

(b) representación espectral

Esquema demodulador

El tag es alimentado eléctricamente con la señal emitida por el lector. Cuando el

lector no transmite datos emite un nivel de señal denominado CW (Continuous Wave,

Onda Continua) con el objeto de proporcionar energía al tag. Suponemos que el tag

responde al mensaje enviado por el lector con los mismos datos (010). Suponemos que el

tag utiliza la codificación FM0 y modulación ASK. mt(t) es la señal en banda base, con

codificación FM0, que contiene la información que pretende transmitir el tag. Se muestra

en la Figura 6.13 (a). Su espectro se muestra en la Figura 6.13 (b). La señal modulada

que emite el tag usa la misma frecuencia portadora que la emitida por el lector (ya que el

tag responde simplemente cambiando el coeficiente de reflexión de su antena), y la

podemos escribir como mt(t)cos(ωct). Esta señal modulada mt(t)cos(ωct) se representa en

la Figura 6.14 (a), y su espectro en frecuencia equivale a desplazar el espectro de m t(t)

una cantidad ωc y -ωc, como se muestra en la Figura 6.14 (b).


Figura 6.12: Ejemplo de señal modulada emitidapor el lector: (a) Representación temporal, (b)

representación espectral

Esquema demodulador

Las señales emitidas por el lector y el tag se reciben mediante otra antena. A esta

señal recibida por la antena la denominamos ra(t) y consiste en la superposición de las

señales emitidas por lector y tag: ra(t)=mr(t)cos(ωct)+mt(t)cos(ωct). El lector emite los datos

(010), y pasa a emitir CW. El tag responde con sus datos (010), y esta señal emitida por el

tag se superpone al nivel de CW que está emitiendo el lector, como se representa en la

Figura 6.15 (a). El espectro de ra(t) sigue concentrado en torno a ωc y -ωc, como se

muestra en la Figura 6.15 (b).


Figura 6.13: Ejemplo de señal de información deltag en banda base: (a) Representación temporal, (b)


Esquema demodulador

Para detectar la señal ra(t), tenemos que devolverla a baja frecuencia (banda base),

es decir, demodularla. Una forma de hacerlo es mezclarla con una senoide con la misma

frecuencia portadora que se usó para modular, de forma que se obtiene el espectro de la

señal original en las frecuencias 0, 2ωc y -2ωc, como se comentó en el apartado anterior.

Dado que está disponible la señal emitida por el lector m r(t)cos(ωct), que obviamente tiene

la misma frecuencia portadora, se va a usar esta señal como oscilador local,

comprobándose a continuación que, aunque no se trate de una senoide pura, se puede

realizar el análisis cualitativo en el que estamos interesados en este capítulo.


Figura 6.14: Ejemplo de señal moduladaemitida por el tag: (a) Representacióntemporal, (b) representación espectral

Esquema demodulador

Por tanto, a la hora de demodular, se utiliza un mezclador, en el que se usa como

entrada del puerto LO (oscilador local) la señal emitida por el lector, como entrada del

puerto RF (radiofrecuencia) la superposición de las señales emitidas por el lector y el tag,

y se conecta el puerto IF (frecuencia intermedia), que en este caso es de salida, a la

entrada del osciloscopio.

Al mezclar la señal recibida por la antena ra(t) con la señal mr(t)cos(ωct) se obtiene la

señal rm(t) (señal recibida tras el mezclador), que se puede expresar como se muestra en

la ecuación (5), haciendo uso de la identidad trigonométrica (4).

cos2(θ)=

12(1+cos (2θ)) (4)


Figura 6.15: Ejemplo de señal recibida por laantena: (a) Representación temporal, (b)


Esquema demodulador

r m(t)=r a(t)⋅mr(t )⋅cos(ωc t )(mr( t)⋅cos (ωc t )+mt( t )⋅cos (ωc t))mr (t)⋅cos (ωc t )=

=(mr2(t )+mr (t)⋅mt(t))cos2

(ωc t )=(mr2(t )+mr (t)⋅mt(t))

12(1+cos(2ωc t)) (5)

A continuación se aplica un filtro paso de baja a la señal rm(t), con lo que se rechaza

el término de alta frecuencia cos(2ωct), y se obtiene la señal r(t), que es la que se

visualizaría en el osciloscopio. El filtrado paso de baja lo realiza el propio osciloscopio, ya

que posee un ancho de banda de 60MHz, muy superior al ancho de banda de las señales

emitidas por lector y tag en banda base pero muy inferior a fc=912MHz. Por tanto,

podemos escribir r(t) como se muestra en la ecuación (6), ignorando constantes

multiplicativas.

r (t)≈mr2(t)+mr(t)mt (t) (6)

Dado que la comunicación entre lector y tag es half-duplex, se pueden distinguir dos

casos:

• Cuando el lector transmite, el tag no lo hace. En este caso el lector emite m r(t) y

mt(t) = 0. Por tanto en este caso podemos expresar r(t) como en la expresión (7).

mr (t )mt(t )=0}⇒ r (t )≈mr

2(t ) (7)

• Cuando el tag transmite, el lector está emitiendo CW. En este caso el tag emite

mt(t) y mr(t) ≈ CW. Por tanto en este caso podemos expresar r(t) como en la

expresión (8).

mr( t)≈CWmt(t) }⇒ r ( t)≈CW +mt (t) (8)

Es decir, r(t) en teoría exhibe una forma proporcional a mr2(t) (que se corresponde

con una versión más abrupta de mr(t)) cuando emite el lector, y proporcional a la señal

mt(t) superpuesta al valor CW cuando emite el tag, lo que hace posible distinguir

cualitativamente, observando la pantalla del osciloscopio, si el lector o el tag están

emitiendo datos y qué símbolos se están transmitiendo. En la Figura 6.16 se muestra una

imagen de la pantalla del osciloscopio, en la que se observan los símbolos binarios 1 y 0

que transmite el lector.


Esquema demodulador


Figura 6.16: Captura del osciloscopio en laque se observa la señal transmitida por el lector

Programas y periféricos utilizados

Capítulo 7 Programas y periféricos utilizados

7.1. Introducción

En el desarrollo de este trabajo se han utilizado una serie de herramientas software,

tanto para programar el microcontrolador como para desarrollar la GUI. También se ha

hecho uso, como instrumento de medida, de un osciloscopio para visualizar las señales

emitidas por el lector y el tag.

7.2. Silicon Labs IDE

Se trata de un entorno de desarrollo integrado que proporciona las herramientas

necesarias para desarrollar y testear proyectos de programación de microcontroladores

de Silabs [28].

Proporciona las funcionalidades habituales de debug (breakpoints, watchpoints,

ejecución paso a paso...).

Permite integrar ensambladores, compiladores y enlazadores externos, a través del

diálogo Tool Chain Integration. En este caso el código se ha escrito en el lenguaje de

programación C (ligeramente extendido con algunas palabras clave que permiten

especificar algunas opciones propias de la programación del microcontrolador), y se ha

usado el compilador correspondiente.

Se ha elegido este entorno de desarrollo para la programación del firmware del

microcontrolador debido a que lo proporciona el mismo fabricante que el microcontrolador,

minimizando los problemas de compatibilidad y configuración.

7.3. Keil 8051 Tools

Los productos Keil de ARM proporcionan una serie de herramientas de desarrollo de

software para varias familias de procesadores, entre ellas la familia de microcontroladores



8051 de Silicon Labs (a la que pertenece el microcontrolador que se ha usado aquí).

Las herramientas para la familia 8051 [29] (concretamente un ensamblador, un

compilador y un enlazador) se integran con el Silicon Labs IDE para programar el

microcontrolador.

La documentación proporcionada por el fabricante austriamicrosystems junto con el

lector ROGER incluye una nota de aplicación con instrucciones para integrar las

herramientas de desarrollo Keil 8051 con el Silicon Labs IDE. Asimismo, el fabricante

Silabs ofrece en su página web de descargas para su familia de microcontroladores de 8

bits (en la que se incluye el microcontrolador usado en este trabajo) las herramientas Keil

[30]. Por tanto, la elección de estas herramientas se considera la más apropiada para la

programación del microcontrolador.

7.4. USBXpress

USBXpress es una solución proporcionada por el fabricante Silabs para facilitar la

comunicación por USB con los microcontroladores de este fabricante que incorporan esta

interfaz [31].

Esta solución incorpora:

• Drivers para Windows

• API para el host (es decir, para el PC), en el formato de una librería DLL. Esta

librería se puede importar para su uso en aplicaciones escritas en los lenguajes de

programación Visual Basic y C++. Consiste en una serie de funciones que se

pueden invocar para manejar la comunicación por USB desde el lado del PC.

• API para el dispositivo (es decir, el microcontrolador). Consiste en una serie de

funciones que se pueden invocar en el firmware que se ejecuta en el

microcontrolador para manejar la comunicación por USB desde el lado del

microcontrolador.

Dado que el microcontrolador que incorpora el lector RFID ROGER es del fabricante

Silabs, y que dispone de la posibilidad de comunicación por USB, la elección de la

solución USBXpress para la comunicación por USB entre la GUI y el lector es la más

adecuada, ya que la proporciona el mismo fabricante que el microcontrolador, por lo que

se minimizan los problemas de compatibilidad y configuración. Además no requiere de

conocimientos expertos del protocolo USB ni del driver del PC.



7.5. Visual Basic 2010 Express Edition

Ha sido necesario desarrollar una GUI relativamente simple, con la funcionalidad

básica de un formulario (botones, checkboxes, cajas de entrada de texto, botones

radio,...). La API USBXpress permite usar como lenguaje de programación Visual Basic o

C++, y se ha elegido Visual Basic por ofrecer mayor simplicidad en la elaboración de la

GUI.

Microsoft Visual Studio Express es un conjunto de IDEs con licencia freeware

desarrollados por Microsoft, y que suponen una versión limitada (y orientada a estudiantes

y aficionados) de Microsoft Visual Studio, que está dirigida a desarrolladores de software

profesionales. Entre estos IDEs se encuentran Visual Basic Express y Visual C++

Express, que serían las opciones permitidas por USBXpress.

Por tanto, el IDE usado en este caso para desarrollar la GUI ha sido Visual Basic

Express, en su versión de 2010 [32], que posee todas las funcionalidades precisas para la

aplicación requerida en este trabajo.

7.6. Osciloscopio

El osciloscopio usado ha sido el modelo TDS 1002B del fabricante Tektronix [33].

Este dispositivo posee un ancho de banda de 60MHz, 2 canales analógicos, una tasa de

muestreo de 109 muestras/s y una longitud de registro de 2500 puntos en todas las bases

temporales. Se pretende visualizar en la pantalla de un osciloscopio las señales emitidas

por el tag y el lector. El único requisito que debe cumplir el dispositivo es poseer un ancho

de banda muy superior a las señales emitidas por el lector y el tag, para que estas puedan

ser visualizadas correctamente, y muy inferior a la frecuencia portadora de modulación,

para que las componentes de alta frecuencia sean filtradas, como se comenta en el

Capítulo 6.

El ancho de banda de las señales en banda base emitidas por el lector y el tag oscila

entre 26,7 y 128 kHz en el caso del lector y entre 40 y 640 kHz en el caso del tag (usando

codificación FM0). La frecuencia portadora oscila entre 860 y 960 MHz [11].

Por tanto, el osciloscopio mencionado cumple con los requisitos, y fue elegido por

encontrarse disponible en el laboratorio donde se realizaron las pruebas.


Conclusiones y trabajo futuro


1. Conclusiones

En este proyecto se ha programado un lector RFID para la comunicación con el tag

RFID sensor de señales biomédicas compatible con el protocolo EPC Gen2 presentado

en [4], cumpliendo con los requisitos establecidos por dicho tag sensor. Se ha

comprobado que eligiendo un lector con suficiente capacidad de personalización y

herramientas software fácilmente accesibles ha sido posible cumplir e implementar los

requisitos exigidos.

Adicionalmente, se ha implementado una interfaz de usuario para poder gestionar la

comunicación con el tag de forma más cómoda y a más alto nivel y responder a las

necesidades establecidas por el diseñador del tag. Esto también se ha realizado con

herramientas software disponibles para cualquier persona.

Por último, se ha comprobado que con un equipamiento y montaje relativamente

simple es posible validar cualitativamente en las pantalla de un osciloscopio con un ancho

de banda limitado las señales emitidas por el lector y el tag.

Ha sido preciso el estudio del estándar EPC Gen2, del datasheet del chip lector

AS3992, de la forma de configurar el entorno de desarrollo para programar el

microcontrolador y de las funciones de la librería USBXpress para la comunicación por

USB. También se ha necesitado realizar algún ajuste del código básico proporcionado por

el fabricante del lector para poder realizar en la práctica la comunicación entre lector y

tags de prueba.

Los cambios principales respecto a una comunicación RFID normal siguiendo el

protocolo EPC Gen2 han consistido en la implementación de dos comandos

personalizados relacionados con la calibración del tag sensor y la implementación y

validación de una forma de cumplir los requisitos temporales específicos de este tag.



2. Trabajo futuro

Este proyecto tiene una orientación muy específica (la comunicación con el tag

sensor desarrollado en [4]). Por tanto, el trabajo futuro derivado de él más inmediato

consistiría en usar la herramienta desarrollada con fines de test del tag indicado.

Se podría explorar la forma de extenderlo para su aplicación a un entorno en el que

existiera más de un lector y/o más de un tag, y en general la adaptación a trabajos futuros

derivados del tag sensor. También podrían reutilizarse y adaptarse la plataforma y el

código desarrollado para realizar pruebas con otros tags compatibles con el protocolo

EPC Gen2.

Asimismo, en base al trabajo desarrollado, conviene plantear la posibilidad de

desarrollar lectores específicos para este tipo de aplicaciones biomédicas, sin tener que

recurrir a una plataforma de test como la descrita, y con vistas a una posible aplicación

comercial. Para ello sería preciso modificar el estándar EPC Gen2 (o extenderlo) para:

• Definir un procedimiento estandarizado de calibración de tag sensor de señales

biomédicas, y los comandos RFID correspondientes (similares a los

ClockCalibration y SensorCalibration definidos en este trabajo).

• Definir los comandos necesarios para leer los datos obtenidos por el tag sensor,

con la suficiente flexibilidad temporal para obtener la medida. El tag podría, durante

la identificación, comunicarle al lector los tipos de medida biomédica que puede

realizar y el tiempo necesario para obtenerlas. Convendría definir un comando

específico para indicar al tag que debe obtener la medida, en lugar de hacerlo

escribiendo en la memoria del tag mediante el comando Write. Asimismo habría

que definir las posiciones de la memoria del tag en las que habría que aplicar el

comando Read para leer el resultado de la medida. Estas posiciones podrían estar

definidas a priori en el estándar o, para mayor flexibilidad, ser establecidas en el

diálogo entre lector y tag durante la identificación o durante la orden de obtención

de la medida biomédica.


Bibliografía

Bibliografía

[1] K. Finkenzeller, RFID Handbook: Fundamentals and Applications in Contactless

Smart Cards, Radio Frequency Identification and Near-Field Communication, 3rd ed.

John Wiley and Sons, 2010.

[2] Daniel M. Dobkin, The RF in RFID, 2nd ed. Newnes, 2012.

[3] Rodriguez-Rodriguez, J.A.; Delgado-Restituto, M.; Masuch, J.; Rodriguez-Perez, A.;

Alarcon, E.; Rodriguez-Vazquez, A., "An Ultralow-Power Mixed-Signal Back End for

Passive Sensor UHF RFID Transponders," Industrial Electronics, IEEE Transactions

on , vol.59, no.2, pp.1310,1322, Feb. 2012

[4] J.A. Rodríguez-Rodríguez; “Diseño de un sistema RFID pasivo de bajo consumo

para monitorizar inalámbricamente constantes biomédicas”; Thesis - Date of

defense: 05/04/2013; UNIVERSIDAD DE SEVILLA, IMSE-CNM

[5] http://www.impinj.com/RFID_Products/

[6] http://www.thingmagic.com/embedded-rfid-readers

[7] http://solutions.3m.com/wps/portal/3M/en_US/NA_Motor_Vehicle_Services_Systems/

Motor_Vehicle_Industry_Solutions/product_catalog/rfid-access-control-system/rfid-

readers/

[8] http://www.alientechnology.com/readers/

[9] https://www.ams.com/eng/Support/Demoboards/UHF-RFID/UHF-RFID-Reader-

ICs/AS3991-Demo-Kit-Roger

[10] https://www.ams.com/eng/Products/UHF-RFID/UHF-RFID-Reader-ICs/AS3992

[11] “EPC Radio-Frequency Indentity Protocols Class-1 Generation-2 UHF RFID Protocol

for Communications at 860 MHz – 960 MHz Version 1.2.0”; October 2008.


http://www.impinj.com/RFID_Products/

https://www.ams.com/eng/Products/UHF-RFID/UHF-RFID-Reader-ICs/AS3992

https://www.ams.com/eng/Support/Demoboards/UHF-RFID/UHF-RFID-Reader-ICs/AS3991-Demo-Kit-Roger

https://www.ams.com/eng/Support/Demoboards/UHF-RFID/UHF-RFID-Reader-ICs/AS3991-Demo-Kit-Roger

http://www.alientechnology.com/readers/

http://solutions.3m.com/wps/portal/3M/en_US/NA_Motor_Vehicle_Services_Systems/Motor_Vehicle_Industry_Solutions/product_catalog/rfid-access-control-system/rfid-readers/



http://www.thingmagic.com/embedded-rfid-readers

Bibliografía

[12] J.-P. Curty, M. Declercq, C. Dehollain, and N. Joehl. Design and Optimization of

Passive UHF RFID Systems. Springer, New York, 2007

[13] P. V. Nikitin and K. V. S. Rao, “Theory and measurement of backscattering from

RFID tags”, IEEE Antennas and Propagation Magazine, vol. 48, no. 6, Dec. 2006, pp.

212-218

[14] ISO 11784:1996 “Radio frequency identification of animals -- Code structure”

[15] ISO 11785:1996 “Radio frequency identification of animals -- Technical concept”

[16] ISO 14223-1:2011 “Radiofrequency identification of animals -- Advanced

transponders -- Part 1: Air interface”

[17] ISO/IEC 18000-2:2009 “Information technology -- Radio frequency identification for

item management -- Part 2: Parameters for air interface communications below 135

kHz”

[18] ISO/IEC 14443-1:2008 “Identification cards -- Contactless integrated circuit cards --

Proximity cards -- Part 1: Physical characteristics”

[19] ISO/IEC 15693-1:2010 “Identification cards -- Contactless integrated circuit cards --

Vicinity cards -- Part 1: Physical characteristics”

[20] California Code of Regulations, Title 21, Chapter 16, “Compatibility Specifications for

Automatic Vehicle Identification Equipment”

[21] “EPC Tag Data Standard”, GS1 Standard, Version 1.8, Jan-2014

[22] http://www.silabs.com/Support%20Documents/TechnicalDocs/8-bit-USB-Debug-

Adapter.pdf

[23] Karrenberg, Ulrich, Signals, Processes, and Systems, Berlin, Heidelberg : Springer

Berlin Heidelberg : Imprint: Springer, 2013, 3rd ed. 2013

[24] Sergei Semenov, Evgenii Krouk, Modulation and coding techniques in wireless

communications, Chichester, West Sussex, U.K. ; Hoboken, N.J. : Wiley, 2011

[25] Dag Stranneby, William Walker, Digital signal processing and applications, Oxford :

Newnes, cop. 2004, 2nd ed.

[26] Ferenc Marki & Christopher Marki, Ph.D., Mixer Basics Primer. A Tutorial for RF &


http://www.silabs.com/Support%20Documents/TechnicalDocs/8-bit-USB-Debug-Adapter.pdf

http://www.silabs.com/Support%20Documents/TechnicalDocs/8-bit-USB-Debug-Adapter.pdf

Bibliografía

Microwave Mixers, © 2010 Marki Microwave, Inc.

[27] Haykin, Simon, Communication systems, New York [etc.] John Wiley and Sons,

2000, 4th. ed.

[28] http://www.silabs.com/products/mcu/Pages/8-bit-microcontroller-software.aspx#ide

[29] http://www.keil.com/c51/

[30] http://www.silabs.com/products/mcu/Pages/8-bit-microcontroller-software.aspx

[31] http://www.silabs.com/products/mcu/Pages/USBXpress.aspx

[32] http://www.visualstudio.com/downloads/download-visual-studio-

vs#DownloadFamilies_4

[33] http://www.tek.com/datasheet/tds1000b-series


http://www.tek.com/datasheet/tds1000b-series

http://www.visualstudio.com/downloads/download-visual-studio-vs#DownloadFamilies_4

http://www.visualstudio.com/downloads/download-visual-studio-vs#DownloadFamilies_4

http://www.silabs.com/products/mcu/Pages/USBXpress.aspx

http://www.silabs.com/products/mcu/Pages/8-bit-microcontroller-software.aspx

http://www.keil.com/c51/

http://www.silabs.com/products/mcu/Pages/8-bit-microcontroller-software.aspx#ide

Anexos

Anexos

1. Código fuente de la interfaz de usuario

1.1. USBXpress.vb

Module USBXpress

' Declare statements for all the functions in the SiF32xUSb DLL ' NOTE: These statements assume that the DLL file is located in ' the same directory as this project. ' If you change the location of the DLL, be sure to change the location ' in the declare statements also. Public Declare Function SI_GetNumDevices Lib "SiUSBXp.dll" (ByRef lpwdNumDevices As Integer) As Integer Public Declare Function SI_GetProductString Lib "SiUSBXp.dll" (ByVal dwDeviceNum As Integer, ByRef lpvDeviceString As Byte, ByVal dwFlags As Integer) As Integer Public Declare Function SI_Open Lib "SiUSBXp.dll" (ByVal dwDevice As UInt32, ByRef cyHandle As UInt32) As Integer Public Declare Function SI_Close Lib "SiUSBXp.dll" (ByVal cyHandle As UInt32) As Integer Public Declare Function SI_Read Lib "SiUSBXp.dll" (ByVal cyHandle As UInt32, ByRef lpBuffer As Byte, ByVal dwBytesToRead As Integer, ByRef lpdwBytesReturned As Integer, ByVal lpOverlapped As Integer) As Integer Public Declare Function SI_Write Lib "SiUSBXp.dll" (ByVal cyHandle As UInt32, ByRef lpBuffer As Byte, ByVal dwBytesToWrite As Integer, ByRef lpdwBytesWritten As Integer, ByVal lpOverlapped As Integer) As Integer Public Declare Function SI_SetTimeouts Lib "SiUSBXp.dll" (ByVal dwReadTimeout As Integer, ByVal dwWriteTimeout As Integer) As Integer Public Declare Function SI_GetTimeouts Lib "SiUSBXp.dll" (ByRef lpdwReadTimeout As Integer, ByRef lpdwWriteTimeout As Integer) As Integer Public Declare Function SI_CheckRXQueue Lib "SiUSBXp.dll" (ByVal cyHandle As UInt32, ByRef lpdwNumBytesInQueue As UInt32, ByRef lpdwQueueStatus As UInt32) As Integer

'Masks for the serial number and description Public Const SI_RETURN_SERIAL_NUMBER = &H0 Public Const SI_RETURN_DESCRIPTION = &H1

'Masks for return values from the device Public Const SI_SUCCESS = &H0 Public Const SI_DEVICE_NOT_FOUND = &HFF Public Const SI_INVALID_HANDLE = &H1 Public Const SI_READ_ERROR = &H2 Public Const SI_RX_QUEUE_NOT_READY = &H3 Public Const SI_WRITE_ERROR = &H4 Public Const SI_RESET_ERROR = &H5 Public Const SI_INVALID_BUFFER = &H6 Public Const SI_INVALID_REQUEST_LENGTH = &H7 Public Const SI_DEVICE_IO_FAILED = &H8

Public Const SI_QUEUE_NO_OVERRUN = &H0 Public Const SI_QUEUE_OVERRUN = &H1 Public Const SI_QUEUE_READY = &H2

Public Const SI_MAX_DEVICE_STRLEN = 256 Public Const SI_MAX_READ_SIZE = 64 Public Const SI_MAX_WRITE_SIZE = 64


Anexos

Public Const INVALID_HANDLE_VALUE = &H1

Public Const MAX_PACKET_SIZE = &H40 Public Const MAX_WRITE_PKTS = &H8

Public Const FT_READ_MSG = &H0 Public Const FT_WRITE_MSG = &H1 Public Const FT_READ_ACK = &H2 Public Const FT_MSG_SIZE = &H3

Public hUSBDevice As UInt32 Public Status As Integer Public TempString As String

Public Function ConvertToVBString(ByVal Str)

Dim NewString As String Dim i As Integer

'for the received string array, loop until we get 'a 0 char, or until the max length has been obtained 'then add the ascii char value to a vb string i = 0 Do While (i < SI_MAX_DEVICE_STRLEN) And (Str(i) <> 0) NewString = NewString + Chr(Str(i)) i = i + 1 Loop

ConvertToVBString = NewString

End Function

End Module

1.2. Form1.vb

Public Class Form1

'numero de dispositivos USB conectados Dim DevNum As Integer 'numero de bytes leidos por la interfaz USB Dim BytesReturned As Integer 'numero de bytes escritos para su envio por la interfaz USB Dim BytesWritten As Integer 'numero de bytes en la cola de recepcion USB Dim BytesInQueue As UInt32 'estado de la cola de recepcion USB Dim QueueStatus As UInt32

'I/O Buffer Dim IOBufSize As Integer = 12 '12 bytes es el maximo que va a hacer falta transmitir o recibir por USB Dim IOBuf(IOBufSize) As Byte 'variable para enviar y recibir datos por USB

' Rutina que se ejecuta al abrir el formulario Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load 'determinamos cuantos dispositivos USB estan conectados Status = SI_GetNumDevices(DevNum)

If DevNum <> 0 Then ' Se ha encontrado el dispositivo (microcontrolador) 'abrimos el dispositivo Status = SI_Open(0, hUSBDevice) If Status = SI_SUCCESS Then Else TextBoxError.Text = "Ocurrio un error al abrir el dispositivo" End If


Anexos

GetConfiguration() ' Obtenemos la configuracion del chip (AS3992) End If End Sub

' Rutina que envia el comando GetConfiguration al dispositivo (obtener la configuracion del chip(AS3992)) Private Sub GetConfiguration() ' Variable que indica si se han recibido datos por USB Dim DatosEnCola As Boolean = False

' Parametros de configuracion Dim Rxcod As Byte ' Codificacion RX Dim Tari As Byte ' Tari Dim TxPW As Byte ' PW length Dim TxOne As Byte ' TX one length Dim Session As Byte ' Session Dim Rx_LF As Byte ' Link frequency Dim TRext As Boolean ' RX preamble length Dim DR As Boolean ' Divide Ratio (DR) ; DR bit = 0 -> DR value = 8 ; DR bit = 1 -> DR value = 64/3 Dim TRcal As UShort ' TRcal Dim etx As Byte ' Power (current) Dim Txdel As Byte ' Delayed transmission wait time Dim NoResp As Byte ' No response wait time Dim Rxw As Byte ' RX wait time

' Solicitud de GetConfiguration IOBuf(0) = &H0 ' Este numero indica el comando GetConfiguration

' Enviamos el codigo del comando y los parametros al uC Status = SI_Write(hUSBDevice, IOBuf(0), 1, BytesWritten, 0) If Status = SI_SUCCESS Then TextBoxError.Text = ""

' Esperar a que el dispositivo haya escrito la configuracion While Not DatosEnCola Status = SI_CheckRXQueue(hUSBDevice, BytesInQueue, QueueStatus) If Status = SI_SUCCESS Then Select Case QueueStatus Case SI_QUEUE_NO_OVERRUN ' = SI_RX_EMPTY TextBoxError.Text = "Cola vacia" Case SI_QUEUE_OVERRUN Case SI_QUEUE_READY ' Hay bytes en la cola DatosEnCola = True TextBoxError.Text = "" End Select Else TextBoxError.Text = "Ocurrio un error" End If End While

' Leer la configuracion (son 7 bytes) Status = SI_Read(hUSBDevice, IOBuf(0), 7, BytesReturned, 0) If Status = SI_SUCCESS Then

' Procesamos los datos de configuracion recibidos

' IOBuf(0): Rxcod<1:0> Tari<1:0> TxPW<1:0> TxOne<1:0> Rxcod = IOBuf(0) >> 6 Tari = (IOBuf(0) And &H30) >> 4 TxPW = (IOBuf(0) And &HC) >> 2 TxOne = IOBuf(0) And &H3 ' IOBuf(1): S<1:0> Rx_LF<3:0> TRext DR Session = IOBuf(1) >> 6 Rx_LF = (IOBuf(1) And &H3C) >> 2 TRext = (IOBuf(1) And &H2) >> 1 DR = IOBuf(1) And &H1 ' IOBuf(2): TRcal<7:0> ' IOBuf(3): TRcal<11:8> etx<1:0> 0 0 TRcal = IOBuf(3) And &HF0 ' Metemos en el byte bajo de TRcal los bits <11:8> TRcal = TRcal << 4 ' Pasamos los bits <11:8> al byte alto de TRcal TRcal = TRcal Or IOBuf(2) ' Metemos en el byte bajo de TRcal los bits <7:0>


Anexos

etx = (IOBuf(3) And &HC) >> 2 ' IOBuf(4): Txdel<7:0> Txdel = IOBuf(4) ' IOBuf(5): NoResp<7:0> NoResp = IOBuf(5) ' IOBuf(6): Rxw<7:0> Rxw = IOBuf(6)

' Escribimos los datos de configuracion en la interfaz de usuario

Select Case Rxcod Case 0 LabelCodificacion.Text = "FM0" RadioButtonFM0.Checked = True Case 1 LabelCodificacion.Text = "Miller 2" RadioButtonMiller2.Checked = True Case 2 LabelCodificacion.Text = "Miller 4" RadioButtonMiller4.Checked = True Case 3 LabelCodificacion.Text = "Miller 8" RadioButtonMiller8.Checked = True End Select

Select Case Tari Case 0 LabelTari.Text = "6.25" RadioButtonTari625.Checked = True Case 1 LabelTari.Text = "12.5" RadioButtonTari125.Checked = True Case 2 LabelTari.Text = "25" RadioButtonTari25.Checked = True End Select

Select Case TxPW Case 0 LabelPWLength.Text = "0.27*Tari" RadioButtonPW027Tari.Checked = True Case 1 LabelPWLength.Text = "0.35*Tari" RadioButtonPW035Tari.Checked = True Case 2 LabelPWLength.Text = "0.44*Tari" RadioButtonPW044Tari.Checked = True Case 3 LabelPWLength.Text = "0.5*Tari" RadioButtonPW05Tari.Checked = True End Select

Select Case TxOne Case 0 LabelTXOneLength.Text = "1.5*Tari" RadioButtonTXone15Tari.Checked = True Case 1 LabelTXOneLength.Text = "1.66*Tari" RadioButtonTXone166Tari.Checked = True Case 2 LabelTXOneLength.Text = "1.83*Tari" RadioButtonTXone183Tari.Checked = True Case 3 LabelTXOneLength.Text = "2*Tari" RadioButtonTXone2Tari.Checked = True End Select

Select Case Session Case 0 LabelSession.Text = "S0" RadioButtonSessionS0.Checked = True Case 1 LabelSession.Text = "S1" RadioButtonSessionS1.Checked = True


Anexos

Case 2 LabelSession.Text = "S2" RadioButtonSessionS2.Checked = True Case 3 LabelSession.Text = "S3" RadioButtonSessionS3.Checked = True End Select

Select Case Rx_LF Case 0 LabelLinkFrequency.Text = "40" RadioButton40kHz.Checked = True Case 6 LabelLinkFrequency.Text = "160" RadioButton160kHz.Checked = True Case 9 LabelLinkFrequency.Text = "256" RadioButton256kHz.Checked = True Case 12 LabelLinkFrequency.Text = "320" RadioButton320kHz.Checked = True Case 15 LabelLinkFrequency.Text = "640" RadioButton640kHz.Checked = True End Select

Select Case TRext Case False LabelRXPreambleLength.Text = "Short" RadioButtonShortPreamble.Checked = True Case True LabelRXPreambleLength.Text = "Long" RadioButtonLongPreamble.Checked = True End Select

Select Case DR Case False LabelDR.Text = "8" RadioButtonDR8.Checked = True Case True LabelDR.Text = "64/3" RadioButtonDR643.Checked = True End Select

LabelTRcal.Text = (TRcal + 1) / 10

Select Case etx Case 1 LabelPower.Text = "7" RadioButtonPower7mA.Checked = True Case 2 LabelPower.Text = "14" RadioButtonPower14mA.Checked = True Case 3 LabelPower.Text = "22" RadioButtonPower22mA.Checked = True End Select

LabelDelayedTransmissionWaitTime.Text = Txdel * 6.4 NumericUpDownTxdel.Value = Txdel * 6.4

LabelNoResponseWaitTime.Text = NoResp * 25.6 NumericUpDownNoResp.Value = NoResp * 25.6

LabelRXWaitTime.Text = Rxw * 6.4 NumericUpDownRxw.Value = Rxw * 6.4

Else TextBoxError.Text = "Ocurrio un error" End If

Else TextBoxError.Text = "Ocurrio un error al intentar escribir en el dispositivo" End If


Anexos

End Sub

' Rutina que envia el comando SetConfiguration al dispositivo (especificar la configuracion del chip (AS3992)) Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click ' Variable que indica si se han recibido datos por USB Dim DatosEnCola As Boolean = False

' Parametros de configuracion Dim Rxcod As Byte ' Codificacion RX Dim Tari As Byte ' Tari Dim TxPW As Byte ' PW length Dim TxOne As Byte ' TX one length Dim Session As Byte ' Session Dim Rx_LF As Byte ' Link frequency Dim TRext As Boolean ' RX preamble length Dim DR As Byte ' DR (Divide Ratio): 0 ó 1 Dim DRValue As Single ' DR (Divide Ratio): 8 ó 64/3 Dim TRcal As UShort ' TRcal Dim BLF As UShort ' BLF (Backward Link Frequency) [kHz] Dim etx As Byte ' Power (current) Dim Txdel As Byte ' Delayed transmission wait time Dim NoResp As Byte ' No response wait time Dim Rxw As Byte ' RX wait time

' Se escriben en las variables correspondientes a los parametros de configuracion ' los valores que se corresponden con las opciones elegidas en la interfaz de usuario

If RadioButtonFM0.Checked = True Then Rxcod = 0 ElseIf RadioButtonMiller2.Checked = True Then Rxcod = 1 ElseIf RadioButtonMiller4.Checked = True Then Rxcod = 2 ElseIf RadioButtonMiller8.Checked = True Then Rxcod = 3 End If

If RadioButtonTari625.Checked = True Then Tari = 0 ElseIf RadioButtonTari125.Checked = True Then Tari = 1 ElseIf RadioButtonTari25.Checked = True Then Tari = 2 End If

If RadioButtonPW027Tari.Checked = True Then TxPW = 0 ElseIf RadioButtonPW035Tari.Checked = True Then TxPW = 1 ElseIf RadioButtonPW044Tari.Checked = True Then TxPW = 2 ElseIf RadioButtonPW05Tari.Checked = True Then TxPW = 3 End If

If RadioButtonTXone15Tari.Checked = True Then TxOne = 0 ElseIf RadioButtonTXone166Tari.Checked = True Then TxOne = 1 ElseIf RadioButtonTXone183Tari.Checked = True Then TxOne = 2 ElseIf RadioButtonTXone2Tari.Checked = True Then TxOne = 3 End If

If RadioButtonSessionS0.Checked = True Then Session = 0 ElseIf RadioButtonSessionS1.Checked = True Then Session = 1 ElseIf RadioButtonSessionS2.Checked = True Then Session = 2 ElseIf RadioButtonSessionS3.Checked = True Then


Anexos

Session = 3 End If

If RadioButton40kHz.Checked = True Then Rx_LF = 0 BLF = 40 ElseIf RadioButton160kHz.Checked = True Then Rx_LF = 6 BLF = 160 ElseIf RadioButton256kHz.Checked = True Then Rx_LF = 9 BLF = 256 ElseIf RadioButton320kHz.Checked = True Then Rx_LF = 12 BLF = 320 ElseIf RadioButton640kHz.Checked = True Then Rx_LF = 15 BLF = 640 End If

If RadioButtonShortPreamble.Checked = True Then TRext = False ElseIf RadioButtonLongPreamble.Checked = True Then TRext = True End If

If RadioButtonDR8.Checked = True Then DR = 0 DRValue = 8 ElseIf RadioButtonDR643.Checked = True Then DR = 1 DRValue = 64 / 3 End If

If RadioButtonPower7mA.Checked = True Then etx = 1 ElseIf RadioButtonPower14mA.Checked = True Then etx = 2 ElseIf RadioButtonPower22mA.Checked = True Then etx = 3 End If

Txdel = NumericUpDownTxdel.Value / 6.4 NoResp = NumericUpDownNoResp.Value / 25.6 Rxw = NumericUpDownRxw.Value / 6.4

' Solicitud de SetConfiguration IOBuf(0) = &H1 ' Este numero indica el comando SetConfiguration

'IOBuf(1): 0 0 0 0 RXcod<1:0> Tari <1:0> IOBuf(1) = &H0 ' IOBuf(1) = 0 0 0 0 0 0 0 0 IOBuf(1) = IOBuf(1) Or (Rxcod << 2) ' IOBuf(1) = 0 0 0 0 Rxcod<1:0> 0 0 IOBuf(1) = IOBuf(1) Or Tari ' IOBuf(1) = 0 0 0 0 Rxcod<1:0> Tari<1:0>

'IOBuf(2): TxPW<1:0> TXOne<1:0> 0 0 S<1:0> IOBuf(2) = &H0 ' IOBuf(2) = 0 0 0 0 0 0 0 0 IOBuf(2) = IOBuf(2) Or (TxPW << 6) Or (TxOne << 4) Or Session ' IOBuf(2) = TxPW<1:0> TXOne<1:0> 0 0 S<1:0>

'IOBuf(3): Rx_LF<3:0> 0 0 TRext 0 IOBuf(3) = &H0 ' IOBuf(3) = 0 0 0 0 0 0 0 0 If TRext = False Then IOBuf(3) = IOBuf(3) Or (Rx_LF << 4) ' IOBuf(3) = Rx_LF<3:0> 0 0 0 0 ElseIf TRext = True Then IOBuf(3) = IOBuf(3) Or (Rx_LF << 4) Or &H2 ' IOBuf(3) = Rx_LF<3:0> 0 0 1 0 End If

'IOBuf(4): 0 0 0 0 0 0 etx<1:0> IOBuf(4) = &H0 ' IOBuf(4) = 0 0 0 0 0 0 0 0 IOBuf(4) = IOBuf(4) Or etx ' IOBuf(4) = 0 0 0 0 0 0 etx<1:0>

'IOBuf(5): Txdel<7:0> IOBuf(5) = Txdel


Anexos

'IOBuf(6): NoResp<7:0> IOBuf(6) = NoResp

'IOBuf(7): Rxw<7:0> IOBuf(7) = Rxw

'IOBuf(8): 0 0 0 0 0 0 0 DR IOBuf(8) = DR

'IOBuf(9): TRcal<7:0> 'IOBuf(10): 0 0 0 0 TRcal<11:8> ' BLF = DR / TRcal ' TRcal [us] = DR * 1000 / BLF [kHz] ; TRcal = 0.1...409 [us] ' TRcal [0...4095] = (DR * 1000 / BLF [kHz]) * 10 - 1 ' En el caso del AS3992, los posibles valores de TRcal son discretos (como lo son los de BLFy DR) Select Case BLF Case 40 If DR = 0 Then ' DR = 8 TRcal = 1999 End If Case 160 If DR = 0 Then ' DR = 8 TRcal = 499 ElseIf DR = 1 Then ' DR = 64/3 TRcal = 1332 End If Case 256 If DR = 0 Then ' DR = 8 TRcal = 312 ElseIf DR = 1 Then ' DR = 64/3 TRcal = 832 End If Case 320 If DR = 0 Then ' DR = 8 TRcal = 249 ElseIf DR = 1 Then ' DR = 64/3 TRcal = 666 End If Case 640 If DR = 1 Then ' DR = 64/3 TRcal = 332 End If End Select

IOBuf(9) = TRcal And &HFF IOBuf(10) = TRcal >> 8

'IOBuf(11): byp160 byp40 lp<3:1> hp<3:1> Select Case BLF Case 40 IOBuf(11) = &HFF Case 160 IOBuf(11) = &H3F Case 256 IOBuf(11) = &H37 Case 320 IOBuf(11) = &H27 Case 640 IOBuf(11) = &H7 End Select


' Esperar a que el dispositivo haya escrito los datos While Not DatosEnCola Status = SI_CheckRXQueue(hUSBDevice, BytesInQueue, QueueStatus) If Status = SI_SUCCESS Then Select Case QueueStatus Case SI_QUEUE_NO_OVERRUN ' = SI_RX_EMPTY TextBoxError.Text = "Cola vacia"


Anexos

Case SI_QUEUE_OVERRUN Case SI_QUEUE_READY ' Hay bytes en la cola If BytesInQueue = 1 Then ' La respuesta a este comando (SetConfiguration) es de 1 byte DatosEnCola = True TextBoxError.Text = "" End If End Select Else TextBoxError.Text = "Ocurrio un error" End If End While

' Leer la respuesta a este comando (SetConfiguration) Status = SI_Read(hUSBDevice, IOBuf(0), 1, BytesReturned, 0) ' La respuesta a este comando (SetConfiguration) es de 1 byte

If Status = SI_SUCCESS Then If IOBuf(0) = &H0 Then ' No ha ocurrido ningun error al procesar el comando SetConfiguration GetConfiguration() ' Obtenemos la configuracion del chip (AS3992) Else ' Ha ocurrido un error al procesar el comando SetConfiguration TextBoxError.Text = "Error al enviar la configuracion al chip" End If Else TextBoxError.Text = "Ocurrio un error" End If


End Sub

' Rutina que envia el comando StoreRN16 al dispositivo (almacenar numero aleatorio de 16 bits) Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click ' Variable que indica si se han recibido datos por USB

Dim DatosEnCola As Boolean = False' Variable para el fichero de texto para escribir los RN16 recibidos

Dim Fichero As System.IO.StreamWriter' Variable para cada linea del fichero de texto

Dim Linea As String

' Barra de progreso en la interfaz de usuario. Se llena a medida que se va escribiendo el numero especificado de RN16 ProgressBarRN16.Value = 0

' Creamos un nuevo fichero de log de los RN16 Fichero = Microsoft.VisualBasic.FileIO.FileSystem.OpenTextFileWriter("C:/Users/usuario/Desktop/RN16 log.txt", False)

' Obtenemos del Tag el numero de RN16 indicado por el control NumericUpDownNumberOfRN16 For index = 1 To NumericUpDownNumberOfRN16.Value

'Solicitud de StoreRN16 IOBuf(0) = &H2 'Este numero indica el comando StoreRN16 ' Construimos un byte en el que el nibble mas significativo es el tiempo en que el Tag se mantiene a power-on ' y el nibble menos significativo es el tiempo que el Tag se mantiene powered-off IOBuf(1) = (NumericUpDownPoweredOnTime.Value / NumericUpDownPoweredOnTime.Increment) * 16 _ + (NumericUpDownPoweredOffTime.Value / NumericUpDownPoweredOffTime.Increment)


' Esperar a que el dispositivo haya escrito el RN16 While Not DatosEnCola 'While BytesInQueue < 4 ' La respuesta a este comando es de 3 bytes: ErrorCode


Anexos

(1 byte) RN16 (2 bytes) 'While False Status = SI_CheckRXQueue(hUSBDevice, BytesInQueue, QueueStatus) If Status = SI_SUCCESS Then Select Case QueueStatus Case SI_QUEUE_NO_OVERRUN ' = SI_RX_EMPTY TextBoxError.Text = "Cola vacia" Case SI_QUEUE_OVERRUN Case SI_QUEUE_READY ' Hay bytes en la cola ' Aparentemente, esperando a que se produzca el estado SI_QUEUE_READY y a que el numero ' de bytes en la cola sea el esperado, la recepcion de RN16 funcionasiempre bien If BytesInQueue >= 4 Then DatosEnCola = True TextBoxError.Text = "" End If End Select Else TextBoxError.Text = "Ocurrio un error" End If End While

DatosEnCola = False

' Leer el RN16 Status = SI_Read(hUSBDevice, IOBuf(0), BytesInQueue, BytesReturned, 0)

If Status = SI_SUCCESS Then

If IOBuf(1) = 0 Then ' La respuesta al Query fue correcta por lo que habremos recibido un RN16 ' Construimos el RN16 Linea = Hex(IOBuf(2)) & Hex(IOBuf(3)) ' Escribimos el RN16 en el fichero de log Fichero.WriteLine(Linea)

Else ' La respuesta al Query NO fue correcta por lo que NO habremos recibido un RN16

' Reflejamos el fallo en el fichero de log Fichero.WriteLine("Failed")

End If



' Actualizamos la barra de progreso ProgressBarRN16.Value = (index / NumericUpDownNumberOfRN16.Value) * 100

Next

' Cerramos el fichero de log de los RN16 Fichero.Close()

End Sub

' Rutina que envia el comando SingleRead al dispositivo (lectura simple) Private Sub Button3_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button3.Click 'Variable que indica si se han recibido datos por USB

Dim DatosEnCola As Boolean = False

' Solicitud de SingleRead IOBuf(0) = &H3 ' Este numero indica el comando SingleRead

IOBuf(1) = &H0 ' Construimos el byte que es el parametro de este comando


Anexos

If CheckBoxTemperatura.Checked = True And CheckBoxECG.Checked = True Then IOBuf(1) = &H3 ElseIf CheckBoxTemperatura.Checked = True Then IOBuf(1) = &H2 ElseIf CheckBoxECG.Checked = True Then IOBuf(1) = &H1 End If

If IOBuf(1) <> &H0 Then ' Si se ha marcado Temperatura o ECG

' Enviamos el codigo del comando y los parametros al uC Status = SI_Write(hUSBDevice, IOBuf(0), 2, BytesWritten, 0) If Status = SI_SUCCESS Then

' Esperar a que el dispositivo haya escrito los datos While Not DatosEnCola Status = SI_CheckRXQueue(hUSBDevice, BytesInQueue, QueueStatus) If Status = SI_SUCCESS Then Select Case QueueStatus Case SI_QUEUE_NO_OVERRUN ' = SI_RX_EMPTY TextBoxError.Text = "Cola vacia" Case SI_QUEUE_OVERRUN Case SI_QUEUE_READY ' Hay bytes en la cola DatosEnCola = True End Select Else TextBoxError.Text = "Ocurrio un error" End If

End While

' Leer el valor de Temperatura o ECG solicitado ' Respuesta del uC al comando SingleRead ' Temperatura ECG ' 1 byte 1 byte Status = SI_Read(hUSBDevice, IOBuf(0), 2, BytesReturned, 0) If Status = SI_SUCCESS Then

If CheckBoxTemperatura.Checked = True Then LabelTemperatura.Text = IOBuf(0) End If If CheckBoxECG.Checked = True Then LabelECG.Text = IOBuf(1) End If



End If

End Sub

' Rutina que envia el comando CompleteSense al dispositivo (sensado completo) Private Sub Button4_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button4.Click ' Variable que indica si se han recibido datos por USB

Dim DatosEnCola As Boolean = False Dim WaitTime As Byte ' Para definir el tiempo que se va a esperar entre el Write y el Read ' Numero de bytes que se esperan en respuesta al comando CompleteSense Dim ExpectedBytes As Byte ' Seran 8 (si se mide tempratura y ECG) o 6 (si se mide solo una de las 2 magnitudes)

' Solicitud de CompleteSense IOBuf(0) = &H4 ' Este numero indica el comando CompleteSense

IOBuf(1) = &H0 ' Construimos el byte que es el primer parametro de este comando If CheckBoxECG.Checked = True Then IOBuf(1) = IOBuf(1) + 1


Anexos

End If If CheckBoxTemperatura.Checked = True Then IOBuf(1) = IOBuf(1) + 2 End If If CheckBoxClockCalibration.Checked = True Then IOBuf(1) = IOBuf(1) + 4 End If ' Hemos obtenido en IOBuf(1): 0 0 0 0 0 ClockCal T ECG

WaitTime = (NumericUpDownWaitTime.Value - 3) * 2 ' WaitTime: 0 0 0 0 WaitTime<3:0> WaitTime = WaitTime << 4 ' Obtenemos en WaitTime: WaitTime<3:0> 0 0 0 0 IOBuf(1) = IOBuf(1) Or WaitTime ' Obtenemos en IOBuf(1): WaitTime<3:0> 0 ClockCal T ECG

' Construimos los otros 2 bytes que tiene como parametros este comando IOBuf(2) = NumericUpDownSensorCalibration.Value IOBuf(3) = NumericUpDownClockCalibration.Value

If IOBuf(1) <> &H0 Then ' Si se ha marcado Temperatura o ECG

'Determinamos el numero de bytes que se esperan en respuesta al comando CompleteSense If CheckBoxTemperatura.Checked = True And CheckBoxECG.Checked = True Then ExpectedBytes = 9 ' Si se marcan temperatura y ECG la respuesta sera de 9 bytes Else ' Solo se ha marcado o bien temperatura o bien ECG ExpectedBytes = 7 End If

' Enviamos el codigo del comando y los parametros al uC Status = SI_Write(hUSBDevice, IOBuf(0), 4, BytesWritten, 0)

Return


' Esperar a que el dispositivo haya escrito los datos solicitados While BytesInQueue < ExpectedBytes ' La respuesta al comando CompleteSense es de ExpectedBytes bytes 'While Not DatosEnCola Status = SI_CheckRXQueue(hUSBDevice, BytesInQueue, QueueStatus) If Status = SI_SUCCESS Then Select Case QueueStatus Case SI_QUEUE_NO_OVERRUN ' = SI_RX_EMPTY TextBoxError.Text = "Cola vacia" Case SI_QUEUE_OVERRUN Case SI_QUEUE_READY ' Hay bytes en la cola DatosEnCola = True End Select Else TextBoxError.Text = "Ocurrio un error" End If

End While

' Leer el valor de Temperatura o ECG solicitado y los parametros para el escalado ' Respuesta del uC al comando SingleRead ' sens_cal_count N2cal N2temp (Temperatura) ncycles (ECG) ' 2 bytes 2 bytes 2 bytes 2 bytes Status = SI_Read(hUSBDevice, IOBuf(0), ExpectedBytes, BytesReturned, 0) 'Status = SI_Read(hUSBDevice, IOBuf(0), 1, BytesReturned, 0) If Status = SI_SUCCESS Then

MsgBox(Hex(IOBuf(0)) & " " & Hex(IOBuf(1)) & " " & Hex(IOBuf(2)) & " " & Hex(IOBuf(3)) & _ " " & Hex(IOBuf(4)) & " " & Hex(IOBuf(5)) & " " & Hex(IOBuf(6)))

If IOBuf(ExpectedBytes - 1) <> &HFF Then ' No ha habido error

If CheckBoxTemperatura.Checked = True Then LabelTemperatura.Text = IOBuf(4) * 16 + IOBuf(5) End If If CheckBoxECG.Checked = True And CheckBoxTemperatura.Checked = True Then LabelECG.Text = IOBuf(6) * 16 + IOBuf(7) ElseIf CheckBoxECG.Checked = True Then LabelECG.Text = IOBuf(4) * 16 + IOBuf(5) End If


Anexos

MsgBox("sens_cal_count: " & (IOBuf(0) * 16 + IOBuf(1)) & ", N2cal: " & (IOBuf(2) * 16 + IOBuf(3))) Else ' Ha habido error MsgBox("Error") End If



End If

End Sub

' Rutina que envia el comando TestClockCalibration al dispositivo (testeo de la calibracion del reloj) Private Sub Button5_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button5.Click

' Variable que indica si se han recibido datos por USB Dim DatosEnCola As Boolean = False

' Solicitud de TestClockCalibration IOBuf(0) = &H5 ' Este numero indica el comando TestClockCalibration

' Barra de progreso en la interfaz de usuario. Se llena a medida que se van enviando los comandos ProgressBarTestClockCalibration.Value = 0

' Bucle para iterar por todos los valores posibles del parametro del comando ClockCalibration For CalWord = 0 To 255 IOBuf(1) = CalWord


' Esperar a que el dispositivo haya escrito los datos While Not DatosEnCola Status = SI_CheckRXQueue(hUSBDevice, BytesInQueue, QueueStatus) If Status = SI_SUCCESS Then Select Case QueueStatus Case SI_QUEUE_NO_OVERRUN ' = SI_RX_EMPTY TextBoxError.Text = "Cola vacia" Case SI_QUEUE_OVERRUN Case SI_QUEUE_READY ' Hay bytes en la cola If BytesInQueue = 1 Then DatosEnCola = True TextBoxError.Text = "" End If End Select Else TextBoxError.Text = "Ocurrio un error" End If End While

DatosEnCola = False

' Leer la respuesta a este comando Status = SI_Read(hUSBDevice, IOBuf(0), 1, BytesReturned, 0)


If IOBuf(1) = 0 Then ' La respuesta fue correcta ' Actualizamos la barra de progreso

ProgressBarTestClockCalibration.Value = (CalWord / 255) * 100

Else ' La respuesta NO fue correcta


Anexos

TextBoxError.Text = "Ocurrio un error durante la ejecucion del comando TestClockCalibration"

End If



Next

End Sub End Class


ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA...

Documents

Transcript of ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA...