antenas inteligentes

UNIVERSIDAD DE CARABOBO

FACULTAD DE INGENIERÍA

ESCUELA DE INGENIERÍA DE

TELECOMUNICACIONES

DEPARTAMENTO DE

ELECTROMAGNETISMO Y RADIACIÓN

SIMULACIÓN Y EVALUACIÓN DE ALGORITMOS DE DIRECCIÓN

DE ARRIBO (DOA) EN DISTINTOS PROCESADORES DIGITALES DE

SEÑALES (DSP’S) USADOS EN ANTENAS INTELIGENTES

DAVID A. RANGEL B.

e-mail: [email protected]

JOSÉ D. MADURO H.

e-mail: [email protected]

Bárbula, 4 de Marzo del 2015




TELECOMUNICACIONES

DEPARTAMENTO DE





TRABAJO ESPECIAL DE GRADO PRESENTADO ANTE LA ILUSTRE UNIVERSIDAD DE

CARABOBO PARA OPTAR AL TÍTULO DE INGENIERO DE TELECOMUNICACIONES E

INGENIERO ELECTRICISTA, RESPECTIVAMENTE

DAVID A. RANGEL B.

JOSÉ D. MADURO H.





TELECOMUNICACIONES

DEPARTAMENTO DE


CERTIFICADO DE APROBACIÓN

Los abajo firmantes miembros del jurado asignado para evaluar el trabajo espe-

cial de grado titulado «SIMULACIÓN Y EVALUACIÓN DE ALGORITMOS DE DIREC-

CIÓN DE ARRIBO (DOA) EN DISTINTOS PROCESADORES DIGITALES DE SEÑALES

(DSP’S) USADOS EN ANTENAS INTELIGENTES», realizado por los bachilleres DA-

VID A. RANGEL B., cédula de identidad 21.653.185, JOSÉ D. MADURO H., cédula de

identidad 20.194.455, hemos decidido otorgar la máxima calificación y la mención

honorífica al presente trabajo, con base a los siguientes motivos:

1) Los estudiantes lograron un dominio muy amplio del tema tratado, abarcando otros campos

del saber y excediendo ampliamente el logro de los objetivos iniciales. 2) Los estudiantes desarro-

llaron un alcance que sobrepasa los límites iniciales planteados. 3) El material desarrollado quedó

estructurado como una plataforma de amplio uso, para investigaciones futuras en el área de Antenas

Inteligentes.

Firma

Prof. RAFAEL ALBORNOZ

TUTOR

Firma

Prof. PAULINO DEL PINO

JURADO

Firma

Prof. CARLOS MEJÍAS

JURADO


Dedicatoria

A mi Señor Jesucristo, la fuente de mi vida

A mi amada y dulce esposa, Karen Pérez

A mis padres Eugenio Rangel y Gregoria Bolcan

DAVID A. RANGEL B.

A mi amado Cristo, Rey, Señor y Salvador de mi vida

A mis padres Gregorio y Dumidián y a mi tía Nene, mis pilares

A mis hermanos, Jesús, Adriana y Gregori, mis fuentes de apoyo

JOSÉ D. MADURO H.

Agradecimientos

A nuestro Señor Jesucristo, quien murió por nuestros pecados y resucitó para

darnos redención y vida eterna. A Él que en todo momento estuvo con nosotros

y escuchó nuestras oraciones, y tal como diría el Apóstol Pablo: «Toda la gloria sea

para Dios, quien puede lograr mucho más de lo que pudiéramos pedir o incluso imaginar

mediante su gran poder, que actúa en nosotros. ¡Gloria a él en la iglesia y en Cristo Jesús

por todas las generaciones desde hoy y para siempre! Amén» Efesios 3:20-21.

A nuestros padres, por su apoyo incondicional, por los principios y valores sem-

brados en nuestras vidas, por ser ellos el motor que nos impulsa a alcanzar nuestras

metas.

Al Profesor Rafael Albornoz, nuestro Tutor académico, por sus conocimientos

impartidos en la cátedra de Antenas y Propagación, por la paciencia y dedicación

que tuvo con nosotros en el desarrollo de esta investigación y además, por su agra-

dable humor.

A la Ilustre Universidad de Carabobo, nuestra alma máter, por ser nuestro se-

gundo hogar y quien nos brindó tan preciados conocimientos.

Al cuerpo docente de la Facultad de Ingeniería que han sido parte de nuestra

formación profesional.

A nuestro amigo Gabriel Santamaría porque siempre contamos con su apoyo

y por brindarnos su ayuda para resolver varias de nuestras interrogantes en este

trabajo.

A la familia Maduro Henríquez por acogerme con amor y atención en su hogar

durante el transcurso de esta investigación, estando atentos a todas nuestras necesi-

dades, gracias al Señor Gregorio por estar dispuesto en todo momento y a la Señora

Dumidián por su atención tan especial. Agradezco a Dios el haberme dado la opor-

tunidad de tener como compañero de tesis a mi hermano y amigo Daniel Maduro,

VI

por su valioso trabajo en esta investigación, su gran esfuerzo en no perder cada de-

talle, estoy seguro que cada línea de esta investigación han llevado sus excelentes

correcciones. Dios bendiga su vida y el fruto de sus manos, (David Rangel).

A mis amigos que en todo tiempo estuvieron para apoyarme; en especial quiero

agradecer a Janeitti Matos, quien con mucho cariño siempre me escuchó cada vez

que necesitaba hablar con alguien, sus palabras alimentaron mi ser de ese ánimo

que necesitaba para continuar. A Rossana Márquez que cada día estuvo pendiente

de cómo iba todo y estuvo presente en cada paso que daba. A Karen Mendoza por

estar siempre atenta, contar con su motivación fue de gran estima. A Marelyn Sáez

quien desde inicios de la carrera ha batallado conmigo, y por haberme ofrecido

su ayuda para lo que necesitara. Gracias especiales a mi mejor amigo y hermano

David Rangel, además de excelente compañero de tesis, por su valiosa amistad y

por estar siempre presente en todo momento, (Daniel Maduro H).

Índice general

Índice de Figuras XI

Índice de Tablas XV

Acrónimos XIX

Lista de Símbolos XXI

Resumen XXV

I. Introducción 11.1. MOTIVACIÓN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. OBJETIVOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1. Objetivo General. . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.2. Objetivos Específicos. . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. ALCANCES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

II. Marco conceptual 72.1. INTRODUCCIÓN A LOS SISTEMAS DE ANTENAS INTELIGENTES. 7

2.1.1. Limitaciones de las técnicas de Acceso Múltiples convencio-nales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2. Acceso Multiple por División de Espacio (SDMA). . . . . . . . 82.1.3. Tecnología de Antenas Inteligentes. . . . . . . . . . . . . . . . 9

2.1.3.1. Técnicas de implementación. . . . . . . . . . . . . . . 11Haz Conmutado. . . . . . . . . . . . . . . . . . . . . . . 12Haz de Seguimiento. . . . . . . . . . . . . . . . . . . . . 12Haz Adaptativo. . . . . . . . . . . . . . . . . . . . . . . 13

2.1.3.2. Sistema de Antena Inteligente de haz adaptativo. . . 142.2. ESTIMACIÓN DE LA DIRECCIÓN DE ARRIBO (DOA). . . . . . . . 15

2.2.1. Modelo general del sistema. . . . . . . . . . . . . . . . . . . . . 152.2.1.1. Sistema de coordenadas a usar. . . . . . . . . . . . . 162.2.1.2. Propagación de ondas. . . . . . . . . . . . . . . . . . 162.2.1.3. Modelo paramétrico de los datos. . . . . . . . . . . . 18

VII

VIII Índice general

2.2.1.4. Agrupación de antena. . . . . . . . . . . . . . . . . . 202.2.1.5. Consideraciones generales del modelo. . . . . . . . . 222.2.1.6. Matriz de observaciones. . . . . . . . . . . . . . . . . 24

2.2.2. Algoritmo de Clasificación de Señales Múltiples (MUSIC-MUltipleSIgnal Classification). . . . . . . . . . . . . . . . . . . . . . . . 272.2.2.1. Espectro MUSIC. . . . . . . . . . . . . . . . . . . . . . 29

2.2.3. Método de Máxima Verosimilitud (ML-Maximum Likelihood). 312.2.3.1. Máxima Verosimilitud Determinística (DML-Deterministic

Maximum Likelihood). . . . . . . . . . . . . . . . . . 322.3. PROCESAMIENTO DIGITAL DE LAS SEÑALES. . . . . . . . . . . . 34

2.3.1. Procesador Digital de Señal (DSP). . . . . . . . . . . . . . . . . 362.3.2. Elementos básicos de un sistema de DSP en tiempo real. . . . 36

2.4. GENERACIÓN Y OPTIMIZACIÓN DE CÓDIGO PARA DSP’s. . . . 372.4.1. Embedded MATLAB. . . . . . . . . . . . . . . . . . . . . . . . 38

2.4.1.1. Limitaciones de Embedded MATLAB. . . . . . . . . 412.4.1.2. Funciones C-MEX (C-Matlab Executable). . . . . . . 42

2.4.2. Compilador C de propósito general. . . . . . . . . . . . . . . . 432.4.3. Code Composer Studio (CCS). . . . . . . . . . . . . . . . . . . 43

III.Procedimientos de la investigación. 453.1. Estudio de la estimación de llegada y los métodos MUSIC y ML. . . . 46

3.1.1. Naturaleza de las señales del entorno. . . . . . . . . . . . . . . 473.1.2. Respuesta del Arreglo de antena. . . . . . . . . . . . . . . . . . 483.1.3. Matriz de Covarianza . . . . . . . . . . . . . . . . . . . . . . . 52

3.2. Simulaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3. Evaluación de la respuesta computacional de distintos DSP’s. . . . . 56

3.3.1. Optimización de MUSIC y DML. . . . . . . . . . . . . . . . . . 563.3.2. Estimación del tiempo de ejecución del algoritmo DoA en el

DSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.3.3. Método para el desarrollo de software de sistemas embebi-

dos, Harmony/ESW. . . . . . . . . . . . . . . . . . . . . . . . . 603.4. Creación de un procedimiento general. . . . . . . . . . . . . . . . . . . 62

3.4.1. Modificación del código en MATLAB con las restricciones in-terpuestas por Embedded MATLAB. . . . . . . . . . . . . . . . 62

3.4.2. Generación de código fuente C. . . . . . . . . . . . . . . . . . . 633.4.3. Depuración y validación del código C resultante. . . . . . . . 653.4.4. Compilación de los códigos en CCS. . . . . . . . . . . . . . . . 66

IV. Análisis, interpretación y presentación de los resultados 674.1. ANÁLISIS DEL PROBLEMA DE ESTIMACIÓN Y LOS MÉTODOS

MUSIC Y DML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.1.1. MUSIC Y DML. . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.2. SIMULACIONES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Índice general IX

4.2.1. Escenario 1: Comportamiento de MUSIC y DML variando(SNR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2.2. Escenario 2: Comportamiento de MUSIC y DML variando elnúmero de observaciones (N). . . . . . . . . . . . . . . . . . . 76

4.2.3. Escenario 3: Comportamiento de MUSIC y DML en condicio-nes desfavorables. . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.2.4. Escenario 4: Comportamiento de MUSIC y DML para distin-tas portadoras que se encuentran dentro del ancho de bandadel dipolo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.2.5. Escenario 5: Comportamiento de MUSIC y DML con fuentesmuy próximas entre sí. . . . . . . . . . . . . . . . . . . . . . . . 88

4.3. EVALUACIÓN DE LA RESPUESTA COMPUTACIONAL DE PRO-CESADORES DIGITALES DE SEÑAL (DSP’s). . . . . . . . . . . . . . 924.3.1. Simulaciones en Code Composer Studio (CCS). . . . . . . . . 924.3.2. Tiempo de ejecución de los algoritmos DoA. . . . . . . . . . . 102

4.4. CREACIÓN DE UN PROCEDIMIENTO GENERAL. . . . . . . . . . . 1104.4.1. Modificación del código en MATLAB con las restricciones in-

terpuestas por Embedded MATLAB. . . . . . . . . . . . . . . . 1114.4.2. Generación de código fuente C. . . . . . . . . . . . . . . . . . . 1134.4.3. Depuración y validación del código C resultante. . . . . . . . 1184.4.4. Simulación en Code Composer Studio (CCS). . . . . . . . . . . 119

V. Conclusiones y recomendaciones 1295.1. Conclusiones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295.2. Recomendaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

A. Códigos en Embedded MATLAB de algoritmos DoA. 1331.1. MATRIZ DE COVARIANZA. . . . . . . . . . . . . . . . . . . . . . . . 1331.2. RUIDO AWGN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1361.3. ALGORITMO MUSIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

1.3.1. Función SVD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1371.3.2. FUNCION MAXIMO . . . . . . . . . . . . . . . . . . . . . . . 137

1.4. DML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

B. DoA Y BF en un solo DSP. 1432.1. Conformación de Haz (BF-Beamforming). . . . . . . . . . . . . . . . . 143

2.1.1. Conformación de Haz digital (DBF-Digital Beamforming). . . 1442.2. DoA y BF usando técnicas de multiprogramación. . . . . . . . . . . . 148

C. Consideración de la frecuencia de portadora. 1573.1. Algoritmo DML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573.2. Algoritmo MUSIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

X Índice general

Referencias Bibliográficas 163

Índice de figuras

2.1. Posible escenario de SDMA. . . . . . . . . . . . . . . . . . . . . . . . . 102.2. Diferencia entre un patrón de radiación de una estación base tradi-

cional y una de Antena Inteligente. . . . . . . . . . . . . . . . . . . . . 122.3. Técnicas de implementación para sistemas de Antena Inteligente. . . 132.4. Sistema de Antenas Inteligentes en un sistema de comunicación full

Duplex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5. Sistema de coordenadas a usar. . . . . . . . . . . . . . . . . . . . . . . 162.6. Frente de onda en el plano de una fuente puntual en función de la

distancia de propagación |r| [1]. . . . . . . . . . . . . . . . . . . . . . . 182.7. Geometría de un arreglo genérico. . . . . . . . . . . . . . . . . . . . . 192.8. Arreglo Lineal Uniforme (ULA) de un conjunto de antenas. . . . . . . 212.9. Arreglo lineal de antena generalizado. . . . . . . . . . . . . . . . . . . 252.10. Diagrama de bloque de la estimación de DoA usando MUSIC [1]. . . 282.11. Diagrama de bloque básico de un sistema de DSP en tiempo real [2]. 37

3.1. Etapas de la investigación. . . . . . . . . . . . . . . . . . . . . . . . . . 463.2. Arreglo lineal uniforme usado en comunicaciones móviles con diver-

sidad espacial y polarización vertical. . . . . . . . . . . . . . . . . . . 483.3. Arreglo linealmente uniforme a usar para la simulación. . . . . . . . 493.4. Diagrama de flujo del algoritmo MUSIC. . . . . . . . . . . . . . . . . 533.5. Diagrama de flujo del algoritmo DML. . . . . . . . . . . . . . . . . . . 543.6. Escenario del usuario crítico . . . . . . . . . . . . . . . . . . . . . . . . 593.7. Tiempo a satisfascer en la ejecución del algoritmo DoA. . . . . . . . . 603.8. Método adoptado para desarrollo de software de sistemas embebi-

dos, Harmony/ESW). . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.9. Proceso para la generación de aplicaciones embebidas mediante MATLAB,

lenguaje C y Code Composer Studio (CCS). . . . . . . . . . . . . . . . 62

4.1. Máximos del espectro MUSIC con SNR = 30dB. . . . . . . . . . . . . 714.2. Máximos del espectro MUSIC con SNR = 20dB. . . . . . . . . . . . . 724.3. Máximos del espectro MUSIC con SNR = 10dB. . . . . . . . . . . . . 724.4. Máximos del espectro MUSIC con SNR = 0dB. . . . . . . . . . . . . . 734.5. Ángulos estimados (�θ) por DML con SNR = 30dB. . . . . . . . . . . . 74

XI

XII Índice de figuras

4.6. Ángulos estimados (�θ) por DML con SNR = 20dB. . . . . . . . . . . . 744.7. Ángulos estimados (�θ) por DML con SNR = 10dB. . . . . . . . . . . . 754.8. Ángulos estimados (�θ) por DML con SNR = 0dB. . . . . . . . . . . . 754.9. Máximos del espectro MUSIC con N = 500. . . . . . . . . . . . . . . . 774.10. Máximos del espectro MUSIC con N = 200. . . . . . . . . . . . . . . . 774.11. Máximos del espectro MUSIC con N = 100. . . . . . . . . . . . . . . . 784.12. Máximos del espectro MUSIC con N = 10. . . . . . . . . . . . . . . . . 784.13. Ángulos estimados (�θ) por DML con N = 500. . . . . . . . . . . . . . 794.14. Ángulos estimados (�θ) por DML con N = 200. . . . . . . . . . . . . . 804.15. Ángulos estimados (�θ) por DML con N = 100. . . . . . . . . . . . . . 804.16. Ángulos estimados (�θ) por DML con N = 10. . . . . . . . . . . . . . . 814.17. Máximos del espectro MUSIC en ambiente desfavorable. . . . . . . . 824.18. Ángulos estimados (�θ) por DML en ambiente desfavorable. . . . . . 834.19. Máximos del espectro MUSIC para distintas frecuencias de portadoras. 854.20. Ángulos estimados (�θ) por DML para distintas frecuencias de porta-

doras. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.21. Máximos del espectro MUSIC con fuentes próximas entre sí. . . . . . 894.22. Ángulos estimados (�θ) por DML con fuentes próximas entre sí. . . . 904.23. Espectro MUSIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.24. Máximos del espectro MUSIC con la modificación de la función Máximo.1104.25. Mensaje de error de compilación. . . . . . . . . . . . . . . . . . . . . . 1134.26. Reporte de error de compilación. . . . . . . . . . . . . . . . . . . . . . 1144.27. Mensaje de reporte de compilación satisfactorio. . . . . . . . . . . . . 1154.28. Resultados de la matriz de covarianza usando la función original de

MATLAB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1164.29. Resultados de la matriz de covarianza usando la función C-MEX. . . 1164.30. Generación de código fuente C libre de plataforma mediante RTW. . 1164.31. Reporte de compilación de la generación de código C mediante RTW. 1174.32. Validación de los resultados de la matriz de covarianza en el IDE

Code::Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194.33. Secuencia inicial para crear un nuevo proyecto . . . . . . . . . . . . . 1204.34. Configuraciones del proyecto . . . . . . . . . . . . . . . . . . . . . . . 1214.35. Opción para añadir archivos al proyecto . . . . . . . . . . . . . . . . . 1224.36. Linker Command File para el TMS320C6727 . . . . . . . . . . . . . . 1234.37. Nombre de las secciones de memoria. . . . . . . . . . . . . . . . . . . 1244.38. Configuración del simulador de Texas Instruments. . . . . . . . . . . 1264.39. Simulador de Texas instruments. . . . . . . . . . . . . . . . . . . . . . 1264.40. Interfaz del Simulador donde se observan la función Clock y la ven-

tana de variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

2.1. Estructura de BF [3]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1442.2. Secuencia de muestreo en DBF [3]. . . . . . . . . . . . . . . . . . . . . 145

Índice de figuras XIII

2.3. Secuencia de muestreo en ∆/2 . . . . . . . . . . . . . . . . . . . . . . . 1472.4. Etapa de DoA, Tarea 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1502.5. Etapa de BF, Tarea 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1502.6. Multitarea en una ventana de tiempo. . . . . . . . . . . . . . . . . . . 1542.7. Esquema de memoria principal. . . . . . . . . . . . . . . . . . . . . . . 155

3.1. Espectro MUSIC con ∆f = 100KHz. . . . . . . . . . . . . . . . . . . . . 1593.2. Espectro MUSIC con dos señales a la misma frecuencia de portadora. 159

Indice de tablas

2.1. Variables e índices utilizadas para definir las dimensiones de las ma-trices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2. Diferencias entre MATLAB y lenguaje C. . . . . . . . . . . . . . . . . 42

3.1. Rangos de frecuencias para comunicaciones móviles más usados; es-tablecidos por CONATEL. . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2. Variables de interés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.3. Comando para la generación de funciones C-MEX. . . . . . . . . . . . 633.4. Comando para la generación de código fuente C. . . . . . . . . . . . . 65

4.1. Variables de entrada para evaluar los algoritmos MUSIC y DML. . . 704.2. Media y varianza de MUSIC con SNR = 10dB. . . . . . . . . . . . . . 734.3. Media y varianza de DML con SNR = 0dB. . . . . . . . . . . . . . . . 764.4. Media y varianza de DML con N = 10. . . . . . . . . . . . . . . . . . . 814.5. Media y varianza de DML con N = 10. . . . . . . . . . . . . . . . . . . 844.6. Distintas frecuencias de portadora. . . . . . . . . . . . . . . . . . . . . 854.7. Media y varianza de MUSIC para distintas frecuencias de portadoras. 864.8. Frecuencias portadora de las señales. . . . . . . . . . . . . . . . . . . . 864.9. Media y varianza de DML para distintas frecuencias de portadoras. . 874.10. Modificación de variables para fuentes próximas entre sí. . . . . . . . 884.11. Media y varianza de MUSIC para fuentes próximas entre sí. . . . . . 894.12. Ciclos de reloj de la matriz de covarianza y MUSIC con 500 observa-

ciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.13. Ciclos de reloj de la matriz de covarianza y MUSIC con 200 observa-

ciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.14. Ciclos de reloj de la matriz de covarianza y MUSIC con 100 observa-

ciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.15. Resultados de la estimación de MUSIC con 500 observaciones. . . . . 954.16. Resultados de la estimación de MUSIC con 200 observaciones. . . . . 954.17. Resultados de la estimación de MUSIC con 100 observaciones. . . . . 954.18. Requisitos de memoria del algoritmo MUSIC. . . . . . . . . . . . . . . 964.19. Ciclos de reloj de la matriz de covarianza y DML con 500 observacio-

nes y una iteración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

XV

XVI Indice de tablas

4.20. Ciclos de reloj de la matriz de covarianza y DML con 500 observacio-nes y dos iteraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

4.21. Ciclos de reloj de la matriz de covarianza y DML con 500 observacio-nes y tres iteraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.22. Ciclos de reloj de la matriz de covarianza y DML con 200 observacio-nes y una iteración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98



4.25. Ciclos de reloj de la matriz de covarianza y DML con 100 observacio-nes y una iteración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99



4.28. Resultados de la estimación de DML con 500 observaciones para lastres iteraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101



4.31. Requisitos de memoria del algoritmo DML. . . . . . . . . . . . . . . . 1024.32. Ciclos de reloj de MUSIC con 100 observaciones en modo release. . 1034.33. Tiempo de ejecución de MUSIC con 100 observaciones en modo release.1034.34. Resultados de la estimación de MUSIC con 100 observaciones en mo-

do release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1044.35. Requisitos de memoria del algoritmo MUSIC. . . . . . . . . . . . . . . 1044.36. Ciclos de reloj de DML con 100 observaciones y dos iteraciones en

modo release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.37. Tiempo de ejecución de DML con 100 observaciones y dos iteraciones

en modo release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.38. Resultados de la estimación de MUSIC con 100 observaciones en mo-

do release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.39. Requisitos de memoria del algoritmo MUSIC. . . . . . . . . . . . . . . 1054.40. Tiempo de ejecución para la matriz de covarianza usando la plata-

forma C672x. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074.41. Tiempo de ejecución para la matriz de covarianza usando la plata-

forma C674x. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084.42. Tiempo de ejecución para la matriz de covarianza usando la plata-

forma C66xx. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084.43. Optimización de la función Máximo. . . . . . . . . . . . . . . . . . . . 109

Indice de tablas XVII

4.44. Equivalencias de los tipos de variables básicas en MATLAB, lenguajeC y Real-Time Workshop. . . . . . . . . . . . . . . . . . . . . . . . . . 118

4.45. Niveles de simulación dispuestas en Texas Instruments . . . . . . . . 127

3.1. Resultados de las estimaciones a fp = 850MHz. . . . . . . . . . . . . . 1583.2. Prueba de resolución a fp = 850MHz. . . . . . . . . . . . . . . . . . . . 158

Acrónimos

ADC Analogic Digital Converter

ASIC Application Specific Integrated Circuit

AWGN Additive White Gaussian Noise

BER Bit Error Rate

BF BeamForming

CCS Code Composer Studio

CDMA Code Division Multiple Access

C-MEX C-Matlab Executable

CRB Cramer-Rao Bound

DBF Digital BeamForming

DML Deterministic Maximum Likelihood

DoA Direction of Arrival

DSP Digital Signal Processor

EVD Eigen Value Descomposition

FDMA Frecuency Division Multiple Access

FPGA Field Programmable Gate Array

GFLOPS Giga FLoating Point Per Second

IDE Integrated Development Environment

ML Maximun Likelihood

MIT Massachusetts Institute of Technology

MUSIC MUltiple SIgnal Classification

nULA non Uniform Linear Array

PDF Probability Density Function

RTOS Real-Time Operating System

XIX

XX Acrónimos

SDMA Space Division Multiple Access

SNR Signal to Noise Ratio

SVD Singular Value Descomposition

TDMA Time Division Multiple Access

TI Texas Instruments

UC Universidad de Carabobo

ULA Uniform Linear Array

Lista de Símbolos

al(θ) Respuesta del l− ésimo elemento de antena

a(θ) Vector de direccionamiento o respuesta del arreglo de antenas

aULA(θ) Vector de direccionamiento de un arreglo ULA

A(θ), A Matriz de direccionamiento

A† Pseudoinversa de Moore-Penrose de A

B Inducción magnética

c Velocidad de la luz

d Distancia entre dos elementos de antena consecutivos

E Campo eléctrico

E(r, t) Campo eléctrico en dirección de r

I Matriz identidad

k Vector de onda

k, |k| Número de onda

l l− ésimo elemento de antena

L Número de elementos de antena

N Número de observaciones

n(t) Vector de ruido AWGN

N(t) Matriz de ruido AWGN

P Matriz de covarianza de las fuentes

PMUSIC Espectro MUSIC

r Vector de posición desde la fuente al punto r

rl Vector de posición desde el origen al l− ésimo elemento de antena

R Matriz de covarianza�R Matriz de covarianza estimada para N observaciones

XXI

XXII Lista de Símbolos

s(t) Señal transmitida

si(t) i− ésima señal en banda base

�s(t) Estimado de la señal transmitida

S(t) Vector de señales

t Tiempo

ul Autovectores de señal y ruido

U Matriz de unitaria

US Subespacio de señal

Un Subespacio de ruido

xl Coordenada en x del l− ésimo elemento de antena

xl(t) Señal de salida en banda base del l− ésimo elemento de antena

x(t) Vector de salida del arreglo

yl Coordenada en y del l− ésimo elemento de antena

ε0 Constante dieléctrica

µ0 Constante magnética

ω Frecuencia angular

λ Longitud de onda

λl Autovalores de señal y ruido

θ Dirección de llegada de la fuente

θi Dirección de llegada de la i− ésima señal�θ Dirección de llegada estimada�θDML Dirección estimada usando DML

σ2 Varianza del ruido

�σ2 Varianza de ruido estimada

δts Delta de Dirac

Λ Matriz diagonal con los autovalores λ1, . . . , λL

ΛS Matriz diagonal con los autovalores del subespacio de señal

Λn Matriz diagonal con los autovalores del subespacio de ruido

ΠS Matriz de proyección del subespacio de señal

Πn,Π⊥S Matriz de proyección del subespacio de ruido

Π⊥A Proyector ortogonal sobre el espacio nulo de AH

Lista de Símbolos XXIII

E{·} Esperanza estadística

∇ · (·) Operador de divergencia

∇× (·) Operador rotacional

∇2(·) Operador laplaciano

(·)T Transpuesta

(·)H Hermitiano o complejo conjugado transpuesto

(·)∗ Complejo conjugado�(·) Estimado

(·)† Pseudoinversa de Moore-Penrose

‖ · ‖ Norma Euclidiana

LDML(·) Función de verosimilitud determinística

Tr{·} Traza de una matriz cuadrada

arg{·} Argumento de un número complejo




por

DAVID A. RANGEL B. y JOSÉ D. MADURO H.

Presentado en el Departamento de Electromagnetismo y Radiación

de la Escuela de Ingeniería en Telecomunicaciones

el 4 de Marzo del 2015 para optar al Título de

Ingeniero de Telecomunicaciones e Ingeniero Electricista

respectivamente

RESUMEN

En los últimos años, el constante crecimiento del número de usuarios en los

sistemas de comunicaciones móviles ha creado la necesidad de aumentar su capa-

cidad. Además, los sistemas actuales radian potencia sobre la zona de cobertura

de forma omnidireccional o sectorizada, emitiendo de esta manera, señal a usua-

rios no deseados ocasionando la aparición de interferencias y, también, la recepción

de señales de otros usuarios y de las componentes multitrayecto. En este trabajo,

se evalúa la respuesta computacional de distintos Procesadores Digitales de Señal

(DSP’s) cuando trabajan con algoritmos de Dirección de Arribo (DoA) usados en

XXV

XXVI Resumen

Antenas Inteligentes. De esta manera, se pretende conocer el tiempo de ejecución y

requisitos de memoria de cada algoritmo, así como la precisión en las estimaciones.

Los DoA exigen una gran carga computacional mientras que deben procesarse en

tiempo real, por lo que suponen una seria limitación, de allí la importancia de reali-

zar códigos optimizados. Inicialmente, se diseña el algoritmo DoA haciendo uso de

MATLAB quien dispone de herramientas que permiten la conversión de una parte

del lenguaje MATLAB, llamado Embedded MATLAB, a código C embebido que

sirve como puente para la generación de código objeto ejecutable por el DSP. Es-

te trabajo, además, sirve como una guía referencial para desarrollar cualquier tipo

de algoritmo para sistemas embebidos desde su conceptualización, hasta su simu-

lación en Code Composer Studio, un Entorno de Desarrollo Integrado (IDE) para

DSP’s de Texas Instruments (TI). Finalmente, se adopta un procedimiento iterativo

mediante el modelo Harmony Embedded, un método que consiste en desarrollar

un software funcional y, a partir de él, depurarlo y mejorarlo gradualmente me-

diante cambios incrementales, hasta satisfacer los requisitos deseados. Se avaluaron

distintos procesadores digitales de señal de la familia C6000 de Texas Instruments.

