antenas inteligentes
DESCRIPTION
TRABAJO ESPECIAL DE GRADO PRESENTADO ANTE LA ILUSTRE UNIVERSIDAD DE CARABOBO POR JOSÉ DANIEL MADURO Y DAVID RANGEL PARA OPTAR AL TÍTULO DE INGENIERO ELECTRICISTA EINGENIERO DE TELECOMUNICACIONES RESPECTIVAMENTETRANSCRIPT
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
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
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.
Bárbula, 4 de Marzo del 2015
UNIVERSIDAD DE CARABOBO
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA DE
TELECOMUNICACIONES
DEPARTAMENTO DE
ELECTROMAGNETISMO Y RADIACIÓN
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
Bárbula, 4 de Marzo del 2015
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.23. Ciclos de reloj de la matriz de covarianza y DML con 200 observacio-nes y dos iteraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.24. Ciclos de reloj de la matriz de covarianza y DML con 200 observacio-nes y tres iteraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.25. Ciclos de reloj de la matriz de covarianza y DML con 100 observacio-nes y una iteración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.26. Ciclos de reloj de la matriz de covarianza y DML con 100 observacio-nes y dos iteraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.27. Ciclos de reloj de la matriz de covarianza y DML con 100 observacio-nes y tres iteraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.28. Resultados de la estimación de DML con 500 observaciones para lastres iteraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.29. Resultados de la estimación de DML con 200 observaciones para lastres iteraciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.30. Resultados de la estimación de DML con 100 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
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
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].
4 Capítulo I. Introducción
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.
6 Capítulo I. Introducción
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.
10 Capítulo II. Marco conceptual
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].
Capítulo II. Marco conceptual 11
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.
12 Capítulo II. Marco conceptual
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
Capítulo II. Marco conceptual 13
(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
14 Capítulo II. Marco conceptual
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.
Capítulo II. Marco conceptual 15
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
16 Capítulo II. Marco conceptual
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).
Capítulo II. Marco conceptual 17
∇ · 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)
18 Capítulo II. Marco conceptual
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.
Capítulo II. Marco conceptual 19
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
20 Capítulo II. Marco conceptual
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.
Capítulo II. Marco conceptual 21
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◦
].
22 Capítulo II. Marco conceptual
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)
Capítulo II. Marco conceptual 23
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
24 Capítulo II. Marco conceptual
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)
Capítulo II. Marco conceptual 25
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)
26 Capítulo II. Marco conceptual
∴ 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.
Capítulo II. Marco conceptual 27
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
28 Capítulo II. Marco conceptual
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)
Capítulo II. Marco conceptual 29
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
30 Capítulo II. Marco conceptual
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)
Capítulo II. Marco conceptual 31
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)
32 Capítulo II. Marco conceptual
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)
Capítulo II. Marco conceptual 33
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)
34 Capítulo II. Marco conceptual
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.
Capítulo II. Marco conceptual 35
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].
36 Capítulo II. Marco conceptual
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].
Capítulo II. Marco conceptual 37
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
38 Capítulo II. Marco conceptual
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.
Capítulo II. Marco conceptual 39
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].
40 Capítulo II. Marco conceptual
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.
Capítulo II. Marco conceptual 41
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.
42 Capítulo II. Marco conceptual
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
Capítulo II. Marco conceptual 43
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
44 Capítulo II. Marco conceptual
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)
48 Capítulo III. Procedimientos de la investigación.
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.
Capítulo III. Procedimientos de la investigación. 49
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.
50 Capítulo III. Procedimientos de la investigación.
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)
Capítulo III. Procedimientos de la investigación. 51
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)
52 Capítulo III. Procedimientos de la investigación.
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.
Capítulo III. Procedimientos de la investigación. 53
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.
54 Capítulo III. Procedimientos de la investigación.
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.
Capítulo III. Procedimientos de la investigación. 55
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.
56 Capítulo III. Procedimientos de la investigación.
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
Capítulo III. Procedimientos de la investigación. 57
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
58 Capítulo III. Procedimientos de la investigación.
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.
Capítulo III. Procedimientos de la investigación. 59
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)
60 Capítulo III. Procedimientos de la investigación.
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
Capítulo III. Procedimientos de la investigación. 61
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).
62 Capítulo III. Procedimientos de la investigación.
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
Capítulo III. Procedimientos de la investigación. 63
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.
64 Capítulo III. Procedimientos de la investigación.
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:
Capítulo III. Procedimientos de la investigación. 65
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.
66 Capítulo III. Procedimientos de la investigació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
70 Capítulo IV. Análisis, interpretación y presentación de los resultados
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 71
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
72 Capítulo IV. Análisis, interpretación y presentación de los resultados
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
Figura 4.2: Máximos del espectro MUSIC con SNR = 20dB.
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
Figura 4.3: Máximos del espectro MUSIC con SNR = 10dB.
Capítulo IV. Análisis, interpretación y presentación de los resultados 73
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
Figura 4.4: Máximos del espectro MUSIC con SNR = 0dB.
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
74 Capítulo IV. Análisis, interpretación y presentación de los resultados
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
Iteración 1 = 45, 33, 79, 144, 48Iteración 2 = 42, 31, 79, 144, 50Iteración 3 = 42, 30, 79, 145, 50
Figura 4.6: Ángulos estimados (�θ) por DML con SNR = 20dB.
Capítulo IV. Análisis, interpretación y presentación de los resultados 75
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
Figura 4.7: Ángulos estimados (�θ) por DML con SNR = 10dB.
30 42 50 79 145
1
2
3
4
θ°
Nro
de
itera
cion
es d
e D
ML
Iteración 1 = 44, 33, 79, 144, 49Iteración 2 = 45, 30, 145, 80, 49Iteración 3 = 41, 32, 144, 79, 50Iteración 4 = 47, 30, 79, 145, 44
Figura 4.8: Ángulos estimados (�θ) por DML con SNR = 0dB.
76 Capítulo IV. Análisis, interpretación y presentación de los resultados
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 77
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
Figura 4.10: Máximos del espectro MUSIC con N = 200.
78 Capítulo IV. Análisis, interpretación y presentación de los resultados
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
Figura 4.11: Máximos del espectro MUSIC con N = 100.
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
Figura 4.12: Máximos del espectro MUSIC con N = 10.
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
Capítulo IV. Análisis, interpretación y presentación de los resultados 79
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
Iteración 1 = 45, 33, 79, 144, 48Iteración 2 = 42, 31, 79, 145, 50Iteración 3 = 42, 30, 79, 145, 50
Figura 4.13: Ángulos estimados (�θ) por DML con N = 500.
80 Capítulo IV. Análisis, interpretación y presentación de los resultados
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.14: Ángulos estimados (�θ) por DML con N = 200.
30 42 50 79 145
1
2
3
θ°
Nro
de
itera
cion
es d
e D
ML
Iteración 1 = 45, 34, 144, 79, 48Iteración 2 = 40, 30, 145, 79, 50Iteración 3 = 42, 30, 145, 79, 50
Figura 4.15: Ángulos estimados (�θ) por DML con N = 100.
Capítulo IV. Análisis, interpretación y presentación de los resultados 81
30 42 50 79 145
1
2
3
4
θ°
Nro
de
itera
cion
es d
e D
ML
Iteración 1 = 48, 143, 80, 36, 77Iteración 2 = 48, 144, 83, 38, 78Iteración 3 = 47, 144, 82, 39, 77Iteración 4 = 47, 144, 52, 32, 79
Figura 4.16: Ángulos estimados (�θ) por DML con N = 10.
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
82 Capítulo IV. Análisis, interpretación y presentación de los resultados
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
Capítulo IV. Análisis, interpretación y presentación de los resultados 83
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
Iteración 1 = 144, 80, 59, 30, 49Iteración 2 = 144, 36, 80, 51, 58Iteración 3 = 46, 146, 79, 36, 113Iteración 4 = 145, 47, 80, 124, 32
Figura 4.18: Ángulos estimados (�θ) por DML en ambiente desfavorable.
84 Capítulo IV. Análisis, interpretación y presentación de los resultados
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 85
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
Número de observaciones N 1000
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.
86 Capítulo IV. Análisis, interpretación y presentación de los resultados
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)
Capítulo IV. Análisis, interpretación y presentación de los resultados 87
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
Iteración 1 = 45, 33, 140, 79, 54Iteración 2 = 46, 30, 141, 80, 56Iteración 3 = 45, 30, 140, 80, 55
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
88 Capítulo IV. Análisis, interpretación y presentación de los resultados
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
Número de observaciones N 1000
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 89
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.
90 Capítulo IV. Análisis, interpretación y presentación de los resultados
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
Iteración 1 = 61, 74, 55, 73, 66Iteración 2 = 62, 75, 55, 72, 66Iteración 3 = 59, 75, 55, 71, 65Iteración 4 = 60, 75, 55, 70, 65
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 91
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
92 Capítulo IV. Análisis, interpretación y presentación de los resultados
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 93
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
Tabla 4.13: Ciclos de reloj de la matriz de covarianza y MUSIC con 200 observa-ciones.
C672x C674x
Función Ciclos de reloj Ciclos de reloj
Matriz de covarianza 31898613 31752438
MUSICSVD 640752 622544
Máximo 5209364 5068192
Total ciclos de reloj 37748729 37443174
94 Capítulo IV. Análisis, interpretación y presentación de los resultados
Tabla 4.14: Ciclos de reloj de la matriz de covarianza y MUSIC con 100 observa-ciones.
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 95
Resultados de las estimaciones:
La Tabla 4.15, Tabla 4.16 y Tabla 4.17 presentan resultados de las estimaciones
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.15: Resultados de la estimación de MUSIC con 500 observaciones.
C672x C674x
[30, 42, 50, 79, 145] [30, 42, 50, 79, 145]
Tabla 4.16: Resultados de la estimación de MUSIC con 200 observaciones.
C672x C674x
[30, 42, 50, 79, 145] [30, 42, 50, 79, 145]
Tabla 4.17: Resultados de la estimación de MUSIC con 100 observaciones.
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.
96 Capítulo IV. Análisis, interpretación y presentación de los resultados
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 97
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
Función Ciclos de reloj Ciclos de reloj
Matriz de covarianza 79819499 80055247
DML 215398762 220416643
Total ciclos de reloj 295218261 300471890
Tabla 4.20: Ciclos de reloj de la matriz de covarianza y DML con 500 observacionesy dos iteraciones.
C672x C674x
Función Ciclos de reloj Ciclos de reloj
Matriz de covarianza 79819426 80055247
DML 508890315 519081308
Total ciclos de reloj 588709741 599136555
98 Capítulo IV. Análisis, interpretación y presentación de los resultados
Tabla 4.21: Ciclos de reloj de la matriz de covarianza y DML con 500 observacionesy tres iteraciones.
C672x C674x
Función Ciclos de reloj Ciclos de reloj
Matriz de covarianza 79779099 80055247
DML 803856586 819270800
Total ciclos de reloj 883635685 899326047
Tabla 4.22: Ciclos de reloj de la matriz de covarianza y DML con 200 observacionesy una iteración.
C672x C674x
Función Ciclos de reloj Ciclos de reloj
Matriz de covarianza 31614893 31727759
DML 215397674 220415556
Total ciclos de reloj 247012567 252143315
Tabla 4.23: Ciclos de reloj de la matriz de covarianza y DML con 200 observacionesy dos iteraciones.
C672x C674x
Función Ciclos de reloj Ciclos de reloj
Matriz de covarianza 31615220 31727759
DML 508851730 519043756
Total ciclos de reloj 540466950 550771515
Capítulo IV. Análisis, interpretación y presentación de los resultados 99
Tabla 4.24: Ciclos de reloj de la matriz de covarianza y DML con 200 observacionesy tres iteraciones.
C672x C674x
Función Ciclos de reloj Ciclos de reloj
Matriz de covarianza 31615220 31727759
DML 804404793 819820328
Total ciclos de reloj 836020013 851548087
Tabla 4.25: Ciclos de reloj de la matriz de covarianza y DML con 100 observacionesy una iteración.
C672x C674x
Función Ciclos de reloj Ciclos de reloj
Matriz de covarianza 15794818 15846592
DML 215032768 220047367
Total ciclos de reloj 230827586 235893949
Tabla 4.26: Ciclos de reloj de la matriz de covarianza y DML con 100 observacionesy dos iteraciones.
C672x C674x
Función Ciclos de reloj Ciclos de reloj
Matriz de covarianza 15794818 15846592
DML 509389944 519583929
Total ciclos de reloj 525184762 535430521
100 Capítulo IV. Análisis, interpretación y presentación de los resultados
Tabla 4.27: Ciclos de reloj de la matriz de covarianza y DML con 100 observacionesy tres iteraciones.
C672x C674x
Función Ciclos de reloj Ciclos de reloj
Matriz de covarianza 15794818 15846592
DML 804356558 819772965
Total ciclos de reloj 820151376 835619557
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.
Resultados de las estimaciones:
La Tabla 4.28, Tabla 4.29 y Tabla 4.30 presentan resultados de las estimaciones
con N = 500, N = 200 y N = 100 respectivamente usando las plataformas C672x y
C674x. Los resultados mostrados fueron realizados para las tres iteraciones.
Capítulo IV. Análisis, interpretación y presentación de los resultados 101
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]
Tabla 4.29: Resultados de la estimación de DML con 200 observaciones para lastres iteraciones.
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]
Tabla 4.30: Resultados de la estimación de DML con 100 observaciones para lastres iteraciones.
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.
Requisitos de memoria:
La Tabla 4.31 muestra los requisitos de memoria para las plataformas C672x,
C674x. Cabe señalar que la compilación se ha hecho en modo debug.
102 Capítulo IV. Análisis, interpretación y presentación de los resultados
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
Capítulo IV. Análisis, interpretación y presentación de los resultados 103
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
Función Ciclos de reloj Ciclos de reloj Ciclos de reloj
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
Resultados de las estimaciones:
La Tabla 4.34 presenta los resultados de las estimaciones en modo release para
las plataformas C672x, C674x y C66xx.
104 Capítulo IV. Análisis, interpretación y presentación de los resultados
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]
Requisitos de memoria:
La Tabla 4.35 muestra los requisitos de memoria para las plataformas C672x,
C674x y C66xx en modo release.
Tabla 4.35: Requisitos de memoria del algoritmo MUSIC.
Memoria C672x C674x C66xx
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 105
Tabla 4.36: Ciclos de reloj de DML con 100 observaciones y dos iteraciones enmodo release.
C672x C674x C66xx
Función Ciclos de reloj Ciclos de reloj Ciclos de reloj
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
Resultados de las estimaciones:
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]
Requisitos de memoria:
La Tabla 4.39 muestra los requisitos de memoria para las plataformas C672x,
C674x y C66xx en modo release.
Tabla 4.39: Requisitos de memoria del algoritmo MUSIC.
Memoria C672x C674x C66xx
MUSIC.out (KB) 146, 738 230, 581 136, 812
MUSIC.map (KB) 44, 308 60, 787 34, 665
106 Capítulo IV. Análisis, interpretación y presentación de los resultados
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
Capítulo IV. Análisis, interpretación y presentación de los resultados 107
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
108 Capítulo IV. Análisis, interpretación y presentación de los resultados
Tabla 4.41: Tiempo de ejecución para la matriz de covarianza usando la plataformaC674x.
Cálculo de la Matriz de covarianza Ciclos de reloj Tiempo de ejecución
Cálculo de una observación 1206 2, 64µs
Dividir entre N 22389 49, 908µs
Tabla 4.42: Tiempo de ejecución para la matriz de covarianza usando la plataformaC66xx.
Cálculo de la Matriz de covarianza Ciclos de reloj Tiempo de ejecución
Cálculo de una observación 1118 0, 89µs
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
Capítulo IV. Análisis, interpretación y presentación de los resultados 109
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.
110 Capítulo IV. Análisis, interpretación y presentación de los resultados
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 111
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.
112 Capítulo IV. Análisis, interpretación y presentación de los resultados
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
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 acumulacion.
ReRN = ReRN+ReRn;
ImRN = ImRN+ImRn;
Capítulo IV. Análisis, interpretación y presentación de los resultados 113
%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.
114 Capítulo IV. Análisis, interpretación y presentación de los resultados
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).
Capítulo IV. Análisis, interpretación y presentación de los resultados 115
>> 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.
116 Capítulo IV. Análisis, interpretación y presentación de los resultados
>> [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
Capítulo IV. Análisis, interpretación y presentación de los resultados 117
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).
118 Capítulo IV. Análisis, interpretación y presentación de los resultados
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 119
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.
120 Capítulo IV. Análisis, interpretación y presentación de los resultados
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 121
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
122 Capítulo IV. Análisis, interpretación y presentación de los resultados
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
Capítulo IV. Análisis, interpretación y presentación de los resultados 123
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
124 Capítulo IV. Análisis, interpretación y presentación de los resultados
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 125
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.
126 Capítulo IV. Análisis, interpretación y presentación de los resultados
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.
Capítulo IV. Análisis, interpretación y presentación de los resultados 127
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.
128 Capítulo IV. Análisis, interpretación y presentación de los resultados
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 (SNR) == (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
ReRn(x,xh) = RXaux(x)*RXaux(xh)+IXaux(x)*IXaux(xh);
ImRn(x,xh) = IXaux(x)*RXaux(xh)-RXaux(x)*IXaux(xh);
136 Apéndice A. Códigos en Embedded MATLAB de algoritmos DoA.
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] ) )
assert ( all ( size (SNR) == (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
Apéndice A. Códigos en Embedded MATLAB de algoritmos DoA. 137
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'))
138 Apéndice A. Códigos en Embedded MATLAB de algoritmos DoA.
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));
Apéndice A. Códigos en Embedded MATLAB de algoritmos DoA. 139
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
140 Apéndice A. Códigos en Embedded MATLAB de algoritmos DoA.
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)
Apéndice A. Códigos en Embedded MATLAB de algoritmos DoA. 141
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
146 Apéndice B. DoA Y BF en un solo DSP.
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
Apéndice B. DoA Y BF en un solo DSP. 147
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.
148 Apéndice B. DoA Y BF en un solo DSP.
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
Apéndice B. DoA Y BF en un solo DSP. 149
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
150 Apéndice B. DoA Y BF en un solo DSP.
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
Apéndice B. DoA Y BF en un solo DSP. 151
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
152 Apéndice B. DoA Y BF en un solo DSP.
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.
Apéndice B. DoA Y BF en un solo DSP. 153
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.
154 Apéndice B. DoA Y BF en un solo DSP.
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.
Apéndice B. DoA Y BF en un solo DSP. 155
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
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.
Referencias Bibliográficas 165
[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.
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.
Referencias Bibliográficas 167
[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.