Se consiguió obtener el tiempo de ejecución de los algoritmos MUSIC y DML, así

como los requisitos de memoria y la precisión en las estimaciones para cada proce-

sador. Se determinó que MUSIC ofrecía una menor carga computacional que DML,

pudiendo establecer que sí es posible implementar este algoritmo en las platafor-

mas C672x, C674x y C66xx.

Palabras Claves: Antenas Inteligentes, Dirección de Arribo, Procesadores Digitales

de Señal

Tutor: RAFAEL ALBORNOZ

Profesor del Departamento de Electrónica y Comunicaciones.

Escuela de Eléctrica. Facultad de Ingeniería

Capítulo I

Introducción

1.1. MOTIVACIÓN.

Desde sus inicios, los sistemas de comunicaciones móviles han empleado ante-

nas que proporcionan un diagrama de radiación fijo estableciendo, de este modo,

una cobertura determinada. Debido a este diseño, existen sectores pertenecientes al

área de cobertura que en ciertos instantes de tiempo no son aprovechados por los

usuarios por el hecho de no encontrarse en ellos y, además, no se puede discernir

aquellos sectores donde se encuentran fuentes que generan interferencia al sistema.

Aun cuando esta tecnología pudo satisfacer las necesidades de capacidad del

sistema en relación al flujo de datos, no obstante, el constante crecimiento de las

comunicaciones móviles en los últimos años ha traído como consecuencia un ago-

tamiento de esta capacidad [4].

Dicho aumento ha creado un colapso en el sistema, generando así un desmejo-

ramiento en la Relación Señal a Ruido (SNR-Signal to Noise Ratio) y en la Tasa de

Error Binario (BER-Bit Error Rate). Por lo tanto, han surgido nuevas tecnologías con

el propósito de aumentar la capacidad y confiabilidad del sistema en conjunto con

una mejora en la calidad de la transmisión de la información.

1

2 Capítulo I. Introducción

En este sentido, emerge la tecnología de Antenas Inteligentes que combina un

arreglo de antenas (arrays) con un Procesador Digital de Señal (DSP-Digital Signal

Processor) que optimiza los diagramas de transmisión y recepción dinámicamente

en respuesta a una señal de interés en el entorno [5] [6].

Una Antena Inteligente procesa, en tiempo real, las señales recibidas por los

sensores (arreglo de antenas), en dos etapas: El algoritmo de Dirección de Arribo

(DoA-Direction of Arrival) y el algoritmo de la síntesis del diagrama de radiación

conocido como Conformación de Haz (BF-Beamforming) [1].

En 2005, Amévir Castillo y Elimes Rodríguez realizaron la simulación y estudio

comparativo de los algoritmos de Dirección de Arribo (DoA). Esta tesis de grado,

fue llevada a cabo en la Universidad de Carabobo (UC). En esta investigación se

compara funcional y económicamente mediante simulaciones de prueba bajo dis-

tintas condiciones, siete algoritmos DoA, entre los que se encuentra el de Clasifi-

cación de Señales Múltiples (MUSIC-MUltiple SIgnal Classification) y el de Máxima

Verosimilitud (ML-Maximum Likelihood). Para la simulación, se codifican los algo-

ritmos en el lenguaje propio de MATLAB [7].

En 2007, en la Escuela Superior de Ingeniería Mecánica y Eléctrica del Instituto

Politécnico Nacional de México, José Guadalupe Arceo Olague realizó un estudio

donde desarrolló algoritmos para la síntesis del diagrama de radiación en comu-

nicaciones móviles celulares basadas en Antenas Inteligentes. Allí, se plantea el

problema de estimación de DoA, al usar un Arreglo Linealmente Uniforme (ULA-

Uniform Linear Array) de antenas y un Arreglo Lineal no Uniforme (nULA-non Uni-

form Linear Array) de antenas. Se utilizan los algoritmos MUSIC y ML para abordar

el problema de estimación de llegada. Se presenta el desarrollo matemático de am-

bos y se realiza una simulación para comparar su rendimiento en campo lejano y

campo cercano en función de la relación señal a ruido, cantidad de observaciones,

número de sensores y separación espacial entre las fuentes [1].

En 2010-2011, Arantxa Miquel Estrugo de la Escuela Superior de Ingeniería de

la Universidad de Sevilla. Realiza un estudio de las Aportaciones metodológicas al

procesado de bioseñales en sistemas embebidos. Allí, propone un procedimiento

Capítulo I. Introducción 3

general que sirve de guía para la implementación de aplicaciones en sistemas em-

bebidos de DSP, para procesar señales (en cuyo caso se usaron señales biomédicas)

en tiempo real. En esta metodología se explica detalladamente las herramientas

(Embedded MATLAB y Real-Time Workshop) que permiten llevar código fuente

MATLAB a un código fuente C eficiente para sistema embebidos, para luego traba-

jar con CCS [8].

Este trabajo, se enfocará en la etapa de DoA, usando distintos algoritmos que

permiten estimar la posición angular de las señales de los usuarios. De allí la impor-

tancia de realizar la simulación y evaluación de los mismos sobre distintas platafor-

mas de DSP’s, que trabajan en tiempo real, para proveer información respecto a la

respuesta computacional de distintos procesadores para su futura implementación

en sistemas de Antenas Inteligentes.

Por último, esta tarea se llevará a cabo utilizando el Entorno de Desarrollo Inte-

grado (IDE-Integrated Development Environment) para procesadores embebidos que

proporciona el software MATLAB, herramienta que permite la traducción de códi-

gos de MATLAB a lenguaje C. Luego, se realizará la depuración y validación de los

códigos traducidos mediante el IDE Code::Blocks para lenguaje C, para su posterior

evaluación en Code Composer Studio (CCS) un IDE para procesadores digitales de

señal, microcontroladores y procesadores de aplicación de Texas Instruments (TI).

La importancia de las Antenas Inteligentes radica en los beneficios que ofrecen a

los sistemas de comunicaciones móviles, como el incremento tanto de la capacidad

como de la confiabilidad, reducción de potencia de transmisión, reducción de pro-

pagación multitrayecto, reducción de nivel de interferencia, incremento del nivel

de seguridad, así como un aumento de cobertura [9] [10]. La técnica de haz adap-

tativo representa el máximo nivel de inteligencia que se podría dar a un sistema

de antenas. Este procedimiento requiere el uso de algoritmos DoA y, su principal

ventaja, es la conformación de un diagrama de radiación dinámico que dirige el

haz principal hacia la posición del usuario deseado, los haces o lóbulos secunda-

rios hacia las direcciones de las componentes de multitrayecto de la señal deseada

y mínimos o nulos de radiación en dirección de las fuentes interferentes [6] [11].


En los últimos años, estos sistemas han venido tomando auge a nivel mundial,

y han captado especial interés por parte de los investigadores siendo, de igual ma-

nera, parte de la línea de investigación en Telecomunicaciones del Departamento

de Electromagnetismo y Radiación, de la Escuela de Ingeniería de Telecomunica-

ciones de la Universidad de Carabobo (UC). Por tanto, en este trabajo se realiza la

evaluación del rendimiento, requisitos de memoria y precisión que ofrecen distin-

tos Procesadores Digitales de Señal (DSP’s), cuando trabajan con algoritmos DoA

usados en sistemas de Antenas Inteligentes para, de esta manera, conocer qué tan

eficientes pueden ser cada uno de ellos usando este tipo de algoritmos y qué tan

factible puede ser su implementación en estos sistemas.

Por último, esta investigación aporta un procedimiento general de los pasos que

se deben seguir, desde la conceptualización de cualquier algoritmo que se desee

ejecutar en tiempo real, hasta que son introducidos en Code Composer Studio si-

mulando plataformas de DSP’s.

1.2. OBJETIVOS.

1.2.1. Objetivo General.

Evaluar mediante simulaciones la respuesta computacional de distintos Proce-

sadores Digitales de Señal (DSP’s) cuando trabajan con algoritmos de Dirección de

Arribo (DoA) usados en Antenas Inteligentes.

1.2.2. Objetivos Específicos.

Estudiar el problema de estimación de DoA, así como los métodos MUSIC

(Multiple SIgnal Classification) y ML (Maximum Likelihood) empleados para

este propósito.

Simular los algoritmos DoA usando las herramientas de MATLAB que per-

miten la compatibilización con las plataformas de DSP’s.

Capítulo I. Introducción 5

Evaluar la respuesta computacional de distintos DSP’s cuando trabajan con

los algoritmos DoA seleccionados.

Crear un procedimiento general que se debe seguir, desde la conceptualiza-

ción de cualquier algoritmo que permite la ejecución en tiempo real, hasta la

implementación en un DSP.

1.3. ALCANCES.

La simulación y evaluación en distintos Procesadores Digitales de Señal, de al-

goritmos de Dirección de Arribo usados en Antenas Inteligentes, es una investi-

gación que tomará como referencia los algoritmos MUSIC y ML codificados y si-

mulados en [7] para que, posteriormente, sean transformados a códigos fuente en

lenguaje C, que pueden ser compilados en el entorno de desarrollo integrado para

DSP’s como Code Composer Studio (CCS) perteneciente a Texas Instruments.

La transformación a código fuente C, se hará posible al someter los algoritmos

DoA a las modificaciones que realizan las herramientas Embedded MATLAB y

Real-Time Workshop que proporciona el software MATLAB.

De esta manera, se buscará conocer la respuesta computacional de distintos

DSP’s cuando trabajan con algoritmos DoA. Tal respuesta se medirá en función

de tres parámetros principales, a saber:

Rendimiento. Tiempo que tarda un DSP en ejecutar un algoritmo DoA. El

rendimiento es el recíproco del tiempo de ejecución, por tanto, cuando se ha-

ble de un «mejor rendimiento» se referirá a un incremento de rendimiento y

disminución del tiempo de ejecución [12].

Consumo de memoria. Ocupacón en memoria necesaria para ejecutar cada

algoritmo.

Precisión. Dado por el tamaño que pueden tener los datos.


Finalmente, se establecerán tablas de resultados que reflejen la respuesta que

ofrecen distintas tarjetas DSP’s, la cual será una fuente de consulta que permita

realizar una elección certera de estos dispositivos para aplicaciones de Antenas In-

teligentes.

Capítulo II

Marco conceptual

2.1. INTRODUCCIÓN A LOS SISTEMAS DE ANTENAS

INTELIGENTES.

2.1.1. Limitaciones de las técnicas de Acceso Múltiples convencionales.

Los sistemas de comunicaciones móviles, cada vez se ven más limitados para

satisfacer la creciente demanda de mayor velocidad y ancho de banda por parte de

los usuarios asignados a la red. Dicha demanda, toma lugar por los avances que

se ha tenido en la telefonía celular generando aplicaciones que, además de prestar

un servicio de voz, también permitan al usuario disponer de servicios de datos

(multimedia, imágenes) [1]. Para lograr que múltiples usuarios accedan a la red, se

utilizan tres técnicas principales de acceso, las cuales se mencionan a continuación:

Acceso Múltiple por División de Frecuencia (FDMA).

Acceso Múltiple por División de Tiempo (TDMA).

Acceso Múltiple por División de Código (CDMA).

7

8 Capítulo II. Marco conceptual

Estos métodos resultaron óptimos para la trasmisión de señales de voz y datos

al principio de su implementación, pero en la actualidad las redes de telefonía mó-

vil se encuentran sobrecargadas ya que el número de usuarios que deben atender

supera su capacidad nominal. Este desbalance de la oferta y la demanda genera

una disminución en la calidad del servicio, ya que degrada los indicadores de ren-

dimiento como son la Relación Señal a Ruido (SNR), la Tasa de Error Binario (BER),

la relación de energía de bit con respecto a la densidad de potencia de ruido Eb/No,

entre otros [11] [13].

Para abordar este problema, se presentan distintas soluciones. La primera con-

siste, principalmente, en aumentar el número de radio bases para cubrir los sectores

donde existen nulos de cobertura, y donde se concentre un gran número de usua-

rios. Aunque esta solución es realizable y fácil de ejecutar, lleva consigo grandes

inversiones para su implementación y un gasto permanente para su mantenimien-

to, lo que a la larga genera un incremento de los costos por la prestación del servicio

telefónico [7].

La segunda solución se basa en identificar las deficiencias de los subsistemas

(antenas, transmisores, receptores, etc.) pertenecientes a una estación base de co-

municaciones móviles, esto con el objetivo de incrementar el rendimiento de la pla-

taforma ya existente tanto como sea posible, realizando cambios específicos que

impliquen pequeñas inversiones. Un ejemplo de esta solución, es la técnica de ac-

ceso SDMA, la cual explota el dominio espacial cuando hace que la antena de la

radio base pueda variar su diagrama de radiación de forma dinámica y, ademas,

esta técnica permite usar los métodos de acceso multiples ya existentes [5].

2.1.2. Acceso Multiple por División de Espacio (SDMA).

El método SDMA es una de las últimas fronteras que están siendo implemen-

tadas en los nuevos sistemas de comunicaciones móviles. Ésta permite realizar una

transmisión y recepción espacialmente selectiva. SDMA, se basa en la tecnología

de Antenas Inteligentes empleadas en las estaciones bases de comunicaciones mó-

viles [5].

Capítulo II. Marco conceptual 9

En este sentido, como cada usuario móvil ocupa una localización espacial úni-

ca, esta nueva técnica de acceso permite que múltiples usuarios que se encuentren

angularmente espaciados, puedan acceder a la red, al mismo tiempo y con la mis-

ma frecuencia (en caso de FDMA) o con el mismo código (en caso de CDMA) sin

causar interferencia unos con otros, de modo que se trata de un híbrido de las técni-

cas de acceso múltiple existentes y la nueva técnica SDMA. Esto es posible, puesto

que al habilitar el diagrama de radiación para transmisión/recepción en un sec-

tor específico, existe la posibilidad de incluir en ese instante de tiempo a múltiples

usuarios que estén ubicados en dicho sector, a través de los métodos TDMA, FDMA

o CDMA [14].

La Figura 2.1 muestra un ejemplo ilustrativo, donde P usuarios acceden a la red

en condiciones más favorables de desvanecimiento por multitrayectoria e interfe-

rencia cocanal, las cuales limitan de forma considerable los sistemas de comunica-

ciones móviles [11]. Así mismo, se observa gráficamente como SDMA está consti-

tuida por la combinación de las técnicas de acceso ya existente, CDMA para el caso

de la Figura 2.1a y FDMA para la Figura 2.1b.

Adicionalmente, todo el beneficio de SDMA se traduce en un aumento de la

capacidad del sistema. La capacidad de un sistema de comunicaciones móviles se

puede definir como la tasa binaria que puede ofrecerse en el ancho de banda dis-

ponible y en un área geográfica determinada, es decir bits/s/Hz/m2 [9].

La realización de esta técnica de filtrado espacial se realiza mediante Antenas

Inteligentes, que son sistemas capaces de modificar el tiempo, la frecuencia y la

respuesta espacial [5].

2.1.3. Tecnología de Antenas Inteligentes.

Los sistemas de comunicaciones móviles, han empleado antenas que radian so-

bre la zona de cobertura de forma omnidireccional1 o sectorizada2. Esto puede ser

1La radiación de una antena omnidireccional es igual en todas direcciones.2La radiación de una antena sectorizada se divide por sector para cubrir 360 grados.


Tx - Rx

CDMA

(a) CDMA

Tx - Rx

FDMA

(b) FDMA

Figura 2.1: Posible escenario de SDMA.

considerado como una pérdida de potencia, pues la mayor parte de ella será radiada

en otras direcciones y no hacia el usuario deseado [5].


El concepto de Antenas Inteligentes, radica en el uso de diagramas de radia-

ción que no son fijos sino que, más bien, dirigen un haz hacia un usuario especí-

fico. Por lo tanto, la diferencia entre una antena adaptativa/inteligente y una

tradicional/fija, es la propiedad de tener una adaptación y un patrón fijo, res-

pectivamente [9].

Para los nuevos servicios de 3G, se plantea como solución el empleo de la no-

vedosa tecnología de Antenas Inteligentes ya que, aprovechando las características

particulares de estos sistemas, se consigue aumentar la capacidad de conexión a

múltiples usuarios simultáneamente con las siguientes ventajas adicionales [6]:

Incremento de la Capacidad y Confiabilidad.

Reducción de Potencia de Transmisión.

Reducción de Propagación Multitrayecto.

Reducción de Nivel de Interferencia.

Incremento del Nivel de Seguridad.

En la Figura 2.2 se muestra la diferencia entre el concepto de antena fija e inteli-

gente, donde se observa una antena tradicional cuyo patrón de radiación se divide

en tres sectores para cubrir 120◦ espaciales cada uno y el otro es un patrón de ra-

diación de una Antena Inteligente que se adapta a los usuarios deseados.

2.1.3.1. Técnicas de implementación.

La característica fundamental de un sistema de Antena Inteligente, es la capaci-

dad de seleccionar espacialmente a los distintos usuarios. Existen varias formas de

implementación que se describen, a continuación, por orden de complejidad. En la

Figura 2.3 se detalla cada una de estas técnicas.


Figura 2.2: Diferencia entre un patrón de radiación de una estación base tradicio-nal y una de Antena Inteligente.

Haz Conmutado. Está formado por múltiples haces o lóbulos principales que se

conmutan alternativamente en posiciones fijas, los cuales tienen una alta sensibili-

dad en direcciones específicas. Además, se logra tener una alta ganancia y lóbulos

laterales bajos, o ancho de haz controlado [15]. No obstante, esta técnica no ga-

rantiza que el usuario se encuentra en un máximo de radiación, ni que las señales

interferentes sean notablemente reducidas.

Haz de Seguimiento. Se utiliza un arreglo de antenas con una red de excitación,

que permite controlar electrónicamente las fases de las corrientes de excitación que

llegan a los elementos del arreglo, de manera que puede modificarse a voluntad la

dirección en la que apunta el haz y, de este modo, establecer comunicación con el

usuario deseado [6]. A su vez, es necesario utilizar algún algoritmo de detección de

la Dirección de Arribo (DoA), de modo que pueda reorientarse dinámicamente el


(a) Haz Conmutado

Señal

Interferencia

(b) Haz de Seguimiento (c) Haz Adaptativo

Figura 2.3: Técnicas de implementación para sistemas de Antena Inteligente.

haz para apuntar al usuario deseado. Con esta técnica sí se garantiza que el usua-

rio esté en el lóbulo principal en todo momento y con máxima ganancia (teniendo

en cuenta las limitaciones de los algoritmos empleados). Sin embargo, tampoco se

puede evitar que las interferencias entren por algún lóbulo secundario del diagra-

ma de radiación [11].

Haz Adaptativo. Esta técnica representa el máximo nivel de inteligencia que pue-

de tener una antena. Las antenas adaptativas son controlados de forma dinámica

para dirigir el lóbulo principal hacia los usuarios deseados, esto se hace a través

ajustes de los elemento de excitación, en lugar de simplemente mediante la realiza-

ción de una operación de conmutación [15], además de dirigir lóbulos secundarios

en la componente multitrayecto y mínimos o nulos en las direcciones interferentes.

Esta técnica también usa algoritmos DoA y, adicionalmente, es posible detectar la

dirección de las fuentes interferentes. Así, el sistema adaptativo se aprovecha de


su capacidad para localizar y rastrear varios tipos de señales lo que minimiza la

interferencia y maximiza dinámicamente la recepción de la señal deseada [5].

2.1.3.2. Sistema de Antena Inteligente de haz adaptativo.

Un sistema de Antena Inteligente de haz adaptativo combina múltiples elemen-

tos de antenas con un procesador digital de señal. En la Figura 2.4 se representa el

esquema de este tipo de sistemas, donde las P señales arriban al arreglo. En telefo-

nía móvil, se hace uso de Duplexers que separan la frecuencia de bajada (Downlink)

y de subida (Uplink) para que, con un mismo arreglo de antena, se pueda operar

tanto en transmisión (Tx) como en recepción (Rx).

Para que el DSP pueda identificar las posiciones angulares (θ) de los usuarios,

es necesario tomar muestras de la información percibida por cada sensor, mediante

acopladores direccionales. Luego, el DSP procesa algoritmos de Dirección de Arri-

bo (DoA) arrojando como resultado la información angular de los P usuarios que

arriban al arreglo de antenas.

Por último, una etapa de Conformación de Haz (BF) es requerida para la síntesis

del diagrama de radiación que obedecen a características particulares interpuestas

en la etapa del DoA. De igual forma que en el caso de DoA, se genera una serie

de vectores que contienen la información de los pesos (ω1,ω2,ωl, . . . ,ωL). Cada

peso ωi es un número complejo escrito en su forma polar, el cual indica las modi-

ficaciones en amplitud y fase que sufre la corriente que alimenta a cada sensor del

arreglo. En la Figura 2.4 se muestra este procedimiento, para un sistema de Antenas

Inteligentes en un sistema de comunicación full Duplex, donde se resalta la etapa en

la que está enfocada este trabajo.


DUPLEXER DUPLEXER DUPLEXER

COUPLER

COUPLER

COUPLER

DSPDoA

+

+Tx

Uplink

Downlink

BF

Rx

Figura 2.4: Sistema de Antenas Inteligentes en un sistema de comunicación fullDuplex.

2.2. ESTIMACIÓN DE LA DIRECCIÓN DE ARRIBO (DOA).

2.2.1. Modelo general del sistema.

Se plantea el modelo general del problema de estimación de DoA, comenzando

desde el problema físico de propagación de las ondas electromagéticas, y se hace

uso de un arreglo de antenas como el conjunto de sensores a utilizar. Además, se

generaliza el problema para un arreglo lineal uniforme de antenas. Por otro lado, se

analizan las consideraciones generales del modelo, las cuales son parte importante


para cada algoritmo. Finalmente, se estudian los dos algoritmos que serán usados

en este trabajo, MUSIC y ML3

2.2.1.1. Sistema de coordenadas a usar.

Figura 2.5: Sistema de coordenadas a usar.

Se usará un sistema de coordenadas esférico cuyos ángulos θ y φ son medidos

según se muestra en la Figura 2.5.

2.2.1.2. Propagación de ondas.

El problema físico de propagación de onda, parte de las ecuaciones de Maxwell

en el espacio libre, donde hay ausencia de carga o corriente [16] [17]. Se soluciona el

problema de propagación mediante la ecuación de onda para un medio homogé-

neo [17]. Así, se tiene lo siguiente:3Existen muchos métodos de Máxima Verosimilitud, en este estudio se ha seleccionado el de Má-

xima Verosimilitud Determinística (DML-Deterministic Maximum Likelihood).


∇ · E = 0 (2.1)

∇ · B = 0 (2.2)

∇× E = −∂B

∂t(2.3)

∇× B = ε0µ0∂E

∂t(2.4)

donde (·) y (×) representan la divergencia y rotacional, respectivamente. Adicio-

nalmente, B es la inducción magnética y E es el campo eléctrico. Mientra que ε0 y µ0

son las constantes dieléctrica y magnética, respectivamente. Usando la ecuación (2.1)

en la siguiente identidad vectorial, resulta:

∇× (∇× E) = ∇(∇ · E) −∇2E = −∇2E (2.5)

De las ecuaciones (2.3) y (2.4), se tiene:

∇× (∇× E) = −∂

∂t(∇× B) = −ε0µ0

∂2E

∂t2(2.6)

Con la expresión anterior y combinada con la identidad vectorial de la ecuación

(2.5), se tiene la forma homogénea de la ecuación de onda [17]:

∇2E−1

c2∂2

∂t2E = 0 (2.7)

En el espacio libre c es la velocidad de propagación de una onda electromagné-

tica, donde c = 1/√ε0µ0 = 3 × 108m/s. Al resolver la ecuación de onda, el campo

eléctrico E(r, t) en dirección de r es [17]:

E(r, t) ∼= s(t)ej(ωt−rTk) (2.8)


donde s(t) es la señal transmitida y varía lentamente en comparación a la por-

tadora ejωt de frecuencia angular ω. El término e−jrTk representa la variación es-

pacial del campo eléctrico, el superíndice T indica la transpuesta, k es el vector de

onda y su magnitud |k| = k = ω/c = 2π/λ es el número de onda y λ es la longitud

de onda.

Una fuente puntual isotrópica genera ondas electromagnéticas que se propagan

idénticamente en todas direcciones, de manera que, en el caso de tres dimensiones

esta fuente forma una esfera. Sin embargo, la condición de zona lejana (en la ecua-

ción (2.8) está implícita la condición de zona lejana) implica que |r| es mucho mayor

que la longitud de onda y, en consecuencia, el frente de onda en r es plano. Dicha

condición es usada, generalmente, en el problema de estimación de llegada, donde

la distancia |r| es mucho mayor que la dimensión de la agrupación de antena. En la

Figura 2.6 se ilustra un frente de onda esférico observado en el plano.

Frente de Onda Esférico

Frente de Onda Plano

Onda Electromagnética

Fuente Puntual

Figura 2.6: Frente de onda en el plano de una fuente puntual en función de ladistancia de propagación |r| [1].

2.2.1.3. Modelo paramétrico de los datos.

La mayoría de los enfoques modernos al procesamiento de señales, se basan en

ciertas suposiciones hechas a los datos observados [17]. A continuación, se presenta

el modelo adoptado a lo largo de este trabajo.


Para simplificar la notación de los siguientes análisis, se asume que el vector de

onda está contenido en el plano x− y, en cuyo caso φ = 90◦. En la Figura 2.7 se

muestra un arreglo genérico, donde la dirección de llegada de la fuente (usuario)

se simboliza con θ [3], y se mide respecto al eje x, tal como se observa.

Fuente

Sensor

Figura 2.7: Geometría de un arreglo genérico.

Para el modelo asumido, el vector de onda queda descrito como:

k = k(cos θ sin θ

)T(2.9)

y para el sensor, se tiene:

rl =(xl yl

)T(2.10)

donde el superíndice T indica la transpuesta. Usando las ecuaciones (2.8) y (2.9),

el campo eléctrico medido en el sensor l para un arreglo genérico es:

E(rl, t) = s(t)ej[ωt−k(xl cosθ+yl sinθ)] (2.11)

Para que todos los elementos del arreglo se comporten exactamente igual, se

necesita que cada uno tenga una ganancia unidad en todo el ancho de banda de

la señal y, en consecuencia, la salida que resulta será proporcional al campo eléc-

trico recibido. Con esta condición, y descartando por conveniencia el término de


la portadora pues en la práctica, generalmente, la señal es reducida a banda base4

antes del muestreo [17], entonces la señal de salida xl(t) del l− ésimo elemento se

modela por:

xl(t) = e−jk(xl cosθ+yl sinθ)s(t) = al(θ)s(t) (2.12)

Para un arreglo de antenas de L elementos con geometría arbitraria, el vector de

salida del arreglo se obtiene como:

x(t) = a(θ)s(t) (2.13)

donde a(θ) es llamado vector de direccionamiento, acción vector o vector de

propagación del arreglo, el cual representa la respuesta del arreglo dada una direc-

ción de llegada θ [17].

2.2.1.4. Agrupación de antena.

Para el problema de estimación de DoA, el aspecto espacial juega un papel im-

portante [1]. La radiación de la agrupación de antenas, depende del tipo de elemen-

tos, la posición relativa y la alimentación con amplitudes y fases [9] [18].

En el desarrollo de este trabajo se considera un sistema de comunicaciones mó-

viles, el cual hace uso de una agrupación lineal de antenas. En la Figura 2.8 se ilustra

un Arreglo Lineal Uniforme (ULA-Uniform Linear Array) de L elementos.

De la ecuación (2.10), para un ULA se tiene que:

rl =(xl 0

)T=(ld 0

)T(2.14)

donde l ={0, 1, 2, . . . ,L − 1

}, d es la distancia entre dos elementos de antenas

consecutivos y rl representa el vector de posición desde el origen de coordenadas

4En este caso es banda base de radiofrecuencia o, lo que es igual, una señal trasladada a frecuenciaintermedia que sigue conservando las mismas propiedades de la onda plana.


Fuente

Sensor

Onda

Plana

Figura 2.8: Arreglo Lineal Uniforme (ULA) de un conjunto de antenas.

al l − ésimo elemento (sensor) del arreglo. Adicionalmente, el elemento «0» de la

agrupación de antena está en el origen y sirve de referencia para el resto de los

elementos.

Además, de la ecuación (2.12) se obtiene:

xl(t) = e−jkxl cosθs(t) = e−jkld cosθs(t) = al(θ)s(t) (2.15)

Así, para un ULA el vector de direccionamiento toma la siguiente forma:

aULA(θ) =(1 e−jkd cosθ e−jk2d cosθ . . . e−jk(L−1)d cosθ

)T(2.16)

Se asume que θ es un escalar real [17], y para la referencia tomada en la Figu-

ra 2.8, θ ∈[0◦, 180◦

]. Esta es una restricción de los ULA’s, pues las ondas planas

proveniente de dos fuentes simétricas con respecto al eje del arreglo arriban al mis-

mo en iguales instantes de tiempo, por lo que no se puede distinguir una de la

otra [19]. Esta ambiguedad de los ULA’s se elimina mediante el uso de sensores

que sólo procesan señales cuyas DoA’s estén entre[0◦, 180◦

].


Si P señales inciden en el ULA en distintas direcciones θ1, . . . , θP entonces, el

vector de salida complejo se puede escribir como:

x(t) = a(θ1)s1(t) + . . .+ a(θP)sP(t) =

P∑i=1

a(θi)si(t) (2.17)

donde si(t), con i = 1, . . . ,P representa la i − ésima señal en banda base. La

ecuación (2.17) se puede escribir de forma compacta si se define una matriz de

direccionamiento y un vector de señales de la siguiente forma:

A(θ) =(a(θ1),a(θ2), . . . ,a(θP)

)L×P

(2.18)

S(t) =(s1(t), s2(t), . . . , sP(t)

)TP×1

(2.19)

De esta manera, y tomando en cuenta la presencia de Ruido Blanco Gaussiano

Aditivo (AWGN-Additive White Gaussian Noise), se obtiene un modelo lineal del sis-

tema que es comúnmente usado en el procesamiento de señales con agrupación de

antena:

x(t) = A(θ)S(t) + n(t) (L× 1) (2.20)

Todos los métodos de estimación de DoA requieren que P < L [17]. Por lo tanto,

esto se asume a lo largo de este trabajo.

2.2.1.5. Consideraciones generales del modelo.

Los parámetros de las señales que interesan en este trabajo, son de naturaleza

espacial. Por lo tanto, es necesario obtener la covarianza entre los distintos senso-

res, es decir, la matriz de covarianza espacial, que se define de la siguiente mane-

ra [17] [19]:

R = E{x(t)xH(t)

}= AE

{S(t)SH(t)

}AH + E

{n(t)nH(t)

}(2.21)


Los términos cruzados desaparecen pues se asume que la señal y el ruido no

están correlacionados y la media del ruido es cero. Además, E{·} denota la esperanza

estadística, donde:

E{S(t)SH(t)

}= P (2.22)

es la matriz de covarianza de las fuentes y:

E{n(t)nH(t)

}= σ2I (2.23)

es la matriz de covarianza del ruido. El superíndice H indica el Herminitano,

definido como la transpuesta del complejo conjugado [20], e I es la matriz identi-

dad. Para el caso de la covarianza del ruido, se tiene una varianza σ2 común en

todos los sensores e incorrelados entre sí. Usualmente, este ruido se denomina es-

pacialmente blanco. Por otro lado, se asume que la matriz P de covarianza de las

fuentes es no singular5. De las condiciones anteriores, y si R es positiva se garantiza

la siguiente descomposición espectral [17] [21]:

R = APAH + σ2I = UΛUH (2.24)

donde A = A(θ), U es una matriz unitaria6 [20], y Λ = diag{λ1, λ2, . . . , λL

}es

una matriz diagonal con los valores propios reales, con λ1 > λ2 > . . . λL > 0. Por

otro lado, de la ecuación (2.24) se observa que si z es cualquier vector ortogonal a

A, es decir:

AHz = 0 (2.25)

entonces z es un autovector de R con autovalor correspondiente σ2:

(R− σ2I

)z = 0 (2.26)

5Una matriz cuadrada es no singular si su determinante es distinto de cero y, en consecuencia, esinvertible.

6Una matriz compleja cuadrada tal queUUH = I


Muchos esquemas de estimación de DoA que se encuentran en la literatura,

confían en la autodescomposición de la matriz de covarianza R como la suma de

dos partes, una relacionada a los autovectores que corresponden a los autovalores

iguales a la varianza del ruido, y otra parte relacionada con la señal. Esta descom-

posición, a veces llamada factorización espectral, se usa comúnmente cuando se trata

con estimación basada en subespacio.

Por último, toda la formulación anterior supone la existencia de cantidades

exactas, es decir, tiempo de observación infinito. Sin embargo, en la práctica es ne-

cesario realizar la estimación de DoA a partir de un conjunto finito de datos de x(t),

que se obtiene en t = 1, 2, . . . ,N, y se denota con el símbolo �(·). De esta manera, so-

lo se puede tener una estimación de la matriz de covarianza de observación, de la

siguiente manera [17] [19]:

�R =1

N

N∑t=1

x(t)xH(t) (2.27)

2.2.1.6. Matriz de observaciones.

En esta sección se deduce la matriz de observaciones a partir de un arreglo lineal

de antenas, generalizado en cuanto a la separación de sus elementos. En la Figura

2.9 se observa dicho arreglo:

En la práctica, el procesamiento de señales para la estimación de DoA se hace

para un conjunto finito de datos [1]. Partiendo del vector de salida x(t), se genera

una matriz X(t) que contiene las N observaciones de L elementos de antena, para

t = 1, 2, . . . ,N. De forma similar a la ecuación (2.20), la expresión matricial para un

conjunto de observaciones es:

X(t) = A(θ)S(t) +N(t) (L×N) (2.28)


Fuente

Sensor

Onda

Plana

Figura 2.9: Arreglo lineal de antena generalizado.

Explícitamente, se tiene que:

X(t) =(x(1), x(2), . . . , x(N)

)=

x1(1) x1(2) . . . x1(N)

x2(1) x2(2) . . . x2(N)...

.... . .

...

xL(1) xL(2) . . . xL(N)

L×N

(2.29)

Adicionalmente, se puede expresar de forma explícita la matriz de direcciona-

miento A(θ) de la siguiente manera:

A(θ) =(a(θ1),a(θ2), . . . ,a(θP)

)(2.30)


∴ A(θ) =

1 1 . . . 1

e−jkd1 cosθ1 e−jkd1 cosθ2 . . . e−jkd1 cosθP

e−jkd2 cosθ1 e−jkd2 cosθ2 . . . e−jkd2 cosθP

......

. . ....

e−jkdL−1 cosθ1 e−jkdL−1 cosθ2 . . . e−jkdL−1 cosθP

L×P

y la matriz de observaciones de las fuentes S(t) como:

S(t) =

s1(t)

s2(t)...

sP(t)

=

s1(1) s1(2) . . . s1(N)

s2(1) s2(2) . . . s2(N)...

.... . .

...

sP(1) sP(2) . . . sP(N)

P×N

(2.31)

También, se puede definir la matriz N(t) de Ruido Blanco Gaussiano Aditivo

(AWGN) cuya media es cero y varianza σ2, de la siguiente manera:

N(t) =(n(1),n(2), . . . ,n(N)

)=

n1(1) n1(2) . . . n1(N)

n2(1) n2(2) . . . n2(N)...

.... . .

...

nL(1) nL(2) . . . nL(N)

L×N

(2.32)

En la Tabla 2.1 se muestra un resumen de las diferentes variables e índices que

definen las dimensiones de las matrices utilizadas.


Tabla 2.1: Variables e índices utilizadas para definir las dimensiones de las matri-ces.

Variable Significado

L Número de elementos

P Número de fuentes

d Separación entre elementos de antena

N Número de observaciones

l Índice de elementos de antena

i Índice de fuentes

2.2.2. Algoritmo de Clasificación de Señales Múltiples (MUSIC-MUltiple

SIgnal Classification).

El algoritmo MUSIC fue desarrollado por Schmidt [22], como un estimador para

el problema de DoA [17]. Este método, basado en subespacios, propone las siguien-

tes propiedades de la matriz de covarianza:

El espacio que contiene los eigenvectores (vectores propios o autovectores)

puede ser dividido en dos subespacios, llamado el subespacio de señal y el

subespacio de ruido.

Los vectores de dirección que corresponden a las fuentes son ortogonales al

subespacio de ruido.

En este sentido, el algoritmo MUSIC aprovecha las consideraciones realizadas

sobre las señales y el ruido, las cuales están espacialmente incorreladas [1]. En la Fi-

gura 2.10 se observa el mecanismo de estimación de DoA usado por este algoritmo,

en el que partiendo de la matriz de covarianza estimada a partir de un conjunto de

N observaciones, se extraen las características espaciales de dicha matriz mediante

la descomposición en valores y vectores propios. Luego, y a partir de la descom-

posición de valores propios (EVD-Eigen Value Descomposition) se forman los subes-

pacios de señal y ruido US y Un respectivamente, los cuales son utilizados para


calcular el espectro PMUSIC y a partir de éste se estiman las direcciones de llegada�θ.

DescomposiciónEVD

Figura 2.10: Diagrama de bloque de la estimación de DoA usando MUSIC [1].

Como se señaló anteriormente, la estructura exacta de la matriz de covarianza,

asumiendo ruido espacialmente blanco, implica la descomposición espectral expre-

sada en la ecuación (2.24). La hipótesis del algoritmo MUSIC está basada en que el

vector de direccionamiento a(θ) está determinado por la posición de cada elemen-

to de antena y está en función de la dirección de llegada. Un vector de direcciona-

miento contiene, entonces, la dirección de llegada de una fuente. Si las fuentes son

diferentes, se tendrá un conjunto P de vectores columnas independientes entre sí.

De la ecuación (2.30) se observa que la matriz de direccionamiento A(θ) tie-

ne rango P dentro del espacio L − dimensional. Entonces, la descomposición en

valores y vectores propios de la matriz de covarianza contendrá un espacio P di-

mensional correspondiente a las señales y, además, de las ecuaciones (2.25) y (2.26)

cualquier vector ortogonal aA = A(θ) es un autovector de R con autovalor corres-

pondiente σ2. Hay L − P de estos vectores linealmente independientes que forman

el subespacio de ruido. Así se tiene que la descomposición en valores y vectores

propios de R, partiendo de la ecuación (2.24) es [17]:

R = USΛSUHS +UnΛnU

Hn (2.33)

De la misma forma, para la estimación de la matriz de covarianza se tiene que:

�R = �US �ΛS �UHS + �Un �Λn �U

Hn (2.34)


Los subespacios de señal US y de ruido Un se forma de acuerdo a la relación

que existe entre los valores propios λl y vectores propios ul, donde los P vectores

propios correspondientes a los valores propios mayores forman el subespacio de

señal y el resto de los vectores forman el subespacio de ruido, como se indica a

continuación [1]:

US =(u1,u2, ...,uP

)L×P

(2.35)

Un =(uP+1,uP+2, ...,uL

)L×(L−P)

(2.36)

ΛS = diag(λ1, λ2..., λP

)(2.37)

Λn = diag(λP+1, λP+2, ..., λL

)(2.38)

donde ΛS es una matriz diagonal con los valores propios correspondiente al

subespacio de señal, con λ1 > λ2, ...,> λP > σ2 y Λn es una matriz diagonal de di-

mensiones (L − P) con los valores propios correspondiente al subespacio de ruido.

Como los autovalores del subespacio de ruido son λP+1 = λP+2 = λL = σ2, enton-

ces la matriz diagonal del subespacio de ruido puede escribirse comoΛn = σ2In.

Finalmente, la descomposición espectral puede ser expresada de la siguiente

manera [17]:

R = APAH + σ2I = USΛSUHS + σ2UnU

Hn (2.39)

De la ecuación (2.39), se observa que el subespacio de señales US coincide con

A(θ). De esta manera, se comprueba la hipótesis que se propone en el algoritmo

MUSIC, donde la combinación lineal de los frentes de onda de las señales y del

ruido está contenida en la matriz de covarianza y los subespacios de señal y ruido

se obtienen de la EVD. A partir de dichos subespacios, es posible definir el espectro

MUSIC [1].

2.2.2.1. Espectro MUSIC.

Considerando la ecuación (2.25), el problema de estimación de DoA es resuelto

con MUSIC al tener en cuenta que, cualquier vector propio asociado al subespacio


de ruido Un, es ortogonal al espacio columna de la matriz de direccionamiento

A(θ), en cuyo caso su producto será cero. De esta manera, se tiene que [1] [17]:

AHul = 0 ∀ θ ∈[θ1, θ2, . . . , θP

](2.40)

(a(θ1),a(θ2), . . . ,a(θP)

)⊥(uP+1,uP+2, . . . ,uL

)(2.41)

con ⊥ que denota ortogonalidad. Lo anterior muestra la esencia del algoritmo

MUSIC, donde al encontrar los vectores de direccionamiento que son aproxima-

damente ortogonales al subespacio de ruido, es posible estimar la dirección de

llegada. De esta manera, encontrar la dirección de llegada es posible al proyectar

el vector de direccionamiento por medio de una matriz de proyección dentro del

subespacio del ruido. Entonces, se define la matriz de proyección Π para cada uno

de los subespacios de la siguiente forma [17] [19]:

ΠS = USUHS (2.42)

Πn = Π⊥S = UnUHn = I−USU

HS (2.43)

donde Πn es la proyección complementaria de ΠS, y se denota como Π⊥S . Así

mismo, la ortogonalidad de los subespacios, implica que al proyectar el vector de

direccionamiento dentro del dominio de θ ∈[θmin, θmax

], que contiene las direc-

ciones de llegada, entonces la proyecciónΠSa(θ) será máxima cuando el parámetro

θ coincida con las direcciones de llegada[θ1, θ2, . . . , θP

], o bien queΠna(θ) ≈ 0.

Teniendo en cuenta que la matriz de proyección estimada para el subespacio

del ruido es [17]:�Πn = �Π

⊥n = �Un �U

HS = I− �US �U

HS (2.44)

Entonces, el espectro espacial MUSIC es definido de la siguiente forma [17] [22]:

PMUSIC =1

aH(θ) �Un �UHna(θ)

=1

aH(θ)(I− �US �UHS )a(θ)

(2.45)


En sentido estricto éste no es un espectro sino que, más bien, representa la dis-

tancia entre dos subespacios, presentando picos en las proximidades de los verda-

deros DoA’s [17]. El algoritmo MUSIC ha sido ampliamente estudiado y en una

evaluación detallada basada en miles de simulaciones, el Laboratorio Lincoln del

MIT (Massachusetts Institute of Technology) concluyó que, entre los algoritmos de alta

resolución aceptados, MUSIC es uno de ellos [23]. No obstante, para casos de bajo

SNR o fuentes cercanas el algoritmo pierde resolución. Esta pérdida de resolución

se vuelve más evidente para señales altamente correladas [17]. Para estas condi-

ciones, se requieren de los llamados métodos óptimos o de Máxima Verosimilitud

(ML-Maximum Likelihood), los cuales son estadísticamente eficientes y superiores a

los métodos basados en subespacios.

2.2.3. Método de Máxima Verosimilitud (ML-Maximum Likelihood).

Aun cuando MUSIC es computacionalmente atractivo, no siempre produce su-

ficiente precisión. Una alternativa a esto, es explotar completamente el modelo de

data subyacente, conduciendo a los llamados métodos paramétricos de procesa-

miento de arreglo [17]. Estos métodos ofrecen un mayor rendimiento en términos

de precisión y resolución, por lo que exigen una mayor complejidad y carga compu-

tacional [24], sin embargo, para ULA’s se presentan algoritmos mucho menos exi-

gentes [17].

En este sentido, se necesita una nueva medida de rendimiento, ya que las esti-

maciones de DoA se obtienen sin calcular un espectro. En lugar de ello, se utilizan

dos propiedades estadísticas para las estimaciones de DOA, como una medida de

rendimiento [1] [24].

Consistencia. Un estimador es consistente si converge al valor verdadero

cuando el número de datos tiende a infinito. Matemáticamente se expresa

de la siguiente forma:

l��mN→∞P(|�θ− θ| > ε) = 0 (2.46)


Insesgadez. Un estimador es insesgado, si en promedio los valores estimados

son iguales a los valores reales. Matemáticamente expresado de la siguiente

manera:

E(�θ) = θ (2.47)

Eficiencia estadística. Un estimador insesgado es eficiente desde el punto de

vista estadístico si la covarianza del valor estimado alcanza la cota de Cramer-

Rao (CRB-Cramer Rao Bound).

Uno de los métodos paramétricos más conocidos y utilizados es la técnica de

Máxima Verosimilitud (ML-Maximum Likelihood), la cual es una de las principales

técnicas sistemáticas de procesamiento estadístico de la señal [24] [25]. El método

ML asume un modelo para las señales y también una estructura estadística para la

generación de la información. Aquí, se usará el modelo de la señal introducido en

la sección 2.2.1. Existen varias versiones de ML, en este trabajo se usará la Máxima

Verosimilitud Determinística (DML-Deterministic Maximum Likelihood).

2.2.3.1. Máxima Verosimilitud Determinística (DML-Deterministic Maximum

Likelihood).

Mientras que el ruido en el receptor se considera que emana de un largo número

de fuentes independientes, usualmente no ocurre lo mismo con las señales. Por

lo tanto, es posible modelar el ruido como un proceso aleatorio estacionario de

tipo blanco Gaussiano, mientras que la forma de las señales son determinísticas y

desconocidas; las frecuencias de las portadoras son conocidas [17]. El momento de

segundo orden, para el término del ruido toma la siguiente forma [17] [24]:

E{n(t)nH(t)

}= σ2Iδts (2.48)

E{n(t)nT (t)

}= 0 ∀ t, s (2.49)


Como consecuencia de estos supuestos estadísticos, el vector de salida x(t) es

un proceso aleatorio temporalmente blanco de distribución Gaussiana, con media

As(t) y matriz de covarianza σ2I. La función de verosimilitud (likelihood function) es la

Función de Densidad de Probabilidad (PDF-Probability Density Function) de todas

las observaciones dada por los parámetros desconocidos. La PDF para un vector

medido x(t) es el complejo L-variable Gaussiano [17]:

1

(πσ2)Le−‖x(t)−As(t)‖2/σ2 (2.50)

donde ‖·‖ denota la norma Euclidiana. Ya que las mediciones son independien-

tes, la función de verosimilitud se obtiene como [17]:

LDML

(θ, s(t),σ2

)=

N∏t=1

(πσ2)−Le−‖x(t)−As(t)‖2/σ2 (2.51)

Los parámetros desconocidos en la función de verosimilitud son los ángulos θ

de las señales, las formas de onda de las señales s(t) y la varianza del ruido σ2. Las

estimaciones de ML para los parámetros desconocidos se calculan maximizando

los argumentos de L(θ, s(t),σ2

). Por conveniencia la estimación se realiza minimi-

zando la función negativa logarítmica de probabilidad − log L(θ, s(t),σ2

). Norma-

lizando para N e ignorando el parámetro independiente L logπ, se tiene [17]:

lDML

(θ, s(t),σ2

)= L logσ2 +

1

σ2N

N∑t=1

∥∥x(t) −As(t)∥∥2 (2.52)

cuyos argumentos de minimización son las estimaciones DML. Explícitamente,

se tiene que la minimización respecto a σ2 y s(t) están dadas por [17]:

�σ2 =1

LTr{Π⊥A

�R}

(2.53)

�s(t) = A†x(t) (2.54)


donde �R es la matriz de covarianza estimada, A† denota la pseudoinversa de

Moore-Penrose deA yΠ⊥A es el proyector ortogonal sobre el espacio nulo deAH [20].

La matriz de covarianza estimada se calcula según la ecuación (2.27) y, además, se

tiene que [17]:

A† =(AHA

)−1

AH (2.55)

ΠA = AA† (2.56)

Π⊥A = I−ΠA (2.57)

Sustituyendo las ecuaciones (2.53) y (2.54) en (2.52) el ángulo estimado de la

señal, entonces, se obtiene resolviendo el siguiente problema de minimización [17]:

�θDML = arg

{m��nθTr{Π⊥A

�R}}

(2.58)

donde Tr{·} denota la traza7 de una matriz cuadrada, y arg{·} es el argumento

de un número complejo. La interpretación es que las mediciones de x(t) se proyec-

tan sobre un modelo de subespacio ortogonal para todas las componentes de las

señales previstas, entonces la medida de potencia es igual a [17]:

1

N

N∑t=1

∥∥Π⊥A �R∥∥2 = Tr{Π⊥A �R} (2.59)

2.3. PROCESAMIENTO DIGITAL DE LAS SEÑALES.

El procesamiento digital de señales abarca todo lo concerniente con la repre-

sentación digital de señales y el uso de sistemas digitales para analizar, modificar,

almacenar, transmitir o extraer información de estas señales. El avance rápido en

tecnología digital en los últimos años ha creado la implementación de sofisticados

algoritmos de procesado digital de señales que hacen que realizar tareas en tiempo

real sea factible. Las ventajas de usar sistemas de procesamiento de señal en lugar

7La traza de una matriz cuadrada se define como la suma de los elementos de su diagonal princi-pal.


de dispositivos analógicos tradicionales (como amplificador, moduladores y filtros)

son las siguientes [2]:

Flexibilidad. Las funciones del procesado digital de señal pueden ser modi-

ficadas o actualizadas mediante software y, usando el mismo hardware, para

un algoritmo específico.

Reproductibilidad. El rendimiento de estos sistemas puede ser repetido exac-

tamente, de una unidad a otra. Esto porque el procesamiento de las señales

de estos sistemas trabajan directamente con secuencias binarias.

Confiabilidad. La memoria y lógica del hardware de estos sistemas no se de-

teriora con el tiempo. Por lo tanto, el rendimiento en el campo de los sistemas

de procesado digital de señal, no se deteriora con el cambio de las condiciones

ambientales o el tiempo de los componentes electrónicos, como sus contrapar-

tes analógicas lo hacen.

Complejidad. Estos sistemas permiten sofisticadas aplicaciones que pueden

ser implementadas en dispositivos portátiles con un bajo consumo de poten-

cia, lo que resultaría impráctico con técnicas analógicas tradicionales.

Algoritmos de procesado de pueden ser desarrollados, analizados y simulados

usando herramientas de lenguaje de alto nivel como C/C++ y MATLAB. El rendi-

miento de estos algoritmos puede ser verificado usando una computadora perso-

nal. Por lo tanto, un sistema de procesado digital de señal es relativamente fácil de

analizar, simular, y probar [2].

Sin embargo, existen limitaciones; por ejemplo, el ancho de banda de estos siste-

mas esta limitado por la tasa de muestreo y los periféricos del hardware. El costo de

diseño inicial de estos sistemas puede ser elevado, especialmente cuando un largo

ancho de banda de las señales están implicados. Para aplicaciones en tiempo real,

algoritmos de procesamiento digital de señal son implementados usando un nú-

mero fijo de bits, que resulta en un limitado rango dinámico produciendo errores

aritméticos [2].


2.3.1. Procesador Digital de Señal (DSP).

Un DSP es, básicamente, un microprocesador con una arquitectura y un conjun-

to de instrucciones diseñados específicamente para aplicaciones de procesamiento

digital de señales [2]. Este tipo de dispositivo tiene ventajas que optimizan el diseño

de circuitos electrónicos, tales ventajas son: alta flexibilidad, bajo tiempo de diseño,

bajo consumo de potencia y un bajo costo en el desarrollo.

Para la programación de algoritmos de DSP, las compañías que fabrican estos

dispositivos han generado IDE’s que contienen herramientas como compiladores

de lenguaje C y Assembler para la interpretación de las reglas secuenciales de los

algoritmos y llevarlos al lenguaje máquina del procesador. También cuenta con op-

timizadores, enlazadores, depuradores, simuladores y emuladores.

2.3.2. Elementos básicos de un sistema de DSP en tiempo real.

Hay dos tipos de aplicaciones de sistemas de DSP’s: aplicaciones en tiempo no

real y en tiempo real. La primera establece que el procesamiento de los datos que

son adquiridos, generalmente, por un Convertidor Analógico Digital (ADC-Analog

to Digital Converter) debe ser ejecutado antes que se capturen los próximos datos.

Estas aplicaciones procesan las señales digitales sin tales restricciones de tiempo. La

segunda es el propósito principal de uso de un DSP e indica que el procesamiento

de las señales siguen el ritmo de un evento externo [26]. En la Figura 2.11 se observa

un esquema básico de un sistema de DSP en tiempo real [2]. La señal de entrada es

amplificada y luego entra a un filtro anti-aliasing. El ADC captura esa señal de entra-

da y, la representación digital que resulta de esta señal captada, es procesada por un

DSP. Luego la salida se reconstruye con un DAC y entra a un filtro de reconstrucción

para suavizar o reconstruir la señal de salida [2] [26].


Figura 2.11: Diagrama de bloque básico de un sistema de DSP en tiempo real [2].

2.4. GENERACIÓN Y OPTIMIZACIÓN DE CÓDIGO PA-

RA DSP’s.

Sistema embebido es el nombre genérico que reciben los equipos electrónicos que

incluyen un procesamiento de datos, pero que, a diferencia de una computadora

personal, están diseñados para satisfacer una función específica. El cerebro de un

sistema embebido es típicamente un microcontrolador, aunque los datos también

pueden ser procesados por un DSP, una FPGA (Field Programmable Gate Array), un

microprocesador o un ASIC (Application Specific Integrated Circuit), y su diseño está

optimizado para reducir su tamaño y su costo, aumentar su confiabilidad y mejorar

su desempeño [27]. En esta sección se estudiarán las herramientas para la genera-

ción de código para sistemas embebidos de DSP’s.

Los entornos de desarrollo de procesado matemático, son útiles para el diseño

de algoritmos pues permiten la implementación y prueba de códigos de forma rela-

tivamente sencilla y rápida [8]. Las características de estos lenguajes subyace en su

flexibilidad y simplicidad a la hora de codificar, así como la claridad de su interfaz

gráfica, lo que facilita el desarrollo de algoritmos que necesiten un procesamien-

to de señal, para su posterior implementación en sistemas embebidos. Uno de los


lenguajes de computación matemático de alto nivel más potentes es MATLAB de

Mathworks.

Los DSP’s ejecutan código objeto8, los cuales son interpretados por la unidad

central de procesamiento de cualquier circuito integrado programable, como DSP’s,

microcontroladores, microprocesadores, entre otros. El código objeto se genera a

partir del código fuente de un determinado software de lenguaje medio o alto nivel,

que bien puede o no ser el mismo lenguaje de computación matemática en el que,

inicialmente, se diseña la aplicación.

Los indicadores más utilizados para evaluar el rendimiento de un sistema en

tiempo real son el tiempo de ejecución de un programa y la ocupación en memoria y,

generalmente, la optimización de un indicador conlleva a la desmejora del otro.

Por lo tanto, es necesario realizar una evaluación de los requisitos del sistema9 en

cuestión, para establecer cuál indicador es más crítico, para mejorar uno de ellos o

bien para encontrar un equilibrio entre ambos, si eso resulta más beneficioso.

A continuación, se describirán las herramientas que permiten la codificación de

un algoritmo que admite la ejecución en tiempo real, desde su conceptualización

hasta la simulación en los entornos de desarrollo integrados para DSP’s.

2.4.1. Embedded MATLAB.

MATLAB es un lenguaje de alto nivel y un entorno interactivo sencillo, ágil y

dinámico para el diseño y resolución de problemas, cuyas herramientas de desa-

rrollo permiten una mejora en la calidad del código, facilidad de mantenimiento

y maximización del rendimiento. No obstante, por lo general no es posible gene-

rar a partir de él, aplicaciones ejecutables por dispositivos integrados. Por lo tanto,

es necesario convertir el código elaborado en MATLAB a un determinado lengua-

je de programación que se denomina lenguaje intermedio para que, a partir de éste,

se pueda generar el código objeto ejecutable por el DSP. Uno de los lenguajes más

comúnmente usados es C.8Código en lenguaje máquina.9Esta tesis está basada en sistemas de Antena Inteligente, más específicamente la etapa de DoA.


En un primer momento, se podría pensar en reescribir manualmente el código

MATLAB a lenguaje C. Uno de los retos que esto conlleva son las diferencias fun-

cionales y de comportamiento, entre ambos lenguajes, introducidos en su diseño.

Por tal motivo, el principal problema de esta aproximación, es que se deben mante-

ner dos implementaciones que no están automáticamente sincronizadas entre ellas.

De esta manera, si los requisitos cambian durante el desarrollo, que es algo que

siempre ocurre, es bastante ineficiente modificar el código C, para probarlo nue-

vamente y asegurar que su funcionalidad es la misma que el código original de

MATLAB [28].

Los errores de codificación se traducen habitualmente durante el proceso de tra-

ducción manual, conduciendo a tiempos de pruebas más largos y sin garantía que

se capturen todos los errores introducidos. Con la traducción automática de algo-

ritmos de MATLAB a C, se dedica mucho menos tiempo a la escritura y depuración

de código C y más tiempo en desarrollo y sintonización de algoritmos [28].

En este sentido, MATLAB dispone de herramientas que abordan esta cuestión y

que facilitan la conversión de MATLAB a lenguaje C reduciendo el costo en el desa-

rrollo y verificación del algoritmo final. Estas herramientas pueden convertir una

parte del lenguaje MATLAB, llamado Embedded MATLAB, a código C portable y

multiplataforma.

Embedded MATLAB es un subconjunto del lenguaje MATLAB que soporta la

generación de código eficiente para su implementación en sistemas embebidos y

aceleración de algoritmos de punto fijo [29]. Está compuesto por más de 270 ope-

radores y funciones tradicionales de MATLAB y 90 funciones para el desarrollo de

aplicaciones en punto fijo [30].

Entre las características de MATLAB que soporta Embedded MATLAB se en-

cuentran los arreglos N-dimensional, operaciones con matrices, números comple-

jos, diferentes tipos de variables y clases numéricas, aritmética de simple y doble

precisión, aritmética de punto fijo, estructuras de control de flujo (if, switch, whi-

le, for), subfunciones, variables persistentes, estructuras, caracteres o llamadas a

funciones de MATLAB entre otras características [29].


En este sentido, trabajando dentro de dicho subconjunto, el diseño de algo-

ritmos es más fácil pues el algoritmo Embedded MATLAB es todavía código de

MATLAB, y conserva las capacidades interactivas de depuración y visualización

en MATLAB. Este enfoque permite generar automáticamente código C a partir del

código Embedded MATLAB, eliminando el costo de producción y verificación de

código escrito a mano en lenguaje C [30]. La conversión de un algoritmo típico

MATLAB en código C, implica considerar varios requerimientos de implementa-

ción [30]:

Gestión de tipo de datos. Los tipos de datos se deben determinar antes de su

implementación.

Asignación de memoria estática. MATLAB perfectamente maneja variables

que cambian dinámicamente de tamaño en tiempo de ejecución. En aplicacio-

nes embebidas, sin embargo, se recomienda evitar la asignación de memoria

dinámica, definiendo así tipo de datos de tamaño específico antes de ser uti-

lizados.

Reducción de la complejidad computacional. Se recomienda diseñar algo-

ritmos óptimos, pues existe limitación de recursos computacionales para el

hardware de destino, este esfuerzo resulta en afinar el diseño para el conjun-

to de instrucciones y datos de los algoritmos.

Soporte de punto fijo. La implementación en software o hardware embebido

puede requerir que el algoritmo se definina completamente con tipos de datos

de punto fijo.

Embedded MATLAB puede emplearse en diversas tareas como la generación

de código C desde código MATLAB, generación de funciones C-MEX (C-MATLAB

Executable) para la verificación desde MATLAB del código C generado, integración

de código MATLAB en Simulink o integrar código C en MATLAB, entre otros. De

estas características, recibe especial interés la capacidad de generación de código

C a partir de código MATLAB y la verificación del código C generado dentro del

entorno MATLAB.


Para ello es necesario el Real-Time Workshop (RTW), una herramienta para la

generación de código C embebido a partir de funciones de Embedded MATLAB

en Simulink, Stateflow o en código MATLAB plano por medio de su característica

Real-Time Workshop Embedded Coder. De esta manera, Real-Time Workshop ge-

nera y ejecuta código C independiente para desarrollo y verificación de algoritmos

modelados en Simulink o en código Embedded MATLAB, de modo que permi-

te obtener código eficiente para aplicaciones en tiempo real, al mismo tiempo que

permite realizar todo el proceso, desde el diseño del algoritmo hasta la consecución

del código C, sin salir del entorno MATLAB [8] [31].

2.4.1.1. Limitaciones de Embedded MATLAB.

No todos los elementos de MATLAB soportan la conversión a lenguaje C. Si

existe este tipo de elementos, entonces se generará un informe en formato html con

los errores de compilación. En el desarrollo de algoritmos en MATLAB, normal-

mente no se toma en cuenta estas consideraciones, no obstante, para la codificación

de algoritmos mediante la herramienta Embedded MATLAB es importante tenerlas

presentes desde un principio, y así evitar la reprogramación de los códigos produc-

to de los errores de compilación.

Embedded MATLAB no soporta cell array (matrices cuyas celdas contienen dis-

tintos tipos de datos) , dualidad10 comando/función, variables dinámicas11, varia-

bles globales, funciones anidadas, eliminación de matriz, objetos, matrices disper-

sas y las declaraciones try/catch [29].

Es menester considerar algunas de las diferencias entre el lenguaje MATLAB y

el lenguaje C para la posterior conversión de uno a otro, de esta forma es posible

salvar algunas de las limitaciones de Embedded MATLAB. La Tabla 2.2 muestra

algunas de estas diferencias [30].

10Embedded MATLAB soporta la sintaxis de estilo de función Embedded, pero no sintaxis de estilocomando para llamadas a funciones. MATLAB soporta ambos estilos.

11No soporta variables que cambian de tamaño.


Tabla 2.2: Diferencias entre MATLAB y lenguaje C.

MATLAB Código CNo necesita declaración de variabley tamaño antes de ser usadas

Necesita declaración de variable ytamaño antes de ser usadas

Permite el cambio de tamaño de lasvariables sin necesidad de progra-mación

Los cambios en el tamaño de lasvariables son permitidos explícita-mente a través de la asignación dememoria dinámica

No necesita declarar nombre, tipo ylongitud de un array

Necesita declarar nombre, tipo ylongitud de un array

Incorporación de variables de tipocomplejas

No incorpora variables de tipocomplejas

Soporte extensivo para librerías deálgebra lineal y aplicaciones especí-ficas organizadas en toolboxes

No soporte para librerías de álge-bra lineal y aplicaciones específicas

Por otra parte, un algoritmo diseñado en MATLAB no considera la importancia

de su análisis para asegurar que opera de forma eficiente, dentro de la ocupación

en memoria requerida y de los recursos de los que se dispone a fin de reducir la

complejidad computacional y el total de memoria ocupada, algo que si debe ser

considerado para aplicaciones embebidas.

2.4.1.2. Funciones C-MEX (C-Matlab Executable).

Una de las características resaltantes de Embedded MATLAB, es que permite

verificar dentro de MATLAB el código C generado, es decir, se puede compilar

código C en funciones que son llamadas desde MATLAB [29]. Aun cuando no es

posible hacer el llamado del código C, directamente desde el Command Window de

MATLAB, existe una herramienta para poder generar un ejecutable de este archivo

para poder ser usado en el entorno de MATLAB.

El archivo que se genera, es llamado mex que sería el equivalente en español a

ejecutable de MATLAB y es este tipo de funciones las que posteriormente se pueden

llamar en el Command Window o en cualquier fichero o función de MATLAB. De


esta manera, es posible verificar escaladamente cada parte del código C generado

mediante estas funciones C-MEX.

2.4.2. Compilador C de propósito general.

C se ha convertido en uno de los lenguajes mayormente usados para desarrollos

de software para DSP’s, no sólo debido a sus poderosos comandos y estructuras de

datos, sino también debido a su portabilidad entre distintas plataformas y dispositi-

vos DSP’s. El hecho que los compiladores de C están disponibles para una amplia

gama de unas plataformas de computadoras y DSP’s hace que C sea el software más

portable para aplicaciones en tiempo real [2]. Con un diseño cuidadoso, es posible

escribir programas en C que sean portables para la mayoría de las computadoras o

dispositivos [32].

Code::Blocks es un entorno de desarrollo integrado libre y multiplataforma para

el desarrollo de programas en lenguaje C, C++ y Fortran, diseñado para satisfacer

las necesidades más exigentes de sus usuarios [33]. Es útil para el desarrollo de

aplicaciones, pues permite la verificación de un programa en lenguaje C de forma

independiente, en un entorno totalmente separado de otras herramientas que se

emplean en el proceso de desarrollo de software embebido.

El propósito es conseguir que el código escrito sea independiente de cualquier

plataforma, de manera que pueda ser compilado por cualquier herramienta de

desarrollo de software e implementado en cualquier entorno ya sea un DSP, un

microcontrolador, entre otros.

2.4.3. Code Composer Studio (CCS).

Code Composer Studio es un IDE que soporta microcontroladores de Texas Ins-

truments (TI) y procesadores integrados. CCS cuenta con un conjunto de herra-

mientas que se utilizan para desarrollar y depurar aplicaciones integradas. Incluye


una optimización del compilador C/C++, editor de código fuente, entorno de cons-

trucción de proyectos, depurador, y muchas otras características. Es un IDE intui-

tivo que proporciona una única interfaz de usuario, cuyas herramientas permiten

a los usuarios empezar más rápido que nunca, dando la posibilidad de seleccionar

un target concreto dentro de la familia de DSP’s de TI [34].

En su interfaz, proporciona el abordaje de cada uno de los pasos a seguir en el

proceso de desarrollo de aplicaciones embebidas, lo que permite reducir el tiempo

que se invierte en el desarrollo e integración de software para DSP’s.

CCS incluye herramientas para la generación de código, tal como un compila-

dor de C, un ensamblador y un enlazador. Tiene capacidades gráficas y apoya la

depuración en tiempo real. Proporciona una herramienta fácil de usar software pa-

ra construir y depurar programas. El compilador de C compila un programa fuente

con extensión .c para producir un archivo de origen asembler con extension .asm.

El ensamblador ensambla el archivo fuente .asm para producir un archivo objeto

en lenguaje máquina con extension .obj. El enlazador combina archivos objeto y

bibliotecas de objetos como entrada para producir un archivo ejecutable con exten-

sion .out. Este archivo ejecutable es quien finalmente se puede cargar y ejecutar

directamente en el procesador [26].

Capítulo III

Procedimientos de la

investigación.

Con el objeto de evaluar los algoritmos DoA en Code Composer Studio, se ana-

lizan dos alternativas posibles:

Codificación manual de código en lenguaje C.

Conversión automática de código en lenguaje de computación matemática

(MATLAB) a un código fuente C.

Evaluando estas dos alternativas y tomando en cuenta que en [7] ya se han co-

dificados los algoritmos MUSIC y DML en el lenguaje propio de MATLAB, resulta

de gran provecho hacer uso de las herramientas que dispone MATLAB para la ge-

neración automática de código fuente C. Por lo tanto, se tomaron dichos códigos

como punto de partida y se hizo uso de las herramientas que dispone MATLAB

para la generación automática de código fuente C.

En este sentido, esta investigación se divide en cuatro etapas principales como

se muestra en la Figura 3.1. Cada una de ellas se explica de manera detallada en las

siguientes secciones.

45

46 Capítulo III. Procedimientos de la investigación.

ETAPA 1Estudio de la estimación

de llegada y los métodos MUSIC y ML

ETAPA 3Evaluación de la respuesta

computacional de distintos DSP’s

ETAPA 2 Simulaciones

ETAPA 4 Creación de un procedimiento general

Figura 3.1: Etapas de la investigación.

3.1. Estudio de la estimación de llegada y los métodos MU-

SIC y ML.

Se realizó mediante la documentación sobre el problema general de estimación

de la dirección de llegada y, luego, se hizo un análisis de los dos algoritmos DoA

utilizados en este estudios, MUSIC y DML. Por consiguiente, se seleccionó MU-

SIC por ser uno de los métodos más ampliamente usado (es un método basado en

subespacio) y el cual ha recibido bastante atención por parte de investigadores [21].

Por otro lado, se seleccionó DML por ser un método paramétrico y mucho más

preciso que MUSIC aun cuando ofrece una mayor carga computacional [17].

Capítulo III. Procedimientos de la investigación. 47

3.1.1. Naturaleza de las señales del entorno.

Las señales que se usaron para la simulación, tienen un comportamiento de tipo

senoidal. De esta forma, la i− ésima señal de información está representada por la

siguiente ecuación:

s(t) = Ai sin(2πfit) (3.1)

donde Ai y fi representan la amplitud y la frecuencia, respectivamente. El índi-

ce i, toma valores de 1, 2, ...,P.

Ahora bien, las componentes frecuenciales deben estar contenidas en un rango

que sea menor o igual al ancho de banda del dipolo de λ/2. Dicho ancho de banda

es menor o igual al diez por ciento de la frecuencia de trabajo nominal del dipolo

(BWd = 0,1fd) [35].

En la Tabla 3.1 se muestran algunos rangos de frecuencia, donde las empresas de

telecomunicaciones pueden operar en Venezuela como servicio primario [36]. Por

lo tanto, conocido algunos rangos de frecuencias por la Tabla 3.1, y considerando el

alto nivel computacional de los algoritmos DoA, la frecuencia de trabajo nominal

del dipolo se tomó como:

fd =(806+ 890)MHz

2= 848MHz ≈ 850MHz (3.2)

Tabla 3.1: Rangos de frecuencias para comunicaciones móviles más usados; esta-blecidos por CONATEL.

Rango de frecuencias Atribución Venezuela[806 − 890]MHz MOVIL, FIJO

[947, 58 − 960]MHz MOVIL, FIJO

[1710 − 2170]MHz MOVIL, FIJO

De esta manera, se tiene que :

BWd = 85MHz (3.3)


Las señales de radiofrecuencia que arriban al arreglo se rigen por la siguiente

ecuación:

Ai sin(2πfit)ej2πfpit (3.4)

donde fi es la frecuencia de la i − ésima señal de información, cuyo ancho de

banda es de 10KHz [37], y fpi es la frecuencia de la portadora de la i− ésima señal

y ∈ [850± 80]MHz.

Finalmente, se asumió que el ruido que se superpone a las señales es de tipo

AWGN, el cual se denota por n(t).

3.1.2. Respuesta del Arreglo de antena.

En los sistemas de comunicaciones móviles, los elementos principales de las an-

tenas son, generalmente, dipolos de λ/2 que tienen una ganancia unitaria y la mis-

ma respuesta en una banda estrecha de frecuencias [1]. En la práctica, un arreglo de

antenas de una radio base, obedece a un arreglo linealmente uniforme, donde cada

antena perteneciente al arreglo, contiene diversidad espacial [5]. En la Figura 3.2 se

aprecia el modelo de un arreglo de antenas con diversidad espacial y polarización

vertical.

Figura 3.2: Arreglo lineal uniforme usado en comunicaciones móviles con diver-sidad espacial y polarización vertical.


Para objeto de esta investigación, los elementos de este arreglo fueron repre-

sentados por dipolos de λ/2 que operan a una frecuencia de 850MHz, tal como se

propuso en la sección 3.1.1. Este cambio es posible pues en la simulación se con-

sideran ondas planas cuyo vector de onda está contenido en el plano x− y. Los

elementos de antenas estuvieron separados 0,5λ para evitar lóbulos de difracción

y acoplamiento mutuo entre los elementos. En la Figura 3.3, se observa el mode-

lo del arreglo que se usó en las simulaciones. En cuanto al número de elementos

empleados en una Antena Inteligente, se recomienda, que esté entre [6− 10] [9].

Figura 3.3: Arreglo linealmente uniforme a usar para la simulación.

Por lo tanto, se seleccionó un número de L = 10 dipolos. El definir la confi-

guración del arreglo es importante, ya que el mismo condiciona la calidad de la

estimación de las señales y la etapa de BF. Sin embargo, esto limita la estimación,

ya que la matriz de observación está formada por el producto de la matriz de direc-

cionamiento y la matriz de las señales.

En cuanto a la etapa de BF, el arreglo afecta de forma directa la resolución angu-

lar que tiene el haz principal del patrón de radiación, así como en la carga compu-

tacional procesada por el DSP puesto que, a mayor número de elementos del arre-

glo, mayor es el número de información a procesar.


Después de haber configurado el arreglo, se generó la matriz de observaciones

al discretizar las señales que se obtienen de cada sensor. De esta forma, se obtuvo

una matriz de L × N donde cada elemento estuvo integrado por un número com-

plejo.

Por otro lado, la etapa de muestreo debe realizarse a frecuencias inferiores a

las frecuencias de la onda plana que arriba al arreglo ya que, cuando se realizan

simulaciones para analizar el rendimiento de los DSP’s, se debe considerar las limi-

taciones del hardware (por ejemplo: la velocidad de muestreo de los convertidores

A/D). Por tal motivo, y atendiendo lo recomendado en [17], las señales se anali-

zaron en una frecuencia intermedia (fI) y, es desde allí, donde se realizó la etapa

de muestreo. Para este estudio, la frecuencia intermedia fue de 50MHz y la fre-

cuencia de muestreo se calculó mediante la ecuación 3.5, atendiendo al criterio de

Nyquist [37].

fs = 3fI = 150MHz (3.5)

Y a partir de la frecuencia de muestreo, el tiempo de muestreo fue de:

ts = 1/fs ≈ 6,67ns (3.6)

Por otra parte, el término s(t) se ha utilizado para describir las señales de infor-

mación que arriban al arreglo. Sin embargo, para conservar la misma notación, a

partir de ahora cuando se haga referencia a s(t), son las señales que se encuentran

alrededor de fI, esto se describe en la ecuación 3.7. De esta manera, las señales que

usaron los algoritmos MUSIC y DML, fueron señales de radiofrecuecia trasladadas

a una frecuencia intermedia. La siguiente ecuación describe la señal que se usó para

el problema de estimación:

s(t) = Ai sin(2πfit)ejωfIt (3.7)


Antes de calcular la matriz de covarianza, se debe aclarar la expresión de la

ecuación 3.8.

k =2π

λo(3.8)

donde λo es referido a la onda plana. Esta aclaratoria toma lugar porque la

distancia entre los elementos de la antena, mejor conocida como d, también está en

función de λ pero, a diferencia de λo, éste se encuentra en función de la frecuencia

de trabajo nominal del dipolo fd. De esta forma, se tiene la siguiente ecuación:

kd(l− 1) cos(θi) = π(l− 1)fpi − fifd

cos(θi) (3.9)

donde d = 0,5λ e i es un índice que toma valores de 1, 2, . . . ,P. La matriz de N

observaciones está compuesta por la siguiente ecuación:

X = AS+N (3.10)

donde A toma la siguiente forma:

A =

1 1 · · · 1

ejπ

fp1−f1fd

cos(θ1)ejπ

fp2−f2fd

cos(θ2) · · · ejπ

fpP−fP

fdcos(θP)

......

. . ....

ej(L−1)π

fp1−f1fd

cos(θ1)ej(L−1)π

fp2−f2fd

cos(θ2) · · · ej(L−1)π

fpP−fP

fdcos(θP)

L×P(3.11)

S se describe, a continuación, yN es la matriz de ruido AWGN.

S =

0 s1(ts) · · · s1((N− 1)ts)

0 s2(ts) · · · s2((N− 1)ts)...

.... . .

...

0 sP(ts) · · · sP((N− 1)ts)

L×P

(3.12)


3.1.3. Matriz de Covarianza

Para calcular la matriz de covarianza, se tiene como variable de entrada la ma-

triz de observación de N muestras (X). La ecuación 2.27 resulta semejante a la si-

guiente expresión.

R =XXH

N(3.13)

Para obtener precisión en los datos finales, el número de muestras (N) estuvo

entre 100 y 500 para el algoritmo MUSIC [7]. Sin embargo, esta condición hace que

la matriz de observaciones tenga un excesivo consumo de memoria y resulta casi

imposible que todos sus datos puedan estar en la memoria interna de los DSP’s. No

obstante, esta matriz se redujo a un vector de L elementos y con éste, se construyó

la matriz de covarianza estimada, pero este proceso de optimazación será abordado

posteriormente.

La matriz R es la variable de salida del problema de estimación, después de ha-

berla calculado, es la que se usó como variable de entrada en los algoritmos MUSIC

y DML.

3.2. Simulaciones.

En esta etapa, inicialmente, se codificaron los algoritmos con las restricciones

impuestas por Embedded MATLAB. Se comenzó con la matriz de covarianza, la

cual es usada tanto para MUSIC como para DML. En las Figuras 3.4 y 3.5 se ob-

servan los diagramas de flujo de MUSIC y DML, respectivamente. De esta forma,

ambos algoritmos tienen como salida un vector que contiene las posiciones estima-

das de las fuentes de interés.

Luego de codificar y confirmar el correcto funcionamiento de los algoritmos,

se procedió a evaluar un conjunto de cinco escenarios para determinar cuál era el

comportamiento de ambos. Para el primer escenario, se consideró la variación de

la relación señal a ruido, manteniendo constante el número de muestras.


Rxx

Declarar

variables

Descomposición SVD

i = 1j = 1

Un(i,j) = U(i,P+j)

j = j+1

j <= L - P

No

Sí

i = i+1

i <= LSí

No

k = 1

Incremento

No

Fin

k = k+1No

Sí

Sí g=2

z=1

No

aux=z; z=g; g=k; k =aux

Sí

No

Sí

Figura 3.4: Diagrama de flujo del algoritmo MUSIC.


Valor = traza{Proy*Rxx}

Valor < mínimo

i <= P

i = i+1

Sí

No

No

Sí

No

Rxx

Declarar

variables

i = 1

Inicializar

mínimo

Sí

Incremento

mínimo = Valor

Figura 3.5: Diagrama de flujo del algoritmo DML.


Para el segundo escenario, se varió el número de muestras manteniendo la rela-

ción señal a ruido constante. Seguidamente, el tercer escenario consistió en el com-

portamiento de MUSIC y DML en condiciones desfavorables, es decir, un número

bajo tanto de observaciones como de la relación señal a ruido. Para el cuarto es-

cenario, se consideró distintas portadoras que se encontraban dentro del ancho de

banda del dipolo. Finalmente, para el quinto escenario se evaluó la resolución de

los algoritmos cuando fuentes se localizaban muy próximas entre sí.

Según lo establecido en la sección 3.1.2, para todos los escenarios, se consideró

constante el número de dipolos y la distancia entre ellos. Adicionalmente, según

la sección 2.2.1.4 se estableció que el número de fuentes fuese menor al número

de dipolos. Para todos los escenarios, se usó MATLAB1 para realizar los gráficos

pertinentes. Es menester acotar que, para DML, se requirió un número de iteraciones

que dependió del escenario en cuestión.

Para generar código fuente C, de cada función perteneciente a los algoritmos

MUSIC y DML, se siguió el procedimiento descrito en la sección 3.4, mismo que

será detallado en la sección 4.4 usando la MATRIZDECOVARIANZA.m. En el proceso

de la conversión, se generó un error de compilación en cuyo reporte se establecía

que la función awgn, que añade ruido AWGN al vector de observaciones, no era

soportada por Embedded MATLAB impidiendo así la generación de las funciónes

C-MEX de ambos algoritmos. Pese a esto, se realizó una función llamada Rawgn

con funciones que si soporta Embedded MATLAB (randn, var, sqrt) y que tuvo el

mismo comportamiento de la función no soportada awgn.

Por otro lado, para corroborar el correcto funcionamiento de los algoritmos MU-

SIC y DML en lenguaje C, se utilizó el IDE Code::Blocks. Al ejecutar los dos algorit-

mos en Code::Blocks se pudo constatar que los archivos generados por Real-Time

Workshop para cada algoritmo no contenían errores. Además, los valores de las va-

riables de salida de MUSIC y DML fueron similares a los que se obtuvieron desde

el entorno MATLAB.1En esta investigación se usó la versión R2010a de MATLAB.


3.3. Evaluación de la respuesta computacional de distintos

DSP’s.

En esta etapa, se determinó el costo computacional de cada algoritmo, para co-

nocer cuánto tiempo se necesita para ser ejecutados por los DSP’s, así como los

requisitos de memoria y la precisión de las estimaciones.

3.3.1. Optimización de MUSIC y DML.

La optimización del algoritmo MUSIC siguió un proceso sistemático, ya que

se evaluaron cada una de las etapas que lo integran, incluyendo sus variables de

entrada y de salida. La secuencia que sigue el algoritmo está representado en la

Figura 2.10.

En principio, la matriz de covarianza estimada (�R), que entra a ambos algorit-

mos, se genera al multiplicar la matriz de observaciones X, por el hermitiano de la

misma XH y, luego, se divide este producto entre el número de observaciones N.

La generación de la matriz de observación X consume una sección considerable

en la memoria de datos ya que, en MUSIC, para tener buenas estimaciones, se ne-

cesitan más de 100 observaciones. Por lo tanto, si se considera crear una matriz de

covarianza para N = 500 y L = 10, la matriz de observaciones de punto flotante de

simple precisión tiene el siguiente tamaños en bytes:

Tamaño en bytes = 500× 10× 4× 2 = 40KB (3.14)

De la ecuación 3.14, se tiene que la matriz de observaciones tiene un tamaño

de 40KB, el cual es casi la mitad del tamaño que ocupan todos los archivos en

lenguaje C del algoritmo MUSIC. En este sentido, se observó que este problema se

podía solucionar si se obedece la secuencia que tiene la ecuación 2.27, puesto que es

posible realizar la matriz de covarianza para cada una de las observaciones, usando

solo un vector de observación que se actualice para cada muestra, cuyo tamaño


está en función del número de dipolos, es decir, se genera la multiplicación de la

primera observación, luego se genera la multiplicación de la segunda observación y

se suma con la anterior, este proceso se repite sucesivamente hasta llegar al número

de muestras deseadas, tal como lo establece la ecuación 3.15 . Al final, solo resta

dividir toda la sumatoria por el número de muestras N.

R|N=500 =1

500

(x(1)x(1)H + x(2)x(2)H + . . .+ x(500)x(500)H

)(3.15)

Usando este tipo de secuencia, solo se utilizó un vector cuyo tamaño máximo

fue de 40 bytes. Además, ya que el proceso se realiza en tiempo real, la construcción

de la matriz de covarianza se realizó en paralelo con la toma de observaciones. De

esta forma, se elaboró el código de la matriz de covarianza, y se verificó que los

resultados fueron los correctos.

En el análisis del código fuente C de los algoritmos MUSIC y DML, se obser-

vó que algunas veces, RTW generaba funciones que son llamadas desde el código

primario, las cuales están formadas por operaciones matemáticas que necesitan los

mismo archivos de cabecera que ya el código primario contiene. Un ejemplo de es-

to, es la creación de la función exp, la cual está formada solo por las funciones cos y

sin. Teniendo en cuenta lo anterior, se evitó el llamado de una función codificando

directamente en MATLAB.

Para ambos algoritmos, se cuidó de tener variables de gran tamaño para que

pudieran ser almacenadas en la memorias internas del núcleo, o los núcleos del

DSP. De esta forma, se mejoró el rendimiento de la ejecución del programa. Todas

las varibles de MUSIC ocuparon aproximadamente un tamaño de 2, 8KB.

3.3.2. Estimación del tiempo de ejecución del algoritmo DoA en el DSP.

En esta sección, se calcula un estimado del tiempo que se debe satisfacer en la

ejecución del algoritmo DoA, considerando las características de las señales y la


configuración del arreglo que fue definido en la sección 3.1.2. Dicha estimación,

servió de referencia para comparar el tiempo que tarda el DSP en ejecutar los algo-

ritmos MUSIC y DML.

En la Tabla 3.2, se resumen todas las variables de interés usadas en este proceso.

Tabla 3.2: Variables de interés.

Parámetros de interés Simbolo ValorNúmero de dipolos L 10

Frecuencia del dipolo fd 850MHz

Número de observaciones N 500

Frecuencia de muestreo fs 150MHz

Velocidad del usuario critico ν 90km/h

Ancho de media potencia ∆θMP 5◦

Zona lejana de la antena rzl 80m

Inicialmente, para el problema de estimación de DoA, es necesario adquirir las

observaciones. El tiempo para llevar a cabo esto, con 500 observaciones, está defi-

nido por la siguiente ecuación:

∆t|N=500 = 500ts = 3,33µs (3.16)

Como se mencionó en la sección 3.3.1, la matriz de covarianza se construye

al mismo tiempo que se toman las observaciones. Cuando las fuentes presentan

movilidad, la información espacial contenida en las observaciones es válida para

un pequeño instante de tiempo. La Figura 3.6 sirve de referencia para tener un

estimado del tiempo para el cual un usuario crítico2 sale de una determinada área

de cobertura.

Considerando un usuario crítico que se desplace por una autopista a una velo-

cidad de 90km/h [38], y además esté ubicado justamente donde inicia la zona lejana

de la antena, que para efectos de esta investigación corresponde a rzl = 80m, enton-

ces, el ∆tac de la ecuación 3.17 es el tiempo aproximado que tardaría dicho usuario

2La condición más crítica de un sistema de Antena Inteligente, es una fuente que se mueva a unadeterminada velocidad.


Estación base

Usuario

Usuario

crítico

Figura 3.6: Escenario del usuario crítico

en salir del área de cobertura. Dicho tiempo puede aproximarse por la siguiente

ecuación:

∆tac ≈∆x

ν≈ 139ms (3.17)

Para usuarios que se encuentren a distancias mayores a 80m, el ∆tac siempre

será mayor. Para que el usuario tenga disponible la potencia del lóbulo principal

del patrón de radiación, las estimaciones de las posiciones de las señales deben ac-

tualizarse cada ∆tac. Por tal motivo, a éste se le denomina tiempo de refrescamiento

o de actualización de DoA.

El tiempo para el cual se debe realizar la estimación de DoA, debe ser mucho

menor que ∆tac. De esta manera, se garantiza la actualización de la posición del

usuario, la cual es usada en la etapa de BF, misma que se encarga de trazar los

diagramas de radiación (DRθ1 ,DRθ2 , . . . ,DRθP)

tDoA << ∆tac (3.18)


En la Figura 3.7 se ilutra un diagrama de bloque con el tiempo que debe satisfa-

cer el algoritmo DoA.

BF

MUSIC

DML

Sí No

Figura 3.7: Tiempo a satisfascer en la ejecución del algoritmo DoA.

3.3.3. Método para el desarrollo de software de sistemas embebidos, Har-

mony/ESW.

Finalmente, se adoptó un método que permite obtener los mejores resultados en

el desarrollo de software embebido, que se denomina Harmony Embedded Softwa-

re (Harmony/ESW), perteneciente a la familia de procesos Harmony. Este método

consiste en desarrollar un software funcional para después, a partir de él, depurar-

lo y mejorarlo progresivamente mediante cambios incrementales, hasta cumplir los

requisitos deseados. Es un procedimiento iterativo, en el que las fases que lo com-

ponen se recorren cíclicamente de forma que los resultados de un ciclo determinan

las acciones a llevar a cabo en el siguiente, lo que permite aprovechar la experiencia


recogida para mejorar el diseño en el siguiente ciclo y, de esta manera, realizar una

optimización rápida y dinámica [8] [39].

Cabe señalar, que el método iterativo propuesto es un modelo implícito en el

procedimiento general propuesto en la Figura (3.8), en donde cada una de las fases

no se contempla como una etapa cerrada que comienza cuando termina la anterior

sino que, más bien, cada fase se repite más de una vez a lo largo del proceso, has-

ta que se obtenga la aplicación embebida de acuerdo a los requisitos planteados

inicialmente. En la Figura (3.8) se muestra este procedimiento:

Hacer cambio

incremental

Validar

cambios

¿Requisitos

validados?

Sí

No

Figura 3.8: Método adoptado para desarrollo de software de sistemas embebidos,Harmony/ESW).


3.4. Creación de un procedimiento general.

En la Figura 3.9 se refleja todo el proceso para la generación de aplicaciones

embebidas mediante MATLAB, lenguaje C y Code Composer Studio (CCS).

Esta etapa se dividió en varias actividades. Por tal motivo, para abordar cada

una de ellas, se particularizó todo el procedimiento tomando como ejemplo la fun-

ción MATRIZDECOVARIANZA.m para ilustrar los pasos de este proceso de desarrollo.

Dicha función fue usada como entrada tanto en MUSIC como en DML.

Todos estos pasos fueron seguidos de la misma manera para la simulación de

ambos algoritmos, desde su codificación en MATLAB hasta llegar a CCS para la

evaluación de la respuesta computacional. Se realizaron optimizaciones a los códi-

gos teniendo en cuenta los recursos limitados de memoria de los DSP’s. El mismo

procedimiento planteado es aplicable a cualquier algoritmo que se desee imple-

mentar en aplicaciones embebidas usando DSP’s.

MATLAB

Proceso de

optimización

Embedded

MATLAB

MUSIC.m

DML.m

C-MEX Error

Sí

No

Real-Time

Workshop

Entorno MATLAB Entorno C

Código .c

libre de

plataforma

Depuración en

Code::Blocks

IDE de DSP

Simulaciones

CCS

Figura 3.9: Proceso para la generación de aplicaciones embebidas medianteMATLAB, lenguaje C y Code Composer Studio (CCS).

3.4.1. Modificación del código en MATLAB con las restricciones inter-

puestas por Embedded MATLAB.

Una vez verificado el correcto funcionamiento de los códigos en MATLAB, se

procedió a considerar las restricciones de Embedded MATLAB, esto es, la declara-

ción de la clase de cada una de las variables, así como el tamaño y complejidad las


mismas. La función assert [29], se usó para especificar los parámetros de entrada

a las funciones.

3.4.2. Generación de código fuente C.

Una de las características de Embedded MATLAB es que permite la verificación

del código resultante C, dentro del entorno de MATLAB. Para esto, se usaron las

funciones C-MEX, herramienta que permite realizar esta verificación. En este paso,

se pudo constatar que no se genera código fuente C libre de plataforma sino que,

más bien, se crea una función C-MEX que está en código C pero que solo puede

ejecutarse desde MATLAB. Por lo tanto, se verificó que al traducir el código de

MATLAB a C, el mismo se comportaba de la misma manera, es decir, el algoritmo

no fue alterado a causa de la conversión por lo que la función C-MEX realizaba

la misma tarea que la función original de MATLAB. Para generar las funciones

C-MEX se utilizó el pragma %#eml para cada una de las funciones que se quiso

comprobar.

Luego, desde la ventana de comando de MATLAB se escribe el comando de la

Tabla 3.3 [8] [30]:

Tabla 3.3: Comando para la generación de funciones C-MEX.

emlc -o nombrefuncionmex -report nombrefuncion.m -eg {W}

donde:

-o: Indica que se genere función C-MEX.

nombrefuncionmex: Es la función C-MEX generada.

nombrefuncion.m: Es la función original con las restricciones interpues-

tas por Embedded MATLAB.

-report: Indica que se genere un informe de compilación.

eg {W}: La entrada de la función se especifica mediante un ejemplo en

la variable W, misma que debe ser declarada previamente.


Cada vez que se presentó un reporte de error de compilación, se regresó a Em-

bedded MATLAB y se corrigieron los errores reportados. Este procedimiento se

realizó hasta que el proceso de compilación fuera exitoso. Cabe señalar que para

funciones no soportadas por Embedded MATLAB se presentaron dos alternativas

para solucionar este problema:

1. La función no soportada puede declararse como una función extrínseca que

se ejecuta desde MATLAB, pero esto tiene como desventaja que no permite la

generación de código fuente C [29].

2. Hacer un código que tenga la misma característica de la función no soportada

bien desde MATLAB o desde C.

Se tomó en cuenta que la entrada de la función, se especifica mediante una va-

riable que sirve de ejemplo del tipo de parámetros de entrada que ha de tener dicha

función. Adicionalmente, se consideró que la función C-MEX admite como válidas

solo aquellas entradas que son de la misma longitud, tipo y tamaño que la variable

que se utilizó como ejemplo al momento de ser generada.

Seguidamente, la función C-MEX generada se llamó desde el entorno MATLAB

como si se tratara de cualquier función ordinaria de MATLAB. Así, sustituyendo la

función original por su correspondiente función C-MEX se comprobó que el código

generado realizaba el mismo propósito que el código original MATLAB.

Una vez verificada la función, y a partir del código de Embedded MATLAB, se

procedió a generar el código fuente C junto con los demás archivos necesarios para

su compilación. Esto se hizo mediante la herramienta Real-Time Workshop [31]. El

motivo por el cual se genera código en lenguaje C, es debido a que CCS trabaja con

este lenguaje, que en este estudio representa el código intermedio.

Desde la ventana de comando de MATLAB, se escribe el comando de la Tabla

3.4 [8] [30]:

donde:


Tabla 3.4: Comando para la generación de código fuente C.

emlc -c -T RTW -report nombrefuncion.m -eg {W}

-c: Indica que se genere el código C.

T RTW: Genera el código C embebido y lo compila en una librería.

-report: Indica que se genere un informe de compilación.

nombrefuncion.m: Es la función original con las restricciones interpues-

tas por Embedded MATLAB.

eg {W}: La entrada de la función se especifica mediante un ejemplo en

la variable W, misma que debe ser declarada previamente.

De esta manera, RTW genera un código óptimo para ser utilizado en aplicacio-

nes de tiempo real y sistemas embebidos. Cabe señalar que, para cumplir con estas

condiciones, el código que se ha generado en lenguaje C, no siempre mantendrá

la misma estructura del código que se hizo en el lenguaje propio de MATLAB. En-

tre las modificaciones más relevantes hechas por Real-Time Workshop, se tiene lo

siguiente [31]:

La clase de las variables que se definió en MATLAB podrá cambiar a una clase

más simple, si la misma no afecta el comportamiento del código.

El número de variables definidas en MATLAB se reducirá, si no afecta el com-

portamiento del código.

3.4.3. Depuración y validación del código C resultante.

Se realizó una depuración al código y una validación del mismo mediante el

IDE Code::Blocks, una herramienta de acceso libre y multiplataforma que permite

el desarrollo de programas en C. Aun cuando el código generado por Real-Time

Workshop, resulta óptimo para aplicaciones en tiempo real, es conveniente exami-

nar dicho código para que, de ser necesario, se logre una mejor optimización.


3.4.4. Compilación de los códigos en CCS.

Una vez obtenido el código C, de la MATRIZDECOVARIANZA.m, se trabajó en CCS

y se detalló el procedimiento para la creación de un nuevo proyecto, la selección de

las tarjetas, la simulación del algoritmo, el cálculo del ciclo de reloj y las configura-

ciones de memoria necesaria para la compilación de los códigos.

Capítulo IV

Análisis, interpretación y

presentación de los resultados

4.1. ANÁLISIS DEL PROBLEMA DE ESTIMACIÓN Y LOS

MÉTODOS MUSIC Y DML.

El problema de estimación de la dirección de llegada, se concentra en la infe-

rencia de las posiciones angulares de las fuentes de interés que están dentro del

área de cobertura de una estación base. Para efectos de este trabajo, se abordó el

problema para un arreglo lineal uniforme de una antena sectorizada, donde cada

arreglo cubre un sector de cobertura de 120◦ espaciales [5], tal como se muestra en

la Figura 2.2. En este sentido, tomando uno de esos arreglos, las estimaciones solo

son posibles para señales que se encuentren entre 30◦ y 150◦ con respecto al eje del

arreglo.

Las señales que arriban al arreglo, pueden presentar movilidad, estar muy cerca

una de la otra, así como también estar o no correlacionadas. De esta manera, la

movilidad y la correlación de las señales complica el problema de estimación. Por

otro lado, la configuración del arreglo elegido impone condiciones al tipo de señales

que pueden adquirir, además influir sobre el nivel computacional al que el DSP

será sometido, afectando los indicadores como: tiempo de ejecución, precisión y

67

68 Capítulo IV. Análisis, interpretación y presentación de los resultados

memoria. Para el arreglo lineal uniforme de la Figura 3.3, se estiman las posiciones

que varían en θ. Por otra parte, se tiene que el ancho de banda de los elementos

del arreglo son de banda estrecha, en consecuencia, el ancho de banda donde se

concentra la energía de las señales debe ser mucho menor a la frecuencia de la

portadora usada para la transmisión.

Para construir la matriz de observación, se debe discretizar la señal que sale

de los sensores, la cual está formada por la superposición de las señales de interés

y el ruido. En la práctica, este muestreo se realiza a la frecuencia intermedia [17],

lo que amerita que la frecuencia de muestreo deberá ser como mínimo, dos veces

la frecuencia intermedia. La matriz de observación está formada por N vectores

columnas, y L vectores filas.

Luego que la matriz de observaciones fue sido construida, la misma fue la varia-

ble de entrada que necesita la etapa encargada de construir la matriz de covarianza,

con la cual se pudo obtener la covarianza entre los elementos pertenecientes a la

agrupación de la antena, que contiene información de las señales y el ruido.

4.1.1. MUSIC Y DML.

Existen muchos algoritmos que son usados para abordar el problema de estima-

ción, los cuales se encuentran clasificados en tres familias o subconjuntos. En pri-

mer lugar, existen los métodos convencionales, donde el proceso se basa en hacer

un barrido electrónico del lóbulo principal del arreglo para detectar las direcciones

de máxima potencia. Por tal motivo, este método es el que se utiliza en la tecnología

de haz conmutado y no es primordial contar con una unidad de DSP. El segundo

método, se basa en la descomposición espectral de la matriz de covarianza para

estimar las direcciones de llegada de las fuentes y las frecuencias de las señales.

De manera que las propiedades intrínsecas de la eigen estructura de la matriz de

covarianza son utilizadas para resolver el problema de estimación. En el tercer mé-

todo, se encuentran los estimadores de Máxima Verosimilitud, siendo estos, uno de

los más óptimos ya que estiman con mayor precisión los ángulos de llegada, aun

cuando se encuentren en ambientes de baja relación señal a ruido (SNR) o cuenten

Capítulo IV. Análisis, interpretación y presentación de los resultados 69

con un número pequeños de observaciones (N) de las señales que arriban a cada

sensor de la antena. En consecuencia, la estimación está basada en la teoría de la

inferencia estadísticas de las señales el cual utiliza un conjunto de observaciones

del arreglo de antena lo que maximiza el logaritmo de la función de verosimilitud.

De esta manera, ésta es la función de probabilidad conjunta de los datos obtenidos

dado un conjunto de direcciones de arribo [1] [5].

En fin, de los tres métodos que se nombran anteriormente, los últimos se utilizan

para un sistema de Antena Inteligente con tecnología de haz adaptativo, donde una

unidad de procesamiento digital de señales es requerida.

Con el propósito de evaluar la respuesta computacional de la unidad de DSP,

se seleccionaron dos algoritmos donde uno representó a los métodos basados en

subespacio y, el otro, a los métodos de Máxima Verosimilitud para obtener resul-

tados que permitan tener conclusiones con un mayor alcance, esto es, la respuesta

del DSP en:

Ambientes favorables utilizando algoritmos basados en subespacios.

Ambientes desfavorables utilizando algoritmos basados en los estimadores

de Máxima Verosimilitud.

De esta manera, MUSIC es el que se ha seleccionado para representar a los mé-

todos basados en subespacio y DML para representar los métodos de Máxima Ve-

rosimilitud. En la siguiente sección, se inicia con un conjunto de simulaciones en

el entorno de MATLAB. Cabe señalar que todos los resultados fueron validados en

lenguaje C usando el IDE Code::Blocks.

4.2. SIMULACIONES.

En esta sección, se muestran las simulaciones de MUSIC y DML realizadas en

MATLAB después de haber realizado la codificación de ambos algoritmos. Adicio-

nalmente, se consideraron las restricciones impuestas por Embedded MATLAB y


se verificó el correcto funcionamiento de los algoritmos desde MATLAB. Posterior-

mente, se procedió a realizar varias simulaciones de ambos algoritmos en diferentes

escenarios.

Para las gráficas de MUSIC se usaron coordenadas cartesianas. De esta manera,

cada gráfico contiene los máximos del espectro MUSIC, donde el eje horizontal

representa los ángulos, mientras que el eje vertical corresponde a los máximos en

dB.

Por otra parte, DML requiere un número de iteraciones para converger a los va-

lores reales de las posiciones de interés, que dependió del escenario en cuestión

(número de muestras, relación señal a ruido, proximidad entre las direcciones de

llegada, frecuencia de portadoras). En este sentido, el eje horizontal corresponde a

los ángulos, mientras que el eje vertical corresponde al número de iteraciones. En la

Tabla 4.1 se resumen los datos de las variables de entrada a los algoritmos MUSIC

y DML.

Tabla 4.1: Variables de entrada para evaluar los algoritmos MUSIC y DML.

Variables de entrada de MUSIC y DML Símbolo ValorSeparación entre dipolos d 0,5λ

Número de dipolos L 10

Frecuencia del dipolo fd 850MHz

Separación entre portadoras ∆f 1MHz

Número de fuentes P 5

Posiciones de las señales θ [30 42 50 79 145]

4.2.1. Escenario 1: Comportamiento de MUSIC y DML variando (SNR).

A continuación, se presentan las gráficas de ambos algoritmos, para un número

de observaciones N = 500, y una variación de la relación señal a ruido de 30dB a

0dB en pasos de 10dB.


Gráficas de MUSIC:

La Figura 4.1 muestra los máximos del espectro MUSIC para una SNR de 30dB.

Por otro lado, la Figura 4.2 corresponde a una SNR de 20dB. Por su parte, la Figura

4.3 corresponde a una SNR de 10dB mientras que la Figura 4.4 corresponde a una

SNR de 0dB. Por otro lado, la Tabla 4.2 muestra los resultados de la media y la

varianza de las posiciones estimadas para una SNR de 10dB.

30 42 50 79 14597 109 122−20

−10

0

10

20

30

40

50

θ

Max

de

MU

SIC

(dB

)

37.86 40.7236.69

32.49

−9.50 −9.63 −9.51

18.38

θ = 30 42 50 79 145

Figura 4.1: Máximos del espectro MUSIC con SNR = 30dB.

En el primer escenario, se mantuvo el número de muestras en 500 y se varió la

relación señal a ruido. Para MUSIC se obtienen estimaciones exactas para una SNR

de 30dB y 20dB. Por otro lado, a medida que disminuye la relación señal a ruido, las

estimaciones de MUSIC pierden precisión. En este sentido, para una SNR = 10dB

se calculó la media y la varianza de las estimaciones como se muestra en la Tabla

4.2. Para este caso, en promedio los resultados de las estimaciones se encuentran

alrededor de los valores reales y existe una variabilidad mínima en los datos esti-

mados. Por último, para una SNR = 0dB las estimaciones de MUSIC pierden pre-

cisión, debido a que la información espacial contenida en la matriz de covarianza

ha sido contaminada con un alto nivel de ruido. En este sentido, no fue posible

calcular la media y la varianza para este caso ya que en ocasiones algunos ángulos

no eran estimados, lo que confirma la hipótesis que establece que en condiciones


de bajo SNR el algoritmo MUSIC pierde precisión. Por tal motivo, para compensar

esta pérdida se debe aumentar el número de muestras.

30 42 50 79 14597 109 145122−20

−10

0

10

20

30

40

50

θ

Max

de

MU

SIC

(dB

)

θ = 30 42 50 79 145

36.1332.11

32.03 29.82

−9.51 −9.63 −9.51

18.58


30 43 49 79 97 109 122 145−20

−10

0

10

20

30

θ

Max

de

MU

SIC

(dB

)

θ = 30 42 50 79 14526.88 26.35

22.8326.11

−9.52 −9.62 −9.53

17.76



Tabla 4.2: Media y varianza de MUSIC con SNR = 10dB.

Estimaciones

30 43 49 79 145

31 43 50 79 143

30 42 51 79 143

31 42 50 79 143

31 42 50 79 143

Media 30,60 42,40 50,00 79,00 143,40

Varianza 0,30 0,30 0,50 0 0,80

32 48 79 99 121 144−20

−15

−10

−5

0

5

10

15

20

25

θ

Max

de

MU

SIC

(dB

)

θ = 30 42 50 79 145

11.93

17.02

11.10

−8.75 −9.50

11.21


Gráficas de DML:

La Figura 4.5 muestra las estimaciones de DML para una SNR de 30dB y tres

iteraciones. Por su parte, la Figura 4.6 corresponde a una SNR de 20dB con tres

iteraciones. Por otro lado, la Figura 4.7 corresponde a una SNR de 10dB con cuatro

iteraciones mientras que la Figura 4.8 corresponde a una SNR de 0dB con cuatro

iteraciones. Por último, la Tabla 4.3 muestra los resultados de la media y la varianza


de las posiciones estimadas para una SNR de 0dB en cuyo caso las estimaciones se

realizaron con cuatro iteraciones.

30 42 50 79 145

1

2

3

θ °

Nro

de

itera

cion

es d

e D

ML

Iteración 1 = 45, 33, 79, 144, 48Iteración 2 = 42, 31, 79, 145, 50Iteración 3 = 42, 30, 79, 145, 50

Figura 4.5: Ángulos estimados (�θ) por DML con SNR = 30dB.

4230 79 14550

1

2

3

θ°

Nro

de

itera

cion

es d

e D

ML




4230 50 79 145

1

2

3

4

θ°

Nro

de

itera

cion

es d

e D

ML

Iteración 1 = 45, 33, 79, 144, 48Iteración 2 = 43, 31, 79, 145, 50Iteración 3 = 43, 30, 79, 145, 50Iteración 4 = 42, 30, 79, 145, 50


30 42 50 79 145

1

2

3

4

θ°

Nro

de

itera

cion

es d

e D

ML




Tabla 4.3: Media y varianza de DML con SNR = 0dB.

Estimaciones

30 44 47 79 145

30 45 52 79 143

30 40 51 80 143

30 37 50 79 143

30 40 49 79 143

Media 30,00 41,20 49,80 79,20 143,40

Varianza 0 10,70 3,70 0, 2 0,80

Para el caso de DML, con 30dB y 20dB se necesitó realizar tres iteraciones para

que los valores estimados pudiesen converger a los valores reales. No obstante,

para una SNR de 10dB, se hizo uso de una cuarta iteración, necesaria para obtener

una estimación sin error. Por último, en el caso de 0dB con cuatro iteraciones existe

un pequeño error en la estimación. Por tal razón, se calculó la media y la varianza

de las posiciones estimadas y se observó que en promedio los resultados de las

estimaciones se encuentran alrededor de los valores reales y existe una variabilidad

mínima en las posiciones estimadas. De esta manera, se confirma que para bajos

niveles de relación señal a ruido, el algoritmo DML estima de manera más precisa

que MUSIC.

4.2.2. Escenario 2: Comportamiento de MUSIC y DML variando el nú-

mero de observaciones (N).

Ahora, se presentan gráficos para un valor constante de SNR = 30dB y una va-

riación de N = 500, 200, 100, 10.


Gráficas de MUSIC:

La Figura 4.9 muestra los máximos del espectro MUSIC para un número de

muestras N = 500. Por otro lado, la Figura 4.10 corresponde a un número de ob-

servaciones N = 200. Por su parte, la Figura 4.11 corresponde a un número de

muestras igual a 100 mientras que la Figura 4.12 corresponde a N = 10.

30 42 50 79 14597 109 122−20

−10

0

10

20

30

40

50

θ

Max

de

MU

SIC

(dB

)

37.86 40.7236.69

32.49

−9.50 −9.63 −9.51

18.38

θ = 30 42 50 79 145

Figura 4.9: Máximos del espectro MUSIC con N = 500.

30 42 50 79 14597 109 122−20

−10

0

10

20

30

40

50

θ

Max

de

MU

SIC

(dB

)

θ = 30 42 50 79 145

35.70 37.70

33.2830.75

−9.49 −9.62 −9.52

18.73



30 42 50 79 14511097 123−20

−10

0

10

20

30

40

θ

Max

de

MU

SIC

(dB

)

33.8937.93

32.93 32.26

−9.49 −9.61 −9.53

18.51

θ = 30 42 50 79 145


48 79 98 115 145−10

−8

−6

−4

−2

0

2

4

6

θ

Max

de

MU

SIC

(dB

)

θ = 30 42 50 79 145

−4.96−4.13

−8.71 −8.01

2.71


En el segundo escenario, se mantuvo la SNR constante en 30dB y se varió el

número de muestras. En este sentido, respecto a MUSIC, N igual a 500 es la mis-

ma condición de la Figura 4.9 del primer escenario, analizado anteriormente. Por

otra parte, para N igual a 200 y 100 se obtienen, de igual forma, estimaciones exac-

tas que son similares a las obtenidas con 500 observaciones indicando que, en un


margen entre 500 a 100 muestras, la diferencia entre estas estimaciones radica sólo

en la potencia de sus máximos. Por último, para 10 observaciones MUSIC pierde

resolución considerablemente que provoca estimaciones erróneas. En este sentido,

no fue posible realizar un análisis estadístico de la media y la varianza pues las

estimaciones no eran certeras.

Gráficas de DML:

La Figura 4.13 muestra las estimaciones de DML para un número de observa-

ciones de 500 con tres iteraciones. Por su parte, la Figura 4.14 corresponde a un

número de 200 muestras con tres iteraciones. Por otro lado, la Figura 4.15 corres-

ponde a N = 100 con tres iteraciones mientras que la Figura 4.16 corresponde a un

número de 10 observaciones con cuatro iteraciones. Por último, la Tabla 4.4 mues-

tra los resultados de la media y la varianza de las posiciones estimadas para 10

observaciones en cuyo caso las estimaciones se realizaron con cuatro iteraciones.

30 42 50 79 145

1

2

3

θ°

Nro

de

itera

cion

es d

e D

ML


Figura 4.13: Ángulos estimados (�θ) por DML con N = 500.


30 42 50 79 145

1

2

3

θ°

Nro

de

itera

cion

es d

e D

ML



30 42 50 79 145

1

2

3

θ°

Nro

de

itera

cion

es d

e D

ML




30 42 50 79 145

1

2

3

4

θ°

Nro

de

itera

cion

es d

e D

ML



Tabla 4.4: Media y varianza de DML con N = 10.

Estimaciones

32 47 52 79 145

30 42 50 79 143

30 43 50 80 143

30 41 50 79 143

30 42 50 79 143

Media 30,40 43,00 50,40 79, 00 143,40

Varianza 0, 80 5, 50 0,80 0 0,80

En lo que respecta a DML, igual que en el escenario anterior, se necesitó un

número de iteraciones para converger a los ángulos reales. Con un número de ob-

servaciones de 500, 200 y 100, fue necesario realizar tres iteraciones para que las

estimaciones convergieran a los valores reales. Por otro lado, para 10 observaciones

se necesitó una cuarta iteración, para obtener los ángulos estimados con un mínimo

error. Por tal motivo, se calculó la media y la varianza de las posiciones estimadas


y se observó que en promedio los resultados de las estimaciones se encuentran al-

rededor de los valores reales y existe una variabilidad mínima en las posiciones

estimadas. De esta manera, se confirma que para bajo número de muestras, el algo-

ritmo DML estima de manera más precisa que MUSIC.

4.2.3. Escenario 3: Comportamiento de MUSIC y DML en condiciones

desfavorables.

En este caso, se evaluó ambos algoritmos en condiciones desfavorables, con un

SNR = 10dB y un número de observaciones N = 10.

Gráfica de MUSIC:

La Figura 4.17 muestra los máximos del espectro MUSIC en condiciones desfa-

vorables.

56 74 94 109 142−9

−8

−7

−6

−5

−4

−3

−2

−1

θ

Max

de

MU

SIC

(dB

)

θ = 30 42 50 79 145 −2.31

−2.97

−8.18

−7.12

−4.60

Figura 4.17: Máximos del espectro MUSIC en ambiente desfavorable.

En el tercer escenario, se evaluó el comportamiento de ambos algoritmos en

condiciones desfavorables, es decir, para una SNR de 10dB, y un número de 10

observaciones. En el caso del algoritmo MUSIC, las estimaciones no son favorables

lo que confirma la hipótesis que establece que en condiciones de bajo nivel de SNR


y/o pocas muestras, el algoritmo pierde precisión. En este sentido, no fue posible

calcular la media y la varianza para este caso ya que no se producían estimaciones

certeras. Por tal motivo, para compensar esta pérdida se debe aumentar el número

de muestras.

Gráfica de DML:

La Figura 4.18 muestra las estimaciones de DML en condiciones desfavorables

con cuatro iteraciones. Por otro lado, la Tabla 4.5 muestra los resultados de la media

y la varianza de las posiciones estimadas en cuyo caso las estimaciones se realizaron

con cuatro iteraciones.

30 42 50 79 145

1

2

3

4

θ°

Nro

de

itera

cion

es d

e D

ML


Figura 4.18: Ángulos estimados (�θ) por DML en ambiente desfavorable.


Tabla 4.5: Media y varianza de DML con N = 10.

Estimaciones

32 47 80 124 145

34 47 80 99 145

35 47 66 80 145

40 41 53 78 145

35 47 67 80 143

30 42 50 79 143

Media 35,20 45,80 69,20 92, 20 144,60

Varianza 8, 70 7, 20 127, 70 389, 20 0,80

Para el caso de DML, sin embargo, independientemente del número de itera-

ciones que se realicen, los valores estimados nunca llegan a converger a los valores

reales. Por tal razón, se calculó la media y la varianza como se muestra en la Tabla

4.5. En este sentido, las estimaciones no son favorables puesto que algunos ángu-

los estimados en promedio no están cercanos a los valores reales, en cuyo caso la

varianza para estas estimaciones es alta, lo que indica que para bajo número de

muestras aunado a la baja relación señal a ruido, las estimaciones de DML pierden

precisión.

4.2.4. Escenario 4: Comportamiento de MUSIC y DML para distintas por-

tadoras que se encuentran dentro del ancho de banda del dipolo.

A continuación, se presentan los resultados del comportamiento de ambos al-

goritmos para distintas frecuencias de portadora, para un SNR yN dados, tal como

se observa en la Tabla 4.6.


Tabla 4.6: Distintas frecuencias de portadora.

Variables de entradas de MUSIC y DML Símbolo ValorFrecuencias de las portadoras fp [790− 838]MHz

Relación Señal a Ruido SNR 30dB


Gráfica de MUSIC:

La Figura 4.19 presenta los máximos del espectro MUSIC para distintas frecuen-

cias de portadora. Por otro lado, la Tabla 4.7 muestra el cálculo de la media y la

varianza para las estimaciones de MUSIC en este escenario.

31 44 52 80 98 114 140−20

−10

0

10

20

30

40

50

θ

Max

de

MU

SIC

(dB

)

θ = 30 42 50 79 145

30.46

37.88

45.57

16.01

−9.51 −9.58

18.31

Figura 4.19: Máximos del espectro MUSIC para distintas frecuencias de portado-ras.


Tabla 4.7: Media y varianza de MUSIC para distintas frecuencias de portadoras.

Estimaciones

31 44 52 80 140

30 42 51 79 143

30 42 51 79 143

30 42 51 79 143

30 42 51 79 143

Media 30,20 42,40 51,20 79, 20 142,40

Varianza 0, 20 0, 80 0, 20 0, 20 1, 80

El cuarto escenario, consistió en portadoras de distintas frecuencias. En la Fi-

gura 4.19 se aprecia como el algoritmo MUSIC no estima de manera exacta. No

obstante, en la Tabla 4.7 se aprecia que las estimaciones se concentran alrededor del

valor promedio con una variabilidad mínima en los datos. Por otro lado, el mayor

error de estimación se encuentra en la señal que arriba con θ = 145◦, por ser quien

tiene una frecuencia de portadora que se encuentra más lejos de fd. En la Tabla 4.8

se expone la frecuencia portadora de cada una de las señales.

Tabla 4.8: Frecuencias portadora de las señales.

Señales θ fp

s1(t) 30 838MHz

s2(t) 42 826MHz

s3(t) 50 814MHz

s4(t) 79 802MHz

s5(t) 145 790MHz

De esta manera, este error de estimación está presente pues el ancho de banda

del dipolo es de banda angosta. Por otro lado se tiene que, en el vector de direc-

cionamiento, el λ asociado al número de onda (k) es igual al λ que corresponde al

dipolo, de tal manera que se cumple la siguiente ecuación:

λ/λo = 1 (4.1)


Gráfica de DML:

La Figura 4.20 presenta las estimaciones de DML para distintas frecuencias de

portadora. Por otro lado, la Tabla 4.9 muestra el cálculo de la media y la varianza

para las estimaciones de DML en este escenario.

30 42 50 79 145

1

2

3

θ°

Nro

de

itera

cion

es d

e D

ML


Figura 4.20: Ángulos estimados (�θ) por DML para distintas frecuencias de porta-doras.

Tabla 4.9: Media y varianza de DML para distintas frecuencias de portadoras.

Estimaciones

30 45 55 80 140

31 44 52 80 140

31 44 52 80 140

31 44 52 80 140

31 44 52 80 140

Media 30,80 44,20 52,60 80, 00 140,00

Varianza 0, 20 0, 20 1, 80 0 0

Para el caso de DML, independientemente del número de iteraciones que se


realicen, los valores estimados nunca llegan a converger a los valores reales de ma-

nera exacta. No obstante, de la Tabla 4.9 que en promedio los valores estimados

se encuentran alrededor de los valores reales, con una mínima variabilidad en los

datos.

4.2.5. Escenario 5: Comportamiento de MUSIC y DML con fuentes muy

próximas entre sí.

A continuación, se modificaron los ángulos de llegada, para representar fuentes

que se encuentran próximas entre sí. De esta manera, se presentan los resultados

del comportamiento de ambos algoritmos para un SNR y N dados, tal como se

observa en la Tabla 4.10.

Tabla 4.10: Modificación de variables para fuentes próximas entre sí.

Variables de entradas de MUSIC y DML Símbolo ValorPosiciones de las señales θ [55 60 65 70 75]

Relación Señal a Ruido SNR 30dB


Gráfica de MUSIC:

La Figura 4.21 presenta los máximos del espectro MUSIC para fuentes próximas

entre sí. Por otro lado, la Tabla 4.11 muestra el cálculo de la media y la varianza para

las estimaciones de MUSIC en este escenario.


55 61 66 71 76 107 138−20

−15

−10

−5

0

5

10

15

20

θ °

Max

de

PM

US

IC (

dB)

15.3081 16.1829

10.2425 11.4477

−16.8168 −17.3960

18.0076 θ = 55 60 65 70 75

Figura 4.21: Máximos del espectro MUSIC con fuentes próximas entre sí.

Tabla 4.11: Media y varianza de MUSIC para fuentes próximas entre sí.

Estimaciones

55 61 66 71 76

55 61 65 71 75

55 60 66 69 76

55 60 66 70 75

55 61 65 69 75

Media 55,00 60,60 65,60 70, 00 75,40

Varianza 0 0, 30 0, 30 1, 00 0, 30

En el quinto escenario, se realizó la evaluación de la resolución de los algorit-

mos, en un ambiente favorable con 1000 muestras y 30dB de relación señal a ruido.

De esta manera, se consideraron fuentes que se encontraban angularmente muy

próximas entre sí. Para el caso de MUSIC, la estimación que realiza no converge a

los valores reales de manera exacta. No obstante, en la Tabla 4.11 se observa que en

promedio los valores estimados tienden a aproximarse a los valores reales con una

mínima variabilidad en los datos.


Gráfica de DML:

La Figura 4.22 presenta las estimaciones de DML para fuentes que se encontra-

ban próximas entre sí.

De esta manera, para el caso de DML, la resolución en este escenario es mayor

que la de MUSIC estimando, para cuatro iteraciones, la ubicación de las fuentes de

manera precisa.

55 60 65 70 75

1

2

3

4

θ°

Nro

de

itera

cion

es d

e D

ML


Figura 4.22: Ángulos estimados (�θ) por DML con fuentes próximas entre sí.

En otro orden de ideas, el análisis del algoritmo MUSIC se realiza con la curva

generada por el espectro MUSIC. Dicho espectro se encuentra en función de θ, la

cual varía dentro de un dominio angular [θmin, θmax] que contiene las direcciones

de llegada.

En la Figura 4.23 se presenta, a modo ilustrativo, un típico espectro1 MUSIC. A

diferencia de ésta, en la presente investigación sólo se han graficado, para los cinco

escenarios, los máximos que se generan en el espectro del algoritmo MUSIC ya que,

sólo es de nuestro interés, obtener el vector que contiene los DoA’s de las fuentes.

1Para N = 500 y SNR = 30dB.


30 42 50 79 145−10

0

10

20

30

40

50

θ°

PM

US

IC (

dB)

Figura 4.23: Espectro MUSIC.

Por otro lado, es importante acotar que los máximos que se generaron en el

espectro MUSIC con un nivel de potencia muy bajo se consideraron que están in-

mersos en una plataforma de ruido. De acuerdo a las simulaciones efectuadas, se

ignoraron aquellos máximos que se encuentran por debajo de −5dB.

De esta manera, se han presentado cinco escenario en los que se ha podido eva-

luar el comportamiento de MUSIC y DML. Para el caso de DML, se necesitó un

número de iteraciones del código que dependió del escenario en cuestión, esto con-

firma lo estudiado en la sección 2.2.3, acerca de los métodos de Máxima Verosimili-

tud, respecto a la exigencia de una mayor carga computacional.

Luego de simular los algoritmos MUSIC y DML, se generó el código C de ca-

da uno de ellos siguiendo el procedimiento descrito en la sección 4.4. Una de las

ventajas de trabajar de esta manera, fue el generar código C a partir de MATLAB

sin codificar directamente en C, lo que representa una herramienta para verificar y

realizar pruebas de los algoritmos. Por otro lado, el tiempo de codificación y vali-

dación de los códigos se hace mucho más rápido si se realiza de esta manera.

Por último, posterior a realizar la depuración respectiva de MUSIC y DML, se

validaron los resultados en el IDE Code::Blocks, para los distintos escenarios, lo


que proporciona códigos fuente C libres de plataforma, los cuales pueden ser intro-

ducidos en los simuladores de DSP’s para evaluar la respuesta computacional de

distintas plataformas cuando trabajan con estos algoritmos.

4.3. EVALUACIÓN DE LA RESPUESTA COMPUTACIONAL

DE PROCESADORES DIGITALES DE SEÑAL (DSP’s).

En la sección 4.3.1 se realizaron las simulaciones en CCS para distintas plata-

formas de la familia C6000 (C672x, C674x y C64xx) de Texas Instruments (TI), cuya

compilación se ha llevado a cabo en modo debug. Esto con el fin de verificar el co-

rrecto funcionamiento de los algoritmos que se cargan en la imagen de hardware

virtual de cada plataforma y, adicionalmente, ubicar cada sección del código en los

bancos de memoria dispuestos en el DSP. De esta manera, se calculó el número de

ciclos de reloj, precisión en las estimaciones y requisitos de memoria, tanto de la

matriz de covarianza como de los algoritmos MUSIC y DML. Posterior a esto, en la

sección 4.3.2, una segunda simulación fue efectuada en modo release en las pla-

taformas C672x, C674x y C66xx para eliminar toda la información adicional que se

tiene en modo debug y obtener códigos con una mayor optimización permitiendo,

de esta forma, una ejecución más rápida. En todas las pruebas se ha mantenido

constante el SNR en 30dB.

4.3.1. Simulaciones en Code Composer Studio (CCS).

Para las plataformas C672x y C674x se ha variado el número de observaciones

enN = 500, 200, 100 para ambos algoritmos. En el caso de la plataforma C64xx, solo

se realizó la simulación de MUSIC con 100 observaciones.

ALGORITMO MUSIC:

A continuación, se presentan los ciclos de reloj de la matriz de covarianza y el

algoritmo MUSIC para las plataformas de DSP’s. Además, se muestran tablas de

las estimaciones y de los requisitos de memoria.


Resultados de los ciclos de reloj:

La Tabla 4.12, Tabla 4.13 y Tabla 4.14 presentan resultados de los ciclos de reloj

con N = 500, N = 200 y N = 100 respectivamente usando las plataformas C672x y

C674x. Adicionalmente, la plataforma C64xx es incluida para N = 100.

Tabla 4.12: Ciclos de reloj de la matriz de covarianza y MUSIC con 500 observa-ciones.

C672x C674x

Función Ciclos de reloj Ciclos de reloj

Matriz de covarianza 80477288 80117542

MUSICSVD 647989 629898

Máximo 5211098 5068011

Total ciclos de reloj 86336375 85815451


C672x C674x



MUSICSVD 640752 622544

Máximo 5209364 5068192




C672x C674x C64xx

Función Ciclos de reloj Ciclos de reloj Ciclos de reloj

Matriz de covarianza 15942368 15858711 169632553

MUSICSVD 662572 644313 3498824

Máximo 5208293 5068141 27418478

Total ciclos de reloj 21813233 21571165 200549855

Se realizó el cálculo de los ciclos de reloj de la matriz de covarianza y MUSIC

para 500, 200 y 100 observaciones. En este sentido, a medida que el número de ob-

servaciones disminuye también lo hace los ciclos de reloj. De esta manera, para la

plataforma C672x se registró con 200 observaciones una disminución de 128, 71%

del total de ciclos de reloj respecto a la misma plataforma con 500 observaciones.

Por otro lado, para la misma plataforma con 100 observaciones hubo una dismi-

nución del 295, 798% del total de ciclos de reloj respecto al total de ciclos de reloj

registrados con 500 muestras.

Por su parte, para la plataforma C674x se registran porcentajes similares, por lo

que la comparación que se hará a continuación será respecto a la plataforma C672x.

De esta manera, con 500 observaciones se registró una disminución en los ciclos

de reloj del 0, 6% para la plataforma C674x respecto a la C672x. Por otro lado, con

200 observaciones se registró una disminución en los ciclos de reloj del 0, 81% para

la plataforma C674x respecto a la C672x. Finalmente, con N = 100 se registró una

disminución en los ciclos de reloj del 1, 12% para la plataforma C674x respecto a la

C672x.

Por último, la plataforma C64xx ofrece un alto número de ciclos de reloj. Por tal

razón, la misma no fue usada para el cálculo del tiempo de ejecución de DoA hecho

en la sección 4.3.2.


Resultados de las estimaciones:

La Tabla 4.15, Tabla 4.16 y Tabla 4.17 presentan resultados de las estimaciones


C674x. Adicionalmente, la plataforma C64xx es incluida para N = 100.

Tabla 4.15: Resultados de la estimación de MUSIC con 500 observaciones.

C672x C674x

[30, 42, 50, 79, 145] [30, 42, 50, 79, 145]


C672x C674x

[30, 42, 50, 79, 145] [30, 42, 50, 79, 145]


C672x C674x C64xx

[31, 42, 50, 79, 145] [31, 42, 50, 79, 145] [31, 42, 50, 79, 145]

De acuerdo a las simulaciones efectuadas en la sección 4.2, se concluyó que

con una SNR igual a 30dB y para un número de observaciones entre 100 y 500 las

estimaciones de MUSIC convergían a los valores reales. En este sentido, la Tabla

4.15, Tabla 4.16 y la Tabla 4.17 confirma el análisis hecho previamente usando las

plataformas de DSP’s.

Requisitos de memoria:

La Tabla 4.18 muestra los requisitos de memoria para las plataformas C672x,

C674x y C64xx. Cabe señalar que la compilación se ha hecho en modo debug.


Tabla 4.18: Requisitos de memoria del algoritmo MUSIC.

Memoria C672x C674x C64xx

MUSIC.out (KB) 198, 305 182, 651 266, 432

MUSIC.map (KB) 48, 420 38, 740 85, 736

Para el algoritmo MUSIC, los requisitos de memoria se muestran en la Tabla

4.18. Cabe señalar que debido a las modificaciones hechas al código, el consumo

de memoria es independiente del número de observaciones N ya que se usó un

solo vector que se actualizó para cada observación y cuya dimensión estuvo en

función del número de dipolos. El .out es un ejecutable mientras que el .map es

un archivo donde se encuentra el mapa de la memoria del programa. Allí se halla

información sobre el consumo de memoria referente a cada sección del código, las

funciones perteneciente a la librería usada, el consumo de la pila, entre otros. De

esta manera, a través de la información del archivo .map se calculó el consumo total

de memoria del programa cuando se corrió en los simuladores correspondientes a

las plataforma C672x, C674x y C64xx de Texas Intruments.

Por lo tanto, a partir de la Tabla 4.18 del archivo .map, hubo una disminución

en el consumo de memoria del 24, 98% de la plataforma C674x respecto a la C672x.

Por otro lado, hubo un aumento en el consumo de memoria del 77, 06% de la pla-

taforma C64xx respecto a la C672x.

ALGORITMO DML:

A continuación, se presentan los ciclos de reloj de la matriz de covarianza y el al-

goritmo DML para las plataformas de DSP’s; se presentan resultados para distintos

número de observaciones. Cabe señalar que para este algoritmo se necesitó un nú-

mero de iteraciones para que las estimaciones convergieran a los valores reales. Por

otro lado, se muestran tablas de las estimaciones y de los requisitos de memoria.


Resultados de los ciclos de reloj:

Para N = 500 la Tabla 4.19, Tabla 4.20 y Tabla 4.21 presentan resultados de los

ciclos de reloj para una, dos y tres iteraciones respectivamente. Por otro lado, para

N = 200 la Tabla 4.22, Tabla 4.23 y Tabla 4.24 presentan resultados de los ciclos de

reloj para una, dos y tres iteraciones respectivamente. Por su parte, para N = 100

la Tabla 4.25, Tabla 4.26 y Tabla 4.27 presentan resultados de los ciclos de reloj para

una, dos y tres iteraciones respectivamente. Para todos los resultados se han usado

las plataformas C672x y C674x.

Tabla 4.19: Ciclos de reloj de la matriz de covarianza y DML con 500 observacionesy una iteración.

C672x C674x



DML 215398762 220416643


Tabla 4.20: Ciclos de reloj de la matriz de covarianza y DML con 500 observacionesy dos iteraciones.

C672x C674x



DML 508890315 519081308



Tabla 4.21: Ciclos de reloj de la matriz de covarianza y DML con 500 observacionesy tres iteraciones.

C672x C674x



DML 803856586 819270800



C672x C674x



DML 215397674 220415556



C672x C674x



DML 508851730 519043756




C672x C674x



DML 804404793 819820328



C672x C674x



DML 215032768 220047367



C672x C674x



DML 509389944 519583929




C672x C674x



DML 804356558 819772965


Se realizó el cálculo de los ciclos de reloj de la matriz de covarianza y DML para

500, 200 y 100 observaciones usando tres iteraciones, y se observó que a mayor nú-

mero de iteraciones mayor es la carga computacional. De esta manera, a continua-

ción se realizará una comparación de los porcentajes de variación de DML respecto

a MUSIC. Así, para la plataforma C672x con 500 observaciones y tres iteraciones se

registró un aumento en el total de ciclos de reloj para DML del 481, 88% respecto

a MUSIC. Por otro lado, para N = 200 y tres iteraciones se registró un aumento en

el total de ciclos de reloj para DML del 2114, 69% respecto a MUSIC. Finalmente,

para N = 100 y tres iteraciones se registró un aumento en el total de ciclos de reloj

para DML del 3659, 87% respecto a MUSIC. Por lo tanto, a partir de los porcentajes

obtenidos para DML se confirma la hipótesis que establece que el algoritmo DML

exige una mayor carga computacional que MUSIC.


La Tabla 4.28, Tabla 4.29 y Tabla 4.30 presentan resultados de las estimaciones


C674x. Los resultados mostrados fueron realizados para las tres iteraciones.


Tabla 4.28: Resultados de la estimación de DML con 500 observaciones para lastres iteraciones.

C672x C674x

Iteración 1 [45, 33, 79, 144, 48] [45, 32, 79, 144, 48]

Iteración 2 [42, 31, 79, 145, 50] [42, 31, 79, 145, 50]

Iteración 3 [42, 30, 79, 145, 50] [42, 30, 79, 145, 50]


C672x C674x

Iteración 1 [45, 33, 79, 144, 48] [45, 33, 79, 144, 48]

Iteración 2 [42, 31, 79, 145, 50] [42, 31, 79, 145, 50]

Iteración 3 [42, 30, 79, 145, 50] [42, 30, 79, 145, 50]


C672x C674x

Iteración 1 [45, 34, 79, 144, 48] [45, 34, 79, 144, 48]

Iteración 2 [40, 30, 79, 145, 50] [42, 31, 79, 145, 50]

Iteración 3 [42, 30, 79, 145, 50] [42, 30, 79, 145, 50]

De acuerdo a las simulaciones efectuadas en la sección 4.2, se concluyó que con

una SNR igual a 30dB y para un número de observaciones entre 100 y 500 las es-

timaciones de DML convergían a los valores reales para tres iteraciones. En este

sentido, la Tabla 4.28, Tabla 4.29 y la Tabla 4.30 confirma el análisis hecho previa-

mente usando las plataformas de DSP’s.



C674x. Cabe señalar que la compilación se ha hecho en modo debug.


Tabla 4.31: Requisitos de memoria del algoritmo DML.

Memoria C672x C674x

DML.out (KB) 207, 039 281, 001

DML.map (KB) 52, 500 65, 792

Para el algoritmo DML, los requisitos de memoria se muestran en la Tabla 4.31.

De la misma forma que en MUSIC, el consumo de memoria es independiente del

número de observacionesN. A través de la información del archivo .map se calculó

el consumo total de memoria del programa cuando se corrió en los simuladores

correspondientes a las plataforma C672x y C674x de Texas Intruments.

Por lo tanto, a partir de la Tabla 4.18 del archivo .map, hubo un aumento en

el consumo de memoria del 25, 31% de la plataforma C674x respecto a la C672x.

Adicionalmente, para la plataforma C672x referido al .map hubo un aumento en

el consumo de memoria por parte de DML del 8, 42% respecto a MUSIC, mientras

que para la plataforma C674x hubo un aumento en el consumo de memoria por

parte de DML del 69, 82% respecto a MUSIC. De esta manera, se confirma el hecho

de que el algoritmo DML exige un mayor consumo de memoria que el algoritmo

MUSIC.

4.3.2. Tiempo de ejecución de los algoritmos DoA.

A partir de los resultados obtenidos en la sección 4.3.1, se realizaron simula-

ciones con un número de observaciones igual a 100 y para el caso de DML, se cal-

cularon dos iteraciones. De esta forma, se obtuvo buenas estimaciones y se tomó

en cuenta el compromiso que se tiene para satisfacer el tiempo de ejecución de los

algoritmos DoA definido en la sección 3.3.2.

El tiempo de ejecución de cada algoritmo, está determinado al conocer la fre-

cuencia de reloj al que trabaja cada DSP [40]. De acuerdo al datasheet de la plata-

forma C672x la frecuencia de operación es de 350MHz, para la C674x la frecuencia

en la que opera es de 456MHz y para la C66xx la frecuencia de reloj es de 1, 25GHz


ALGORITMO MUSIC:

A continuación, se presentan los resultados tanto de los ciclos de reloj como del

tiempo de ejecución del algoritmo MUSIC para las plataformas de DSP’s. Además,

se muestran tablas de las estimaciones y de los requisitos de memoria.

Resultados de los ciclos de reloj y tiempo de ejecución:

La Tabla 4.32 muestra los ciclos de reloj de MUSIC en modo release mientras

que la Tabla 4.33 presenta los resultados del tiempo de ejecución que se calculó con

la frecuencia de reloj de cada DSP.

Tabla 4.32: Ciclos de reloj de MUSIC con 100 observaciones en modo release.

C672x C674x C66xx


MUSICSVD 253577 264319 109611

Máximo 1359892 1317227 494544

Total ciclos de reloj 1613469 1581546 604155

Tabla 4.33: Tiempo de ejecución de MUSIC con 100 observaciones en modorelease.

C672x C674x C66xx

Función Tiempo Tiempo Tiempo

MUSICSVD 0, 72ms 0, 57ms 0, 087ms

Máximo 3, 88ms 2, 88ms 0, 39ms

Total ciclos de reloj 4, 6ms 3, 45ms 0, 477ms


La Tabla 4.34 presenta los resultados de las estimaciones en modo release para

las plataformas C672x, C674x y C66xx.


Tabla 4.34: Resultados de la estimación de MUSIC con 100 observaciones en modorelease.

C672x C674x C66xx

[31, 42, 50, 79, 145] [31, 42, 50, 79, 145] [30, 41, 50, 79, 145]



C674x y C66xx en modo release.



MUSIC.out (KB) 143, 305 137, 381 138, 0792

MUSIC.map (KB) 41, 648 34, 901 34, 772

ALGORITMO DML:

A continuación, se presentan los resultados tanto de los ciclos de reloj como del

tiempo de ejecución del algoritmo DML para las plataformas de DSP’s. Además, se

muestran tablas de las estimaciones y de los requisitos de memoria. Cabe señalar

que los resultados presentados se han llevado a cabo para dos iteraciones.

Resultados de los ciclos de reloj y tiempo de ejecución:

La Tabla 4.36 muestra los ciclos de reloj de MUSIC en modo release mientras

que la Tabla 4.37 presenta los resultados del tiempo de ejecución que se calculó con

la frecuencia de reloj de cada DSP.


Tabla 4.36: Ciclos de reloj de DML con 100 observaciones y dos iteraciones enmodo release.

C672x C674x C66xx


DML 117390882 119353182 21380590

Tabla 4.37: Tiempo de ejecución de DML con 100 observaciones y dos iteracionesen modo release.

C672x C674x C66xx

Función Tiempo Tiempo Tiempo

DML 335, 40ms 261, 74ms 17, 1ms


La Tabla 4.38 presenta los resultados de las estimaciones en modo release para

las plataformas C672x, C674x y C66xx.

Tabla 4.38: Resultados de la estimación de MUSIC con 100 observaciones en modorelease.

C672x C674x C66xx

[30, 79, 145, 40, 50] [30, 79, 145, 40, 50] [30, 79, 145, 40, 50]



C674x y C66xx en modo release.



MUSIC.out (KB) 146, 738 230, 581 136, 812

MUSIC.map (KB) 44, 308 60, 787 34, 665


De acuerdo a los resultados obtenidos en la Tabla 4.37, se determina que el algo-

ritmo DML no cumple con los requisitos referidos al tiempo de ejecución de DoA,

impuestos en la sección 3.3.2. Por lo tanto, los cálculos de tiempo restante referen-

te a la matriz de covarianza se realizaron con el algoritmo MUSIC ya que éste si

satisface la ecuación 3.17.

Consideraciones de tiempo de la matriz de covarianza usando las plataformas

C672x y C674x.

Hasta ahora, se tiene solo el tiempo en que se ejecuta el algoritmo MUSIC. De

esta manera, para calcular el tiempo total de DoA, es necesario conocer el tiempo

de ejecución de la matriz de covarianza y sumarlo con el tiempo de MUSIC.

Ahora bien, antes de calcular el tiempo restante, se debe considerar que parte

del código de la matriz de covarianza, se ha dedicado a la generación de las señales

que arriban al arreglo, ya que no se cuenta con datos reales de entrada. No obstante,

en un ambiente real, las señales no son codificadas, sino que las mismas se adquie-

ren a través de los dipolos de λ/2 y, luego, son muestreadas por los convertidores

A/D. Para cada muestra, se genera un vector de observación cuya dimensión está

en función del número de dipolos.

Se tiene que el número de ciclos de reloj que realmente consume la matriz de co-

varianza, se encuentra en la sección del código responsable de realizar la ecuación

anterior.

for t = 0:ts:(N-1)*ts

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

SECCIÓN DEL CÓDIGO QUE GENERA

EL VECTOR X(t)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%Matriz de covarianza de una observación.

for x=1:L


for xh=1:L

ReRn(x,xh) = RXaux(x)*RXaux(xh)+IXaux(x)*IXaux(xh);

ImRn(x,xh) = IXaux(x)*RXaux(xh)-RXaux(x)*IXaux(xh);

end

end

%Matriz de acumulación.

ReRN = ReRN+ReRn;

ImRN = ImRN+ImRn;

%Parte real e imaginaria de la matriz de covarianza para N

%observaciones.

ReRN = ReRN/N;

ImRN = ImRN/N;

end

En la Tabla 4.40, Tabla 4.41 y Tabla 4.42 se observan, para las tres plataformas,

los ciclos de reloj de la matriz de covarianza para una observación, y los ciclos de

reloj necesarios para dividir XXH entre el número de observaciones.

Tabla 4.40: Tiempo de ejecución para la matriz de covarianza usando la plataformaC672x.

Cálculo de la Matriz de covarianza Ciclos de reloj Tiempo de ejecución

Cálculo de una observación 1303 3, 72µs

Dividir entre N 21542 61,54µs


Tabla 4.41: Tiempo de ejecución para la matriz de covarianza usando la plataformaC674x.



Dividir entre N 22389 49, 908µs

Tabla 4.42: Tiempo de ejecución para la matriz de covarianza usando la plataformaC66xx.



Dividir entre N 2165 1,73µs

Entonces, el tiempo de ejecución de DoA para la plataforma C672x es:

tDoA = 4, 6ms+ (100× 3, 72µs+ 61, 54µs) = 5, 03ms (4.2)

Adicionalmente, el tiempo de ejecución de DoA para la plataforma C674x es:

tDoA = 3, 45ms+ (100× 2, 64µs+ 49, 908µs) = 3, 79ms (4.3)

Por último, el tiempo de ejecución de DoA para la plataforma C66xx es:

tDoA = 0, 477ms+ (100× 0, 89µs+ 1, 73µs) = 0, 57ms (4.4)

Al determinar el tiempo de ejecución de cada función del algoritmo MUSIC, se

obtiene que la función Máximo consume el 77% del tiempo total de ejecución de


DoA, lo que ameritó analizar esta función para realizar las optimizaciones requeri-

das. Una forma de hacerlo fue evitar todo el potencial de MATLAB, esto es, llama-

dos a funciones como conjugados, transpuesta, absoluto y las frecuentes operacio-

nes con números complejos. Luego de modificar la función Máximo, se procedió a

realizar las simulaciones respectivas en CCS con la plataforma C672x, teniendo una

mejora de casi 400000 ciclos de reloj, tal como se oberva en la Tabla 4.43.

Tabla 4.43: Optimización de la función Máximo.

Función Ciclos de reloj Tiempo de ejecución

SVD 253577 0, 72ms

Máximo 992240 2, 83ms

Total 1245817 3, 55ms

Entonces, el tiempo de ejecución de DoA con la optimización, usando la plata-

forma C672x es:

tDoA = 3, 55ms+ (100× 3, 72µs+ 61, 54µs) = 3, 98ms (4.5)

Sin embargo, aunque se logró una disminución en el tiempo de ejecución, los

máximos se encuentran con un nivel menor de potencia. En la Figura 4.24 se expone

lo descrito.


30 42 50 79 145−20

−15

−10

−5

0

5

10

15

20

θ°

PM

US

IC (

dB)

Figura 4.24: Máximos del espectro MUSIC con la modificación de la funciónMáximo.

De esta forma, un aumento del rendimiento conllevó a una disminución en la

potencia de los máximos por lo que a menor tiempo de ejecución, menor es la po-

tencia en las estimaciones.

4.4. CREACIÓN DE UN PROCEDIMIENTO GENERAL.

A continuación, se particulariza usando la función MATRIZDECOVARIANZA.m, el

procedimiento seguido para la simulación de algoritmos en procesadores digita-

les de señal, desde que el mismo es concebido hasta que son introducidos en los

entornos de desarrollo integrado para DSP’s.

Una vez analizado el problema matemático en cuestión, referente a la matriz de

covarianza, se procede a codificarlo en MATLAB como si se tratara de cualquier

función. Una vez hecho esto, y luego de comparar los resultados con los reporta-

dos en [7] bajo los mismos parámetros de las variables de entrada comprobando el

correcto funcionamiento de la misma, se procede a modificar la función con las res-

tricciones interpuestas por Embedded MATLAB. En el siguiente apartado se habla

de ello.


4.4.1. Modificación del código en MATLAB con las restricciones inter-

puestas por Embedded MATLAB.

A continuación, se presenta el código de la MATRIZDECOVARIANZA.m con las

restricciones que impone Embedded MATLAB. Inicialmente, se agregó el pragma

%#eml según lo reportado en la sección 3.4. Luego, se utilizó la función assert

para especificar la clase, tamaño y complejidad de las entradas de la función [29].

function [ReRN, ImRN] = MATRIZDECOVARIANZA(DeltF,theta,SNR,d,L,N)%#eml

%Propiedades de las variables de entradas.

%Clase de las variables: Punto flotante de simple presicion.

assert(isa(DeltF, 'single'))

assert(isa(SNR,'single'))

assert(isa(L, 'single'))

assert(isa(N, 'single'))

assert(isa(theta,'single'))

assert(isa(d, 'single'))

%Tamaño de las variables.

assert ( all ( size (DeltF) == (1) ) )

assert ( all ( size (SNR) == (1) ) )

assert ( all ( size (d) == (1) ) )

assert ( all ( size (L) == (1) ) )

assert ( all ( size (N) == (1) ) )

assert ( all ( size(theta) == [1 3] ) )

%Declaracion e inicializacion de las variables.

ReRN = single(zeros(4,4)); %Parte real e imaginaria de

ImRN = single(zeros(4,4)); %la matriz de covarianza.

P = int8(length(theta)); %Numero de senhales.

f = single((DeltF*(0:2)+DeltF)/3); %Frecuencia de senhales banda base.

fp = single(850e6 - f); %Frecuencia de la portadora.

fd = single(850e6); %Frecuencia del dipolo.

W = 2*pi*f; %Vector de frecuencia angular de las senhales.

ts = single(1/(3*50e6)); %Vector del tiempo de cada muestra.


t = single(0); %Incializacion del tiempo.

while t <= (N-1)*ts

%Las variables RXaux y IXaux son variables auxiliares

RXaux = single(zeros(4,1));

IXaux = single(zeros(4,1));

ReRn = single(zeros(4,4));

ImRn = single(zeros(4,4));

for l=1:L

for i = int8(1:P)

RXaux(l) = RXaux(l)+ cos(2*pi*(50e6-f(i))*t)*cos(pi*(l-1)*...

cos((pi/180)*theta(i))*((fp(i))/fd));

IXaux(l) = IXaux(l)+ cos(2*pi*(50e6-f(i))*t)*sin(pi*(l-1)*...

cos((pi/180)*theta(i))*((fp(i))/fd));

end

end

%Ruido AWGN.

RXaux = awgn(RXaux,SNR);

IXaux = awgn(IXaux,SNR);

%Hermitiano

for x=1:L

for xh=1:L



end

end

%Matriz de acumulacion.

ReRN = ReRN+ReRn;

ImRN = ImRN+ImRn;


%Incremento de tiempo de muestreo.

t = t + ts;

end

%Matriz de covarianza

ReRN = ReRN/N;

ImRN = ImRN/N;

end

Cabe señalar que MATLAB no necesita declaración de variables, no obstante,

Embedded MATLAB define la clase, tamaño y complejidad de las mismas, por de-

fecto asume que toda variable es de clase double y de complejidad real, por lo tanto

las variables fueron modificadas en su declaración de acuerdo a los propósitos de

nuestra aplicación.

4.4.2. Generación de código fuente C.

Luego de lo anteriormente descrito, se procedió a generar la función C-MEX

para verificar desde el entorno de MATLAB, el correcto funcionamiento del código

C generado. Para ello, se introdujo el comando de la primera línea de la Figura 4.25,

donde se observa un mensaje reportando el error de compilación.

??? Error using ==> emlc

??? The function 'awgn' is not supported by Embedded MATLAB for code generation. See the documentation for eml.extrinsic to learn how you can use this function in simulation.

Error in ==> MATRIZDECOVARIANZA Line: 44 Column: 10

Compilation failed: Open error report.

>> emlc -o MATRIZDECOVARIANZAMEX -report MATRIZDECOVARIANZA.m

Figura 4.25: Mensaje de error de compilación.


Seguidamente, se abre este reporte, y se muestra la ventana de la Figura 4.26

indicando la línea que genera el error. En la descripción se señala que la función

awgn no es soportada por Embedded MATLAB.

Figura 4.26: Reporte de error de compilación.

Ante esto, se presentaron las dos posibilidades2 señaladas en la sección 3.4.2. Sin

embargo, a modo ilustrativo, para efectos del presente procedimiento, la función

awgn se eliminó del script y se generaró nuevamente el código C-MEX. Luego de

introducir nuevamente el comando, se presentó el reporte de compilación satisfac-

torio tal como se observa en la Figura 4.27. Por otro lado, en el directorio de trabajo

se creó la carpeta emcprj, dentro de la cual se encuentra la carpeta mexfcn donde

se guardan las funciones C-MEX generadas, lo que indica que la función C-MEX ha

sido generada de manera exitosa.

2Para las simulaciones de MUSIC y DML se introdujo ruido AWGN mediante codificación manual(ver sección 3.2).


>> emlc -o MATRIZDECOVARIANZAMEX -report MATRIZDECOVARIANZA.m

Compilation successful: Open compilation report.

Figura 4.27: Mensaje de reporte de compilación satisfactorio.

Para comprobar que la función C-MEX arroja los mismos resultados que la fun-

ción original de MATLAB, se introdujeron como parámetros de entrada los siguien-

tes valores:

DeltF = single(5e6)

theta = single([50 75 125])

SNR = single(0)

d = single(0,5)

L = single(4)

N = single(500)

Puesto que la función awgn fue eliminada para efectos de este procedimiento, el

valor de SNR es indiferente.

De esta manera, ejecutando la función original se obtienen los valores de la parte

real e imaginaria de la matriz de covarianza que se muestran en la Figura 4.28.

En este sentido, para comprobar que la función C-MEX original arroja los mis-

mos resultados, la misma se llama tal como se muestra en la Figura 4.29. De esta

forma, se comprueba el correcto funcionamiento de la función C-MEX.

Una vez verificado el código C desde MATLAB, se procede a generar el código

fuente C libre de plataforma mediante Real-Time Workshop. Esto se hace introdu-

ciendo el comando de la primera línea de la Figura 4.30.


>> [ReRN, ImRN] = MATRIZDECOVARIANZA(DeltF,theta,SNR,d,L,N)

ReRN =

1.4978 0.0151 -0.7942 0.4221

0.0151 1.4956 0.0320 -0.7953

-0.7942 0.0320 1.5041 0.0069

0.4221 -0.7953 0.0069 1.5090

ImRN =

0 -0.3213 -0.3180 -0.6009

0.3213 0 -0.3260 -0.3286

0.3180 0.3260 0 -0.3332

0.6009 0.3286 0.3332 0

Figura 4.28: Resultados de la matriz de covarianza usando la función original deMATLAB.

>> [ReRN, ImRN] = MATRIZDECOVARIANZAMEX(DeltF,theta,SNR,d,L,N)

ReRN =

1.4978 0.0151 -0.7942 0.4221

0.0151 1.4956 0.0320 -0.7953

-0.7942 0.0320 1.5041 0.0069

0.4221 -0.7953 0.0069 1.5090

ImRN =

0 -0.3213 -0.3180 -0.6009

0.3213 0 -0.3260 -0.3286

0.3180 0.3260 0 -0.3332

0.6009 0.3286 0.3332 0

Figura 4.29: Resultados de la matriz de covarianza usando la función C-MEX.

>> emlc -c -T RTW -report MATRIZDECOVARIANZA.m

Compilation successful: Open compilation report.

Figura 4.30: Generación de código fuente C libre de plataforma mediante RTW.

El mensaje da una compilación satisfactoria que apunta a un reporte de com-

pilación. En el directorio de trabajo se crea la carpeta emcprj, y dentro ésta se en-

cuentra la carpeta rtwlib donde se guardan las funciones C generadas junto con


sus archivos de cabecera.

Figura 4.31: Reporte de compilación de la generación de código C mediante RTW.

Por su parte, en la Figura 4.31 se observa el reporte de compilación. De esta

manera, se ha generado la función MATRIZDECOVARIANZA.c la cual es una función

void. Es menester mencionar algunos de los archivos necesarios para su genera-

ción, los cuales son:

rt_GetInf.c: Es una función de Real-Time Workshop que contiene la defini-

ción de las funciones que trabajan con variables no finitas como Inf y Minu-

sInf.

rt_GetNaN.c: Es una función de RTW que contiene la definición de las fun-

ciones que trabajan con variables no finitas como NaN.

rt_nonfinite.c: Es una función de RTW para inicializar variables no finitas

como Inf, NaN y –Inf.

rtwtypes.h: Es un fichero de cabecera que define tipos genéricos (typedef).


Cabe resaltar que la conversión automática que lleva a cabo Real-Time Works-

hop, define los tipos de datos en todos los casos. En este sentido, a partir del archi-

vo de cabecera denominado rtwtypes.h que se genera durante la compilación, se

construye la Tabla 4.44 donde se muestra cada una de las equivalencias.

Tabla 4.44: Equivalencias de los tipos de variables básicas en MATLAB, lenguajeC y Real-Time Workshop.

MATLAB lenguaje C Real-Time Workshopdouble double real_Tsingle float real32_Tint32 long long int int32_Tint16 long int int16_Tint8 short int int8_T

uint32 unsigned long long int uint32_Tuint16 unsigned long int uint16_Tuint8 unsigned short int uint8_T

int int int_Tuint unsigned int uint_T

boolean - boolean_Tchar char char_T

4.4.3. Depuración y validación del código C resultante.

Luego de la conversión automática de código MATLAB a lenguaje C, se depuró

el código C generado con el compilador Code::Blocks, con la finalidad de obtener

un código libre de plataforma, de modo que pueda ser compilado por diversas he-

rramientas según el entorno en el que se desee implementar. Para este trabajo se uso

el IDE CCS. Adicionalmente, este paso permite la optimización en mayor medida

del código en caso de ser necesario. El código generado por RTW resulta bastan-

te óptimo para aplicaciones en tiempo real, no obstante, siempre es bueno realizar

una verificación del mismo. Por ello, se ha considerado conveniente examinar si el

código necesita una mayor optimización y cuáles son los aspectos de la aplicación

que es preciso optimizar (velocidad de ejecución, ocupación en memoria, precisión)

pues depende de cada aplicación concreta.


Luego de verificar y depurar la función MATRIZDECOVARIANZA.c en el entorno

de Code::Blocks, se procedió a validar el código con los mismos parámetros que

generaron los resultados anteriores, esto se muestra en la Figura 4.32.

Figura 4.32: Validación de los resultados de la matriz de covarianza en el IDECode::Blocks.

4.4.4. Simulación en Code Composer Studio (CCS).

En el siguiente procedimiento se explican los pasos básicos que debe seguirse,

para simular código generado por RTW, en las plataformas de los DSP’s que ofrece

Texas Intruments (TI). CCS es un software muy didáctico que, al ser acompañado

con la gran variedad de documentación técnica y tutoriales disponibles en el sitio

web de TI, su aprendizaje resulta muy amigable y rápido. Cabe señalar que Texas

Intruments, dispone de una versión gratuita de CCS cuya licencia es para un tiempo

limitado de 90 días [41] [42] [43].

Una vez que se obtiene el código fuente C generado por RTW, y luego de haber

depurardo y validado el mismo en Code::Blocks, se inició un nuevo proyecto en

CCS donde se simuló el algoritmo en la plataforma que se adecúa a la aplicación

de interés. Al igual que en cualquier software de programación, para acceder a un

nuevo proyecto, se debe seguir la siguiente secuencia expuesta en la Figura 4.33.


Figura 4.33: Secuencia inicial para crear un nuevo proyecto

Al seleccionar el icono CCS project, aparecerá una ventana con las opciones

de configuración del proyecto, como se observa en la Figura 4.34.

En esta ventana se tiene lo siguiente:

Nombre del proyecto.

Tipo de archivo de salida. Por defecto, se genera un ejecutable del progra-

ma con el nombre del proyecto (New projec.Out), siendo éste, el que será

cargado a la memoria del DSP.

Configuraciones del DSP. En primer lugar, se debe definir la familia del DSP,

y luego, la variante de esa familia. De esta forma, el proyecto será desarro-

llado sobre las características de una tarjeta específica. Por ejemplo, para tra-

bajar sobre la tarjeta TMS320C6727, se debe elegir la familia C6000, variante

TMS320C6727.


Figura 4.34: Configuraciones del proyecto

Configuraciones avanzadas. En esta etapa, se tiene la opción de elegir el

Device endianness, el cual puede ser little o big. Con esta opción, se in-

dica el orden en que son almacenados los datos en la memoria [44]. En la

ventana de Linker command file, se elige el mapa de memoria que utiliza

el proyecto; CCS contiene por defecto una serie de archivos (.cmd) para ca-

da tarjeta. Sin embargo, las configuraciones de memoria de estos archivos no

siempre son compatibles con las aplicaciones del proyecto en cuestión, por lo

que deben ser modificado. Más adelante se explica como construir un Linker

command file.

Luego de haber elegido las característica del proyecto, y dado click a Finish,

se abrirá la ventana del entorno de CCS. En este sentido, el proyecto no contiene


archivos fuentes, solo el entorno de main y los archivos de cabeceras que contiene la

familia C6000. Por lo tanto, antes de añadir los archivos del código, se recomienda

crear una carpeta donde estén todos los archivos necesario para compilar el código

en Code::Blocks. No obstante, para efectos de este procedimiento, se ha creado una

carpeta con el nombre MatrizDeCovarianza donde se encuentra el código usado a

lo largo de este procedimiento. En efecto, para añadir todos los archivos que están

en la carpeta, se debe seleccionar el nombre del proyecto, luego presionar click

derecho y seleccionar la opción Add files, tal como se observa en la Figura 4.35.

Figura 4.35: Opción para añadir archivos al proyecto


De esta forma, todos los archivos del algoritmo de la matriz de covarianza están

dentro del proyecto New project. Se debe notar que en el proyecto no se encuentra

el archivo Linker Command file (.cmd). Este archivo es necesario para generar

el código ejecutable, por lo que a continuación se explica como configurar el linker

command file.

Un linker command file puede ser construido tomando como referencia el

archivo .cmd perteneciente a la tarjeta seleccionada en el proyecto, o bien con el

resumen de memoria que ofrece el datasheet. En la Figura 4.36, se tiene un archivo

.cmd que ha sido configurado para la tarjeta TMS320C6727.

Figura 4.36: Linker Command File para el TMS320C6727

La interpretación de la Figura 4.36, consiste en que la tarjeta está compuesta por

tres memorias. La primera se encuentra dentro del núcleo (256KB Internal RAM)

y las otras dos son memorias externas (128MB External SDRAM y 128MB External


Async/Flash) que permiten un mayor almacenamiento pero, generalmente, traba-

jan a una frecuencia de reloj inferior a la de la memoria interna. Por otro lado, se

tiene que la memoria se ha dividido en secciones, las cuales se describen en la Fi-

gura 4.37.

Figura 4.37: Nombre de las secciones de memoria.

Por otro lado, aparte de estas secciones, es posible definir nuevas secciones que

serán almacenadas en una determinada memoria, con el propósito de ordenar a

conveniencia el programa que se cargará luego al DSP. Entonces, si se tiene un có-

digo que está formado por varias funciones, cada una de ellas se puede alojar bien

sea en la memoria interna o externa del DSP.

Para alojar una sección del programa, por ejemplo la sección main, se debe co-

locar el siguiente pragma, justo antes que comience la función.


pragma CODE_SECTION(main,".main")

Luego, se localiza .cmd de la aplicación y, en la parte de SECTIONS, se introduce

el siguiente comando.

.main < IRAM

Con esta serie de instrucciones, lo que se hace es almacenar la sección del có-

digo main en la memoria RAM interna del DSP. Si se desea especificar aún más, la

localización de main, se puede usar el siguiente comando:

.main < MAIN

Donde MAIN se ha definido en MEMORY como: MAIN : o = 0x10000000 l =

0x00000400. Esto se hizo con las secciones del código de la matriz de covarianza

usado a lo largo de este procedimiento.

Hasta ahora, el proyecto cuenta con los archivos de código fuente C y sus res-

pectivos archivos de cabecera, así como el archivo de configuración de memoria

(.cmd). Con estos archivos, se pudo compilar el programa para generar código

ensamblador ejecutable, apto para ser cargado en la memoria del DSP que se ha

elegido para el proyecto [8].

Luego de haber compilado el programa y verificar que se ha construido el ar-

chivo de salida (New project.Out), el próximo paso es depurar el código eje-

cutable. Para ello, se debe crear un nuevo archivo que tiene por nombre: target

configuration file (.ccxml).

En este archivo se configura el target, el cual puede ser un software que simula

la plataforma donde se está realizando el proyecto o un emulador que será conec-

tado a la tarjeta. En nuestro caso, el target se configura para trabajar en modo de

simulación. Para abrir dicho archivo, se sigue la secuencia ilustrada en la Figura

4.38.


Figura 4.38: Configuración del simulador de Texas Instruments.

Cuando se abre el target configuration file, se debe identificar la ventana

conection y seleccionar la opción Texas Instruments Simulator. Luego, en la

ventana Borad or Device se selecciona el simulador que es compatible con la tar-

jeta que se ha elegido en el proyecto y, además, el tipo de simulación que se desea

realizar.

Figura 4.39: Simulador de Texas instruments.


Tabla 4.45: Niveles de simulación dispuestas en Texas Instruments

Nivel de simulación Tipo de simulador a usarNivel 1. Se comprueba la funciona-lidad del CPU al ejecutar el algorit-mo y algun pereférico puede ser si-mualdo si se amerita

CPU Functional simulator

Nivel 2. Se realizan pruebas sobre elrendimiento del CPU, se analiza eltamaño del código y se utilizan lasherramientas de optimización

CPU Cycle-accurate simulator

Nivel 3. Simula los periféricos, usala DMA para la transferencia de da-tos entre el programa y los periféri-cos y

Device Functional simulator

Nivel 4. Permite una simulación delhardware y usa herramientas deoptimización en DMA y la CACHE

Device Cycle-accurate Simulator

Existen varios niveles de simulación los cuales se presentan en la Tabla 4.45. En

esta investigación, solo se ha llegado al nivel 2, ya que las simulaciones se hicieron

sobre CPU Cycle-accurate simulator, utilizando un sistema de memoria plana.

En este nivel se pueden realizar las mediciones del rendimiento del CPU del DSP,

calculando el tamaño de los códigos y los ciclos de reloj que se necesita para ejecutar

cada aplicación.

Luego de haber explicado los niveles de simulación, se continúa con la ejecu-

ción de la matriz de covarianza, donde se ha usado el simulador C672x CPU Cycle

Accurate Simulator, Litter Endian. Para calcular los ciclos de reloj del algo-

ritmo, se debe habilitar la función Clock que, en la versión 5.3, la forma de hacerlo

es seleccionando Run→ clock→ Enable [40].

Luego de haber ejecutado el algoritmo de la matriz de covarianza, se comprobó

que los resultados coinciden con los obtenidos desde MATLAB. Por otro lado, en

la carpeta de Debug, se dispone de un archivo cuya extensión es .map, en la cual

se observa el consumo de memoria del algoritmo y el estado de todos los archivos

utilizados.


Figura 4.40: Interfaz del Simulador donde se observan la función Clock y la ven-tana de variables

Finalmente, luego de haber realizado la simulación en modo Debug y de deter-

minar que, usando las configuraciones anteriores, el algoritmo puede ser introdu-

cido en el hardware del DSP, una última simulación en modo Release se hizo para

observar el rendimiento del programa terminado y listo para la implementación.

Capítulo V

Conclusiones y recomendaciones

5.1. Conclusiones.

El reto de los sistemas de comunicaciones móviles, es incrementar el número de

usuarios en servicios de voz y datos. Optar por los sistemas de Antenas Inteligen-

tes es una de las soluciones más eficientes pues tiene la ventaja de incrementar la

capacidad del sistema en términos del flujo de datos, reducir la interferencia entre

usuarios, así como un aumento de cobertura en los sistemas de tercera generación

(3G), debido a la separación espacial existente entre los usuarios.

La estimación de la Dirección de Arribo (DoA) es una de las etapas de los sis-

temas de Antenas Inteligentes y fue la que se desarrolló en esta investigación. Por

lo tanto, en este trabajo se seleccionó dos algoritmos DoA. El primero de ellos, MU-

SIC, para que representara a los métodos basado en subespacio y, el segundo fue

DML para representar a los métodos paramétricos. Así mismo, se tomó un Arreglo

Lineal Uniforme (ULA) de una antena sectorizada que cubre 120◦ grados espacia-

les. El número de dipolos usado fue de diez, con una separación de 0,5λ entre dos

elementos consecutivos.

MUSIC y DML fueron simulados en MATLAB, donde se corroboró las ventajas

y desventajas de cada uno, descritos en el marco teórico. Ciertamente, MUSIC es un

algoritmo que realiza estimaciones precisas en condiciones favorables, esto es, un

129

130 Capítulo V. Conclusiones y recomendaciones

considerable número de muestras, así como una alta relación señal a ruido. Por otro

lado, este algoritmo es sensitivo a la frecuencia ya que las frecuencias de las ondas

planas que arriban al arreglo deben estar separadas para evitar la correlación de

las señales pero al mismo tiempo debe estar en la cercanía de la frecuencia nomi-

nal del dipolo. Para efectos de esta investigación, las portadoras estaban separadas

1MHz. En la prueba de fuentes cercanas angularmente se comprobó que, con 1000

observaciones, MUSIC es capaz de alcanzar una resolución de 5◦. En general, con

un número de 100 observaciones y un SNR = 30dB, MUSIC es capaz de realizar

estimaciones precisas.

Por otra parte, DML es un algoritmo mucho más preciso que MUSIC aunque

se necesita un cierto número de iteraciones para que sus estimaciones converjan a

los valores reales. Por ser un estimador insesgado, en promedio las estimaciones

tendían a los valores reales. No obstante, en condiciones desfavorables con bajo

SNR y bajo número de muestras al mismo tiempo, se produjeron estimaciones con

error. Esto se pudo corroborar al calcular la media y la varianza de las estimaciones,

en cuyo caso el valor promedio de las estimaciones se alejaba de los valores reales

y la varianza de los datos era elevada. Por otro lado, DML es menos sensitivo a la

frecuencia que MUSIC ya que estima las posiciones sin antes calcular un espectro.

Antes de evaluar la respuesta computacional del DSP, se realizó una estima-

ción del tiempo en que las observaciones que utiliza la matriz de covarianza deben

actualizarse. Para ello, se tuvo en cuenta un usuario que presenta una movilidad

crítica y, de esta forma, se determinó el tiempo ante el cual deben actualizarse las

muestras usadas en la matriz de covarianza. Aquí, se concluyó que el tiempo de

ejecución de DoA debe ser mucho menor al tiempo de refrescamiento.

Con estas referencias se iniciaron las simulaciones en el software CCS, donde

se pudo probar el rendimiento de núcleo del DSP, haciendo uso de los simuladores

que se encuentran disponibles para las plataformas que permiten datos de punto

flotante de simple precisión, los cuales fueron C672x y C674x. De esta manera, se

alcanzó el nivel 2 de simulación, bajo un sistema de memoria plana que tenía una

capacidad máxima de 64MB.

Capítulo V. Conclusiones y recomendaciones 131

El éxito de la simulación dependió de la forma en que las secciones del código

fueron almacenados en la memoria. De manera que, el linker command file, fue

configurado para la organización en memoria de dicho código. Al calcular los ciclos

de reloj se conoció que los tiempos de ejecución para MUSIC satisficieron el tiempo

de refrescamiento impuesto en la sección 3.3.2.

La ejecución de DoA en las plataformas C672x, C674x resultó exitosa, no obs-

tante, se debe tener presente que una etapa de BF debe ser implementada y que,

generalmente, se hace en el mismo DSP usado para la DoA. De esta manera, esta

situación agudizará los requerimiento de carga computacional que debe realizar el

DSP. Por tal motivo, una última simulación se realizó sobre la plataforma C66xx,

para determinar el tiempo de ejecución de DoA, el cual disminuyó considerable-

mente, esta plataforma cuenta con una frecuencia de reloj de 1,25GHz y pueden

realizar 22GFLOPS. Con esta tarjeta, se abre una ventana para futuras investiga-

ciones que se aboquen a la etapa de BF.

Por otro lado, la generación de código fuente C a partir de MATLAB, sin lugar

a dudas, es una herramienta útil a la hora de elaborar códigos eficientes para sis-

temas embebidos. Con las funciones C-MEX se pudo ejecutar, desde MATLAB, los

algoritmos .c para constatar el buen funcionamiento de los códigos. Así, se verifi-

có que al traducir el código de MATLAB a C, el mismo se comportaba de la misma

manera, por lo que la función C-MEX realizaba la misma tarea que la función ori-

ginal de MATLAB. Luego de ello, Real-Time Workshop permitió la generación de

cada código en lenguaje C, libre de plataforma y optimizado para aplicaciones em-

bebidas, siendo Code::Blocks la herramienta utilizada para realizar la depuración

de los códigos para que pudieran ser cargados en Code Composer Studio. De esta

forma, con la traducción automática de algoritmos de MATLAB a C, se dedicó mu-

cho menos tiempo a la escritura y depuración de MUSIC y DML, y más tiempo en

el desarrollo y sintonización de los algoritmos. Esto se pudo corroborar al observar

que las funciones que resultaron de la traducción, como svd, pinv, arrojaban un

código en C con un número considerable de líneas de códigos.

Por último, al notar la importancia que tienen las herramientas que se usaron,

un procedimiento general fue creado, comenzando desde la conceptualización de

132 Capítulo V. Conclusiones y recomendaciones

cualquier algoritmo, diseñado para aplicaciones embebidas, hasta que los mismos

son introducidos en CCS.

5.2. Recomendaciones.

Generalizar el problema de estimación para resolver situaciones con fuentes

ubicadas en campo cercano, y señales que estén sometidas a desvanecimiento por

multitrayectoria.

Optimizar, en la medida de lo posible, la función Máximo usada para MUSIC pa-

ra obtener un mayor rendimiento sin perder potencia en el cálculo de los máximos.

De esta manera, se reducirían los ciclos de reloj lo que ocasionaría una disminución

en el tiempo de ejecución de DoA.

Alcanzar los niveles 3 y 4 de simulación, para incluir periféricos y lograr una

mayor optimización.

Continuar con la etapa de BF para que ésta se integre a la DoA en un mismo

DSP.

Lograr la implementación de los algoritmos MUSIC y DML en las plataformas

C672x, C674x y C66xx.

Apéndice A

Códigos en Embedded MATLAB

de algoritmos DoA.

A continuación, se presentan los códigos usados en este trabajo. Los mismos

consideran las restricciones impuestas por Embedded MATLAB.

1.1. MATRIZ DE COVARIANZA.

function [ReRN,ImRN] = MATRIZDECOVARIANZA(DeltF,theta,SNR,d,L,N)%#eml

% Propiedades de las variables de entradas

% Clase de las variables: Punto flotante de simple precisión.

assert(isa(DeltF, 'single'))

assert(isa(SNR,'single'))

assert(isa(L, 'single'))

assert(isa(N, 'single'))

assert(isa(theta,'single'))

assert(isa(d, 'single'))

% Tamaño de las variables.

133

134 Apéndice A. Códigos en Embedded MATLAB de algoritmos DoA.

assert ( all ( size (DeltF) == (1) ) )


assert ( all ( size (d) == (1) ) )

assert ( all ( size (L) == (1) ) )

assert ( all ( size (N) == (1) ) )

assert ( all ( size(theta) == [1 5] ) )

% Declaración e inicialización de la matriz de covarianza; parte real e

% imaginaria.

ReRN = single(zeros(10,10));

ImRN = single(zeros(10,10));

% Número de señales.

P = single(length(theta));

% Frecuencia de la portadora;

f = single(DeltF*(0:(P-1)));

fp = single(850e6 - f);

% Frecuencia del dipolo.

fd = single(850e6);

% tiempo de cada muestra.

ts = single(1/(3*50e6));

% Generación de la matriz de covarianza para una muestra.

for t = 0:ts:(N-1)*ts

% Las variables RXaux y IXaux son variables auxiliares. Antes de que se

% genere un nuevo vector, su valor debe ser cero.

RXaux = single(zeros(10,1));

Apéndice A. Códigos en Embedded MATLAB de algoritmos DoA. 135

IXaux = single(zeros(10,1));

ReRn = single(zeros(10,10));

ImRn = single(zeros(10,10));

% Generación del vector de una muestra.

for l=1:10

for i = int8(1:P)

RXaux(l) = RXaux(l)+ cos(2*pi*10000*t)*cos(2*pi*(50e6-f(i))*t)*...

cos(pi*(l-1)*cos((pi/180)*theta(i))*((fp(i))/fd));

IXaux(l) = IXaux(l)+ cos(2*pi*10000*t)*cos(2*pi*(50e6-f(i))*t)*...

sin(pi*(l-1)*cos((pi/180)*theta(i))*((fp(i))/fd));

end

end

% Se añade ruido AWGN al vector de observación con la función Rawgn.

RXaux = Rawgn(RXaux,SNR);

IXaux = Rawgn(IXaux,SNR);

% Para calcular la matriz de covarianza de cada observación,

% se necesita el hermitiano del vector. Solo se conjugará

% la parte imaginaria, ya que la operación de transponer el

% vector puede ser controlado por el programador.

% Conjugar X, equivale a multiplicar por menos uno (-1)

% la parte imaginaria

% Matriz de covarianza de una observación.

for x=1:L

for xh=1:L




end

end

% Matriz de acumulación.

ReRN = ReRN+ReRn;

ImRN = ImRN+ImRn;

end

ReRN = ReRN/N;

ImRN = ImRN/N;

end

1.2. RUIDO AWGN.

function [xg] = Rawgn(x,SNR)%#eml

%%%%% clase de las varibles %%%%%%%%%

assert(isa(x, 'single')) %Vector de observación

assert(isa(SNR, 'single')) % Relación señal a ruido

assert ( all ( size(x) == [10 1] ) )


%%%%% Declaración de las varibles %%%%%%%%%

sgmaS = single(zeros(1,1));

dstd = single(zeros(1,1));

Ruido = single(zeros(10,1));

xg = single(zeros(10,1));

sgmaS = single(var(x,1)); % Varianza de x

dstd = single(sqrt(sgmaS/(10^(SNR/10)))); % Desviación estándar

Ruido = single(dstd*randn(10,1)); % Ruido AWGN

xg = x + Ruido; % Añade ruido al vector x


end

1.3. ALGORITMO MUSIC.

1.3.1. Función SVD.

function [E] = SVD(ReRN,ImRN)%#eml

%--------------------------------------

assert( isa (ReRN, 'single'))

assert( isa (ImRN, 'single'))

assert ( all ( size(ReRN) == [10 10] ) )

assert ( all ( size(ImRN) == [10 10] ) )

% SVD

% variable de salida

E = complex(single(zeros(10,10))); % Matriz con los

% vectores propios de Rxx.

Rxx = complex(single(zeros(10,10)));

Rxx = ReRN + 1i*ImRN;

[E,V] = svd(Rxx);

end

1.3.2. FUNCION MAXIMO

function [POSICION_SENAL,NIVEL_SENAL] = MAXIMO(E)%#eml

assert( isa (E, 'single'))


assert ( all ( size(E) == [10 10] ) )

assert (~isreal((E)))

RePn = single(zeros(10,10));

ImPn = single(zeros(10,10));

Pn = complex(single(zeros(10,5)));

% En la siguiente sección de la función

% se construye Pn en su parte real

% e imaginaria, Pn es la proyección ortogonal

% complementaria de Ps, siendo

% Ps la matriz de proyección del subespacio de señal.

for i = 1:10

for j = 1:10

for l = 1:5

RePn(i,j) = RePn(i,j) + real(E(i,5+l))*...

real(E(j,5+l)) + imag(E(i,5+l))*imag(E(j,5+l));

ImPn(i,j) = ImPn(i,j) + imag(E(i,5+l))*...

real(E(j,5+l)) - real(E(i,5+l))*imag(E(j,5+l));

end

end

end

Pn = RePn + 1i*ImPn;

THETA = complex(single(zeros(1,10)));

k = single(1);

g = single(1);

z = single(1);

x = single(1);

SMUSIC = single(zeros(1,3));


NIVEL_SENAL = single(zeros(1,9));

POSICION_SENAL = single(zeros(1,9));

for theta=29:1:151

for l = 1:10

THETA(l) = cos(pi*(l-1)*cos((pi/180)*theta))+...

1i*sin(pi*(l-1)*cos((pi/180)*theta));

end

SMUSIC(k) = single(-10*log10(abs(conj(THETA)*(Pn)*((THETA).'))));

if theta > 30

if theta == 31

g = single(2); z = single(1);

end

if SMUSIC(g) > SMUSIC(z) && SMUSIC(g) > SMUSIC(k)

NIVEL_SENAL(x) = SMUSIC(g);

aux = z ; z = g ; g = k ; k = aux ;

POSICION_SENAL (x) = theta - 1 ;

x = x+1; SMUSIC(k) = 0;

else

aux = z ; z = g ; g = k ; k = aux ;

SMUSIC(k) = 0;

end

else

k = k +1;

end


end

end

1.4. DML

function [THETADML] = DML(ReRN,ImRN,iteracion)%#eml

assert(isa(ReRN, 'single'))

assert(isa(ImRN, 'single'))

assert(isa(iteracion, 'single'))

assert ( all ( size (ReRN) == [10 10] ) )

assert ( all ( size (ImRN) == [10 10] ) )

assert ( all ( size (iteracion) == (1) ) )

Rxx = ReRN + 1i*ImRN;

D = complex(single(zeros(10,5)));

PiA = complex(single(zeros(10,10)));

Valor = complex(single(zeros(1,1)));

THETADML = single(zeros(1,9));

n = 1;

a1 = single(zeros(1,1));

while n <= iteracion

for i = 1:5

menor = single(100000);

for pasos = single(30:1:150)


for l = 1:10

D(l,i) = cos(pi*(l-1)*cos((pi/180)*pasos))+...

1i*sin(pi*(l-1)*cos((pi/180)*pasos));

end

PiA = D*pinv(D);

Proy = eye(size(PiA)) - PiA;

Valor = (trace(Proy*(ReRN + 1i*ImRN)));

if abs(Valor) < menor

menor = abs(Valor);

a1 = pasos;

end

end

THETADML(i) = a1;

for l = 1:10

D(l,i) = cos(pi*(l-1)*cos((pi/180)*a1))+...

1i*sin(pi*(l-1)*cos((pi/180)*a1));

end

end

n = n + 1 ;

end

end

Apéndice B

DoA Y BF en un solo DSP.

En la sección 2.1.3.2 se dio a conocer que una antena de haz adaptativo contiene

una unidad de DSP para realizar la etapa de DoA y BF. No obstante, el alcance de

esta investigación se limitó a la etapa de DoA, donde se evaluó la respuesta compu-

tacional de los DSP’s utilizando los algoritmos MUSIC y DML, determinando que

solo MUSIC cumple con la restricción de tiempo establecido en la sección 3.3.2.

Ahora, se debe evaluar el rendimiento del DSP cuando se ejecuta DoA y BF. Por tal

motivo, en esta sección se establecen los parámetros de interés que se deben tener

en cuenta al momento de ejecutar la Conformación de Haz.

2.1. Conformación de Haz (BF-Beamforming).

La Conformación de Haz se puede realizar de forma analógica (La unidad de BF

se encuentra antes que las señales sean muestreadas por los A/D) o bien de forma

digital (La unidad de BF se encuentra después que las señales son muestreadas

por los A/D). Un esquema de la Conformación de Haz analógico se muestra en la

Figura 2.1.

De esta manera, todas las señales provenientes de cada sensor son multiplicadas

por los pesosWl y retrasadas τl(Φ). Posteriormente, se realiza la superposición de

143

144 Apéndice B. DoA Y BF en un solo DSP.

Figura 2.1: Estructura de BF [3].

la misma para conformar el haz. En la ecuación 2.1 se muestra la señal de salida de

la etapa de BF.

y(t) =

L∑l=1

Wlxl(t− τl(Φ)) (2.1)

Por lo tanto, el retraso τl(Φ) en cada elemento, se ajusta de modo que las se-

ñales censadas por los dipolo, las cuales provienen de la dirección donde se desea

colocar el haz, se encuentren alineadas o en fase. Después, se ajustan los pesos para

posicionar el haz en la dirección que generó la alineación de las señales [3].

2.1.1. Conformación de Haz digital (DBF-Digital Beamforming).

La Conformación de haz digital (DBF-Digital Beamforming) se puede ejecutar en

la misma unidad de DSP donde se ejecuta DoA. En este sentido, en DBF las señales

multiplicadas por los pesosWl primero son muestreadas, luego almacenadas en la

memoria del DSP y, posteriormente, se suman una vez que se haya hecho los retar-

dos óptimos para conformar el haz. El retardo óptimo se determina al seleccionar

las muestras provenientes de cada dipolo en tiempos diferentes, es decir, en diferen-

tes intervalos de muestreos. Por tal motivo, el tiempo de retardo que experimenta

Apéndice B. DoA Y BF en un solo DSP. 145

cada señal sensada por un dipolo, es múltiplo entero del tiempo de muestreo, el

cual llamaremos ∆t. En la Figura 2.2 se muestra la secuencia de muestreo que se

sigue en DBF usando un arreglo de antenas lineal uniforme.

Figura 2.2: Secuencia de muestreo en DBF [3].

De esta manera, en la Figura 2.2 se observa que la señal cuyo ángulo de arribo

es Φ2, debe ser sometida a un retardo dado por la siguiente ecuación:

τl(Φ2) = (l− 1)∆ (2.2)

En consecuencia, dicha ecuación indica que la señal del primer elemento no


se retrasa, el segundo sufre un retardo de ∆ y así sucesivamente. La limitación de

esta técnica se debe a que solo se pueden formar haces en las direcciones donde

se requieren retardos que sean múltiplos de ∆ como se muestra en la ecuación 2.3,

tales posiciones de arribo son Φ2, Φ3 y Φ1. Para el caso de Φ1, el haz puede ser

formado al sumar las muestras que se encuentran en la línea C.

τl(Φ) = Υl∆ (2.3)

donde Υl = 1, 2, 3, ....,L. Una forma de incrementar el número discreto de po-

siciones donde se puede posicionar el haz, es aumentando el tiempo de muestreo,

como se muestra en la Figura 2.3. Al muestrear a ∆/2, se pueden formar haces en

las posiciones de Φ4 y Φ5 y usando una red de suma para formar cada haz, per-

mite una ejecución en tiempo real. Sin embargo, esto requiere muestrear a una tasa

mayor a la requerida por el criterio de Nysquist para lograr reconstruir la forma

de onda. Además, se debe disponer de memorias que permitan almacenar grandes

cantidades de datos y que trabajen a frecuencias muy elevadas [3].

En la Figura 2.3 se ilustra como varios haces se forman en instantes diferentes

de tiempo, por ejemplo, en el instante t − ∆/2 se maximiza a la salida la señal que

arriba con anguloΦ5, en ∆ se maximiza la señal que arriba con anguloΦ5.

En resumen, se tiene que en la DBF, se toman muestras a la salida de cada ele-

mento del arreglo, que luego se procesan (mediante pesos y retardos) para generar

los haces deseados. Si se desea conseguir precisión en el apuntamiento del haz, es

necesario muestrear mucho más allá del criterio de Nyquist [11].

En contraste a lo anterior, si se tiene una estimación de DoA previamente a tra-

vés de los algoritmos que utilizan métodos de la autoestructura como es el caso de

MUSIC, el cálculo de los pesos puede ser calculado utilizando las técnicas clásicas

de síntesis del diagrama de radiación [11]. Por otro lado, los retardos que se reali-

zan para maximizar a la salida, la señal de interés, están determinados al conocer

las posiciones espaciales de las señales a través de los algoritmos DoA. En este sen-

tido, la ejecución de los algoritmos de dirección de arribo y la Conformación de Haz


Figura 2.3: Secuencia de muestreo en ∆/2

se deben realizar en tiempo real, lo que amerita un esquema de programación don-

de se ejecuten las dos etapas de forma simultánea. Por esta razón, en la siguiente

sección se establece cómo se realiza una programación con multitareas y se presen-

ta un esquema de cómo se aplicaría esta técnica en un DSP de un solo núcleo para

ejecutar DoA y BF.


2.2. DoA y BF usando técnicas de multiprogramación.

La multiprogramación es una técnica de multiplexación que permite la ejecu-

ción simultánea de múltiples procesos en un único procesador. De esta forma, se

permite una ilusión de paralelismo, de manera que parece que todos los procesos

se están ejecutando a la vez. Sin embargo, hay un único proceso ejecutándose en

el procesador a la vez [45]. La multiprogramación se realiza a través de un sistema

operativo en tiempo real mejor conocido como kernel, que en el caso de los DSP’s de

Texas Instruments de la familia C6000, la herramienta que permite la multiprogra-

mación se conoce como TI-RTOS, información más detallada sobre este herramienta

de Texas Instruments puede ser encontrada en [46].

Cabe señalar que los sistemas operativo en tiempo real están formado, princi-

palmente, por las múltiples tareas y por dos funciones que controlan el sistema, las

cuales se listan a continuación:

El planificador de tareas o procesos.

Gestión de Memoria.

Planificación de procesos o tareas. Esta función, determina cual proceso debe

ejecutarse en un instante determinado. Usualmente, el hardware interrumpirá un

proceso en ejecución en determinados instantes para permitir que el sistema ope-

rativo tome una nueva decisión de planificación de forma que el tiempo se reparta

por igual, en la forma más simple, o por el tiempo límite que una tarea se le fue

asignada [47].

Existen dos etapas de planificación, la primera de ellas es la planificación a lar-

go plazo que se encarga de determinar qué programas o tareas son admitidos, para

luego ser procesados en el sistema y cargados en la memoria. De esta manera, en

esta etapa de la planificación se tiene un control del número de tareas que se en-

cuentran en memoria y esperando por ser ejecutadas en el procesador. Una vez que

se admite una tarea, éste se añade a una cola asociada al planificador a corto plazo.

La segunda es la planificación a corto plazo que se ejecuta frecuentemente y toma la


decisión más específica sobre cuál tarea se ejecutará a continuación. Para compren-

der de una mejor forma esta etapa de planificación, se debe conocer los diferentes

estados en que se puede encontrar una tarea. En efecto, una tarea puede estar en

estado nuevo, preparado, ejecución, espera o detenido.

En este orden de ideas, cada tarea contiene un bloque de control de proceso,

donde se aloja toda la información referente a la misma (identificador, estado, prio-

ridad, contador de programa, entre otros) para que el procesador interprete la tarea

y lleve con éxito la reanudación o culminación de la misma.

A continuación, se presenta un ejemplo de dos tareas A y B para comprender

la interacción entre el sistema operativo y las tareas. De esta manera, al iniciar el

programa, la tarea A se encuentra ejecuntándose. Por tal motivo, para ejecutar A,

el procesador toma las instrucciones del programa contenido en la partición de la

memoria de A. Seguidamente, el procesador deja de ejecutar instrucciones de A y

empieza a ejecutar instrucciones del sistema operativo. Esto puede suceder por las

siguientes razones [47]:

1. La Tarea A genera una llamada a un servicio del sistema operativo (ejemplo:

solicitud de una operación Entrada/salida). La ejecución de A se suspende

hasta que el sistema operativo ha completado el servicio solicitado.

2. La Tarea A origina una interrupción. Cuando se detecta la interrupción, deja

de ejecutar A, y pasa al gestor de interrupciones, el cual está incluido en el

sistema operativo. La interrupción se puede generar por un error generado

en la tarea o porque se culminó el tiempo asignado al proceso, lo que evita

que la tarea monopolice al procesador.

3. Algún hecho no relacionado con la Tarea A (una solicitud de entrada de una

tarea en el planificador a largo plazo, complementación de una operación En-

trada/Salida, entre otros).

De esta forma, después que se detiene la Tarea A por algunas de las razones

expuestas anteriormente, el procesador guarda los datos de dicha tarea en el bloque


de control de proceso A y empieza a ejecutar el sistema operativo, donde la porción

de dicho sistema correspondiente al planificador a corto plazo decide ejecutar la

Tarea B.

Una vez aclarado los conceptos para el uso de sistemas operativos en tiem-

po real (RTOS-Real-Time Operating System), un ejemplo es generado a continuación

donde se explica como ejecutar DoA y BF bajo una programación de multitareas.

Ejemplo de multiprogramación para DoA y BF. En la etapa de DoA, se tiene

como entrada al vector de observaciones x y a la salida se tiene el vector que contie-

ne los estimados de las señales (�θ). Toda la etapa de DoA se ha considerado como

una tarea, la cual se llamará Tarea 1.

DoA

Figura 2.4: Etapa de DoA, Tarea 1.

La etapa de BF se puede dividir en dos Tareas. Una Tarea, la cual llamaremos

Tarea 2, está formada por el programa que genera los vectores de pesos para Rx y

Tx, asumiendo que el sistema es full Duplex y, otra tarea, que llamaremos Tarea 3

está formada por el programa que establece la comunicación y controla los retardos

para maximizar a la salida la señal deseada.

BF

Figura 2.5: Etapa de BF, Tarea 2.

Organización de Tareas según su nivel de importancia. La Tarea 3, resulta la

más importante por el hecho de estar ejecutándose continuamente. Por lo tanto, la


misma debe realizarse cada tm/P, donde tm indica el tiempo de muestreo corres-

pondiente a la señal en banda base y P indican el números de señales que arriban

al arreglo siendo P < L. En nuestro caso se tiene:

fm = 3× 10KHz = 30KHz (2.4)

tm = 0,033ms (2.5)

Para ilustrar la secuencia de las tareas, se asume en una primera prueba que

P = 1. En este sentido, en el gestor de interrupciones del sistema operativo, se debe

ejecutar una interrupción cada tm sobre cualquier tarea que esté en ejecución, de

esta manera el planificador a corto plazo debe ordenar que el procesador ejecute la

Tarea 3 cada tm.

Por otro lado, la Tarea 1 está formada por el algoritmo de DoA. De esta manera,

una vez que se establezca la comunicación con el usuario, su información espacial

debe ser actualizada cada 139ms, según lo establecido en la sección 3.3.2, lo que

indica que una interrupción cada 139ms perteneciente a la Tarea 2 debe ejecutarse

para que el planificador a largo plazo ordene cargar en memoria dicha Tarea y sea

puesta en la cola asociada al planificador a corto plazo.

Al momento que la Tarea 1 toma el control del procesador, ésta inicia adqui-

riendo las muestras para construir el vector de observación y, por ende, la matriz

de covarianza. En consecuencia, el muestreo se realiza en modo Recepción, a una

frecuencia intermedia (fI) de 50MHz. Así, se tiene que el tiempo de muestreo es el

siguiente:

ts =1

3× 50MHz= 6, 66ns (2.6)

De esta forma, cada ts se genera un vector de observación que se organiza

en la cola asociado al servicio de Entrada/Salida del sistema operativo. Luego


que se carga un vector de observación en la Tarea 2, se debe realizar la operación

(x(nts)×x(nts)H+A), dondeA representa la matriz que contiene la sumatoria de

la multiplicación anterior a n. El tiempo de procesamiento del mismo fue calculado

en la sección 4.3.2 para las plataformas C672x, C674x y C66xx que, para efectos de

este ejemplo, se consideró el rendimiento de la C672x, por ser ésta la que presenta

los tiempos de ejecución más críticos. De esta manera, el tiempo de procesamien-

to de cada observación es 3, 72µs, por lo que al inicio de DoA, se debe realizar N

interrupciones de 3, 72µs para generar la matriz de covarianza.

Por otro lado, se debe tener presente que la Tarea 1 y la Tarea 3 deben ejecutarse

simultáneamente, de tal manera que en el tiempo entre muestras (tm), se dedicará

un porción para establecer la conexión (Tarea 2) y una porción para ejecutar DoA

(Tarea 1). El porcentaje de tiempo para cada Tarea se puede estimar al establecer

el tiempo de ejecución de DoA, el cual debe ser mucho menor al tiempo de refres-

camiento (139ms). En este ejemplo, se consideró que el tiempo máximo para DoA

debe ser un 10% de 139ms.

tDoAmax = 10%∆ac ≈ 14ms (2.7)

La estimación del porcentaje de tm para ejecutar DoA se determinó por la si-

guiente ecuación:

tDoA|C672x

tDoAmax× 100 (2.8)

donde tDoA|C672x = 5,03ms y tDoAmax = 14ms. De esta manera, de la ecuación

2.8 se tiene que el 35% de tm debe estar dedicado a la ejecución de DoA hasta que

se realice la estimación.

Luego que se tiene el vector con los DoA’s de las señales, se inicia la Tarea 2 la

cual se encarga de estimar los pesos correspondientes a cada señal, el cual se debe

hacer en un tiempo menor que tm.


Interrupciones de las Tareas.

Tarea 3. Ejecuta una interrupción cada tm = 0, 033ms.

Tarea 1. Ejecuta tres interrupciones. La primera interrupción es para dar inicio

a la Tarea 1 por primera vez, esta se realiza cada 139ms. La segunda interrup-

ción es para la adquisición del vector de observación perteneciente a cada

muestra, dicha interrupción se realiza N veces cada 3, 72µs, siendo N el nú-

mero de observaciones que, en nuestro caso N = 100. Por ultimo, se ejecuta

una interrupción cada 0, 64xtm para que el planificador a corto plazo deje de

ejecutar la Tarea 3 y ejecute la Tarea 1.

Tarea 2. Se debe ejecutar en un tiempo menor que tm. Que para efectos de

este ejemplo, dicho tiempo es desconocido porque la investigación solo se

han realizados simulaciones con DoA y no con algoritmos de BF.

En el esquema de la Figura 2.6 se encuentra la representación de la secuencia

de tareas de DoA y BF con respecto a una ventana de tiempo. De esta manera, se

inicia en la Tarea 3 y, posterior a cumplirse el tiempo de refrescamiento, se genera

una interrupción por parte de la Tarea 1. En consecuencia, la Tarea 3 de detiene y

el procesador ejecuta el sistema operativo donde se toma la decisión de ejecutar la

Tarea 1. Luego de haber transcurrido un tiempo igual a 35%tm una interrupción

por parte de la Tarea 3 se genera, para reestablecer la comunicación. Por lo tanto,

este intercambio de tareas se hace hasta que se cumple el tiempo máximo en que se

puede determinar DoA.

Por otro lado, una vez que se haya determinado el nuevo DoA de la señal, se

genera una nueva interrupción por parte de la Tarea 1. De esta forma, el sistema

operativo ordena que se cargue en memoria la Tarea 2 y sea puesto en la cola aso-

ciada al planificador a corto plazo. Posteriormente, se atiende la Tarea 3 y una vez

terminada, se produce una nueva interrupción que ordena la ejecución de la Tarea

2. Dicha Tarea debe terminar en un tiempo menor que tm.


Tar

ea 1

Tar

ea 2

Tar

ea 3

Sist

ema

Ope

rativo

DoA

ter

min

ado

Figura 2.6: Multitarea en una ventana de tiempo.

Por último, es importante acotar que el sistema operativo cuenta con un gestor

de memorias, para controlar el número de tareas que pueden ser cargadas a la me-

moria principal. Por lo tanto, solo estarán en la memoria principal las tareas que

se encuentran en la cola asociada al planificador a corto plazo. En la Figura 2.7 se

muestra la entrada y salida de las tareas en la memoria principal.


MUESTREOMEMORIA

PRINCIPAL

DoA

BF

Tx Rx

Figura 2.7: Esquema de memoria principal.

Apéndice C

Consideración de la frecuencia de

portadora.

En las simulaciones hechas en este trabajo, se consideraron señales que llegaban

al arreglo de antenas con frecuencias de portadoras que estaban separadas 1MHz.

Sin embargo, en los sistemas de comunicaciones móviles celulares todas las señales

tienen una misma frecuencia de portadora. Por tal motivo, se ha llevado a cabo la

simulación de DML y MUSIC bajo este escenario.

3.1. Algoritmo DML.

La simulación se ha llevado a cabo para un número de dipolos igual a 10 con

una separación d = 0, 5λ. Por otro lado, la relación señal a ruido fue de 30dB y se

utilizó un número de observaciones igual a 1000. Adicionalmente, se han calculado

3 iteraciones. Por otra parte, la frecuencia de portadora de todas las señales fue de

850MHz. En la Tabla 3.1 se muestran las estimaciones hechas por DML, así como el

error respecto a los valores reales. En este sentido, si se compara esta Tabla con las

estimaciones hechas en la sección 4.2, se observa que DML pierde precisión cuando

la frecuencia de portadora es única para todas las señales que arriban al arreglo.

157

158 Apéndice C. Consideración de la frecuencia de portadora.

Tabla 3.1: Resultados de las estimaciones a fp = 850MHz.

Posiciones de fuentes 30 42 50 79 145

Estimaciones 31 46 51 79 144

Error −1 −4 −1 0 1

Por último, se evaluó la resolución de este algoritmo, con una separación de 10◦

entre las fuentes. En la Tabla 3.2 se muestran los resultados, donde se observa que

a una sola frecuencia de portadora el algoritmo pierde resolución.

Tabla 3.2: Prueba de resolución a fp = 850MHz.

Posiciones de fuentes 40 50 60 70 80

Estimaciones 44 48 63 73 80

Error −4 2 −3 −3 0

3.2. Algoritmo MUSIC.

La codificación de MUSIC usada en este trabajo, consideró señales de tipo se-

noidal que arriban al arreglo de antenas con la misma potencia y con diferentes fre-

cuencias de portadoras, logrando estimaciones que convergían a los valores reales.

No obstante, como se describió anteriormente, los sistemas de comunicaciones mó-

viles trabajan a una sola frecuencia de portadora. Por tal motivo, se hicieron simu-

laciones considerando una fp = 850MHz y bajo los mismos parámetros de entrada

del algoritmo DML. De esta manera se observó que, para el código usado en es-

ta investigación, en un escenario con la misma frecuencia de portadora para todas

las señales, el espectro MUSIC presenta una desmejora significativa. En la Figura

3.1 se muestra el espectro MUSIC con el código usado en esta investigación, pero

con datos de doble precisión, logrando soportar una separación entre portadoras

de 100KHz.

Por otro lado, una última simulación se realizó considerando dos señales con

la misma frecuencia de portadora de 850MHz y con 15 dipolos. En la Figura 3.2

Apéndice C. Consideración de la frecuencia de portadora. 159

65 90 120−10

−8

−6

−4

−2

0

2

4

6

θ

Esp

ectr

o M

usic

(dB

)

Figura 3.1: Espectro MUSIC con ∆f = 100KHz.

se muestran los resultados, donde se aprecia que para el código usado las señales

deben estar lo suficientemente separadas para lograr estimaciones certeras.

60 120−12

−11.5

−11

−10.5

−10

−9.5

−9

−8.5

−8

−7.5

θ

Esp

ectr

o M

usic

(dB

)

Figura 3.2: Espectro MUSIC con dos señales a la misma frecuencia de portadora.

160 Apéndice C. Consideración de la frecuencia de portadora.

El código usado para estos propósitos fue el siguiente:

L =15;

N = 1000;

vt = [60 120];

d = 0.5;

SNR = 30;

P = length(vt);

% Frecuencia de las señales incidentes en el arreglo

Deltaf = 0e3;

f = Deltaf*(0:P-1);

fd = 850e6;

% frecuencia de muestreo

fm = 2*fd;

THETA = [0 0 0 0];

% Vector de observaciones

ts = (1:N)/fm;

alfa = [0 0 0 0];

% Inicializando la matriz de observaciones

X = complex((zeros(L,N)));

s = complex(double(zeros(1,N)));

A = complex(zeros(L,P));

a = [1 1 1 1 1];

% Modelos de la señal de las fuentes y matriz de señales

for i = 1:P

for n=1:N

s(i,n) = a(i)*(exp(1i*(2*pi*(fp(i)/fm)*n)+THETA(i)));

Apéndice C. Consideración de la frecuencia de portadora. 161

end

end

for l = 1:L

for i = 1:P

A(l,i) = exp(-1i*2*pi*(l-1)*d*cos((pi/180)*vt(i))*((fp(i))/fd));

end

end

X = A*s;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% ALGORITMO MUSIC %

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Rxx = zeros(L,L);

X = awgn(X,SNR);

Rxx = X*X'/(N);

[E,S,V] = svd(Rxx);

Pn = E(:,P+1:L)*E(:,P+1:L)';

ell = 0;

for theta=0:1:180

ell=ell+1;

atheta = exp(-1i*2*pi*d*cos((pi/180)*theta)*(0:L-1));

SMUSIC(ell) = (abs(conj(atheta)*Pn*(atheta.')));

end

theta=0:1:180;

plot(theta,-10*log10(SMUSIC))

Referencias Bibliográficas

[1] J. Arceo. Desarrollo de Algoritmos para la Síntesis del Diagrama de Radiación en

Comunicaciones Móviles Celulares Basadas en Antenas Inteligentes. PhD thesis,

Instituto Politécnico Nacional, Escuela Superior de Ingeniería Eléctrica y Me-

cánica, Unidad Culhuacan, México D.F, Enero 2008.

[2] S. Kuo and B. Lee. Real-Time Digital Signal Processing: Fundamentals, Implemen-

tations and Applications. John Wiley & Sons, 2001.

[3] L.C. Godara. Smart Antennas. CRC Press, 2004.

[4] T. Crook, CDG Technology Forum. Why Smart Antennas & Subscriber Device

Based Enhancements Are Important to Wireless Service Providers, October 1,

2002. URL http://www.cdg.org/news/events/CDMASeminar/cdg_tech_forum_

02/1_sprint_cdg_smart_antenna_rev.pdf. Consultado: Febrero de 2015.

[5] I. Stevanovi’c, A. Skrivervik and J. Mosig. Smart Antenna Systems for Mobile

Communications. Laboratoire d’Electromagnétisme et d’Acoustique Ecole Polytech-

nique Fédérale de Lausanne, January 2003.

[6] R. Albornoz y S. Mustafá. Antenas Inteligentes. V Encuentro Nacional de Ramas

IEEE, Noviembre 2004.

[7] A. Castillo y E. Rodríguez. Simulación y Estudio Comparativo de los

Algoritmos de Detección de Dirección de Arribo (DoA) Usados en Antenas

Inteligentes. Universidad de Carabobo, Venezuela. Trabajo Especial de Grado, No-

viembre 2005.

163

http://www.cdg.org/news/events/CDMASeminar/cdg_tech_forum_02/1_sprint_cdg_smart_antenna_rev.pdf

http://www.cdg.org/news/events/CDMASeminar/cdg_tech_forum_02/1_sprint_cdg_smart_antenna_rev.pdf

164 Referencias Bibliográficas

[8] A. Miquel. Aportaciones Metodológicas al Procesado de Bioseñales en

Sistemas Embebidos. Universidad de Sevilla, España. Proyecto Fin de Carrera,

2010–2011.

[9] P. H. Lehne and M. Pettersen. An Overview of Smart Antenna Technology for

Mobile Communications Systems. IEEE Communications Surveys, 2(4):2–12,

1999.

[10] M. Feuerstein, CDG Technology Forum. The Evolution Of Smart Antennas

To 3G, October 1, 2002. URL http://www.cdg.org/news/events/CDMASeminar/

cdg_tech_forum_02/5_metawave_cdg_technology_forum_10-1-02.pdf. Consul-

tado: Febrero de 2015.

[11] O. Moreno, I. Franco y J. Miranda. Introducción a la Tecnología de Antenas

Inteligentes. Aplicación a UMTS. Comunicaciones de Telefónica I+D, (21):43–56,

1999.

[12] J. Hennessy and D. Patterson. Arquitectura de Computadores: Un Enfoque Cuan-

titativo. McGraw-Hill, 1993.

[13] M. De Quintal. FACTIBILIDAD DE IMPLEMENTACIÓN DE ANTENAS

INTELIGENTES PARA EL SISTEMA CELULAR CDMA 3G1X DE MO-

VILNET. Universidad Central de Venezuela. Trabajo Especial de Grado, Octubre

2004.

[14] A. Mitra. Lecture Notes on Mobile Communication. A Curriculum Development

Cell Project Under QIP, IIT Guwahati, 2009.

[15] C. Dietrich, W. Stutzman, B. Kim, and K. Dietze. Smart Antennas in Wireless

Communications: Base-Station Diversity and Handset Beamforming. IEEE

Antennas and Propagation Magazine, 42(5):142–151, October 2000.

[16] C. Balanis. Antenna theory: Analysis and Design. John Wiley & Sons. 3ra edición.,

2005.

[17] H. Krim and M. Viberg. Two Decades of Array Signal Processing Research:

The Parametric Approach. IEEE Signal Processing Magazine., pages 67–94, 1996.

http://www.cdg.org/news/events/CDMASeminar/cdg_tech_forum_02/5_metawave_cdg_technology_forum_10-1-02.pdf

http://www.cdg.org/news/events/CDMASeminar/cdg_tech_forum_02/5_metawave_cdg_technology_forum_10-1-02.pdf


[18] A. Cardama, L. Jofre, J.M Rius, J. Romeu, S. Blanch y M. Ferrando. Antenas.

Universitat Politècnica de Catalunya, 2002.

[19] P. Stoica and R. Moses. Spectral Analysis of Signals. Prentice Hall, Upper Saddle

River, New Jersey, 2005.

[20] G. Strang, Massachusetts Institute of Technology. Introduction to Linear Algebra.

Wellesley-Cambridge Press, Third Edition, 2003.

[21] P. Stoica and A. Nehorai. Music, Maximum Likelihood, and Cramer-Rao

Bound. IEEE Transactions on Acoustics, Speech, and Signal Processing, 37(5):720–

741, 1989.

[22] R.O. Schmidt. Multiple Emitter Location and Signal Parameter Estimation.

IEEE Transactions on Antennas and Propagation, 34(3):276–280, 1986.

[23] R. Roy and T. Kailath. Esprit-Estimation of Signal Parameters Via Rotational

Invariance Techniques. IEEE Transactions on Acoustics, Speech, and Signal Pro-

cessing, 37(7):984–995, July 1989.

[24] L.C. Godara. Handbook of Antennas in Wireless Communications. CRC Press LLC,

2002.

[25] W. Hines y D. Montgomery. Probabilidad y estadística para ingeniería y adminis-

tración. COMPAÑÍA EDITORIAL CONTINENTAL, S.A. DE C.V. MÉXICO.

Tercera edición, 1996.

[26] R. Chassaing. DSP Applications Using C and the TMS320C6x DSK. John Wiley

& Sons, Inc, 2002.

[27] Simposio Argentino de Sistemas Embebidos (SASE). URL http://www.sase.

com.ar. Consultado: Enero de 2015.

[28] D. Perez, The MathWorks. De MATLAB a C de forma sencilla. URL

http://www.mathworks.com/videos/matlab-to-c-made-easy-92097.html?

form_seq=conf1134&confirmation_page&wfsid=5813059&refresh=true. Con-

sultado: Enero de 2015.

http://www.sase.com.ar

http://www.sase.com.ar

http://www.mathworks.com/videos/matlab-to-c-made-easy-92097.html?form_seq=conf1134&confirmation_page&wfsid=5813059&refresh=true

http://www.mathworks.com/videos/matlab-to-c-made-easy-92097.html?form_seq=conf1134&confirmation_page&wfsid=5813059&refresh=true

166 Referencias Bibliográficas

[29] The MathWorks, Inc. Embedded MATLAB™, User’s Guide. 2007.

[30] H. Zarrinkoub, The MathWorks. Embedded MATLAB, part 1: From MATLAB

to embedded C. URL http://www.eetimes.com/document.asp?doc_id=

1275570&page_number=1. Consultado: Enero de 2015.

[31] The MathWorks, Inc. Real-Time Workshop® For Use with SIMULINK®,

User’s Guide. 1999.

[32] H. Deitel and P. Deitel. Cómo programar en C/C++ y Java. PEARSON, Prentice

Hall, Cuarta edición, 2004.

[33] Code::Blocks. URL http://www.codeblocks.org/home. Consultado: Enero de

2015.

[34] Texas Instruments. Code Composer Studio (CCS) Integrated Development

Environment (IDE), . URL http://www.ti.com/tool/ccstudio. Consultado:

Febrero de 2015.

[35] R. Albornoz. Trabajo Práctico del Laboratorio de Antenas. Universidad de Cara-

bobo, Venezuela, 1982.

[36] CONATEL. Cuadro Nacional de Atribuciones de Bandas de Frecuencias.

2010.

[37] B. Lathi. Introducción a la teoría y SISTEMAS DE COMUNICACIÓN. Limusa,

Noriega Editores. México D. F, 2002.

[38] Gaceta Oficial Nº 5.240. Reglamento de la Ley de Tránsito Terrestre,

Venezuela. Junio 1998.

[39] B. Powel. Real-Time Agility: The Harmony/ESW Method for Real-Time and Embed-

ded Systems Development. Addison-Wesley Professional, 2009.

[40] Texas Instruments. Profile clock in CCS, . URL http://processors.wiki.ti.

com/index.php/Profile_clock_in_CCS. Consultado: Febrero de 2015.

[41] Texas Instruments. Download CCS, . URL http://processors.wiki.ti.

com/index.php/Download_CCS?keyMatch=CCS%20dowload&tisearch=Search-EN.

Consultado: Febrero de 2015.

http://www.eetimes.com/document.asp?doc_id=1275570&page_number=1

http://www.eetimes.com/document.asp?doc_id=1275570&page_number=1

http://www.codeblocks.org/home

http://www.ti.com/tool/ccstudio

http://processors.wiki.ti.com/index.php/Profile_clock_in_CCS

http://processors.wiki.ti.com/index.php/Profile_clock_in_CCS

http://processors.wiki.ti.com/index.php/Download_CCS?keyMatch=CCS%20dowload&tisearch=Search-EN

http://processors.wiki.ti.com/index.php/Download_CCS?keyMatch=CCS%20dowload&tisearch=Search-EN


[42] Texas Instruments. Main Page, . URL http://processors.wiki.ti.com/index.

php/Main_Page. Consultado: Febrero de 2015.

[43] Texas Instruments. Code Composer Studio Getting Started Guide. May 2001.

[44] Computer Science University of Maryland. Big and Little Endian. URL http:

//www.cs.umd.edu/class/sum2003/cmsc311/Notes/Data/endian.html. Consul-

tado: Febrero de 2015.

[45] Universidad de Sevilla. Multiprogramación. URL https://1984.lsi.us.es/

wiki-ssoo/index.php/Multiprogramaci%C3%B3n. Consultado: Marzo de 2015.

[46] Texas Instruments. TI-RTOS 1.21™, Getting Started Guide. 2014.

[47] W. Stallings. Organización y Arquitectura de Computadora. Pearson-Prentice

Hall, 7ma edición, 2006.

http://processors.wiki.ti.com/index.php/Main_Page

http://processors.wiki.ti.com/index.php/Main_Page

http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Data/endian.html

http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Data/endian.html

https://1984.lsi.us.es/wiki-ssoo/index.php/Multiprogramaci%C3%B3n

https://1984.lsi.us.es/wiki-ssoo/index.php/Multiprogramaci%C3%B3n

antenas inteligentes

Documents