identificación de radiobases ds-cdma detectando su desfasaje del
Anuncio
UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA ELECTRÓNICA IDENTIFICACIÓN DE RADIOBASES DS-CDMA DETECTANDO SU DESFASAJE DEL CÓDIGO PN SOBRE PLATAFORMA LABVIEW Por: Br. Daniel San Martín Lens PROYECTO DE GRADO Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero Electrónico Sartenejas, octubre de 2010 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA ELECTRÓNICA IDENTIFICACIÓN DE RADIOBASES DS-CDMA DETECTANDO SU DESFASAJE DEL CÓDIGO PN SOBRE PLATAFORMA LABVIEW Por: Br. Daniel San Martín Lens Realizado con la asesoría de: Ing. Miguel Augusto Díaz Díaz PROYECTO DE GRADO Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero Electrónico Sartenejas, octubre de 2010 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA ELECTRÓNICA ACTA DE EVALUACIÓN DEL PROYECTO DE GRADO CÓDIGO DE LA ASIGNATURA: EP________________________ FECHA:___/___/______ ESTUDIANTE:_______________________________________ CARNET:______________________ TÍTULO DEL TRABAJO: _____________________________________________________________ TUTOR: Prof. CO-TUTOR: Prof. JURADO: Profs. APROBADO: REPROBADO: OBSERVACIONES: El Jurado considera por unanimidad que el trabajo es EXCEPCIONALMENTE BUENO: SI: NO: En caso positivo, justificar razonadamente: Jurado Jurado Tutor Académico Co-Tutor Jurado Nota: Colocar los sellos de los respectivos Departamentos. Para jurados externos, usar sello de la Coordinación UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA ELECTRÓNICA IDENTIFICACIÓN DE RADIOBASES DS-CDMA DETECTANDO EL DESFASAJE DEL CÓDIGO PN SOBRE PLATAFORMA LABVIEW Informe de Proyecto de Grado presentado por Daniel San Martín Lens Carnet: 04-37575 Realizado con la Asesoría del Ing. Miguel Augusto Díaz Díaz. RESUMEN Las radiobases de transmisión pertenecientes a la tecnología celular DS-CDMA realizan el enmascaramiento de las señales del enlace de bajada mediante la utilización de un código de ruido pseudoaleatorio. Las radiobases son identificadas a través del desfasaje particular de dicho código que emplea cada una de ellas, el cual es detectable en el canal piloto. El presente trabajo tiene por objeto realizar la detección e identificación de las radiobases presentes en un área geográfica determinada, a partir de la determinación del desfasaje que emplea cada una de ellas. Para lograrlo se comprobaron los algoritmos de generación de los códigos pseudoaleatorios, así como sus características de autocorrelación y nivel de aleatoriedad, asegurando que cumplieran con las propiedades de balance y autocorrelación esperadas. Partiendo de esta comprobación se diseñó una herramienta de detección e identificación de los desfasajes de cada canal piloto presente en la transmisión, basando el desarrollo del buscador en el aprovechamiento de las propiedades de los códigos pseudoaleatorios en fase y cuadratura. Se obtuvieron resultados gráficos de la presencia de los canales piloto y los multitrayectos configurados en el transmisor, así como un indicador de la existencia de polución de pilotos. Todos los datos de interés y las gráficas obtenidas son almacenados en el disco duro. La totalidad del diseño se realizó utilizando el software LabVIEW® para la programación de las diferentes etapas del proyecto. Palabras clave: canal piloto, ruido pseudoaleatorio iv A mis abuelos, por todo su cariño y dedicación A todos mis padres, por todo su apoyo y amor A mis hermanos, espero ser siempre su guía y amigo A Miguel, por su gran influencia en mi futuro A Cristina, por todo su amor y compañía A mis amigos, por todos los buenos momentos A Rico, por haber sido parte de mi vida v AGRADECIMIENTOS Primero quisiera a gradecer a toda mi familia porque es gracias a ellos que soy quien soy y como soy, gracias por todos los años de esfuerzo y crianza que invirtieron en mi, espero hacerlos sentir siempre orgullosos. Todo lo que soy es por y para ustedes. De ustedes aprendí los valores necesarios para salir adelante por mis propios medios, ayudando a los demás en el proceso. También aprendí que todo lo valioso de la vida se alcanza con esfuerzo y dedicación, y que la mejor recompensa es el resultado de un trabajo bien hecho. Aún me queda mucho por recorrer y muchos logros que cultivar en el proceso, todos los cuales serán siempre gracias a su apoyo. Por todo esto y mucho más, estaré siempre agradecido y orgulloso de todos. En segundo lugar quisiera agradecer a mi tutor y amigo, el ingeniero Miguel Augusto Díaz Díaz. Mi agradecimiento hacia él se extiende más allá de la realización de este trabajo, sin cuyos valiosos consejos y guía no pudiera haber sido realizado. Fue gracias a sus amplios conocimientos y la inmensa pasión e interés con que imparte sus clases, que decidí en un punto crítico de mi carrera tomar el camino de las telecomunicaciones en definitiva y para siempre. De ahora en adelante, cualquier logro que consiga en esta área, incluyendo la Maestría próxima, será en gran medida gracias a él. Por toda su orientación, apoyo y amistad tendrá hoy y siempre mi gratitud. Quisiera también dedicarle unas palabras de agradecimiento a mi novia Cristina De Sousa, quien siempre tuvo una inmensa paciencia conmigo durante los momentos más difíciles de la realización de este trabajo. Sin sus constantes palabras de aliento e impulso este trabajo no sería ni la mitad de lo que es, y sin ella yo no sería ni la mitad de lo feliz que soy. Gracias mi vida, te amo. vi De igual manera agradezco a todos los amigos que de una u otra forma han influido en mi manera de ser, y con quienes comparto un vínculo que difícilmente se romperá. Inicio mi agradecimiento con los amigos de la infancia: Alexmay, Leo, Oswaldo, Otto, Eder, Moisés, Luis Alexis, Mauro, Juanita y Capriles; definitivamente esos años de colegio estarán siempre en mi memoria, gracias a ustedes por entender todas las veces que no pude ir a la playa o a jugar truco mientras realizaba este trabajo. Siguiendo de manera cronológica quisiera agradecer a mis primeros amigos universitarios: Eduars, Rene, Jorge, Plan, El Viejo, El Catire, Mamantón, Guaipo, y un apartado especial para mi gran amigo Roberto “Bocina” Gil, con quienes viví tantas cosas buenas junto con mis amigas: Mumu, Gaby, Adriana y Diana, quienes estuvieron ahí durante todo ese tiempo también. Agradezco a mi tocayo Daniel por todo lo que compartimos y a mi amigo Christian por todo su interés en la realización de este trabajo y por las muchas horas de estudio en conjunto, sus palabras de aliento siempre ayudaron a mitigar mis mayores preocupaciones. Así llego a mis amigos y grandes trolazos: El Mocho, Fede, Emilio y El Osito, quienes junto con Plan fueron partícipes de innumerables bromas, así como de infinitas horas de laboratorios y proyectos. Gracias a ustedes por ayudarme a hacer más llevadera la odisea de estudiar electrónica en la USB. vii ÍNDICE RESUMEN .......................................................................................................................... iv AGRADECIMIENTOS ...................................................................................................... vi ÍNDICE DE TABLAS ........................................................................................................ xi ÍNDICE DE FIGURAS ...................................................................................................... xii LISTA DE ABREVIATURAS ......................................................................................... xiv INTRODUCCIÓN ............................................................................................................... 1 Justificación e Importancia .............................................................................................. 1 Planteamiento del Problema ............................................................................................. 2 Objetivo General .............................................................................................................. 3 Objetivos Específicos ....................................................................................................... 3 CAPÍTULO 1 FUNDAMENTOS TEÓRICOS .................................................................. 6 1.1. Orígenes de la tecnología ....................................................................................... 6 1.2. Códigos ortogonales y espectro expandido ........................................................... 7 1.3. Códigos Walsh ..................................................................................................... 11 1.4. Códigos de ruido pseudoaleatorio........................................................................ 15 1.5. Identificación de bases de transmisión ................................................................ 21 1.6. Multitrayectos y su recepción .............................................................................. 22 1.7. Modulación QPSK ............................................................................................... 24 1.8. Software LabVIEW ® ......................................................................................... 25 CAPÍTULO 2 GENERACIÓN Y PRUEBA DE LOS CÓDIGOS ................................... 27 2.1. Primera aproximación al espectro expandido ...................................................... 29 2.2. Generación y prueba de los códigos Walsh ......................................................... 31 2.3. Generación y prueba de los códigos PN .............................................................. 33 viii 2.3.1. Diseño de los registros de corrimiento .......................................................... 33 2.3.2. Conversión de los códigos PN binarios ......................................................... 38 2.3.3. Pruebas de los códigos PN ............................................................................ 40 CAPÍTULO 3 DISEÑO DEL GENERADOR Y DEL RECEPTOR ................................ 51 3.1. Resumen del procedimiento experimental ........................................................... 51 3.2. Enfoque inicial, el espectro expandido ................................................................ 52 3.3. Aplicando modulación y demodulación analógica .............................................. 52 3.4. Búsqueda de patrones en arreglos binarios .......................................................... 57 3.5. Generación y detección de multitrayectos ........................................................... 66 3.5.1. Primera aproximación.................................................................................... 66 3.5.2. Generación de trayectos cíclicos ................................................................... 67 3.5.3. Modelo de generación, modulación y demodulación de pilotos ................... 68 3.6. Procesamiento digital y representación gráfica de resultados ............................. 76 3.7. Detección de polución de pilotos ......................................................................... 79 3.8. Solución al problema de las detecciones falsas ................................................... 80 3.9. Recorrido paso a paso del funcionamiento de la herramienta ............................. 82 3.10. Diseño de la interfaz gráfica final .................................................................... 83 CAPÍTULO 4 RESULTADOS Y DISCUSIÓN ............................................................... 89 4.1. Caso ideal: radiobases equidistantes .................................................................... 89 4.1.1. Resultados para pruebas de una radiobase .................................................... 89 4.1.1.1. Cero multitrayectos .................................................................................... 89 4.1.1.2. Un multitrayecto ......................................................................................... 93 4.1.1.3. Dos multitrayectos ...................................................................................... 96 4.1.1.4. Tres multitrayectos ..................................................................................... 99 4.1.2. Resultados para prueba de dos radiobases................................................... 102 4.1.3. Resultados para prueba de tres radiobases .................................................. 106 ix 4.1.4. Resultados para prueba de cuatro radiobases .............................................. 110 4.1.5. Resultados para prueba de cinco radiobases................................................ 115 4.1.6. Resultados para prueba de seis radiobases .................................................. 120 4.2. Caso no ideal: radiobases a diferentes distancias .............................................. 126 4.3. Análisis de resultados y limitaciones del proyecto ............................................ 131 CONCLUSIONES Y RECOMENDACIONES ............................................................... 133 REFERENCIAS BIBLIOGRÁFICAS ............................................................................. 135 APÉNDICES .................................................................................................................... 137 APÉNDICE A: Diagrama de bloques de las etapas del sistema .................................. 138 x ÍNDICE DE TABLAS Tabla 2.1: Resultados para distintos códigos de expansión .............................................. 30 Tabla 4.1: Resultados para el caso 4.1.1.1 ........................................................................ 90 Tabla 4.2: Resultados para el caso 4.1.1.2 ........................................................................ 93 Tabla 4.3: Resultados para el caso 4.1.1.3 ........................................................................ 96 Tabla 4.4: Resultados para el caso 4.1.1.4 ........................................................................ 99 Tabla 4.5: Resultados para el caso 4.1.2 ......................................................................... 103 Tabla 4.6: Resultados para el caso 4.1.3, primera mitad ................................................ 107 Tabla 4.7: Resultados para el caso 4.1.3, segunda mitad ................................................ 107 Tabla 4.8: Resultados para el caso 4.1.4, primera mitad ................................................ 111 Tabla 4.9: Resultados para el caso 4.1.4, segunda mitad ................................................ 112 Tabla 4.10: Resultados para el caso 4.1.5, primer tercio ................................................ 117 Tabla 4.11: Resultados para el caso 4.1.5, segundo tercio.............................................. 117 Tabla 4.12: Resultados para el caso 4.1.5, tercer tercio .................................................. 117 Tabla 4.13: Resultados para el caso 4.1.6, primer cuarto ............................................... 122 Tabla 4.14: Resultados para el caso 4.1.6, segundo cuarto ............................................. 122 Tabla 4.15: Resultados para el caso 4.1.6, tercer cuarto ................................................. 122 Tabla 4.16: Resultados para el caso 4.1.6, último cuarto................................................ 123 Tabla 4.17: Resultados para el caso 4.2, primer tercio ................................................... 128 Tabla 4.18: Resultados para el caso 4.2, segundo tercio................................................. 128 Tabla 4.19: Resultados para el caso 4.2, último tercio .................................................... 128 xi ÍNDICE DE FIGURAS Figura 1.1: Diferentes esquemas de múltiple acceso 7 Figura 1.2: Comparación entre una señal banda estrecha y una de espectro expandido 9 Figura 1.3: Comparación entre expansión por saltos de frecuencia y secuencia directa 10 Figura 1.4: Matriz de códigos Walsh de dimensión 64x64 14 Figura 1.5: Expansión y conversión de formato del canal piloto 15 Figura 1.6: Registro de corrimiento de tres etapas 16 Figura 1.7: Registros de desplazamiento para los códigos PN-I y PN-Q 18 Figura 1.8: Registros de desplazamiento para los códigos PN-I y PN-Q 20 Figura 1.9: Posicionamiento de los 512 pilotos en el código PN 22 Figura 1.10: Múltiples caminos de la señal 23 Figura 1.11: Ilustración del rake receiver 24 Figura 1.12: Constelacion QPSK 25 Figura 2.1: Proceso de generación de la matriz de códigos Walsh 32 Figura 2.2: Generación de los códigos PN binarios 37 Figura 2.3: Conversión de los códigos PN binarios a bipolares 39 Figura 2.4: Primera etapa del protocolo de verificación de autocorrelación 44 Figura 2.5: Segunda etapa del protocolo de verificación de autocorrelación 45 Figura 2.6: Tercera etapa del protocolo de verificación de autocorrelación 46 Figura 2.7: Cuarta etapa del protocolo de verificación de autocorrelación 47 Figura 2.8: Quinta etapa del protocolo de verificación de autocorrelación 48 Figura 2.9: Gráfica de la autocorrelación del código PN-I para 3 detecciones 49 Figura 2.10: Gráfica de la autocorrelación del código PN-Q para 3 detecciones 50 Figura 3.1: Segmento de transmisión de la primera aproximación 54 Figura 3.2: Segmento de recepción de la primera aproximación 54 Figura 3.3: Segmento de transmisión del segundo enfoque 56 Figura 3.4: Segmento de recepción del segundo enfoque 56 Figura 3.5: Primera detección de patrones binarios 58 Figura 3.6: Implementación de la espera de 1000 ciclos 62 Figura 3.7: Ambos casos de la implementación del reset de desfasaje 63 Figura 3.8: Primer esquema de la detección por correlación 67 Figura 3.9: Implementación de la función FIFO en el modulador 70 xii Figura 3.10: Modificación de la función FIFO 71 Figura 3.11: Buscador de coincidencias 73 Figura 3.12: Detector de polución 80 Figura 3.13: Ventana de configuración del transmisor 84 Figura 3.14: Ventana de multitrayectos detectados 85 Figura 3.15: Ventana de radiobases detectadas 86 Figura 3.16: Ventana de datos de control 87 Figura 3.17: Ventana de instrucciones 88 Figura 4.1: Gráfica de trayectos para el caso 4.1.1.1 91 Figura 4.2: Gráfica de radiobases para el caso 4.1.1.1 92 Figura 4.3: Gráfica de trayectos para el caso 4.1.1.2 94 Figura 4.4: Gráfica de radiobases para el caso 4.1.1.2 95 Figura 4.5: Gráfica de trayectos para el caso 4.1.1.3 97 Figura 4.6: Gráfica de radiobases para el caso 4.1.1.3 98 Figura 4.7: Gráfica de trayectos para el caso 4.1.1.4 100 Figura 4.8: Gráfica de radiobases para el caso 4.1.1.4 101 Figura 4.9: Gráfica de trayectos para el caso 4.1.2 104 Figura 4.10: Gráfica de radiobases para el caso 4.1.2 105 Figura 4.11: Gráfica de trayectos para el caso 4.1.3 108 Figura 4.12: Gráfica de radiobases para el caso 4.1.3 109 Figura 4.13: Gráfica de trayectos para el caso 4.1.4 113 Figura 4.14: Gráfica de radiobases para el caso 4.1.4 114 Figura 4.15: Gráfica de trayectos para el caso 4.1.5 118 Figura 4.16: Gráfica de radiobases para el caso 4.1.5 119 Figura 4.17: Gráfica de trayectos para el caso 4.1.6 124 Figura 4.18: Gráfica de radiobases para el caso 4.1.6 125 Figura 4.19: Gráfica de trayectos para el caso 4.2 129 Figura 4.20: Gráfica de radiobases para el caso 4.2 130 xiii LISTA DE ABREVIATURAS CDMA Code Division Multiple Access o Acceso Múltiple por División de Códigos FH Frecuency Hopping o Salto Frecuencial DS Direct Sequence o Secuencia Directa GUI Graphical User Interface o Interfaz Gráfica de Usuario IS-95 Interim Standard o Estándar Interno N° 95 TDMA Time Division Multiple Access o Acceso Múltiple por División de Tiempo FDMA Frecuency Division Multiple Access o Acceso Múltiple por División de Frecuencia PN Pseudo-Noise Code o Código Pseudoaleatorio PN-I In-Phase Pseudo-Noise Code o Código Pseudoaleatorio en Fase PN-Q Quadrature Pseudo-Noise Code o Código Pseudoaleatorio en Cuadratura QPSK Quadrature Phase Shift Keying o modulación por desplazamiento de cuatro fases xiv INTRODUCCIÓN Todo proceso de comunicación inalámbrico es por definición susceptible de recibir interferencias externas, por tratarse de un medio de propagación desprotegido y cuyas características varían en el tiempo en función de diversas variables tanto ambientales como humanas. En el caso de la tecnología celular, estas interferencias degradan el nivel de cobertura y la calidad de servicio que se presta a los suscriptores. La transmisión de datos a través de la técnica de espectro expandido ha sido usada desde hace años en comunicaciones militares para resistir interferencia intencional y para lograr una baja probabilidad de detección [1]. Sin embargo, en años recientes la técnica de espectro expandido se ha desplazado hacia las comunicaciones comerciales, llevando a la introducción del Interim Standard (Estándar Interno) IS-95, el cual define la tecnología de múltiple acceso por división de códigos como un estándar para el desarrollo de redes comerciales de telefonía celular digital y sistemas de comunicación personal. Desde entonces han sido implementados sistemas CDMA en las principales áreas metropolitanas, haciendo uso del estándar IS-95 en diversas ciudades alrededor del mundo. Este hecho ha incrementado la densidad de usuarios presentes en las redes, por lo que se ha hecho necesaria su expansión a través del despliegue de nuevas estaciones de transmisión y recepción. Justificación e Importancia La ampliación de las redes de este tipo por medio de la instalación de nuevas celdas se hace cada vez más difícil con el paso del tiempo, debido a que cada vez son más las celdas preexistentes en la zona de interés al momento de la implementación de una nueva. Este hecho impacta directamente en la planificación y localización de las radiobases en la topografía del terreno a ser cubierto por el proveedor de servicios. Para llevar a cabo dicha planificación se requiere hacer diversas mediciones de campo para estimar la calidad de la cobertura a través de parámetros como la potencia, la relación señal a ruido, y en el caso de CDMA, la relación de potencia de cada código. También se requiere conocer todas las celdas de las cuales se reciben 2 señales en un punto a fin de estudiar posibles fuentes de interferencia. Todas estas mediciones involucran generalmente equipos muy sofisticados y de alto costo, el cual incide directamente en los costos totales de planificación e implementación del sistema en la zona. Es por esto que el desarrollo de una herramienta de análisis de menor costo provee una solución para reducir los costos de implementación de la tecnología. Planteamiento del Problema Para poder llevar a cabo el desarrollo de la herramienta de análisis propuesta, es necesario conocer a fondo cómo funciona el sistema CDMA. El estándar IS-95 define la normativa que rige todos los procesos involucrados en la transmisión de señales mediante la implementación de la tecnología celular CDMA, por lo que un estudio detallado del mismo podrá indicarnos cuál es el parámetro a medir a la hora de obtener la potencia de un código CDMA. De la misma manera, es importante conocer de qué manera influyen los diversos trayectos que toma la señal antes de llegar al dispositivo móvil, o en este caso, al medidor; así como de qué manera se enmascaran las señales en el trayecto entre la estación de transmisión y el dispositivo móvil o medidor. Otros puntos críticos a conocer se relacionan con la manera como se realiza la expansión del espectro en CDMA, así como el proceso de generación de los códigos utilizados por el sistema para los diversos canales. Una vez obtenidas las respuestas a estas interrogantes, surgen otras relacionadas con la manera mediante la cual se van a implementar todos estos procesamientos de los datos, tanto para la generación de señales de prueba, como para su posterior detección y medición para generar los resultados gráficos deseados. Este proyecto se enfoca en la identificación de las celdas presentes en un punto geográfico determinado, lo cual es un indicativo de posibles interferencias debidas a la recepción de señales de varias estaciones. Esto permitirá al usuario poder analizar las posibles fuentes que generan esta recepción excesiva y tomar acciones correctivas que representen un aumento en la capacidad de la red, específicamente para redes que implementen la tecnología celular CDMA2000-1X (Code 3 Division Multiple Access, o Acceso Múltiple por División de Código) como método de transmisión y recepción de la información. Objetivo General Desarrollar una herramienta de simulación que permita el monitoreo de las señales de un sistema CDMA2000-1X con el fin de identificar las celdas recibidas en un punto geográfico determinado, provista de una interfaz gráfica que permita la visualización de los distintos pilotos que se reciben en dicho punto. Objetivos Específicos − Identificar cómo se generan los pilotos en el sistema. − Evaluar de qué manera influyen los diversos trayectos que toma la señal antes de llegar al medidor. − Determinar el proceso de enmascaramiento de las señales en el enlace de bajada. − Investigar sobre el funcionamiento de los distintos módulos que posee el software LabVIEW 8.5 con el que se desarrollará la herramienta. − Identificar cómo se realiza la expansión del espectro en CDMA. − Determinar el orden de los pasos que sigue el procedimiento de generación en general y evaluar el proceso de reversión que debe aplicarse para la obtención de la señal original. CAPÍTULO 1 FUNDAMENTOS TEÓRICOS 1.1. Orígenes de la tecnología En la constante evolución de los procesos de comunicación del ser humano, hemos llegado a una era en la que gran parte del trafico de información, ya sea de datos o de voz, es realizado de manera inalámbrica. Dentro del vasto campo de las telecomunicaciones inalámbricas han venido suscitándose grandes avances en lo referente a las diversas maneras de transmitir y recibir las señales de radiofrecuencia que transportan la información. Uno de estos avances viene a ser la tecnología celular CDMA (Code Division Multiple Access, o Acceso Múltiple por División de Código). El término acceso múltiple se refiere al hecho de que múltiples usuarios son capaces de usar el sistema celular simultáneamente. Los sistemas de acceso múltiple comparten un recurso limitado (por ejemplo, el espectro frecuencial) para proveer a los usuarios con canales de voz por demanda. Los métodos tradicionales de separación de señales en tiempo (TDMA, Time Division Multiple Access o Acceso Múltiple por División de Tiempo), o en frecuencia (FDMA, Frecuency Division Multiple Access o Acceso Múltiple por División de Frecuencia) presentan maneras relativamente simples de asegurar que las señales son ortogonales y no interferentes. En el caso de TDMA, el acceso múltiple se realiza por medio de time slots o ranuras de tiempo; mientras que en el FDMA, es logrado mediante la asignación de frecuencias distintas a cada usuario, separadas por una banda de guarda para prevenir interferencias. Sin embargo, en CDMA diferentes usuarios ocupan el mismo espectro frecuencial al mismo tiempo, pero son separados el uno del otro a través del uso de una serie de secuencias o códigos ortogonales. La Figura 1.1 ilustra las diferencias previamente explicadas. 7 Figura 1.1: Diferentes esquemas de múltiple acceso Fuente: Yang, S., “CDMA RF System Engineering”, p. 45 1.2. Códigos ortogonales y espectro expandido El espectro expandido es un medio de transmisión en el que la señal ocupa un ancho de banda por encima del mínimo necesario para enviar la información; la expansión se realiza por medio de un código que es independiente de los datos, y un receptor sincronizado con el código es utilizado para comprimir y recuperar los datos [2]. Esta característica de acceso al medio permite que en el sistema CDMA el mismo sea compartido por todos los usuarios activos, sin necesidad de ser divididos en múltiples ranuras ocupadas individualmente como en el caso de TDMA o FDMA. A primera vista no parece lógico el hecho de que incrementar deliberadamente el ancho de banda requerido para la transmisión incremente a su vez la capacidad del sistema, después de 8 todo, en un esquema tradicional como el de múltiple acceso por división de frecuencias incrementar el ancho de banda requerido para cada usuario implica una disminución del número total de usuarios que el espectro puede soportar (tomando en cuenta que el espectro es un recurso de tamaño fijo, limitado por un organismo rector). La ventaja de esta expansión para el caso de CDMA, es que le confiere la habilidad de mitigar el efecto de la distorsión por multitrayectos, así como una resistencia adicional a desvanecimientos profundos que pudiesen ocurrir en bandas de frecuencia específicas. Para el caso de una distorsión fija o de variaciones lentas, la misma pudiera ser contrarrestada con ecualización adaptativa, es decir, llevando a cabo un ajuste dinámico de la amplitud del filtro de recepción para cada frecuencia incluida en la ventana de filtraje. Pero por otra parte, si la distorsión varía rápidamente en función del tiempo, como sucede en el caso de un ambiente móvil, sería realmente difícil lograr una adaptación lo suficientemente rápida como para lograr una correcta adecuación de la señal. El espectro expandido provee una medida extra de inmunidad a este tipo de distorsión, lo cual puede apreciarse claramente en el dominio de las frecuencias ya que el desvanecimiento por multitrayectos genera una disminución importante de la amplitud de la señal para una banda específica. En cambio, esta disminución tendría poco efecto en la calidad total de la señal si la misma se encontrara expandida en una banda espectral mucho mayor. La característica de expansión de espectro del sistema CDMA hace a la comunicación robusta en ambientes de desvanecimiento por multitrayectos. A medida que el ancho de banda de la señal aumenta, la probabilidad de desvanecimiento profundo para la banda completa de la señal disminuye (ver Figura 1.2). En consecuencia, el receptor puede detectar la señal correctamente usando la información parcial transmitida sobre las bandas de frecuencia no atenuadas, para la mayor parte del tiempo de la comunicación. 9 Figura 1.2: Comparación entre una señal banda estrecha y una de espectro expandido Fuente: Ilustración realizada por el autor Para el caso de la tecnología CDMA, la expansión del espectro puede ser lograda mediante la implementación de dos técnicas diferentes: frecuency hopping (FH) o por salto de frecuencia, y direct-sequence (DS) o por secuencia directa. La primera viene a ser la técnica en la cual la señal transmitida es desplazada de manera pseudoaleatoria por el sintetizador de frecuencias dentro de una banda de frecuencias específica denominada banda de saltos (del inglés hopping bandwidth). De esta manera se minimizan los efectos de interferencia e intercepción por parte de terceros, ya que la misma se encuentra constantemente cambiando su frecuencia de transmisión. La expansión espectral viene dada en este caso por la implementación de la banda de saltos. Por otra parte, la técnica de secuencia directa o DS, por sus siglas en inglés, se realiza mediante la multiplicación de la señal de datos con una señal de alta velocidad (banda ancha), la cual realiza la expansión de la totalidad del mensaje a transmitir, sin realizar cambios en la frecuencia de transmisión. De esta manera si la señal de datos es de banda estrecha en comparación con la señal de expansión, como en efecto lo es para el caso en estudio, la señal resultante de la multiplicación directa de estas señales tendrá aproximadamente el ancho de banda de la señal de expansión [3]. La señal resultante al aplicar el procedimiento de expansión por 10 secuencia directa al sistema CDMA se conoce entonces como DS/CDMA. En la Figura 1.3 se aprecia claramente el comportamiento de ambas técnicas en el dominio de las frecuencias, pudiéndose notar la expansión en una banda mayor a la de la señal original. Figura 1.3: Comparación entre expansión por saltos de frecuencia y secuencia directa Fuente: http://www.futaba.com/products/irc/technology/index.asp consultado el día 20/09/2010 En CDMA, la señal de banda estrecha de cada usuario es expandida a un ancho de banda que es mayor al mínimo requerido para transmitir la información. Cada una de estas señales es expandida con un código diferente, logrando de esta manera la canalización de usuarios simultáneos mediante la utilización de códigos ortogonales. Todas las señales expandidas correspondientes a cada uno de los usuarios son unidas para conformar una sola señal compuesta, la cual es transmitida al aire en la misma banda frecuencial. Por su parte, el receptor es capaz de distinguir entre los diferentes usuarios usando una copia del código original, correlacionando este último con la señal compuesta recibida. Al hacer esto, las señales de los demás usuarios que no posean el código utilizado serán rechazadas. 11 El sistema IS-95 posee enlaces asimétricos, es decir, el enlace de la base de transmisión al móvil o forward link (enlace de avance) y el del móvil a la base de transmisión o reverse link (enlace inverso) tiene cada uno diferentes estructuras. Las diferencias van desde el esquema de modulación hasta los métodos de control de error. Además, cada enlace utiliza códigos diferentes para canalizar usuarios individuales. El forward link está constituido por cuatro tipos de canales lógicos: un pilot channel (canal piloto), un sync channel (canal de sincronismo), hasta siete paging channels (canales de mensajes del sistema) y el resto son traffic channels (canales de tráfico). Cada uno de estos canales del forward link es primero expandido ortogonalmente mediante una función Walsh y luego es enmascarado por un par de secuencias PN cortas, de longitud 215. Todos estos canales son sumados para conformar la señal compuesta a ser transmitida hacia los móviles [2]. El reverse link, por su parte, consiste de dos tipos de canales lógicos: access channels (canales de acceso) y traffic channels (canales de tráfico). Cada uno de estos canales es expandido ortogonalmente por un único código PN largo, de longitud 242; por lo tanto, cada canal es identificado utilizando el código PN largo individual. La razón por la cual no es utilizado un canal piloto es debido a que es impráctico que cada móvil se encuentre transmitiéndolo constantemente. Sin embargo, el reverse link no es motivo de estudio en el presente trabajo, por lo que no se considerará en adelante. 1.3. Códigos Walsh Como hemos visto, en aplicaciones celulares típicas la señal DS/CDMA es generada mediante dos pasos: la expansión y el enmascaramiento. Primero un código de expansión ortogonal es multiplicado con la secuencia de datos, lo cual expande el ancho de banda de la señal de cada usuario y la hace ortogonal con respecto a la del resto de los usuarios. En el caso del enlace de bajada de un sistema IS-95 se utilizan códigos Walsh ortogonales de una longitud de 64 chips para esta expansión espectral, ya que la ortogonalidad evita la interferencia mutua entre diferentes usuarios. 12 Se denominan chips a la unidad básica de transmisión del mensaje expandido como una manera de diferenciarla de los bits de datos originales. De esta manera la tasa de chips de un código viene a ser el número de pulsos (o chips) por segundo al cual se realiza la transmisión o recepción del mismo. La tasa de chips suele ser mucho mayor a la tasa de bits del mensaje original, lo que significa que cada bit es representado por múltiples chips. A la relación del número de chips utilizados por cada bit para su expansión se le conoce como spreading factor o factor de expansión. En el caso de los códigos Walsh utilizados en la tecnología celular CDMA2000-1X, el factor de expansión es de 64. Esto significa que por cada bit de datos se transmiten 64 chips, por lo que la velocidad de transmisión de 19,2 Kbps se convierte en una tasa de chips de 1,2288 Mcps. Para la generación de los códigos de expansión que convertirán los bits en chips se emplea la matriz Hadamard, donde se emplea la recursión para generar matrices de mayor orden a partir de matrices de menor orden. Para ello se emplea la siguiente expresión: (1.1) donde contiene los mismos elementos de , pero de manera invertida. Para ejemplificar esto, veamos cómo la semilla utilizada para generar los códigos Walsh (ecuación 1.2) es invertida para formar la siguiente matriz de dimensión 4x4 (ecuación 1.3). 0 0 0 0 0 0 0 1 0 1 0 1 0 0 1 1 (1.2) 0 1 1 0 (1.3) 13 De esta manera se obtienen entonces cuatro códigos Walsh ortogonales, a partir de las filas de la matriz obtenida en la ecuación 1.3: 0 0 0 0 0 1 0 1 0 0 1 1 0 1 1 0 (1.4) Utilizando recursivamente la ecuación 1.1 se generan matrices de mayor orden para obtener conjuntos mayores de secuencias ortogonales. De esta manera es posible obtener una matriz de 64x64, de donde se obtendrán entonces los 64 códigos Walsh ortogonales utilizados por el sistema a partir de las 64 filas de la matriz obtenida (ver Figura 1.4). El código Walsh asignado a un usuario en el enlace de bajada es único para dicho usuario. Por otra parte, códigos Walsh dedicados pueden ser utilizados para canales comunes que serán monitoreados por todos los móviles, como en el caso del canal de piloto y el de sincronismo. En el enlace de subida, sin embargo, diferentes códigos Walsh transmitidos por un mismo usuario pueden indicar diferentes tipos de información. Por ejemplo, un usuario puede transmitir datos utilizando un código y voz utilizando otro código diferente [4]. En el caso particular del canal piloto que no transmite datos, el mismo se compone únicamente de ceros en su forma binaria, por lo que al realizar la expansión con el código W0 compuesto también únicamente de ceros se obtiene una salida igualmente compuesta únicamente de ceros. Antes de seguir al proceso de enmascaramiento, los chips de todos los canales se convierten a un formato que facilite su modulación analógica. Esta conversión se realiza intercambiando los ceros binarios por el valor +1 y los unos binarios por el valor -1. Es así como el canal piloto se compondrá únicamente de valores +1 a la salida de la conversión [5]. Esto se ejemplifica claramente en la Figura 1.5. 14 Figura 1.4: Matriz de códigos Walsh de dimensión 64x64 Fuente: TIA/EIA-95-B, “Mobile Station-Base Station Compatibility Standard for Dual-Mode Spread Spectrum Systems”, p. 7-22 15 Figura 1.5: Expansión y conversión de formato del canal piloto Fuente: Ipatov, V., “Spread Spectrum and CDMA: Principles and Applications”, p. 348 1.4. Códigos de ruido pseudoaleatorio Para poder hablar en detalle sobre la generación y utilización de los códigos de ruido pseodoaleatorios, debemos primero definir qué significa exactamente este término. La palabra pseudo viene del griego, y es utilizada como prefijo para indicar falsedad. En este caso en particular, indica que realmente no hay aleatoriedad en los códigos PN. Una señal aleatoria no puede ser predicha, por lo que sus variaciones futuras solo pueden ser descritas en un sentido estadístico. Sin embargo, una señal pseudoaleatoria no es en absoluto aleatoria, por el contrario, es una señal periódica y determinística que es conocida tanto para el emisor como para el receptor. El motivo por el cual se le confiere esta característica de aleatoriedad, es debido a que para cualquiera que no posea el código, el mismo aparece como una señal realmente aleatoria dado que parece poseer las propiedades estadísticas del ruido blanco [3]. Para poder verificar que en efecto el código PN posee características de aleatoriedad para agentes externos, deben comprobarse tres propiedades básicas: 16 ‐ Propiedad del Balance: En cada período de la secuencia el número de unos y ceros binarios deben ser iguales o al menos no deben diferir en más de uno. ‐ Propiedad de la Correlación: Si un período de la secuencia es comparado término a término con cualquier versión desplazada de él mismo, es deseable que el número de coincidencias difiera del número de no coincidencias en no más de uno. ‐ Propiedad de la Corrida: Una corrida se define como una secuencia consecutiva del mismo tipo de dígito binario. Es deseable que la mitad de las corridas de cada tipo sean de longitud 1, una cuarta parte de longitud 2, una octava parte de longitud 3, y así sucesivamente. Los códigos PN son generados a partir de linear feedback shift registers o registros de desplazamiento lineales retroalimentados. Un ejemplo de esto puede apreciarse en la Figura 1.6, donde se ilustra un registro de desplazamiento de tres etapas. Los dígitos binarios son desplazados a través de las diferentes etapas del registro y la salida de la última etapa es combinada con una intermedia para servir de entrada a la primera. De esta manera el registro genera continuamente bits de salida que son realimentados. Estos bits de salida son precisamente los que conforman el código PN [2]. Figura 1.6: Registro de corrimiento de tres etapas Fuente: Ilustración realizada por el autor 17 El lazo de realimentación consiste en este caso de una adición módulo 2 de las etapas involucradas. Como resultado de esto, para que el registro de corrimiento pueda funcionar correctamente debe existir un estado de inicialización en el que no todos los registros se encuentren con un valor de cero lógico; de otra manera la secuencia producirá únicamente ceros a la salida y tendremos un ciclo infinito [4]. Como se mencionó anteriormente, una propiedad importante de los códigos PN binarios generados con registros de corrimiento de máxima longitud es que los mismos son ortogonales con versiones desplazadas de sí mismos. De esta manera, al sustituir los unos y ceros binarios por los valores -1 y +1 respectivamente, puede comprobarse que se cumpla la siguiente función de auto correlación: ∑ donde 2 1 1, 1, 0 0 (1.5) viene a ser la autocorrelación del código PN, Ci es el código utilizado y Ci-τ una versión desplazada del mismo [4]. De una forma más sencilla, la fórmula de la autocorrelación también puede entenderse de la siguiente manera [3]: ú ó í í (1.6) í donde p es el tamaño de un período completo del código a analizar. En el caso particular de CDMA, cada canal se expande mediante el uso de códigos PN en fase y cuadratura, tal como lo indica la Figura 1.6. La secuencia de expansión debe ser de longitud 215 chips, es decir, 32768 chips. La componente en fase se conoce como PI (del inglés in 18 phase o en fase), y la componente en cuadratura de conoce como PQ (del inglés quadrature o cuadratura). Estas secuencias son llamadas secuencias PN piloto, y se generan mediante los siguientes polinomios característicos: [6] PI(x) = x15 + x13 + x9 + x8 + x7 + x5 + 1 (1.7) PQ(x) = x15 + x12 + x11 + x10 + x6 + x5 + x4 + x3 + 1 (1.8) A continuación se ilustran los registros de desplazamiento que se generan a partir de los polinomios característicos mencionados, los cuales proporcionarán a su salida el código PN respectivo a cada uno de ellos, es decir, en fase y cuadratura (ver Figura 1.7). Figura 1.7: Registros de desplazamiento para los códigos PN-I y PN-Q Fuente: Ilustración realizada por el autor 19 Las secuencias de máxima longitud generadas por los registros de corrimiento mostrados son de longitud 215-1, es decir, 32767 chips. Para completar el número adecuado de 32768 chips se procede a insertar un cero en ambos códigos, donde se presente una corrida de 14 ceros consecutivos. Esto sucede una sola vez en todo el período para ambos códigos, ya que representa la salida de la semilla o estado inicial de las etapas, en la que se introducen ceros en las catorce primeras y un uno en la quinceava. De esta manera se completa entonces una corrida ahora de 15 ceros y los códigos tienen ambos 32768 chips de longitud. Es importante notar que al introducir este cero se realiza un balanceo del número total de unos y ceros que posee el código, cumpliendo así con la Propiedad del Balance previamente explicada. Debido a las características de aleatoriedad ya mencionadas que poseen los códigos PN, los mismos son utilizados en el forward link luego de la expansión por código Walsh. A la señal de datos expandida se le aplica un proceso de aleatorización al multiplicarla con un código PN, generalmente de la misma tasa, lo que genera un enmascaramiento por chips. El código PN utilizado se conoce como el código de enmascaramiento de la señal. Así, cada usuario CDMA percibe a los demás usuarios como una señal de ruido aleatorio, y la colisión de las señales entre usuarios puede ser evitada a pesar de que ocupan el mismo espectro. De esta manera, cada usuario puede aprovechar plenamente el medio hasta que el nivel de interferencia proporcional al número de señales aleatorias multiusuario no hace posible la transmisión de mayores cantidades de información sobre el mismo. Esto es especialmente beneficioso cuando la tasa de transmisión de datos es variable en el tiempo, lo cual es muy común en aplicaciones de comunicaciones prácticas. En un ambiente de telefonía celular móvil, la señal DS/CDMA transmitida usualmente llega al receptor a través de múltiples vías de propagación con retardos diferentes para cada una, dado que la señal sufre reflexiones ocasionadas durante el trayecto por la colisión con el sinnúmero de obstáculos que presentan los ambientes urbanos actuales. Es por esto que la ortogonalidad entre canales de datos impuesta en el proceso de expansión por códigos Walsh a menudo no puede mantenerse en el receptor. Además, como la propiedad de auto correlación y la correlación cruzada de los códigos de expansión ortogonales es muy pobre, la interferencia resultante de la propagación multitrayectos puede degradar críticamente el desempeño de la 20 detección de datos, a no ser que sea tomada otra medida preventiva. Por tanto, el proceso de enmascaramiento que aleatoriza la señal mientras mantiene una buena correlación es esencial en comunicaciones DS/CDMA inalámbricas. Para lograr este enmascaramiento previo a la modulación analógica, una vez que los datos expandidos por la función Walsh correspondiente de acuerdo al canal son sumados para formar la señal a transmitir, esta es multiplicada de manera paralela por los códigos PN-I y PN-Q. De cada una de estas ramas se obtiene entonces lo que será la entrada del modulador QPSK (del inglés Quadrature Phase Shift Keying o modulación por desplazamiento de fase en cuadratura). La rama PN-I se modula a través de una sinusoide, y la rama PN-Q a través de una onda cosenoidal. Luego ambas señales analógicas se suman para de esta manera obtener la señal de transmisión hacia los dispositivos móviles. Un diagrama de este proceso puede apreciarse con mayor claridad en la Figura 1.8 Figura 1.8: Registros de desplazamiento para los códigos PN-I y PN-Q Fuente: Ipatov, V., “Spread Spectrum and CDMA: Principles and Applications”, p. 351 21 1.5. Identificación de bases de transmisión En el enlace de bajada una secuencia de enmascaramiento específica es asignada a cada celda, lo que hace que tanto las interferencias de celdas cercanas como las interferencias producidas por los demás usuarios de la celda sean detectadas como ruido aleatorio en el receptor [7]. Por otra parte, en el enlace de subida una secuencia de enmascaramiento es asignada específicamente a cada usuario, ya que la alineación temporal entre diferentes usuarios no está garantizada. En sistemas con sincronía inter-celda, tales como el CDMA2000-1X, tanto las estaciones de radio como los receptores móviles pueden alinear sus temporizadores a una referencia de tiempo externa. En consecuencia, en aras de la simplicidad de la circuitería y de la facilidad de coordinación del sistema, es empleado un código de enmascaramiento común en todas las estaciones de radio y receptores móviles del sistema, teniendo cada estación de radio un desfasaje único de dicho código para prevenir colisiones entre las señales [8]. El canal piloto viene a ser entonces la referencia para todos los terminales a la hora de llevar a cabo la demodulación de la señal. Es además el parámetro mediante el cual los terminales seleccionan e identifican a las estaciones de radio que se encuentren en las cercanías, ya que los canales piloto de todas las estaciones de radio son configurados con una potencia de 4 a 6 dB mayor que los canales de tráfico, para que dichos terminales puedan detectarlos. Todas las antenas de transmisión usan el mismo código PN, y cada celda en específico se identifica con un desfasaje de dicho código PN. La sincronización es coordinada mediante el uso de radios de GPS (Global Positioning System o sistema de posicionamiento global) en las bases de transmisión, ya que este sistema no solo provee triangulación para determinar su ubicación geográfica, sino que también provee un servicio de relojes sincronizados fácilmente disponibles [9]. Es entonces este único desfasaje quien sirve como indicador de cada una de las estaciones de radio, por lo que en la planificación de la red debe tomarse en consideración la frecuencia con la cual cada desfasaje es utilizado, así como qué desfasajes son utilizados entre estaciones de radio vecinas. Esto es lo que viene a ser el concepto de re-uso en un sistema celular CDMA donde realmente no se re-usan las frecuencias de transmisión sino los desfasajes del código PN. 22 Los desfasajes entre los distintos canales piloto de las estaciones de radio del sistema se dan en incrementos de 64 chips, por lo que con un tamaño total del código de 32768 chips se obtienen un total de 512 desfasajes únicos (ver Figura 1.9). Es por esto que las posibles confusiones por parte de los terminales móviles a la hora de sincronizarse con uno de estos canales piloto son generadas mayormente por la disponibilidad de varios de ellos (inicialmente tres, actualmente cuatro) [10] con un nivel de potencia lo suficientemente fuerte como para considerarse dentro del rango que lo hace elegible por el terminal, haciendo poco fiable la identificación de la mejor señal [9]. Esta condición se conoce con el nombre de polución de pilotos, y es una condición no deseable en el sistema ya que afecta directamente la capacidad de número de usuarios y las velocidades de transmisión de los mismos. [11] Figura 1.9: Posicionamiento de los 512 pilotos en el código PN Fuente: Prateek S., “Impact of Pilot Channel Pollution in CDMA Systems”, p. 1 1.6. Multitrayectos y su recepción En un ambiente de telefonía celular, la señal llega a través de diferentes caminos y en diferentes momentos al receptor. Esto es debido a la presencia de objetos que se interponen en el camino y generan reflexiones (ver Figura 1.10). Los multitrayectos pueden ser divididos a manera general en tres categorías, de acuerdo a la medida de tiempo entre la llegada del primer 23 trayecto y la del último. Estas categorías son: desvanecimiento, confusión de chips y eco. En el ambiente de telefonía móvil, el eco no suele ser un problema ya que los caminos de la señal rara vez tienen longitudes tan extensas. Para el caso del desvanecimiento, como ya hemos visto, el espectro expandido provee un alto nivel de protección debido a que los desvanecimientos suelen ser en frecuencias específicas y la expansión espectral nos permite obtener la señal del resto de la banda de frecuencia. Pero las diferencias comparables a varios tamaños de chip son las que realmente afectan al sistema, ya que el receptor detecta dos chips diferentes al mismo tiempo. Figura 1.10: Múltiples caminos de la señal Fuente: Rosenberg, A. y Kemp S., “CDMA Capacity and Quality Optimization”, p. 96 Considerando tres trayectos de igual potencia, cuando un chip es transmitido llegará al receptor tres veces separadas. Un receptor único se sincroniza con uno de los tres trayectos y los otros dos trayectos están corridos en tiempo, por lo que producen interferencia. La mejor solución para este problema es la de sumar las tres señales recibidas en el orden inverso a su retraso, esto se conoce como rake receiver o receptor rastrillo y viene a ser un adaptative matched filter o un filtro adaptativo emparejado, donde cada representación de la señal se conoce como uno de los filamentos del rastrillo (ver Figura 1.11). La suma de los tres trayectos genera el chip deseado 24 con el triple de la amplitud, lo cual es proporcional a nueve veces la potencia, que viene a ser el cuadrado de la amplitud, por lo que la implementación de este tipo de receptor ayuda a mitigar enormemente los efectos causados por los multitrayectos en la señal de CDMA [9]. Figura 1.11: Ilustración del rake receiver Fuente: Schulze H. y Lüders C., “Theory and Applications of OFDM and CDMA”, p. 268 1.7. Modulación QPSK Los esquemas de modulación PSK mapean los bits de información a fases del círculo unitario en el plano complejo. La modulación por desplazamiento de fase en cuadratura involucra el mapeo de dos bits de entrada a uno de cuatro posibles valores de la constelación. Un ejemplo de esta puede apreciarse en la Figura 1.12. Puede notarse la utilización de codificación Gray, la cual realiza el mapeo de parejas de bits en la constelación de símbolos de modulación de una manera tal que los símbolos de modulación adyacentes difieran sólo en un bit. [12] 25 Figura 1.12: Constelacion QPSK Fuente: Mandyam G. y Lai J., “Third-Generation CDMA Systems for Enhanced Data Services”, p. 31 1.8. Software LabVIEW ® El software LabVIEW es una plataforma y ambiente de desarrollo para un lenguaje de programación visual de la compañía National Instruments. Sus siglas significan Laboratory Virtual Instrumentation Engineering Workbench o laboratorio de ingeniería de instrumentación virtual, y es comúnmente usado para la adquisición y procesamiento de señales, control instrumental y automatización industrial. Su lenguaje de programación, también conocido como “G” es un lenguaje de programación de flujo de datos. La ejecución está determinada por la estructura de un diagrama 26 de bloques gráfico en el cual el programador conecta diferentes nodos mediante cables virtuales. Estos cables propagan las variables y cada nodo puede ejecutarse tan pronto como todos los datos de entrada conectados al mismo estén disponibles en sus terminales. Los programas y subrutinas creados en LabVIEW reciben el nombre de instrumentos virtuales o VI’s, por sus siglas en inglés. Cada VI tiene tres componentes: un diagrama de bloques, un panel frontal y un panel de conexiones; este último es usado para representar al VI en el diagrama de bloques de otro, a manera de subrutina. Controles e indicadores en el panel frontal permiten al operador introducir o extraer datos de un VI en ejecución. CAPÍTULO 2 GENERACIÓN Y PRUEBA DE LOS CÓDIGOS El procedimiento general a seguir para la realización del proyecto incluye varias etapas y sub-etapas. Debido a que el proyecto final es una parte del receptor de señales DS/CDMA, para poder verificar su correcto funcionamiento deben primero crearse estas señales, teniendo éstas parámetros configurables que puedan ser obtenidos luego con el receptor. Tenemos entonces que inicialmente se divide el proyecto en tres grandes etapas: generación de señales DS/CDMA, recepción correcta de las señales generadas y procesamiento de las mismas. Dentro de la etapa de generación existen a su vez varias sub-etapas; primero debe generarse el piloto, luego éste debe expandirse con el código Walsh apropiado. Posteriormente debe enmascararse con el código PN en fase y cuadratura con un desfasaje específico, obtener una amplitud y modularse para finalmente ser sumado con una cantidad variable de pilotos, cada uno de los cuales contará con un desfasaje del código PN usado para su enmascaramiento. Tanto los desfasajes, como las amplitudes y el número de pilotos y multitrayectos pueden ser configurados por el usuario para simular un canal de radio. En la etapa de recepción debe realizarse el proceso inverso, iniciando por la demodulación de la señal para su procesamiento en búsqueda de los desfasajes y amplitudes configurados en el generador. Para ello se tomará la señal de entrada constituida por la suma de todos los trayectos y se analizarán sus características de correlación punto a punto mediante un código PN que se desplaza al doble de la velocidad y permite recorrer la señal entera en búsqueda de los desfasajes para los cuales exista una alta correlación, hallando así los desfasajes generados y las amplitudes asociadas a cada uno de ellos. 28 En la etapa de procesamiento de los datos se guardan en un arreglo todos estos desfasajes encontrados y sus amplitudes asociadas, para cada una de las componentes en fase y cuadratura. De esta manera podrán luego detectarse las coincidencias entre ambas y obtener los desfasajes y amplitudes de todos los trayectos recibidos correctamente. Luego se implementará una versión propietaria del code search (buscador del código del piloto) para agrupar los trayectos de la misma estación de transmisión en un solo trayecto de mayor potencia y mostrarlo en la posición determinada para dicha estación. Posteriormente se analizarán las potencias finales de todas las estaciones de transmisión detectadas para determinar si están dadas o no las características de una situación de polución de pilotos. Se presentarán gráficamente los resultados obtenidos para todos los trayectos, así como para las estaciones detectadas, junto con un indicador visual de la existencia o no de polución de pilotos. Como tarea final, se organizará la configuración de los desfasajes, amplitudes y número de pilotos y trayectos, así como las gráficas previamente mencionadas y otros datos de control en una GUI (graphical user interface o interfaz gráfica de usuario) que permita un manejo sencillo de la herramienta por parte de cualquier tipo de usuario. A manera de inicio del trabajo experimental, se procedió con la instalación del software LabVIEW 8.5 en el sistema operativo Windows XP. Una vez culminado este proceso fue instalado un módulo complementario llamado Modulation Toolkit (o herramientas de modulación), el cual contiene un compendio de funciones especializadas para la generación y medición de señales analógicas y digitales, así como otras herramientas inherentes a tareas de procesamiento de señales. Luego se llevaron a cabo algunas pruebas sobre la funcionalidad del programa, tales como crear una función simple que realizara varias operaciones matemáticas, observar los resultados en el panel de control, personalizar la apariencia de los indicadores, entre otras; todo esto con el motivo de familiarizarse con el funcionamiento y la manera de utilizar el programa para ejecutar comandos como inicialización de variables, creación de constantes y utilización de las funciones prefabricadas. 29 2.1. Primera aproximación al espectro expandido Una vez culminada la fase de exploración del software, se realizó una prueba más específica en relación a sus capacidades para proporcionar expansión espectral a un stream (o flujo) de datos binarios para asegurar que de hecho sería posible utilizar las funcionalidades del Modulation Toolkit. Para llevar a cabo esta prueba se utilizó la función Spread Symbols (o expandir símbolos), con una entrada de datos binarios aleatorios. De esta manera se pretendía comprobar que sin importar cuál fuera la entrada específica para un momento dado, la función generara la correcta expansión de la misma. Esta entrada se realizó mediante la implementación de un for loop (o ciclo de repetición condicional), cuyo número de repeticiones estaría controlado por el usuario en el panel frontal. Dentro de este for loop se encuentra un generador de números aleatorio, cuya salida están entre 0 y 1 para cada una de las veces que se realice el ciclo. A esta salida se le resta el valor de 0,5 teniendo entonces un resultado aleatorio y equiprobable entre -0,5 y 0,5. En este punto se agrega un comparador para determinar si el resultado es mayor o menor a cero, obteniendo una salida booleana; en el caso de ser mayor a cero el valor de true o verdadero se convierte en un bit 1 y en el caso contrario, es decir, false o falso, en un bit 0. Una vez culminado el número de ciclos especificados por el usuario, se obtiene un arreglo unidimensional de longitud igual a dicho número; este arreglo contiene un bit en cada casilla y los mismos son aleatoriamente 1 o 0. En este punto se agrega un indicador para observar los datos que servirán de entrada al proceso de expansión y así poder compararlos con los que se esperan obtener teóricamente luego de dicho proceso. Además de la entrada de los datos, la función debe ser configurada con otro parámetro importante: el código de expansión. Por tratarse de una primera prueba se utilizó un código sencillo de tres dígitos, de tal manera que los datos expandidos debían ser tres veces más a los de entrada. Para verificar que en efecto esto sucedía, se colocó un indicador a la salida de la función de expansión. Los códigos usados fueron tres: uno cuyos valores sólo eran 1, uno cuyos valores sólo eran 0, y uno que alternaba los valores 1 y 0. 30 Para varias corridas de dos bits de longitud se observaron los resultados expresados en la Tabla 2.1: Tabla 2.1: Resultados para distintos códigos de expansión Fuente: Datos generados por la herramienta ENTRADA 01 10 11 01 00 10 11 01 CODIGO DE EXPANSION 111 111 000 000 101 101 010 010 RESULTADO 111000 000111 111111 000111 101101 010101 101101 010101 De esta manera se comprobó como en efecto la función de expansión se comporta tal como se deseaba, haciéndola perfectamente aplicable en el proyecto. Habiendo confirmado que uno de los procesos más importantes del proyecto podía realizarse sin inconvenientes, se estableció la posible viabilidad del mismo siguiendo incialmente tres líneas de acción: creación de la matriz de códigos Walsh, generación de los códigos PN-I y PN-Q de acuerdo al estándar y aplicación de ambos a un piloto para luego ser modulado. Alcanzado este punto se realizaría la replicación de estos resultados un número de veces suficiente para poder realizar pruebas extensivas sobre la recepción de los trayectos. Basado en la teoría de polución de pilotos se decidió que un número adecuado para probar todos los casos posibles sería el de seis pilotos, cada uno de ellos con un número de multitrayectos configurable entre cero y tres. De esta manera se tendría entonces un total de 24 trayectos agrupables en 6 pilotos estándar. 31 Paralelamente al desarrollo del generador se probaron distintos enfoques al proceso de recepción y detección de los trayectos, para luego pasar al diseño de las operaciones de procesamiento que permitirían expresar los resultados gráficos deseados. Cada uno de estos procedimientos y sus pruebas se detallan a continuación en las secciones siguientes. 2.2. Generación y prueba de los códigos Walsh La matriz de códigos Walsh nos permite seleccionar el código de expansión a utilizar. Como sabemos, el utilizado en el caso de los pilotos es el W0, el cual se constituye de un arreglo unidimensional de 64 ceros. Es por esto que para el desarrollo de este proyecto pudo haber sido utilizado un arreglo constante de este tipo sin limitar la funcionalidad del mismo. En lugar de esto, se realizó un programa que generara la matriz completa y luego permitiera mediante un selector configurado por el usuario, seleccionar qué fila se desea utilizar. De esta manera se habilita el uso de toda la tabla, abriendo la posibilidad al proyecto de desarrollos futuros que pudiesen involucrar la utilización de otros canales aparte del piloto. Para la generación de la matriz se procede tal como indica la teoría, partiendo de una matriz como la indicada en la Ecuación 1.2 y aplicándola a la Ecuación 1.1 hasta alcanzar el tamaño deseado de 64x64. Para ello se creó la matriz base 2x2 como una constante, y se hizo uso de la función Insert Into Array (insertar en el arreglo), la cual tiene como parámetros de entrada el arreglo base, el arreglo que se desea insertar y la selección de la fila y/o columna en la que se desea realizar la inserción. Como paso inicial se inserta la matriz base en ambas entradas, indicando que sea insertada en la posición de la fila 2, tomando en cuenta que el programa toma la primera fila como la cero. Tenemos así una matriz 4x2 que consta de la concatenación de la matriz base con ella misma, tal como se aprecia en la Figura 2.1(a). Paralelamente a esto se hace lo mismo solo que en lugar de concatenarla con ella misma, se hace con la negada o inversa, obteniendo la expresión de la Figura 2.1(b). Posterior a esto se realiza una nueva concatenación de las expresiones de las 32 figuras 2.1(a) y 2.1(b) para obtener la Figura 2.1(c). Finalmente este proceso se repite hasta alcanzar la matriz Walsh deseada de tamaño 64x64. Figura 2.1: Proceso de generación de la matriz de códigos Walsh por concatenación de la matriz base consigo misma (a), concatenación de la matriz base con su negada (b), y concatenación de los resultados previos (c) Fuente: Figura elaborada por el autor Una vez finalizado el proceso se compara la matriz obtenida con la especificada en el estándar (ver Figura 1.4) para determinar su validez. Posteriormente esta matriz se guarda como una constante para evitar el proceso de generación en cada corrida del proyecto principal. Para obtener la fila del código W0, o cualquier otro que se desee, se conecta esta constante a la entrada de la función Index Array (índice de la matriz). Esta función tiene otros dos parámetros de entrada, que vienen a ser el número de fila o de columna que se desea extraer de la matriz original, es decir, el índice del código. En este caso se conecta un control del panel frontal a la entrada del índice de fila, haciendo que este número pueda ser configurado entre 0 y 63, para un total de 64 posibles códigos de la matriz. Como salida se obtiene entonces la fila indicada por el control, que para este proyecto será siempre la correspondiente al índice cero, es decir, el código W0 de expansión de pilotos. 33 2.3. Generación y prueba de los códigos PN 2.3.1. Diseño de los registros de corrimiento Para poder generar los códigos PN-I y PN-Q, es necesario diseñar los registros de corrimiento expresados en las ecuaciones 1.6 y 1.7 e ilustrados en la Figura 1.6. Partimos entonces de un arreglo de 15 casillas, que servirán como las 15 etapas del registro de corrimiento. Este arreglo se inicializa con una semilla o estado inicial de 14 ceros en las posiciones inferiores y un uno en la mayor. Para el procesamiento del mismo, se genera un indicador para esta constante, ya que los indicadores nos permiten crear a su vez variables locales. El primer paso consiste en obtener los valores de los registros de interés para cada uno de los códigos, para poder realizar la operación de adición módulo 2 con ellos. Para esto utilizamos primero la función Index Array explicada anteriormente, la cual permite ser configurada para obtener los elementos del arreglo que sean indicados en sus terminales. De nuevo, para cada código tendremos distintos valores para estos índices. La función genera tantas salidas como índices se hayan configurado, obteniendo así el valor que poseen en ese momento los registros deseados. Todos estos valores servirán de entrada para una nueva función llamada Compound Arithmetic, o “combinación aritmética”, la cual puede ser configurada para realizar las funciones de suma, multiplicación, AND, OR y XOR de todos los datos de entrada simultáneamente. Se selecciona la función XOR que viene a ser el equivalente a una adición en módulo 2, obteniendo a la salida el resultado final binario de la operación. A continuación se procede a realizar el corrimiento de los registros hacia la posición menos significativa, con el fin de introducir el resultado recién obtenido en el registro superior. Para ello hacemos uso de la función Array Subset, o “subconjunto del arreglo”, la cual nos permite obtener una porción del arreglo de entrada mediante la configuración de dos parámetros: el índice a partir del cual se tomará el subconjunto y la longitud del mismo. Se define el índice en la posición 1 y se configura una longitud de 14 registros, para así obtener la porción del arreglo de entrada que debe ser corrida hacia los registros inferiores. Teniendo este nuevo arreglo de 14 34 registros, el mismo toma automáticamente la numeración de 0 a 13 para cada uno de ellos, por lo que solo resta incluir en la quinceava posición, o índice 14, al resultado obtenido en la función XOR del Compound Arithmetic. Para realizar esta inclusión se utiliza la función Insert Into Array, cuyo funcionamiento fue explicado en la sección 2.2. De esta manera, se define el índice 14 como la posición en la cual se desea hacer la inserción, y se conecta la salida del Compound Arithmetic a la entrada del nuevo elemento a insertar. En la salida tendremos entonces un arreglo compuesto de nuevo por 15 registros, donde los catorce primeros son el conjunto que se desplazó y el último es el resultado del XOR. Llegado este punto, a dicha salida se conecta entonces una variable local configurada en modo de escritura, que sobrescribe el contenido de la que fue usada al inicio de todo el proceso. De esta manera en la próxima corrida se tiene que sucede de nuevo todo el proceso pero con el último resultado como entrada inicial, generándose de esta manera el corrimiento cíclico de los registros hasta alcanzar la máxima longitud en la cual el registro vuelve al estado inicial o semilla. Es importante destacar el hecho de que la salida final del registro de corrimientos no es directamente el resultado del XOR, sino que son todos los valores que en cada ciclo se “expulsan” del índice cero, o primer registro. En una aproximación inicial se tomó la salida del XOR como la fuente de valores para generar el arreglo de los códigos PN, lo que trajo consigo errores ya que no se incluía entonces a los valores de la semilla o estado inicial en la formación del arreglo final. Una inspección más detallada dio como resultado la corrección de este error, tomándose entonces la salida del primer registro como entrada para la generación de los arreglos de los códigos PN-I y PN-Q. La formación de estos códigos fue realizada con la implementación de la función Insert Into Array de la cual ya hemos hablado anteriormente. La misma tiene como entrada inicial la variable local de un arreglo vacío configurada a modo de lectura, tal como en el caso del registro de corrimiento, ya que en la salida tiene la misma variable solo que en modo de escritura. De esta manera se genera una realimentación del proceso, donde la salida vuelve a ser la entrada para el 35 ciclo siguiente, y así sucesivamente. Así mismo, a la entrada de nuevos elementos a insertar en el arreglo se conecta entonces la salida del primer registro del proceso del shift register, y a la entrada del valor del índice en el cual se va a realizar la inserción se debe conectar una variable que incremente a cada ciclo para ir llenando el arreglo en posiciones sucesivas. Todo este proceso se enmarca en una estructura llamada while loop, la cual tiene la función de ejecutar todos los comandos que se encuentren en su interior hasta que se interrumpa su operación. La estructura cuenta con dos elementos principales, como son: un contador que lleva el registro del número de veces que se ha ejecutado el ciclo y un control de parada utilizado para detener su ejecución. Esta interrupción se genera mediante un valor binario y puede configurarse de dos maneras: stop if true (detener si la condición es cierta) o continue if true (detener si la condición es falsa). De esta manera tenemos que el contador de ciclos puede usarse directamente para la entrada del valor del índice en el cual se va a realizar la inserción en el Insert Into Array empleado para formar los códigos PN. Así mismo, se puede configurar el while loop para detener su ejecución una vez conformados los códigos finales. Para ello utilizamos la función Array Size, o tamaño del arreglo, para calcular la longitud del arreglo de salida, la cual se conecta a un comparador que verifica la igualdad entre dos números. Al otro conector de este comparador se conecta una constante cuyo valor fijaremos en 32767, que es el tamaño máximo del arreglo que se puede obtener con un registro de corrimiento de 15 elementos (215-1). Al hacer esto, la estructura se ejecuta hasta que el código PN formado alcance la longitud máxima y luego detiene su ejecución, habiendo configurado la misma para el caso de stop if true. Para obtener la longitud deseada de 215 o 32768, tal como se estipula en el estándar IS-95, se debe agregar un cero donde se encuentren 14 ceros consecutivos. Esto sucede únicamente al inicio del código debido a la presencia de la semilla, por lo que es allí donde se procede a insertar el nuevo elemento. Para ello se utiliza nuevamente la función Insert Into Array, teniendo como entradas el código incompleto, una constante de valor cero como elemento a insertar y un índice de inserción de 0. Este índice puede ser cualquier número entre 0 y 13 pero se tomó el cero como 36 un valor más formal. A la salida de la función de inserción tendremos entonces el código PN formado en su totalidad (ver Figura 2.2). Para evitar el proceso de generación de los códigos para cada corrida del proyecto, se crean constantes a partir de estas variables, las cuales pueden duplicarse y utilizarse cuantas veces sea necesario. Todo este procedimiento debe realizarse independientemente para cada código ya que cada uno utiliza distintas posiciones de los registros de corrimiento para ejecutar la función XOR y por lo tanto serán completamente diferentes. 37 Figura 2.2: Generación de los códigos PN binarios Fuente: Captura de pantalla del software LabVIEW® 38 2.3.2. Conversión de los códigos PN binarios En el momento en el cual se lleva a cabo el proceso de enmascaramiento con los códigos PN, los mismos no se emplean en su forma binaria. Esto es debido a que los datos a enmascarar tampoco se encuentran en formato binario. En su lugar, los bits han sido convertidos a valores bipolares de ‘+1’ y ‘-1’ en sustitución de los ‘0’ y ‘1’, respectivamente. Es por esto que se hace imperante la necesidad de convertir los códigos PN binarios que fueron generados, a códigos PN de valores bipolares de ‘+1’ y ‘-1’ que sigan exactamente el mismo patrón. En pocas palabras, deben ser intercambiados todos los ceros por valores ‘+1’ y todos los unos por valores ‘-1’. Para llevar a cabo esta operación se utiliza un while loop en el que se ejecutarán todos los comandos de manera cíclica. Inicialmente tendremos cada uno de los códigos binarios conectados a una función Index Array independiente para cada uno; esta función es la que extrae elementos de un arreglo dada su posición. De nuevo se conecta el contador interno del while loop a las entradas de configuración del número de índice a extraer, de manera que a cada ejecución del ciclo se extraiga el elemento siguiente. A medida que los unos y ceros se van obteniendo en la salida, se conectan con un comparador que verifica si es o no igual a cero, dando como resultado un valor booleano de true para cuando lo sea y uno de false para cuando no lo sea, es decir, cuando sea uno. Esta salida booleana pasa a ser entonces la entrada de una estructura de casos o case structure, donde se pueden configurar varios escenarios de ejecución dependiendo de la entrada recibida. En esta aplicación los escenarios se etiquetan como true y false para dar lugar a los únicos dos casos posibles. De manera tal que dependiendo del valor booleano recibido de la etapa anterior se ejecutarán los comandos que estén en una u otra ventana de escenarios. Para el caso true, es decir, que el número a convertir es un cero, se configura una constante de valor +1 como salida de la ventana. Para el caso contrario se configura entonces una constante de valor -1. De esta manera se obtiene a la salida de este case structure un +1 o un -1 dependiendo si la entrada fue un 0 o un 1 respectivamente. Posteriormente se deben conformar nuevamente los arreglos a partir de estos resultados, por lo que hacemos uso de la función Insert Into Array usando como entrada del valor a insertar 39 esta salida que acabamos de obtener. La entrada que especifica el índice en el cual se va a insertar es conectada de igual forma al contador interno del while loop, haciendo entonces la conversión uno a uno de cada elemento del código binario en el nuevo código. La entrada del arreglo será una variable en modo de lectura inicializada en vacío, y la salida será la misma variable en modo de escritura. De esta manera, y como se ha realizado anteriormente, la salida de un ciclo se convierte en la entrada del siguiente, pudiendo entonces completar la formación de ambos códigos PN en su nuevo formato. La finalización de la ejecución está ligada a la finalización de la conversión de datos, por lo que puede hacerse de varias maneras. La seleccionada fue de nuevo la de comparar el tamaño del arreglo que se formaba mediante las funciones de Array Size y de comparación, con una constante de 32768. La salida del comparador se conecta al control de parada de la estructura configurado para stop if true, y al cumplirse la condición se detiene la ejecución de la misma (ver Figura 2.3). Una vez más, para evitar realizar este proceso en cada corrida del proyecto final, se crean constantes a partir de estas variables, las cuales pueden duplicarse y utilizarse cuantas veces sea necesario. Figura 2.3: Conversión de los códigos PN binarios a bipolares Fuente: Captura de pantalla del software LabVIEW® 40 2.3.3. Pruebas de los códigos PN Para poder asegurar que los códigos PN generados y que van a ser usados en adelante para procesos críticos del funcionamiento total del proyecto se comportan tal como se desea teóricamente, es necesario conducir una serie de pruebas que lo verifiquen. La primera prueba a realizar es la del balance entre unos y ceros, o entre +1 y -1, según el formato del código que se verifique. Para otorgar redundancia a los resultados se comprobaron ambos casos para cada uno de los dos códigos PN. El procedimiento a seguir fue el de tomar cada constante de código generado y conectarlo a la entrada de una función Add Array Elements (sumar elementos del arreglo), con lo que a la salida se obtiene el resultado de la suma de todos los elementos del arreglo para cada caso. En los casos binarios si tenemos igual número de ceros y unos, una suma de todos los elementos debe dar un total igual a la mitad de los elementos, ya que solo los unos contribuyen a la operación. Por lo tanto, se debe obtener un resultado de 16384 para ambos códigos. Para los casos en formato bipolar, una suma de todos los elementos debe dar un total igual a cero, ya que todos los elementos se cancelan unos con otros al haber el mismo número de positivos que de negativos. Al obtener estos resultados se comprueba entonces que se cumple la condición de balance para los códigos. Otra prueba necesaria es la de autocorrelación, para la cual debemos realizar el cálculo de cuántas igualdades y desigualdades existen al comparar el código con versiones desplazadas de sí mismo, de acuerdo a la Ecuación 1.6. Para realizar la prueba de una manera completa este chequeo debe realizarse con todos los posibles desplazamientos del código, por lo que se requerirán un total de 32768 ciclos para confirmar que en efecto hay una alta correlación únicamente en el caso en que no existe desplazamiento, y una baja correlación para todas las versiones desplazadas. Este principio es básico para asegurar el buen funcionamiento del proyecto, por lo que esta prueba es de gran importancia para verificar la posible utilización de los códigos. 41 El proceso se desarrolla de nuevo dentro de un while loop para asegurar que se tomen en cuenta la totalidad de los elementos de los arreglos. No se ahondará en el procedimiento de detención de la ejecución ya que el mismo ha sido explicado de manera profunda con anterioridad. Así mismo, se explicará de manera singular para el caso de uno de los códigos, asumiendo que todo el procedimiento es duplicado para realizar la verificación de ambos. Cada ciclo consta fundamentalmente de cinco etapas, en la primera se genera la versión desplazada del código, en la segunda se comparan término a término la totalidad de los elementos de ambos arreglos, en la tercera se generan arreglos que guarden los resultados de la comparación anterior, en la cuarta se aplica como tal la Ecuación 1.6 con los datos de la etapa anterior y en la quinta se grafican estos datos para obtener una representación visual de los mismos. Estas etapas estarán claramente delimitadas y enmarcadas en un flat sequence structure (estructura de secuencia plana), el cual se compone de ventanas concatenadas que se ejecutan de manera consecuente y en las que se realizan por completo todos los procesos inherentes a cada una antes de proseguir a la siguiente. En la primera etapa básicamente lo que se quiere es obtener trozos del código, solo que del tamaño del código completo. Por esto la ejecución inicia conectando el código a probar en la entrada de una función Array Subset, cuyo tamaño del subarreglo se define de 32768 (lo cual no lo hace realmente un subarreglo, pero se mantendrá esta terminología para darle sentido a la explicación), y su índice de inicio está conectado a un contador que incrementa con cada ciclo. En este caso no se usa el contador del while loop debido a que para el caso en el que se requiera graficar más de una corrida a la vez, es necesario llevar dicho contador a cero, como ya se verá más adelante. Al subarreglo obtenido pasa a ser la entrada de la función Array Size, para poder obtener su longitud y usarla como entrada de un comparador de igualdad conectado a una constante de 32768. El resultado de esta comparación activará uno de los dos posibles escenarios del case structure que sigue a continuación. A primera vista pareciera que el arreglo siempre va a tener una longitud de 32768, ya que ese es el tamaño de la porción que se define en el Array Subset, pero sucede que para LabVIEW® todas las casillas siguientes al último elemento se consideran vacías y, por lo tanto, inexistentes. De esta manera, la ejecución del primer ciclo será el único momento en el cual este 42 subarreglo sea de tamaño 32768, ya que para el siguiente ciclo en el que el índice de inicio aumenta en una unidad, el tamaño del subarreglo disminuye en una unidad también. Sabiendo esto volvamos al case structure, donde en el caso true, es decir, que el arreglo es de tamaño 32768, el mismo entra y sale del escenario sin sufrir modificación alguna, listo para entrar a la segunda etapa del proceso. Por el contrario, para el caso del resto de las ejecuciones del ciclo donde la longitud del subarreglo se hace cada vez menor, se hace necesario compensar la falta de elementos. Pero esta compensación no puede ser realizada a la ligera, ya que sólo pueden compensarse el número de elementos que falten y en el orden adecuado. Por ejemplo, para el caso de la segunda ejecución donde el subarreglo es una unidad menor, debe agregarse al final el elemento inicial que se está dejando por fuera. Igualmente si llegamos a la mitad del código, la otra mitad que lo completa debe ser la primera mitad faltante concatenada al final. Al hacer esto obtenemos un código que se desplaza de manera cíclica manteniendo constante su tamaño y agregando al final los elementos que sean necesarios del principio. Esto se logra en el caso false del case structure, donde como paso inicial se conecta la constante de 32768 a un sustractor a cuyo segundo terminal se conecta el resultado de la función Array Size recién utilizada. De esta manera se determinan cuantos elementos faltan para completar el tamaño total del arreglo. Este resultado se conecta al terminal de tamaño del subarreglo de una nueva función Array Subset a cuyo terminal de índice de inicio se conecta una constante de valor cero, y a su entrada el arreglo original. Así se obtiene a la salida una porción del inicio del arreglo del tamaño requerido para completar el obtenido en el primer Array Subset. Sólo faltaría concatenar este subarreglo al final del primero, para lo cual se utiliza la función Insert Into Array conectando a la entrada principal el primer subarreglo, al terminal de inserción el segundo arreglo y al terminal de índice de inserción el resultado obtenido de la función Array Size. A la salida tendremos entonces un arreglo de tamaño 32768 compuesto de la primera porción obtenida del final del arreglo original, concatenada con la porción faltante del inicio en el punto donde termina dicha primera porción. 43 Al realizar este proceso varias veces se obtiene un arreglo que se desplaza elemento a elemento para poder ser comparado en la segunda etapa con el arreglo original. Para poder asegurar que esto suceda incluso al llegar al final del arreglo original, debe tomarse la precaución de reiniciar el contador independiente que es usado en el primer Array Subset fuera del case structure. Recordemos que este contador está conformado por una función increment, la cual tiene la tarea de aumentar en una unidad el dato de entrada. En la salida se conecta entonces una variable en modo escritura y en la entrada la misma en modo lectura, como ya hemos hecho anteriormente. Para reiniciar esta variable en el momento adecuado debe ser agregado dentro del caso false del case structure un comparador de igualdad en cuyos terminales de entrada se conecten el resultado del Array Size del primer subarreglo y una constante de valor 1. Esto debido a que cuando solo se esté tomando este último elemento y concatenándole los primeros 32767 elementos del arreglo original, el próximo paso será volver de nuevo al arreglo original. De esta manera, cuando el tamaño del primer subarreglo sea igual a 1 el comparador tendrá un resultado de true, activando el caso true de un case structure que se agrega dentro del primero. En este escenario solo habrá una variable en modo escritura del contador independiente del proceso, con una constante de cero conectada a su terminal de entrada. Así la misma pasará a valer cero para la próxima corrida y el primer subarreglo volverá a ser el arreglo original completo. El caso false de este case structure interno permanece vacío ya que mientras no se cumpla la condición deseada no es necesario realizar ninguna otra operación extra. En este punto se culmina la primera etapa, de la cual se utilizarán en la siguiente el arreglo original y su versión desplazada que se obtiene a la salida del case structure mayor (ver Figura 2.4). 44 Figura 2.4: Primera etapa del protocolo de verificación de autocorrelación Fuente: Captura de pantalla del software LabVIEW® La segunda etapa está constituida por la comparación término a término de la totalidad de los elementos de ambos arreglos. Para ello utilizaremos un for loop, el cual tendrá como entradas los dos arreglos obtenidos en la etapa anterior y a cuyo terminal de selección del número de ciclos de ejecución se conecta una constante de 32768 para asegurar que se evalúan los arreglos de forma completa. Dentro del for loop se ubican dos funciones Index Array, una para cada arreglo, y cuyos terminales de índice de extracción se conectan al contador de ejecuciones del for loop. De esta manera en cada ciclo interno del for loop se estarán extrayendo términos de ambos arreglos que estén ubicados en la misma posición. Seguidamente se procede a comparar su igualdad, donde se obtiene un booleano que puede ser true o false dependiendo de si son o no iguales. Se tiene entonces un case structure en el que para ambos casos presenta una función increment que aumenta un contador, de nombre distinto según el caso. Así, se logra contabilizar el número total de veces que hay igualdades y desigualdades, tomando en cuenta todos los 45 elementos de ambos arreglos. Este chequeo completo se realiza cada vez que ocurre un solo desplazamiento en el paso anterior (ver Figura 2.5). Es importante que antes de entrar en esta segunda etapa se lleven a cero los contadores de igualdad y desigualdad, por lo que en la primera deben agregarse variables en modo escritura de cada uno de los ellos, con una constante de cero en ambos terminales de entrada. Figura 2.5: Segunda etapa del protocolo de verificación de autocorrelación Fuente: Captura de pantalla del software LabVIEW® 46 La tercera etapa comprende la formación de los arreglos que contienen los resultados del número de igualdades y desigualdades encontradas para cada uno de los 32768 posibles desplazamientos del código original. Para generarlos se emplea la función Insert Into Array, una para cada variable del contador de la segunda etapa, tomando como entrada arreglos vacíos que se realimentan en cada ciclo. El índice de inserción se controla con el contador del while loop, y los elementos a insertar son los contadores de igualdades y desigualdades respectivamente. De esta manera se obtienen los dos arreglos de los cuales puede recuperarse la pareja de datos igualdades-desigualdades para cada corrimiento del código original (ver Figura 2.6). Figura 2.6: Tercera etapa del protocolo de verificación de autocorrelación Fuente: Captura de pantalla del software LabVIEW® 47 En la cuarta etapa es donde se calculan los valores que se graficarán más adelante, al sustituir cada pareja de datos obtenida en el paso anterior en el desarrollo de la Ecuación 1.6. Para ello se emplea un for loop a cuyo terminal de selección del número de ciclos de ejecución se conecta la salida de una función Index Array cuya entrada puede ser el arreglo de igualdades o desigualdades obtenido en el paso tres, ya que son de la misma longitud. Esto es para asegurar que se evalúan los arreglos de forma completa, en el caso en que se hayan realizado varias corridas continuas. En la ejecución del for loop sistemáticamente se extrae cada pareja de datos con la función Index Array y el índice de extracción conectado al contador interno del mismo. Luego con cada pareja de datos se procede a restar el número de desigualdades al de igualdades, y el resultado se divide entre el período, es decir, una constante de 32768. Este resultado se conecta al terminal de inserción de una función Insert Into Array con el índice de inserción conectado al contador de ciclos del for loop y cuya entrada y salida son la misma variable configurada para leer y escribir respectivamente. De esta manera se obtiene un arreglo de todos los resultados de la autocorrelación del código con versiones desplazadas de sí mismo (ver Figura 2.7). Figura 2.7: Cuarta etapa del protocolo de verificación de autocorrelación Fuente: Captura de pantalla del software LabVIEW® 48 Para finalizar, en la quinta etapa se realiza la presentación gráfica de los datos a través de una función llamada XY Graph. Las entradas de esta función son únicamente los datos del eje de las abscisas y del eje de las ordenadas, ya que la configuración de la presentación de estos datos se realiza en las opciones del gráfico en el panel de control. Para el caso del eje de las abscisas, se debe crear un arreglo de números consecutivos de la misma longitud que el de los resultados de la autocorrelación, por lo que en la cuarta etapa debe incluirse esta generación en paralelo con la formación del arreglo de resultados. Se utiliza la función Insert Into Array de la misma manera, con la entrada y salida compartida por la misma variable y tanto su índice de inserción como el dato a insertar se conectan al contador de ciclos del for loop (ver Figura 2.8). Una vez obtenidos ambos ejes se conectan a los terminales de entrada de la función XY Graph y se observa el resultado gráfico, el cual se asemeja al teórico esperado, descrito por la Ecuación 1.6 (ver Figuras 2.9 y 2.10). Figura 2.8: Quinta etapa del protocolo de verificación de autocorrelación Fuente: Captura de pantalla del software LabVIEW® 49 Figura 2.9: Gráfica de la autocorrelación del código PN-I para 3 detecciones Fuente: Captura de pantalla del software LabVIEW® 50 Figura 2.10: Gráfica de la autocorrelación del código PN-Q para 3 detecciones Fuente: Captura de pantalla del software LabVIEW® CAPÍTULO 3 DISEÑO DEL GENERADOR Y DEL RECEPTOR 3.1. Resumen del procedimiento experimental En principio sería deseable describir los procesos de diseño del generador y del receptor en capítulos separados. Pero dada la manera como se abordó el proceso de diseño esto resultaría imposible, ya que su desarrollo fue en paralelo. Esto se hizo con la intención de poder reportar avances en cualquiera de los dos procesos, de acuerdo a los resultados obtenidos en cada etapa de los mismos. En pocas palabas, no es posible poner a prueba los avances alcanzados en el desarrollo de un receptor si no tenemos una señal qué recibir. De esta manera se pudo también avanzar en el desarrollo del generador, adaptándolo cada vez más al tipo de señales con las que se desea trabajar. El proceso de diseño del generador está compuesto por varios acercamientos distintos al problema. Esto es debido a que inicialmente se enfocó la investigación en la expansión del espectro y la recuperación de los datos enviados, para luego dejar de lado esa línea de desarrollo e incursionar en la modulación y demodulación de señales analógicas. Por último se tomó otra línea de acción, fijando el nuevo enfoque en la generación de pilotos digitales de parámetros configurables, dejando de lado la modulación y concentrando los esfuerzos en el desarrollo del software de procesamiento como tal, más allá del proceso de transmisión analógico. Esto llevó a la presentación del diseño final, con todas las funcionalidades de configuración necesarias para poner a prueba las capacidades del receptor. El receptor por su parte, evoluciona en diseño a la par del generador. Inicialmente se enfocaba en la recuperación de los datos enviados en espectro expandido, para luego dar paso a la 52 demodulación de las señales análogas que emitía el generador. Llegado a este punto se presentó un cambio radical en el enfoque del diseño del receptor, ya que el mismo no requiere la funcionalidad de interpretación de datos de los usuarios. Esto debido al hecho de que como detector e identificador de radiobases, el mismo no requiere la capacidad de recepción de información de los usuarios en la señal, sino únicamente el desfasaje del código PN utilizado para el canal piloto que identifica a la radiobase. Así, el nuevo enfoque de diseño se orientó a la detección de estos desfasajes para realizar la identificación de las radiobases presentes. A continuación se detallan todos los procedimientos seguidos en la evolución de ambos diseños. Se seguirá un orden cronológico salvo en los casos que se requiera la explicación de varios avances juntos para un mejor entendimiento. 3.2. Enfoque inicial, el espectro expandido La primera aproximación al envío y recepción de señales vino de la mano con la prueba de las funciones Spread Symbols y De-Spread Symbols explicadas en detalle en la sección 2.1 del presente trabajo. Básicamente se buscaba comprobar el modo de operación de dichas funciones al enviar y recibir un código binario de poca longitud. Es así como para ese momento tanto el generador como el receptor constaban de una única función cada uno. Este enfoque es rápidamente abandonado y es aquí cuando comienza el desarrollo de la conversión de formato binario a formato bipolar con el fin de realizar la modulación y transmisión de señales analógicas, para luego incluir la demodulación y reconversión a formato binario en la búsqueda de obtener las señales enviadas. 3.3. Aplicando modulación y demodulación analógica Como paso siguiente se incluyó en el modelo anterior la modulación analógica como medio de transmisión de los datos, más específicamente la modulación QPSK. Para lograr esto se utilizaron varias funciones pertenecientes al Modulation Toolkit. La primera de ellas, y con la cual se inicia el proceso de conversión, es la llamada Modulate PSK (Modular PSK). Esta función permite elegir entre distintos tipos de modulación PSK dependiendo de sus parámetros de 53 configuración. La función posee cuatro terminales de entrada y dos de salida. La primera entrada viene a ser la de los bits que se desean transmitir; la segunda proporciona la información de configuración; en la tercera se indica la tasa de símbolos y en la cuarta los coeficientes del filtro de conformación de pulsos. La salida por su parte, se compone de un terminal para la forma de onda compleja y otro que nos permite obtener los símbolos contenidos en dicha onda. Para la obtención de los valores de entrada para el segundo y cuarto terminal de entrada de la función Modulate PSK, es necesario utilizar las funciones Generate System Parameters (generar parámetros del sistema) y Generate Filter Coefficients (generar coeficientes del filtro) respectivamente. En la primera de ellas se configuran parámetros como el número de muestras por símbolo, el tipo de modulación (binaria, cuaternaria, etc.), si la modulación será o no diferencial, y si será normal, shifted (corrida) o con offset (desfasaje). Se implementaron los valores adecuados para el caso, como lo es el tipo de modulación cuaternaria, normal, no diferencial, con 16 muestras por símbolo. Para el caso del generador de coeficientes del filtro se tienen entradas como el tipo de modulación, el tipo de filtro y el número de muestras por símbolo, configuradas para modulación PSK con 16 muestras por símbolo. Una vez conectadas estas dos funciones a la de modulación PSK, se procede con la demodulación de la señal generada. En el proceso de demodulación se utiliza la función Demodulate PSK (Demodular PSK), a la cual se conectan en sus terminales de entrada la señal a demodular, los parámetros del sistema, y los coeficientes del filtro. Para estos dos últimos se utilizó la misma salida de las funciones Generate System Parameters y Generate Filter Coefficients implementadas para la modulación. De esta manera se obtiene a la salida la señal expandida que se introdujo en la función Modulate PSK, la cual se contrae de nuevo para conseguir los bits originales (ver Figuras 3.1 y 3.2). Sin embargo, en la recepción se obtuvo siempre un bit menos de los enviados, por lo que se experimentó con la inclusión de un header o cabecera en el mensaje a enviar, ya que al parecer las funciones lo truncaban en cierta medida. Para ello se implementó la función Insert Into Array con la intención de concatenar una trama de bits en el mensaje, previo a su expansión y modulación. Esta acción no generó ningún resultado positivo en lo que a determinar las causas de la supresión de un bit se refiere, por lo que se procedió a sustituir las funciones de modulación y 54 demodulación directa y se realizó un modelo paso a paso con las funciones que las constituyen, para poder observar la señal en cada uno de los pasos internos del proceso. Figura 3.1: Segmento de transmisión de la primera aproximación Fuente: Captura de pantalla del software LabVIEW® Figura 3.2: Segmento de recepción de la primera aproximación Fuente: Captura de pantalla del software LabVIEW® 55 Para realizar el modelo detallado se sustituyeron las funciones Modulate PSK y Demodulate PSK por una serie de funciones más específicas que realizan el mismo procedimiento, sólo que permitiendo el seguimiento de la señal en cada una de las etapas. La primera de estas funciones es la llamada Map Bits to Symbols (mapear los bits a símbolos) y se encarga de generar los símbolos que van a ser transmitidos a partir de la trama de bits de datos. Esta función tiene además un terminal de entrada para el tipo de PSK a usar y otro para ingresar el mapa de símbolos a utilizar para llevar a cabo la conversión. Esto se obtiene de la función Generate System Parameters explicada anteriormente. De esta manera se obtiene una trama de símbolos a la salida de la función, la cual servirá de entrada a la siguiente. Esta viene a ser Apply Pulse Shaping Filter (aplicar filtro de conformación de pulsos), la cual se encarga de aplicar el filtro de acuerdo a los parámetros de entrada especificados por las funciones Generate System Parameters y Generate Filter Coefficients ya mencionadas. A la salida tendremos la forma de onda compleja que será transmitida. En la rama de demodulación se tiene como primera etapa a la función Apply Matched Filter (aplicar filtro emparejado), la cual toma como entradas a la forma de onda compleja, los coeficientes del filtro y el número de muestras por símbolo y genera como salida una forma de onda compleja filtrada que contiene los símbolos recibidos. Para obtener estos símbolos se utiliza la función Decimate Oversampled Waveform (diezmar la forma de onda sobremuestreada), que toma la forma de onda compleja y el número de muestras por símbolo y genera una forma de onda compleja que alinea los símbolos para permitir su extracción mediante la función Unbundle by Name (desagregar por nombre). Esta función permite obtener los componentes de la forma de onda compleja, en este caso los símbolos recibidos. Estos símbolos se introducen en la función Map Symbols to Bits (mapear símbolos a bits), la cual realiza la operación inversa a Map Bits to Symbols valiéndose del mismo mapa de símbolos. Así se obtienen entonces los bits expandidos que serán comprimidos para recuperar los datos (ver Figura 3.3 y 3.4). 56 Figura 3.3: Segmento de transmisión del segundo enfoque Fuente: Captura de pantalla del software LabVIEW® Figura 3.4: Segmento de recepción del segundo enfoque Fuente: Captura de pantalla del software LabVIEW® 57 A pesar del éxito de esta prueba, y tal como se menciona en la introducción del capítulo, esta manera de abordar el problema no provee de ningún tipo de generación como tal de pilotos, así como tampoco busca su identificación. Es por esto que en este punto se realizó un cambio en el enfoque del problema y se empieza a tratar con arreglos binarios y la búsqueda de patrones en su interior, con miras a obtener un proceso de búsqueda y adquisición de desfasajes de los códigos PN. 3.4. Búsqueda de patrones en arreglos binarios Tomando en cuenta que la función más importante del proyecto es la de obtener los desfasajes de los códigos PN, se procedió a diseñar un VI que explorara este procedimiento. Para ello se generó un arreglo de una longitud manejable para realizar pruebas, en este caso 56 bits, y se le introdujo un patrón reconocible justo en la mitad. El arreglo estaba compuesto de ceros y unos intercalados, teniendo en el medio varios unos seguidos. Luego se creó otro arreglo de longitud 10 y se le introdujo el patrón central del arreglo mayor. La idea era comparar este arreglo menor con porciones de 10 bits del arreglo mayor, corriendo su contenido bit a bit hasta llegar al punto en que ambos arreglos coincidieran. En este momento debería reportarse la distancia recorrida en número de posiciones que le tomó en llegar a la coincidencia. Para realizar esto, se dio uso a la función Array Subset, cuya salida como sabemos es una porción del arreglo de entrada, a partir de una posición y con una longitud especificadas por el usuario. La longitud del arreglo de salida se configuró en 10, para poder compararlo luego con la porción que se tiene fija de antemano. El índice de extracción se configuró en modo de control, de manera tal que el usuario pudiera realizar la exploración paso a paso. La salida generada se compara luego con el arreglo prefabricado que contiene la porción central del arreglo mayor. Para realizar esta comparación se utiliza la función XOR, que realiza la adición módulo 2 bit a bit de las entradas y guarda los resultados en un arreglo de longitud igual, es decir, 10 elementos. De esta manera tenemos entonces un arreglo que contiene las coincidencias y no coincidencias de cada par de bits de la misma posición de los códigos de entrada. 58 La operación XOR da como resultado un 1 cuando los elementos no son iguales, y un 0 cuando sí lo son. Así, al momento de obtener una coincidencia perfecta el arreglo debería estar compuesto únicamente de ceros. Y en el resto de los casos debe tener un número de unos igual al número de no coincidencias. Inicialmente la detección de esta situación estaba a cargo del usuario, quien debía observar continuamente el arreglo de salida para verificar cuándo se cumple la condición de total igualdad. Es por esto que para facilitar el momento de la detección se aplicó la función Add Array Elements (adición de los elementos del arreglo) al arreglo de salida de la función XOR. Esta función daría como resultado cero al momento de la coincidencia y un número distinto de cero en cualquier otro momento. Sabiendo esto, se utilizó un comparador con cero a la salida de la función, el cual genera un resultado true o verdadero en caso de que la suma de los elementos del arreglo sea cero, y un resultado false o falso en caso contrario. A este resultado se le crea un indicador luminoso, de manera tal que el momento de la detección sea evidente para el usuario sin tener que observar detalladamente el funcionamiento del programa (ver Figura 3.5). El procedimiento fue exitoso ya que al ocurrir la coincidencia se encendía el indicador y podía observarse entonces la distancia recorrida hasta el momento de la detección. Figura 3.5: Primera detección de patrones binarios Fuente: Captura de pantalla del software LabVIEW® Para este momento el corrimiento del arreglo sigue en manos del usuario, por lo que el paso lógico siguiente es automatizar el proceso. Esto se logra con el uso de una estructura while 59 loop, tomando como valor inicial un desfasaje introducido por el usuario el cual se incrementaría con cada ciclo mediante la función increment. De esta manera el arreglo se correría automáticamente una posición a cada ciclo del while loop, relegando al usuario de esta operación pero permitiéndole configurar el desfasaje deseado al inicio de la ejecución. Al hacer esto se hace necesario que el arreglo con el que se trabaja sea cíclico para que no se generen porciones de arreglo vacías y se produzcan errores, pero este asunto se resolverá más adelante como veremos. Por ahora el paso siguiente una vez que tenemos una trama de datos que se corre una posición por ciclo, es hacer que el buscador no sea estático sino que por el contrario, se desplace al doble de la velocidad mientras realiza la búsqueda. Este aumento de la velocidad de desplazamiento se logra aplicando varios cambios al diseño que se tiene hasta el momento. Primero debe cambiarse la entrada del comparador de una porción fija del código mayor, a una porción que también se desplace por él. Esto se logra utilizando una función Array Subset también para el buscador, mediante la conexión del índice de extracción a un contador. Para lograr el doble de velocidad de desplazamiento, este contador debe incrementarse dos veces por cada ciclo, por lo que se hace evidente la necesidad de la inclusión de una estructura for loop con una constante de 2 conectada al terminal de número de ciclos. De esta manera, al incluir todo el proceso de detección dentro del for loop se realiza la comparación de dos porciones distintas del buscador, contra la misma porción del arreglo al cual desea encontrársele el desfasaje, logrando entonces el desplazamiento del buscador al doble de la velocidad de la del arreglo desfasado. Luego de hacer esto se intentó erróneamente lograr que el buscador una vez conseguida la coincidencia, se quedara “enganchado” con ella. Erróneamente porque a diferencia de un móvil, que sí debe continuar en fase con el piloto detectado para poder acceder a los canales de tráfico, un escáner debe seguir adelante con el fin de conseguir otros pilotos. Es por esto que hasta que no se corrigió esta configuración más adelante, no se obtuvo un resultado óptimo. Para lograr que el buscador siguiera en fase con el piloto se utilizó un case structure para el contador que incrementa la variable que indica el índice de extracción del Array Subset, el cual 60 trabaja de la manera siguiente: mientras el detector no consiguiera una coincidencia, el resultado de la función Add Array Elements sería siempre false, por ello el caso false del case structure tiene una función de incremento para la variable del índice de extracción, con la intención de que siga adelante en la búsqueda. Una vez conseguida la coincidencia, el resultado de la función Add Array Elements sería true, por lo que el caso true del case structure mantenía la variable del índice de extracción sin cambios. Esto hace que en el próximo ciclo cuando avance la trama externa la coincidencia se pierda, activando el caso false e incrementando la variable del buscador. En este momento se volvía a obtener una coincidencia, manteniendo sin cambios a la variable del índice de extracción del buscador hasta el próximo ciclo, donde se repite este proceso de nuevo. Esto genera una situación de coincidencia y no coincidencia alternante que no permite determinar el desfasaje original, ya que constantemente se genera un nuevo valor para el mismo en cada ciclo. En un intento de solucionar esta situación, pero manteniendo aún el “enganche” con la trama externa, se implementó una relación matemática que vinculara el desfasaje obtenido en cada detección con el introducido a la trama externa al inicio de la simulación. Luego de un proceso de observación del comportamiento del código en ejecución, se llegó a la conclusión de que una vez hallada la coincidencia, esta mantiene una relación constante con el número de ciclos que se han ejecutado, y que esta constante es efectivamente el desfasaje introducido por el usuario a la trama externa. Llegado este momento parece que el problema de conseguir el desfasaje está resuelto, por lo que se procede a probarlo con un código más largo, en este caso el PN-I. Para el momento en que se realizó esta introducción el código PN no se generaba de la manera adecuada, ya que la salida se tomaba de la adición módulo 2 y no del elemento cero del shift register. Pero esto no es lo relevante en este caso, lo que sí lo es, es el hecho de que el mismo es generado al mismo tiempo que se ejecuta el resto del programa, con la intención de hacerlo cíclico. No estaba aún siendo usado como una constante almacenada de la cual se toman las porciones deseadas. El problema es que al ser generado de esta manera, el mismo incrementa su longitud a la par del número de ciclos de la ejecución, por lo que la función Array Subset va a obtener un arreglo vacío en el punto de su índice de extracción, ya que el mismo se encuentra 61 adelantado un número de posiciones igual al desfasaje introducido por el usuario. Al tener un arreglo vacío, la operación del XOR va a generar un arreglo vacío como resultado, teniendo así que la suma de sus elementos es siempre cero, por lo que se detecta como coincidencia válida desde el inicio de la ejecución. Esto mantiene siempre el contador del índice de extracción del buscador constante ya que al ser siempre true, no se incrementa la variable. En un principio esta situación debería generar un error constante, eliminando toda posibilidad de detección válida en el proceso. Por otro lado se tiene como resultado que el programa realiza la detección correcta del desfasaje mientras el mismo sea menor o igual a 255. Una inspección detallada del funcionamiento del programa revela que el contador que incrementa la variable está configurado como tipo U8, es decir unsigned byte o byte sin signo. Esto hace que una vez llegado a 255 el siguiente número sea 0 en lugar de 256, reiniciando el índice de extracción de la trama externa. Sucede entonces que para este nuevo inicio ya los arreglos tienen la longitud suficiente para realizar el proceso de manera correcta hasta conseguir el desfasaje. El problema es que debido a la velocidad de la ejecución el ojo humano no se percata de los cambios de la variable que guarda el resultado final, pero al ejecutar el programa en modo de debugging o depuración es claramente notable el hecho de que la misma varía constantemente. Además, la ejecución es incorrecta porque sólo se pueden utilizar desfasajes de valores hasta 255. Esto no fue descubierto sino hasta más adelante, ya que las primeras pruebas se hicieron para valores de desfasaje pequeños, obtenidos mediante un generador de números aleatorios cuyo valor de salida se encuentra entre 0 y ,1 siendo multiplicado luego por una constante de 100 y aproximado a entero con la función Round to Nearest o redondear hacia el más cercano, por lo que inicialmente se continuó en esta línea de trabajo, la cual se explica en los párrafos siguientes. Luego de verificar que para el momento el programa parecía estar funcionando bien, el paso siguiente fue el de evitar el “enganche” que fue discutido previamente entre el buscador y la trama externa. Para esto se implementó en primera instancia un aumento de dos unidades al índice del buscador luego de que se detectara una coincidencia. Esto introdujo errores en la detección ya que, aunque se seguía viendo el desfasaje introducido, se hacía evidente que el mismo no era constante. Surgió entonces la necesidad de descubrir qué valores tomaba el desfasaje, mediante su almacenamiento en un arreglo. Para ello se introdujo dentro del caso true 62 del detector, una estructura flat sequence o secuencia plana, la cual ejecuta cada una de sus ventanas en serie luego de que la anterior finaliza totalmente. La intención de su uso es la de permitir guardar el valor detectado en un arreglo que aumentaría su tamaño con cada detección. Este arreglo se generaría con una función Insert Into Array de la misma forma que ya se ha discutido en detalle con anterioridad. Un vez más, el uso de variables de tipo U8 generaba errores que compensaban la detección del desfasaje durante una parte de la ejecución y la descompensaban totalmente el resto de la misma. Aún sin detectar el problema del tipo de variable se intentó resolver la que parecía ser la causa del error, es decir, el hecho de que el arreglo de entrada del código PN estuviera vacío en la primera ejecución. Para esto se introdujo un retraso en la activación del buscador de manera tal que el arreglo tuviera una longitud que permitiera su correcto procesamiento desde la primera ejecución. El retraso se implementó con un comparador de igualdad entre el número de ciclos de la ejecución del while loop y una constante que se fijó en un valor de 1000 (ver Figura 3.6). De esta manera el arreglo tendría una longitud de este valor antes de iniciarse el proceso de búsqueda. Esto resolvió el problema de la primera ejecución, evitando la detección de valores erróneos para el desfasaje. Llegado este punto el paso siguiente fue simular la situación en la que se presentaran cambios en el desfasaje durante la ejecución, para determinar si el buscador podría responder a los mismos y realizar el reporte. Figura 3.6: Implementación de la espera de 1000 ciclos Fuente: Captura de pantalla del software LabVIEW® 63 Se procedió a la implementación de un case structure que sería activado por el usuario mediante un control en el panel frontal. Se hace pasar a través de la estructura al conector que incrementa la variable del índice de extracción de la trama externa, haciendo que el caso por defecto no realizara ningún cambio y el activado por el usuario ingresara un aumento repentino en la variable. La configuración fue entonces tal que para el caso false, es decir, mientras el usuario no activara el pulsador, el conector de la variable entra y sale de la estructura sin sufrir modificación alguna. El caso true por su parte, toma la variable que entra a la estructura y le suma un número que para el momento fue una constante de 10, y arroja este resultado a la salida para tener así un nuevo índice de extracción de manera repentina (ver Figura 3.7). En las corridas iniciales se obtuvieron resultados satisfactorios, debido a que el generador de desfasaje inicial aleatorio no sobrepasa el valor de 100 y al subir de 10 en 10 se pueden hacer varias detecciones sin que se presenten problemas evidentes, ya que no se utilizaron aún valores mayores a 255. Figura 3.7: Ambos casos de la implementación del reset de desfasaje Fuente: Captura de pantalla del software LabVIEW® Asumiendo hasta el momento que todo funciona como debería, se desea guardar los resultados del desfasaje a medida que se van obteniendo, con miras a generar un arreglo que contenga los valores de cada trayecto detectado. Para esto se implementó dentro del buscador una función Insert Into Array de la misma manera que se ha discutido anteriormente, incrementando el valor del índice de inserción para cada nueva detección. Para evitar posibles repeticiones 64 consecutivas del mismo valor en el arreglo se aplicó un paso previo donde se compara el valor detectado actualmente con el anterior, de manera tal que si son iguales no se realice su escritura en el arreglo. La manera de realizar esta comparación es mediante el uso de la estructura flat sequence, en la que se divide por pasos el proceso de almacenamiento del desfasaje obtenido. Primero este se guarda en una variable para evitar trabajar con la original y ocasionarle modificaciones que pudieran afectar el normal desempeño del buscador. Seguidamente se procede a realizar la comparación. La variable a usar para la comparación no toma su valor sino hasta el tercer paso, por lo que en la primera corrida la misma se encuentra vacía, dando como resultado que no son iguales y procediendo al almacenamiento del desfasaje. En el paso siguiente el proceso de escritura se encuentra dentro de un case structure, por lo que el mismo sólo se activa si el resultado del paso previo es false. Para el caso true no sucede nada en absoluto. Una vez en el caso false, se realiza la escritura en el arreglo del desfasaje detectado, y se guarda su valor en la variable de comparación. Así, en caso de haber detecciones sucesivas del mismo valor las comparaciones siguientes arrojarán un resultado true, evitando su escritura en el arreglo. Es en este momento cuando se hace evidente el error de la utilización de la variable tipo U8, ya que introduciendo varios desfasajes en el proceso de prueba de la escritura en el arreglo de los valores detectados, se sobrepasó el límite de 255 y se obtuvo que las coincidencias empezaban desde cero de nuevo en lugar de incrementarse a razón de 10 unidades como estaba estipulado. Una aproximación inicial al problema incluía llevar un contador que incrementara cada vez que el valor obtenido sobrepasara 255 para luego compensarlo al sumarle la multiplicación de 255 por el número de veces que se sobrepasó dicho valor. Esta línea de acción fue rápidamente abandonada ya que luego de investigar un poco más sobre el tema en la ayuda del software diseño se procedió a realizar el cambio de tipo de variable a I32, es decir, integer o entero de 32 bits, lo cual permite introducir números de valor hasta 231-1 o 2.147.483.647, siendo esto mucho más de lo necesario para esta aplicación. 65 Al hacer esto la relación entre el desfasaje y el número de corridas deja de ser la que se emplea actualmente, y se requiere mantener un contador del número de coincidencias para compensarla. De igual forma este enfoque no fue exitoso, ya que inicialmente se pensaba que era determinante el hecho de que no se tomaba en cuenta la espera introducida al inicio que permite obtener arreglos no vacíos. Al incluir el efecto de esta espera en la operación matemática igualmente no se produjo ningún resultado favorable. Una revisión detallada de la ejecución permitió entender que a pesar de que existía esta espera interna en el buscador, la trama externa seguía entrando vacía debido a que el uso de la nueva variable tipo I32 prevenía el reinicio de la misma que sucedía con la de tipo U8 al volver a empezar, y por lo tanto siempre el indicador de extracción se encontraba adelantado en relación al tamaño real del arreglo. La solución que se encontró en su momento para esta situación fue la de englobar todo el proceso en un case structure para generar otra espera en un nivel superior de la ejecución, dejando por fuera evidentemente la sección de generación del código. Para mantener las relaciones matemáticas entre la detección y el desfasaje introducido en la trama externa, fue necesario incluir el valor de esta nueva espera en la operación del buscador. Haciendo esto se obtiene un resultado positivo una vez transcurrido el tiempo de espera e iniciadas las funciones del buscador. Luego de varias corridas con distintos valores se producen dos errores vinculados entre sí. El primero de ellos es la imposibilidad de introducir valores elevados de desfasaje, ya que el valor máximo posible está limitado por el tiempo de espera seleccionado. A mayor espera, mayor será la longitud del arreglo y por ende se podrá utilizar valores de desfasaje mayores sin obtener un arreglo vacío a la salida. Esto hace impráctica la ejecución del programa ya que se debe esperar un tiempo considerable para poder utilizar todos los valores posibles de desfasaje a la trama externa. El segundo error está vinculado de igual manera al tiempo de espera, ya que sin importar el valor de tiempo seleccionado, se obtendrá un arreglo vacío a la salida del buscador una vez alcanzado el doble de este tiempo. La explicación para este hecho puede entenderse fácilmente mediante un ejemplo. Suponiendo que la espera es de 1000 ciclos, una vez pasado este tiempo el buscador se activa desde cero y la trama externa tiene una longitud igual al número de ciclos. Como el buscador se desplaza al doble de la velocidad de la trama externa, en 500 ciclos (es decir, para un total de 66 1500 en ejecución) ya ha recorrido las primeras 1000 posiciones de la trama externa que está ahora a la par del total, en 1500. En los próximos 500 ciclos, la trama externa pasará de 1500 a 2000 elementos en longitud, y debido a la velocidad del buscador, el mismo pasará de tener un índice de 1000 a 2000. Llegado a este punto ambos tienen el mismo índice, por lo que de ahora en adelante el buscador estará siempre posicionado más adelante que el último elemento de la trama externa, dando como resultado un arreglo vacío y un error en la ejecución. La manera de resolver este inconveniente es haciendo que tanto la trama externa como el buscador sean alimentados con un código de longitud constante y de salida cíclica, es decir, que llegado el final del mismo la salida sea de nuevo el inicio. Así, el buscador nunca encontrará un arreglo vacío para comparar. Esta solución no es encontrada sino hasta más adelante, por lo que se seguirá en la misma línea de acción por los momentos. 3.5. Generación y detección de multitrayectos 3.5.1. Primera aproximación Dado el hecho de que para una parte de la corrida se obtuvieron resultados positivos, se decidió incluir otro trayecto para intentar detectar ambos. Para ello primero se convierte la trama de entrada binaria al formato bipolar tal como se especifica en la sección 2.3.2, por lo que en el detector se sustituye la función XOR por la de multiplicación y se suman todos los elementos de este nuevo arreglo, para luego dividir este resultado entre el tamaño del arreglo y compararlo con una constante de valor 1. Esto es equivalente a la función de autocorrelación expresada en la Ecuacion 1.5, por lo que es de esta manera como se identificará la detección de un desfasaje válido. 67 Figura 3.8: Primer esquema de la detección por correlación Fuente: Captura de pantalla del software LabVIEW® Para simular la presencia de otro trayecto se utiliza la función Array Subset de la misma manera, sólo que el índice de extracción será obtenido de la salida de una función de adición del desfasaje del primer trayecto con una distancia configurable por el usuario. Luego se suman ambas porciones de salida y se alimentan al buscador. Como resultado se obtiene la detección del primer trayecto mas no del segundo, por lo que se prueba agregando una variable auxiliar en el proceso que se encargue de almacenar el valor del índice de extracción del primer piloto durante cada ciclo de la ejecución. Esto es realizado con la intención de obtener una relación matemática entre el desfasaje obtenido y el siguiente a obtener. El problema de este enfoque es que se tiene dependencia de la configuración de los datos del generador, por lo que no lo hace aplicable en un ambiente real, donde estos parámetros son totalmente desconocidos y son de hecho los que se desean determinar. 3.5.2. Generación de trayectos cíclicos En la búsqueda de obtener los desfasajes introducidos por el usuario, llama la atención el hecho de que a pesar de que las tramas involucradas se desplazan como es debido durante la 68 ejecución del programa, las mismas no son realmente cíclicas. Se tenía la idea de que lo eran ya que al tener el generador del código PN-I continuamente produciendo datos se podría simular el hecho de que los códigos volvieran al inicio una vez alcanzado el final, dadas las características de ejecución que se conocen de la teoría del shift register. Una observación detallada del proceso demostró que esto era falso, ya que por un lado no se estaba incluyendo el dígito faltante al código para completar su longitud de 215, y por otro, sin importar qué tan larga fuera la espera para iniciar al buscador, el mismo siempre terminaba sobrepasando a la trama externa y generando arreglos vacios que introducían errores al correcto desempeño del programa. Es de esta manera como surge la idea de convertir tanto las entradas como el buscador, en elementos totalmente cíclicos que no dependieran de un inicio o final para poder operar con ellos libremente. Esto a su vez eliminaría la necesidad de introducir tiempos de espera para el inicio del buscador, haciendo el proyecto mucho más viable según los objetivos del mismo. Para lograrlo se implementó el procedimiento explicado detalladamente en la sección 2.3.3, teniendo de esta manera porciones del código del tamaño que se deseen y que, una vez llegado el final, se tomen los valores del inicio del arreglo (ver Figura 2.4). Esta primera versión detectaba correctamente al primer trayecto, pero la detección del segundo dependía mucho de los valores utilizados. Esto fue debido a que la operación interna del buscador era heredada de versiones anteriores del programa en evolución, y la misma no se correspondía con el nuevo modo de funcionamiento cíclico. Por lo tanto, los cálculos realizados no siempre generaban una solución correcta al momento de detectar el segundo trayecto. Igualmente la detección del desfasaje estaba aún vinculada a la variable auxiliar que genera dependencia del generador, por lo que esta solución seguía sin ser viable. 3.5.3. Modelo de generación, modulación y demodulación de pilotos Buscando adecuar los pilotos utilizados al modelo de generación de CDMA, se inició una nueva línea de trabajo paralela a la del buscador de desfasajes. En este enfoque se toma un arreglo binario constituido únicamente de ceros y se le aplican las etapas estipuladas en el 69 estándar. La primera de ellas es la expansión espectral mediante el código Walsh específico del piloto, el cual se compone de 64 elementos, todos ellos de valor 0. Una vez obtenido el arreglo expandido se procede a convertir todos los ceros en unos, ya que el paso siguiente de enmascaramiento con códigos PN requiere que se trabaje en formato bipolar. Este nuevo arreglo se multiplica por los códigos PN-I y PN-Q de forma independiente, ambos configurados con el mismo índice de extracción. Luego se introdujo el modulador, tomando la rama I para el coseno y la rama Q para el seno de acuerdo a la Figura 1.8 del presente trabajo. Es importante destacar que debido a que el piloto se compone únicamente de ceros que son expandidos con el W0 y luego convertidos a unos, todo este proceso podría intercambiarse por un arreglo constante compuesto únicamente de unos. El motivo por el cual se realizan los pasos teóricos es únicamente con el fin de darle posibilidades de escalabilidad al proyecto. Este asunto se trata con más detalle en la sección “Conclusiones y Recomendaciones”. Para poder modular los elementos del arreglo como amplitudes del seno y coseno es necesario extraerlos uno a uno, con la intención de ensamblarlos de nuevo en el receptor. Una primera aproximación al problema es la de aplicar la función FIFO (first in, first out o lo que es igual a que el primero que llega es el primero que sale) del Modulation Toolkit. Esta función permite obtener los elementos del arreglo uno a uno para que sirvan de amplitud a las señales analógicas. Una vez realizada la modulación, las ramas I y Q se suman para la transmisión (ver Figura 3.9). En el lado del demodulador se multiplica esta señal recibida en dos ramas paralelas, una por el seno y otra por el coseno, obteniendo así una señal con una componente DC que depende de la amplitud utilizada en la transmisión. De esta manera, en el caso inicial de un solo piloto si la amplitud del transmisor era +1 la señal tendría valores positivos, y para el caso de amplitud -1 valores negativos. Viendo esto se aplicó un proceso de decisión muy simplificado que determinaba mediante la obtención de la sumatoria de todos los puntos de la señal si la misma era positiva o negativa, lo cual activaba el escenario correspondiente del case structure, generando entonces una salida de +1 o -1 según el caso. 70 Figura 3.9: Implementación de la función FIFO en el modulador Fuente: Captura de pantalla del software LabVIEW® Luego, estos valores eran ensamblados de nuevo en un arreglo, pudiéndose comparar con el enviado y observándose que se recibía adecuadamente para proceder a la detección de su desfasaje. El problema se presentó al momento de incorporar un segundo trayecto, ya que el mismo nunca era detectado. Una inspección detallada del problema permitió determinar que la causa de la falla estaba en el bloque de ensamblaje del arreglo recibido, ya que el bloque de decisión implementado sólo podría funcionar para el caso de un trayecto. Revisando de nuevo la teoría se pudo resolver este problema aplicando una amplitud de 2 al seno y coseno del receptor, para luego obtener el valor DC de la onda mediante la implementación de la función Basic DC/RMS, la cual obtiene como parámetro de entrada una forma de onda y genera en una de sus salidas el valor DC de la misma. En este valor DC estaría comprendida la suma de las amplitudes de las señales transmitidas, pudiendo así armar un arreglo que correspondiera a la suma digital de ambas señales, el cual pudiera ser alimentado al buscador de desfasajes. Al implementar este cambio se tuvo un resultado mejorado aunque aún con fallas. Los desfasajes introducidos eran detectados, pero también se obtenían muchas detecciones falsas que no habían sido configuradas en el transmisor. Además, la velocidad de la ejecución era muy lenta ya que la función FIFO demoraba mucho el procesamiento de los datos. Buscando optimizar primero la velocidad de ejecución se procedió a sustituirla por una versión adaptada específicamente para la función que tendría en el proyecto, la cual se ejecutaría dentro del programa en lugar de buscar el sub-VI en disco duro (ver Figura 3.10). Esto mejoró un poco la 71 respuesta del software en cuanto a velocidad, pero aun faltaba resolver el problema de la detección excesiva de desfasajes no introducidos en la transmisión. Figura 3.10: Modificación de la función FIFO Fuente: Captura de pantalla del software LabVIEW® Viendo que en ambas ramas se detectaban los valores introducidos pero luego cada una hacia sus propias detecciones extra, se partió del principio de que al compararlas sólo los desfasajes introducidos se encontrarían simultáneamente en ambas. Se procedió entonces a diseñar una rutina que hiciera esta verificación. Para ello se hizo uso de la función Search 1D Array (buscar en un arreglo de una dimensión) de la siguiente manera: una vez que finalizara la corrida completa del buscador, en el último ciclo antes de iniciar una nueva vuelta al código PN, los arreglos de desfasajes obtenidos se guardan en variables para poder reiniciar estos arreglos sin perder sus datos para su procesamiento. Luego del buscador se tiene un case structure con el caso false vacío y el caso true conteniendo la subrutina que opera con estas variables. Para el momento este caso se activa cuando ambos buscadores llegan al final del recorrido y se produce un resultado true de una función AND entre los booleanos de reinicio de los mismos. 72 Una vez dentro del caso activo, se realiza una nueva verificación con un case structure, donde el caso que contiene la subrutina sólo es activado si ambos arreglos no están vacíos, en versiones posteriores el caso externo es activado directamente de esta manera, eliminando la necesidad de la doble verificación. Es en este momento, una vez iniciada la rutina interna, donde se produce la comparación de los arreglos mediante un for loop que tendrá un número de ciclos de ejecución igual a la longitud de uno de los arreglos de coincidencias, obtenida mediante la función Array Size. Dentro del for loop se tiene una función Index Array cuya entrada es el arreglo al que se le obtuvo el tamaño para ejecutar el for loop, y el índice de extracción de elementos se conecta al contador interno del mismo. De esta manera se obtendrán elementos consecutivos del arreglo para cada ciclo, habilitando así la comparación con los elementos del otro arreglo. Es aquí donde se aplica la función Search 1D Array, la cual recibe como parámetros de entrada el arreglo correspondiente a la otra rama y el elemento recién obtenido de la función Index Array que será buscado (ver Figura 3.11). La salida de la función es el valor del índice en el cual se encuentra el elemento de búsqueda, en el caso de que en efecto se encuentre en el arreglo. En caso contrario la función devuelve un valor de -1, para indicar que no existe ningún índice que contenga ese elemento. El paso siguiente es el de generar un arreglo con las coincidencias entre ambas ramas, por lo que se utiliza un case structure cuya activación dependerá del booleano obtenido de la función de comparación entre el valor obtenido de la función Search 1D Array y una constante de valor -1. Así, en los casos en que se obtenga -1 a la salida de la función, es decir, que no se encuentre dicho elemento en el arreglo, el case structure no realiza ninguna acción al haber configurado el caso true vacío. Para el caso en que se produzca una detección el valor no será igual a -1, activando así el caso false que tomará este valor y lo insertará en un arreglo que en principio está vacío pero se llena con cada detección a medida que estas se van generando. 73 Figura 3.11: Buscador de coincidencias Fuente: Captura de pantalla del software LabVIEW® 74 Para asegurar el correcto funcionamiento de esta función, la misma debe incluirse dentro de una estructura flat sequence como segundo paso a ejecutar. El primer paso se realiza con la intención de inicializar los arreglos vacíos y el contador que incrementa el índice de inserción en cero antes de pasar a la escritura. De no hacer esto se concatenarían los resultados de cada corrida uno tras otro en el arreglo. Al implementar esta rutina en el programa principal se observa que esta funciona correctamente pero los resultados obtenidos siguen sin ser los esperados, ya que se detecta un número de coincidencias entre ambas ramas mayor al configurado en el transmisor. En este momento surge la idea de la posibilidad de distinguir entre los desfasajes configurados y los no deseados de acuerdo a su amplitud, asumiendo que los primeros podrían tener una amplitud notablemente mayor. Para comprobar esta teoría, y también con miras a cumplir el objetivo de determinar la potencia de recepción, se implementó como primera aproximación una rutina que al momento de la detección guardara el valor obtenido en la sumatoria de los elementos del arreglo antes de ser divididos entre el período. Este valor no es exactamente el de la potencia sino el de la suma de las amplitudes del arreglo generado por la proyección del segmento recibido sobre el código, pero permitió tener una aproximación inicial a las relaciones de amplitud entre una detección y otra. Para utilizar de manera correcta los valores de potencia se debe cambiar la manera en la cual esta es calculada. Para ello se ubica en el arreglo obtenido en el buscador luego de detectar una coincidencia la función Square, que calcula el cuadrado de cada elemento del arreglo uno a uno. Seguido a esto se ubica una función Add Array Elements, obteniendo a su salida la suma de los cuadrados de los elementos. Al dividir este resultado entre el tamaño total de la ventana de correlación se obtiene la potencia del código detectado, la cual pasará luego a conformar parte de la potencia total del piloto al ser sumada con los trayectos cercanos, si los hubiere. El procedimiento de almacenamiento de estas potencias generadas en cada detección en un arreglo se realiza de la misma manera que ya se ha discutido, implementando una función Insert Into Array con un incremento del índice de inserción para cada detección. Luego de esto se incluyó una nueva función Index Array en la rutina de detección de coincidencias entre las ramas 75 I y Q. Inicialmente sólo se tomaron en cuenta los valores de potencia extraídos del arreglo generado para la rama Q, los cuales eran buscados entre los elementos del arreglo generado para la rama I, ya que el índice de extracción es el mismo que se maneja dentro del case structure. Esto excluía a las potencias obtenidas en la rama I de la sumatoria final, pero luego se implementó una nueva función Index Array cuyo índice de extracción se tomaba de afuera del case structure, es decir, del índice de la rama I que estaba siendo usado en ese momento para la comparación, de manera de obtener el valor de potencia asociado en dicha rama. Las salidas de estas dos funciones se sumaban para obtener la adición del par de potencias obtenidas para ese desfasaje específico. Este resultado era entonces la nueva entrada para la función de armado del arreglo de potencias para las detecciones. Al observar las potencias obtenidas para los desfasajes introducidos y compararlas con aquellas de las detecciones falsas, se notó que no existía un patrón claro de diferenciación. Esto debido a que algunas de las potencias de las detecciones falsas se encontraban dentro del rango de valores de las obtenidas para los desfasajes introducidos. De esta manera se eliminó la teoría de diferenciación por potencia recibida. En este momento se enfocaron los esfuerzos en el desarrollo de un generador más completo, que permitiese la selección del número deseado de pilotos y sus trayectos, así como las amplitudes de cada uno de ellos. Para esto se procedió a duplicar el generador y modulador descrito al inicio de la presente sección, y organizar estos duplicados dentro de case structures que permitan la selección adecuada de los mismos. El primer paso es implementar un case structure principal, el cual permitirá elegir el número de pilotos de acuerdo al caso seleccionado. Se inicia con el caso de un piloto, teniendo dentro del case structure el generador y modulador mencionado, en el escenario denominado “1”. Luego se desea agregar los multitrayectos de este piloto en particular, por lo que se implementa un case structure dentro del ya creado, cuyas opciones de selección permitirán definir el numero de trayectos extra. Para el caso de no desear ningún trayecto, la entrada (que viene a ser la salida del generador del piloto) atraviesa sin cambios la estructura y sale intacta hacia la salida del case 76 structure principal. En el caso de seleccionar un trayecto, se incluye otro generador y modulador dentro de esta estructura interna, y su salida se suma a la entrada proveniente del piloto, para así tener a la salida la suma de ambos. Esto se repite para el caso del segundo trayecto duplicando el caso de un solo trayecto y agregando otro generador y modulador a la suma interna de la estructura. Lo mismo sucede al momento de incluir un tercer trayecto. Tenemos entonces a la salida del case structure principal la generación de un piloto y la posibilidad de agregarle entre cero y tres trayectos extra. Para aumentar el número de pilotos con sus respectivos multitrayectos se procede a duplicar el caso, asignándole el valor de “2” en el indicador del nombre del mismo, y a agregarle otro conjunto completo de piloto y case structure interno de multitrayectos. Las salidas de ambos case structure internos se suman, para tener a la salida de la estructura principal una señal compuesta por todos los elementos que se seleccionen en la configuración. Este procedimiento de duplicación, agregación y suma se repite hasta alcanzar el objetivo de seis pilotos, con hasta tres multitrayectos cada uno, para un total de 24 trayectos posibles a ser detectados. Habiendo obtenido un generador completo y funcional, se retoma la línea de trabajo de la determinación del motivo por el cual se presentan detecciones falsas. Una aproximación a este problema fue la inclusión de filtros pasabajo luego de la recepción, en un intento por depurar aún más los valores digitales obtenidos. Esto no produjo ninguna diferencia ya que la función de obtención de la componente DC ofrecía los mismos resultados que el filtro. Es en este punto donde se cambia el enfoque del problema y se elimina el proceso de modulación y demodulación QPSK, trabajando de esta manera con datos digitales en búsqueda de la solución del por qué de la aparición de las detecciones falsas. Esta eliminación no influye en el objetivo general del proyecto, ya que el mismo no está enfocado en la aplicación de modulación y demodulación de señales, sino en el diseño de un detector de desfasajes. 3.6. Procesamiento digital y representación gráfica de resultados El primer paso para llevar a cabo el procesamiento meramente digital es el de eliminar todas las funciones de seno y coseno existentes en el generador, así como las implementadas en el 77 receptor. Inicialmente no fue retirado del diagrama de bloques el procedimiento análogo a la función FIFO que estaba implementado para obtener las amplitudes de las señales analógicas. Una inspección detallada del programa en ejecución reveló que no era necesario realizar este proceso, ya que se estaba realizando la separación y unión de elementos de manera continua, sin tener un motivo o función específica para obtener los elementos individuales del arreglo. Para este momento se seguían obteniendo detecciones falsas en los resultados, pero de igual forma se decidió proceder con la elaboración de la presentación final del proyecto, con todas las operaciones y procesamiento de datos que esto conlleva. Así, al momento de probar un nuevo enfoque que solucionara el problema, el resto del procesamiento estaría ya desarrollado. El paso siguiente a la obtención de todos los trayectos es el de agruparlos por radiobase. De esta manera se tendría que los trayectos provenientes de la misma radiobase se unen en el receptor para obtener una señal de mayor potencia. La manera de lograr esto es mediante una serie de case structures anidados, que permitan darle el seguimiento al desfasaje obtenido hasta llegar a la última opción posible que lo acerque más al valor fijo que puede tener una radiobase. Llegado este punto, el valor de la potencia se suma a una variable vacía en modo lectura, y se almacena el resultado en la misma variable en modo escritura. Así, en el caso de obtener otro trayecto para esta radiobase, su potencia se sumará a la obtenida de la detección anterior a través de la variable en modo lectura, y así sucesivamente para el resto de las detecciones. Este procedimiento es el cuarto paso del flat sequence, ya que el tercero consiste en inicializar todas sus variables en cero para evitar que corridas siguientes aumenten de manera inadecuada sus valores. Todas las variables involucradas en el almacenamiento de las sumas de las potencias de los trayectos se organizan luego en un arreglo, ordenado según el desfajase fijo posible de cada radiobase. Esto se realiza como quinto paso del la estructura flat sequence, una vez que los valores de potencia de cada uno sean definitivos. Tal como se explicó en la sección 1.5 del presente trabajo, hay un total de 512 posibles desfasajes para asignación a las radiobases, separados una distancia de 64 chips. En el caso específico de este proyecto, los case structures se 78 diseñaron para agrupar 64 posibles desfasajes, separados una distancia de 512 chips. Esta inversión de valores se hizo con la intención de demostrar la operatividad del programa sin necesidad de realizar 512 case structures. En la sección de recomendaciones se vuelve a mencionar con más detalle este asunto. Una vez obtenido el arreglo de potencias de las 64 posibles radiobases se procedió a elaborar las gráficas que reportaran de una manera visual los datos obtenidos. Se realizó una gráfica para el paso previo, donde se tienen los multitrayectos individuales, y una para la presentación de las radiobases definitivas. Esto fue posible mediante el uso de la función XY Graph, la cual recibe como parámetros de entrada los arreglos correspondientes a los valores de ambos ejes, y genera una representación gráfica de los mismos. Esta función permite elegir el tipo de gráfico a mostrar, siendo seleccionado para este proyecto el modo bar plot o gráfico de barras. El arreglo de potencias de los multitrayectos tiene al arreglo de índices de extracción como complemento a la hora de ingresarlos en los ejes de las ordenadas y las abscisas respectivamente. Por otra parte, el arreglo de las potencias por radiobase no cuenta con un arreglo de valores que lo complemente en el eje de las abscisas, por lo que el mismo debe ser generado e ingresado como un constante. Para generar este arreglo se procede de la misma forma que se ha discutido con anterioridad, realimentando un mismo arreglo en modo de escritura y lectura con la función Insert Into Array. Para esto se aumenta el índice de inserción con una variable que incrementa por cada ciclo y un elemento de entrada que a su vez es realimentado en un sumador que lo incrementa en 512 unidades por ciclo. Esto se realiza en un archivo aparte para generar luego el arreglo final de 64 elementos que van del 0 al 32256, en pasos de 512. De este arreglo se obtiene una constante que será usada en el programa principal, para evitar su generación a cada ciclo de ejecución. Teniendo ambos pares de arreglos se procede a generar cada una de las gráficas de interés, ambas en modo de gráfico de barras. 79 3.7. Detección de polución de pilotos Para la detección de la polución de pilotos se partió inicialmente de una comparación simple con un valor umbral, con el motivo de agregarlo a la presentación para ubicar la posición del indicador. Más adelante se optimizó su funcionamiento para adecuarlo al que es ejecutado en realidad de acuerdo a las bases teóricas del mismo. Para realizar la aproximación inicial simplificada se insertó en la cuarta etapa del flat sequence encargado del procesamiento de datos finales, una estructura for loop cuyo número de ciclos sería determinado por una función Array Size a la que se conecta el arreglo final de potencias de radiobase. Dentro de la estructura se obtienen cada uno de los elementos del arreglo mediante el uso de una función Index Array con el índice de extracción conectado al contador de ciclos. Estos elementos se comparan con el valor umbral determinado y se determina si el elemento es mayor o igual a este, la salida booleana de esta función activa un case structure. Para el caso de no ser igual o mayor, la salida false activará un escenario que no realiza ninguna acción. En caso contrario se activa un flat sequence de dos pasos, donde el primero incrementa un contador y el segundo verifica si el contador es mayor o igual a 4, que es el número de portadoras fuertes a partir del cual se considera que hay polución de pilotos. Mientras esta situación no se presente, el indicador del panel frontal será verde y tendrá la leyenda “SITUACIÓN NORMAL”. En caso contrario se activará de color rojo intenso con la leyenda “POLUCIÓN DE PILOTOS”. En este momento se tienen entonces todos los elementos necesarios para el ensamblaje de la interfaz gráfica final de la herramienta, pero primero debe resolverse el problema de las detecciones falsas. La versión definitiva sustituye el valor umbral fijo por un valor 10dB menor a la potencia máxima recibida entre todas las radiobases. De esta manera se adecúa a la definición teórica de polución de pilotos. Para hacer esto se toma el arreglo antes de entrar al for loop y se hace pasar por la función Array Max & Min, la cual devuelve los valores máximos y mínimos del arreglo y sus índices. Al valor máximo se le divide entre 10, y la salida se alimenta al comparador de umbral que se encuentra dentro del for loop. De esta manera se contabilizarán únicamente 80 aquellos pilotos cuya potencia esté en el rango entre 0 y 10 dB por debajo del piloto más potente (ver Figura 3.12). Figura 3.12: Detector de polución Fuente: Captura de pantalla del software LabVIEW® 3.8. Solución al problema de las detecciones falsas Una vez obtenidas las piezas que conformarían la totalidad de los objetivos del proyecto, fue necesario resolver el problema de las detecciones falsas para obtener así la versión final funcional del mismo. Para esto se realizó una inspección a detalle, paso a paso, de todas las etapas del proceso. La causa del problema fue detectada en la generación de los trayectos, ya que a pesar de que en versiones anteriores de prueba los trayectos generados eran cíclicos, sucedía que en estas versiones más avanzadas del software eso no sucedía. Por el contrario, las porciones de los códigos PN de cada trayecto eran siempre fijas. El error fue causado al momento de incluir la generación completa del trayecto con la expansión del código Walsh, ya que en esa primera etapa se instaló un generador cíclico para el piloto constituido únicamente de ceros, lo que generó la confusión y asunción de que los trayectos generados eran a su vez cíclicos. Esto no era así, ya que la característica de ser cíclicos se le confiere en la etapa de enmascaramiento con el código PN, debido a que a pesar de que la 81 entrada a enmascarar sí era cíclica, el código PN era estático. Por ser el enmascaramiento del piloto una multiplicación del código PN por un arreglo constituido únicamente de unos, la salida era siempre el mismo código PN estático, perdiendo así todas las características de un código cíclico. La solución fue incluir en todos los escenarios del case structure del generador, incluyendo los case structure internos, la rutina explicada en la sección 2.3.3 en la cual se corre el índice de extracción de una función Array Subset con un contador y se toman elementos del inicio del arreglo al llegar a los elementos finales, para completar la longitud adecuada. También se debió modificar el tamaño de la ventana de correlación, ya que por tratarse de un escáner este tamaño debe ampliarse para una mejor detección. Al realizar una investigación en internet sobre especificaciones técnicas de escáneres profesionales multifuncionales, se averiguó que el tamaño de la ventana de correlación implementada en algunos de estos dispositivos es de un tamaño igual a 1024 chips [13]. Al implementar el proceso cíclico dentro de todos los casos del generador y aumentar el tamaño de la ventana de correlación para igualar la del escáner profesional, se obtuvo un resultado exitoso para la detección de cualquier número de trayectos que se configurara, sin importar la distancia entre ellos o los valores elegidos para sus desfasajes siempre y cuando los mismos estuvieran en la primera mitad del código PN. Al realizar pruebas en modo de depuración surgió la causa de esta situación. El problema se presentaba debido a que precisamente por la característica del buscador de poseer el doble de la velocidad de la señal recibida, el proceso de búsqueda culminaba en la mitad de la misma, reiniciando el detector de manera cíclica luego de haber recorrido las 32768 posiciones del buscador para solo las primeras 16384 posiciones de la señal. Para resolver este problema y garantizar el funcionamiento adecuado para cualquier valor del rango de posibles desfasajes, se implementó una solución que permitiera el recorrido completo del detector sobre las 32768 posiciones de la señal recibida. Esto se logró con una simple concatenación de dos segmentos de código PN completos a la entrada del buscador, de esta manera el mismo hace el recorrido completo de la señal recibida con dos periodos del código, logrando así satisfacer los casos en que el desfasaje estuviese en la segunda mitad del rango de posibles valores para el mismo. 82 3.9. Recorrido paso a paso del funcionamiento de la herramienta La generación de la señal comienza con la creación de pilotos cíclicos. Su cantidad, desfasajes, amplitudes y número de multitrayectos particulares son configurados en el panel frontal. Dependiendo de la configuración seleccionada se activarán los case structure correspondientes para la generación de la señal a transmitir. El receptor por su parte consta de dos detectores en paralelo, uno para los desfasajes del código PN-I y otro para los del PN-Q. Cada uno de ellos recorre la señal recibida y detecta los desfasajes donde consigue un valor de correlación adecuado. Se almacenan los valores de los desfasajes encontrados y sus potencias de recepción asociadas en dos arreglos. Luego, el arreglo de desfasajes de la rama PN-I se compara término a término con el arreglo obtenido para la rama PN-Q. Para los casos en lo que se consigan coincidencias se almacena tanto este valor, como la suma de las potencias asociadas al mismo en ambas ramas, en la misma posición de dos nuevos arreglos. Estos arreglos componen las parejas de datos que se grafican en la ventana de “MULTITRAYECTOS DETECTADOS”. Seguidamente se toma el arreglo compuesto por los desfasajes detectados y se analiza término a término para ubicar cada uno de ellos en un desfasaje estándar, es decir, el usado por la radiobase que lo transmitió. Paralelamente a esto, se almacena el valor de su potencia en la variable asignada a dicha radiobase para obtener la potencia total de la misma a partir de la sumatoria de todos sus trayectos. Esto genera un nuevo arreglo de potencias definitivas para cada radiobase detectada, el cual junto con un arreglo constante que contiene los desfasajes estándar para cada radiobase pasan a ser los componentes que se grafican en la ventana de “RADIOBASES DETECTADAS”. Durante este procedimiento los valores de todos los arreglos de interés en cada rama, así como los utilizados para realizar las gráficas, son almacenados en una hoja de cálculo en una ubicación del disco duro seleccionada por el usuario, para su visualización en el programa Microsoft Excel ®. De la misma manera, ambas gráficas son exportadas en formato BMP a una ubicación especificada por el usuario, contando además con la posibilidad de sobrescribir las 83 imágenes generadas en simulaciones previas, o guardar cada imagen con un nuevo nombre. Esto permite el post-procesamiento de los datos obtenidos durante la ejecución de la herramienta. 3.10. Diseño de la interfaz gráfica final Para llevar a cabo la organización de los distintos elementos que debían ser controlados u observados por el usuario final, se implementó la estructura Tab Control en el panel frontal, la cual permite tener una organización por pestañas de las ventanas del programa. Luego sólo es necesario arrastrar los indicadores y controladores hacia la ventana deseada y organizarlos de manera estética y funcional. La pestaña principal, llamada CONFIGURACIÓN DEL TRANSMISOR, es donde se incluyen todos los controladores de los parámetros del número de pilotos, multitrayectos por piloto y amplitudes de los mismos (ver Figura 3.13). La segunda ventana, llamada MULTITRAYECTOS DETECTADOS, presenta la gráfica de multitrayectos sin agrupar (ver Figura 3.14). La tercera ventana, llamada RADIOBASES DETECTADAS, presenta la gráfica de las radiobases que fueron identificadas luego de la agrupación de los multitrayectos (ver Figura 3.15). La cuarta ventana, llamada DATOS DE CONTROL, permite visualizar los arreglos de detección de cada rama, así como el arreglo final compuesto de las coincidencias entre ambos, y el arreglo de agrupación por radiobases. Es aquí donde pueden obtenerse los datos específicos de cada uno de los gráficos mostrados en las ventanas anteriores (ver Figura 3.16). La quinta ventana, llamada INSTRUCCIONES, contiene los pasos a seguir para la correcta utilización de la herramienta y el análisis de los datos obtenidos (ver Figura 3.17). 84 Figura 3.13: Ventana de configuración del transmisor Fuente: Captura de pantalla del software LabVIEW® 85 Figura 3.14: Ventana de multitrayectos detectados Fuente: Captura de pantalla del software LabVIEW® 86 Figura 3.15: Ventana de radiobases detectadas Fuente: Captura de pantalla del software LabVIEW® 87 Figura 3.16: Ventana de datos de control Fuente: Captura de pantalla del software LabVIEW® 88 Figura 3.17: Ventana de instrucciones Fuente: Captura de pantalla del software LabVIEW® CAPÍTULO 4 RESULTADOS Y DISCUSIÓN 4.1. Caso ideal: radiobases equidistantes Inicialmente se realizaron pruebas para el caso ideal en que las radiobases se encontraran todas equidistantes del punto de medición. Para simular esta situación se configuraron todas con la misma potencia, asumiendo que la recepción es igualitaria para todas. Para poder reportar el correcto funcionamiento de la herramienta se realizaron pruebas para todos los casos que involucra una sola radiobase, así como el caso crítico de máximo nivel de trayecto para los casos en los que existieran dos, tres, cuatro, cinco o seis radiobases. 4.1.1. Resultados para pruebas de una radiobase Como primera prueba a la herramienta, se simuló el caso en el que existiera una sola radiobase. Esta situación tiene varias ramificaciones dependiendo del número de multitrayectos utilizados. A continuación los resultados para cada uno de ellos, mostrando en las tablas todos aquellos valores no nulos que se obtuvieron en la simulación. 4.1.1.1. Cero multitrayectos Para realizar esta prueba se configuró el transmisor con los siguientes parámetros: 90 Número de Pilotos: 1 Piloto 1: Amplitud: 2V Desfasaje: 512 Número de Multitrayectos: 0 Esto generó como resultado los valores mostrados a continuación en la Tabla 4.1, los cuales generaron las gráficas de las figuras 4.1 y 4.2 Tabla 4.1: Resultados para el caso 4.1.1.1 Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 512 4 512 4 512 8 512 8 91 Figura 4.1: Gráfica de trayectos para el caso 4.1.1.1 Fuente: Datos generados por la herramienta 92 Figura 4.2: Gráfica de radiobases para el caso 4.1.1.1 Fuente: Datos generados por la herramienta 93 4.1.1.2. Un multitrayecto Para realizar esta prueba se configuró el transmisor con los siguientes parámetros: Número de Pilotos: 1 Piloto 1: Amplitud: 2V Desfasaje: 512 Número de Multitrayectos: 1 Trayecto N° 1: Amplitud: 2V Desfasaje: 600 Esto generó como resultado los valores mostrados a continuación en la Tabla 4.2, los cuales generaron las gráficas de las figuras 4.3 y 4.4 Tabla 4.2: Resultados para el caso 4.1.1.2 Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 512 8.031 512 7.609 512 15.641 512 31.266 600 7.922 600 7.703 600 15.625 94 Figura 4.3: Gráfica de trayectos para el caso 4.1.1.2 Fuente: Datos generados por la herramienta 95 Figura 4.4: Gráfica de radiobases para el caso 4.1.1.2 Fuente: Datos generados por la herramienta 96 4.1.1.3. Dos multitrayectos Para realizar esta prueba se configuró el transmisor con los siguientes parámetros: Número de Pilotos: 1 Piloto 1: Amplitud: 2V Desfasaje: 512 Número de Multitrayectos: 2 Trayecto N° 1: Amplitud: 2V Desfasaje: 600 Trayecto N° 2: Amplitud: 2V Desfasaje: 415 Esto generó como resultado los valores mostrados a continuación en la Tabla 4.3, los cuales generaron las gráficas de las figuras 4.5 y 4.6 Tabla 4.3: Resultados para el caso 4.1.1.3 Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 415 12.375 415 11.406 415 23.781 512 71.125 512 12.156 512 11.5 512 23.656 600 12.25 600 11.437 600 23.687 97 Figura 4.5: Gráfica de trayectos para el caso 4.1.1.3 Fuente: Datos generados por la herramienta 98 Figura 4.6: Gráfica de radiobases para el caso 4.1.1.3 Fuente: Datos generados por la herramienta 99 4.1.1.4. Tres multitrayectos Para realizar esta prueba se configuró el transmisor con los siguientes parámetros: Número de Pilotos: 1 Piloto 1: Amplitud: 2V Desfasaje: 512 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 600 Trayecto N° 2: Amplitud: 2V Desfasaje: 415 Trayecto N° 3: Amplitud: 2V Desfasaje: 745 Esto generó como resultado los valores mostrados a continuación en la Tabla 4.4, los cuales generaron las gráficas de las figuras 4.7 y 4.8 Tabla 4.4: Resultados para el caso 4.1.1.4 Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 415 16.312 415 15.344 415 31.656 512 126.484 512 16.109 512 15.547 512 31.656 600 16.234 600 15.297 600 31.531 745 16.141 745 15.5 745 31.641 100 Figura 4.7: Gráfica de trayectos para el caso 4.1.1.4 Fuente: Datos generados por la herramienta 101 Figura 4.8: Gráfica de radiobases para el caso 4.1.1.4 Fuente: Datos generados por la herramienta 102 4.1.2. Resultados para prueba de dos radiobases Una vez comprobado el correcto funcionamiento de la herramienta para todos los posibles casos de una sola radiobase, se simuló el escenario en el que existieran dos. Esta situación tiene varias ramificaciones dependiendo del número de multitrayectos utilizados. De manera de sintetizar la presentación de los resultados se reportará a continuación únicamente el caso crítico en el que de ambas radiobases se recibe el máximo de trayectos configurables. Para realizar esta prueba se configuró el transmisor con los siguientes parámetros: Número de Pilotos: 2 Piloto 1: Amplitud: 2V Desfasaje: 512 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 600 Trayecto N° 2: Amplitud: 2V Desfasaje: 415 Trayecto N° 3: Amplitud: 2V Desfasaje: 745 Amplitud: 2V Desfasaje: 9216 Piloto 2: Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 9301 Trayecto N° 2: Amplitud: 2V Desfasaje: 9173 Trayecto N° 3: Amplitud: 2V Desfasaje: 9267 Esto generó como resultado los valores mostrados a continuación en la Tabla 4.5, los cuales generaron las gráficas de las figuras 4.9 y 4.10 103 Tabla 4.5: Resultados para el caso 4.1.2 Fuente: Datos generados por la herramienta DESFASAJE RAMA I 415 512 600 745 9173 POTENCIA RAMA I 35.25 34.562 34.437 34.594 31.625 DESFASAJE RAMA Q 415 512 600 745 9173 POTENCIA RAMA Q 28.75 29.812 29.531 31.234 30.437 DESFASAJES COINCIDENTES 415 512 600 745 9173 SUMA DE POTENCIAS 64 64.375 63.969 65.828 62.062 DESFASAJES RADIOBASES 512 9216 POTENCIAS RADIOBASES 258.172 252.953 9216 32.125 9216 30.219 9216 62.344 9267 9301 32.812 32.656 9267 9301 31.453 31.625 9267 9301 64.266 64.281 104 Figura 4.9: Gráfica de trayectos para el caso 4.1.2 Fuente: Datos generados por la herramienta 105 Figura 4.10: Gráfica de radiobases para el caso 4.1.2 Fuente: Datos generados por la herramienta 106 4.1.3. Resultados para prueba de tres radiobases Una vez comprobado el correcto funcionamiento de la herramienta para todos los posibles casos de dos radiobases de las cuales se reciben tres multitrayectos para cada una, se simuló el escenario en el que existieran tres. De nuevo, esta situación tiene varias ramificaciones dependiendo del número de multitrayectos utilizados, por lo que a manera de síntesis la presentación de los resultados se reportará a continuación únicamente el caso crítico en el que de las tres radiobases se recibe el máximo de trayectos configurables. Para realizar esta prueba se configuró el transmisor con los siguientes parámetros: Número de Pilotos: 3 Piloto 1: Amplitud: 2V Desfasaje: 512 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 600 Trayecto N° 2: Amplitud: 2V Desfasaje: 415 Trayecto N° 3: Amplitud: 2V Desfasaje: 745 Amplitud: 2V Desfasaje: 9216 Piloto 2: Número de Multitrayectos: 3 Piloto 3: Trayecto N° 1: Amplitud: 2V Desfasaje: 9301 Trayecto N° 2: Amplitud: 2V Desfasaje: 9173 Trayecto N° 3: Amplitud: 2V Desfasaje: 9267 Amplitud: 2V Desfasaje: 4096 Número de Multitrayectos: 3 107 Trayecto N° 1: Amplitud: 2V Desfasaje: 4100 Trayecto N° 2: Amplitud: 2V Desfasaje: 4120 Trayecto N° 3: Amplitud: 2V Desfasaje: 4000 Esto generó como resultado los valores mostrados a continuación en las Tablas 4.6 y 4.7, los cuales generaron las gráficas de las figuras 4.11 y 4.12 Tabla 4.6: Resultados para el caso 4.1.3, primera mitad Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 415 512 600 745 4000 54.484 52.469 52.375 52.937 45.547 415 512 600 745 4000 44.969 46.672 46.437 47.734 49.875 415 512 600 745 4000 99.453 99.141 98.812 100.672 95.422 512 4096 398.078 380.953 4096 45.219 4096 50.062 4096 95.281 Tabla 4.7: Resultados para el caso 4.1.3, segunda mitad Fuente: Datos generados por la herramienta DESFASAJE RAMA I 9173 9216 9267 9301 POTENCIA RAMA I 46.828 47.875 47.625 47.078 DESFASAJE RAMA Q 9173 9216 9267 9301 POTENCIA RAMA Q 45.812 45.406 47.375 47.578 DESFASAJES COINCIDENTES 9173 9216 9267 9301 SUMA DE POTENCIAS 92.641 93.281 95 94.656 DESFASAJES RADIOBASES 9216 POTENCIAS RADIOBASES 375.578 4100 4120 45.312 45.328 4100 4120 50.094 49.516 4100 4120 95.406 94.844 108 Figura 4.11: Gráfica de trayectos para el caso 4.1.3 Fuente: Datos generados por la herramienta 109 Figura 4.12: Gráfica de radiobases para el caso 4.1.3 Fuente: Datos generados por la herramienta 110 4.1.4. Resultados para prueba de cuatro radiobases Una vez más, al comprobar el correcto funcionamiento de la herramienta para todos los posibles casos de tres radiobases de las cuales se reciben tres multitrayectos para cada una, se simuló el escenario en el que existieran cuatro. De nuevo, esta situación tiene varias ramificaciones dependiendo del número de multitrayectos utilizados, por lo que a manera de síntesis la presentación de los resultados se reportará a continuación únicamente el caso crítico en el que de las cuatro radiobases se recibe el máximo de trayectos configurables. Para realizar esta prueba se configuró el transmisor con los siguientes parámetros: Número de Pilotos: 4 Piloto 1: Amplitud: 2V Desfasaje: 512 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 600 Trayecto N° 2: Amplitud: 2V Desfasaje: 415 Trayecto N° 3: Amplitud: 2V Desfasaje: 745 Amplitud: 2V Desfasaje: 9216 Piloto 2: Número de Multitrayectos: 3 Piloto 3: Trayecto N° 1: Amplitud: 2V Desfasaje: 9301 Trayecto N° 2: Amplitud: 2V Desfasaje: 9173 Trayecto N° 3: Amplitud: 2V Desfasaje: 9267 Amplitud: 2V Desfasaje: 4096 Número de Multitrayectos: 3 111 Trayecto N° 1: Amplitud: 2V Desfasaje: 4100 Trayecto N° 2: Amplitud: 2V Desfasaje: 4120 Trayecto N° 3: Amplitud: 2V Desfasaje: 4000 Amplitud: 2V Desfasaje: 29184 Piloto 4: Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 29196 Trayecto N° 2: Amplitud: 2V Desfasaje: 29116 Trayecto N° 3: Amplitud: 2V Desfasaje: 29083 Esto generó como resultado los valores mostrados a continuación en las Tabla 4.8 y 4.9, los cuales generaron las gráficas de las figuras 4.13 y 4.14 Tabla 4.8: Resultados para el caso 4.1.4, primera mitad Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 415 512 600 745 4000 4096 4100 4120 70.656 69.234 68.75 68.719 62.297 61.625 61.937 62.156 415 512 600 745 4000 4096 4100 4120 61.531 64.5 63.609 64.094 65.297 65.469 65.422 65.297 415 512 600 745 4000 4096 4100 4120 132.19 133.73 132.36 132.81 127.59 127.09 127.36 127.45 512 4096 531.09 509.50 112 Tabla 4.9: Resultados para el caso 4.1.4, segunda mitad Fuente: Datos generados por la herramienta DESFASAJE RAMA I 9173 9216 9267 9301 29083 29116 POTENCIA RAMA I 62.703 63.344 63.516 62.969 64.781 65.75 DESFASAJE RAMA Q 9173 9216 9267 9301 29083 29116 POTENCIA RAMA Q 63 62.969 64.656 64.953 59.953 60.75 DESFASAJES COINCIDENTES 9173 9216 9267 9301 29083 29116 SUMA DE POTENCIAS 125.70 126.31 128.17 127.92 124.73 126.50 DESFASAJES RADIOBASES 9216 29184 POTENCIAS RADIOBASES 508.11 507.55 29184 67 29184 60.875 29184 127.88 29196 67.516 29196 60.922 29196 128.44 113 Figura 4.13: Gráfica de trayectos para el caso 4.1.4 Fuente: Datos generados por la herramienta 114 Figura 4.14: Gráfica de radiobases para el caso 4.1.4 Fuente: Datos generados por la herramienta 115 4.1.5. Resultados para prueba de cinco radiobases Habiendo obtenido los resultados para todos los posibles casos de cuatro radiobases de las cuales se reciben tres multitrayectos para cada una, se simuló el escenario en el que existieran cinco. De nuevo, esta situación tiene varias ramificaciones dependiendo del número de multitrayectos utilizados, por lo que a manera de síntesis la presentación de los resultados se reportará a continuación únicamente el caso crítico en el que de las cinco radiobases se recibe el máximo de trayectos configurables. Para realizar esta prueba se configuró el transmisor con los siguientes parámetros: Número de Pilotos: 5 Piloto 1: Amplitud: 2V Desfasaje: 512 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 600 Trayecto N° 2: Amplitud: 2V Desfasaje: 415 Trayecto N° 3: Amplitud: 2V Desfasaje: 745 Amplitud: 2V Desfasaje: 9216 Piloto 2: Número de Multitrayectos: 3 Piloto 3: Trayecto N° 1: Amplitud: 2V Desfasaje: 9301 Trayecto N° 2: Amplitud: 2V Desfasaje: 9173 Trayecto N° 3: Amplitud: 2V Desfasaje: 9267 Amplitud: 2V Desfasaje: 4096 Número de Multitrayectos: 3 116 Trayecto N° 1: Amplitud: 2V Desfasaje: 4100 Trayecto N° 2: Amplitud: 2V Desfasaje: 4120 Trayecto N° 3: Amplitud: 2V Desfasaje: 4000 Amplitud: 2V Desfasaje: 29184 Piloto 4: Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 29196 Trayecto N° 2: Amplitud: 2V Desfasaje: 29116 Trayecto N° 3: Amplitud: 2V Desfasaje: 29083 Amplitud: 2V Desfasaje: 22016 Piloto 5: Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 22101 Trayecto N° 2: Amplitud: 2V Desfasaje: 21872 Trayecto N° 3: Amplitud: 2V Desfasaje: 21946 Esto generó como resultado los valores mostrados a continuación en las Tabla 4.10, 4.11 y 4.12, los cuales generaron las gráficas de las figuras 4.15 y 4.16 117 Tabla 4.10: Resultados para el caso 4.1.5, primer tercio Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 415 512 600 745 4000 4096 4100 4120 84.031 82.687 82.125 82.719 79.125 78.391 78.719 78.125 415 512 600 745 4000 4096 4100 4120 78.656 81.578 79.812 80.234 85.031 85.516 85.625 86.047 415 512 600 745 4000 4096 4100 4120 162.69 164.27 161.94 162.95 164.16 163.91 164.34 164.17 512 4096 651.84 656.58 Tabla 4.11: Resultados para el caso 4.1.5, segundo tercio Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 7608 9173 9216 9267 9301 21872 21946 22016 81.406 78.25 79.859 79.703 79.984 86.75 87.156 85.531 9173 9216 9267 9301 11479 21872 21946 22016 81.594 81.625 82.484 82.953 80.687 81.359 82.359 81.969 9173 9216 9267 9301 21872 21946 22016 22101 159.84 161.48 162.19 162.94 168.11 169.52 167.50 166.30 9216 22016 646.45 671.42 Tabla 4.12: Resultados para el caso 4.1.5, tercer tercio Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 22101 83.516 22101 82.781 29083 155.47 29184 625.25 29083 79.156 29083 76.312 29116 155.36 29116 79.422 29116 75.937 29184 157.05 29184 29196 31102 80.469 80.625 81.984 29184 29196 31988 76.578 76.75 82.703 29196 157.38 118 Figura 4.15: Gráfica de trayectos para el caso 4.1.5 Fuente: Datos generados por la herramienta 119 Figura 4.16: Gráfica de radiobases para el caso 4.1.5 Fuente: Datos generados por la herramienta 120 4.1.6. Resultados para prueba de seis radiobases Para finalizar, se simuló el escenario en el que existieran seis radiobases. De nuevo, esta situación tiene varias ramificaciones dependiendo del número de multitrayectos utilizados, por lo que a manera de síntesis se reportará a continuación únicamente el caso crítico en el que de las seis radiobases se recibe el máximo de trayectos configurables. Para realizar esta prueba se configuró el transmisor con los siguientes parámetros: Número de Pilotos: 6 Piloto 1: Amplitud: 2V Desfasaje: 512 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 600 Trayecto N° 2: Amplitud: 2V Desfasaje: 415 Trayecto N° 3: Amplitud: 2V Desfasaje: 745 Amplitud: 2V Desfasaje: 9216 Piloto 2: Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 9301 Trayecto N° 2: Amplitud: 2V Desfasaje: 9173 Trayecto N° 3: Amplitud: 2V Desfasaje: 9267 Amplitud: 2V Desfasaje: 4096 Piloto 3: Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 4100 Trayecto N° 2: Amplitud: 2V Desfasaje: 4120 121 Trayecto N° 3: Piloto 4: Amplitud: 2V Desfasaje: 4000 Amplitud: 2V Desfasaje: 29184 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 29196 Trayecto N° 2: Amplitud: 2V Desfasaje: 29116 Trayecto N° 3: Amplitud: 2V Desfasaje: 29083 Amplitud: 2V Desfasaje: 22016 Piloto 5: Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 22101 Trayecto N° 2: Amplitud: 2V Desfasaje: 21872 Trayecto N° 3: Amplitud: 2V Desfasaje: 21946 Amplitud: 2V Desfasaje: 22016 Piloto 6: Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 2V Desfasaje: 22101 Trayecto N° 2: Amplitud: 2V Desfasaje: 21872 Trayecto N° 3: Amplitud: 2V Desfasaje: 21946 Esto generó como resultado los valores mostrados a continuación en las Tablas 4.13, 4.14, 4.15 y 4.16, los cuales generaron las gráficas de las figuras 4.17 y 4.18 122 Tabla 4.13: Resultados para el caso 4.1.6, primer cuarto Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 415 512 600 745 2063 3407 102.81 99.36 99.58 99.13 93.66 98.03 415 512 600 745 1214 4000 92.56 94.27 92.80 93.55 104.69 101.31 415 512 600 745 4000 4096 195.38 193.63 192.38 192.67 194.52 194.19 512 4096 774.05 777.92 4000 4096 93.20 93.11 4096 4100 101.08 101.23 4100 4120 194.53 194.69 Tabla 4.14: Resultados para el caso 4.1.6, segundo cuarto Fuente: Datos generados por la herramienta DESFASAJE RAMA I 4100 4120 7608 9173 9216 9267 9301 POTENCIA RAMA I 93.30 93.14 98.58 94.48 94.61 95.09 96.30 DESFASAJE RAMA Q 4120 6500 9173 9216 9267 9301 9974 POTENCIA RAMA Q 101.55 99.28 100.30 99.95 100.41 100.73 103.64 DESFASAJES COINCIDENTES 9173 9216 9267 9301 16279 16308 16384 SUMA DE POTENCIAS 194.78 194.56 195.50 197.03 187.47 187.25 188.83 DESFASAJES RADIOBASES 9216 16384 POTENCIAS RADIOBASES 781.88 750.63 10686 96.55 10715 100.55 16429 187.08 Tabla 4.15: Resultados para el caso 4.1.6, tercer cuarto Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 11477 98.39 11479 97.48 21872 200.91 22016 801.00 12066 101.59 12574 96.14 21946 200.64 14864 91.23 14183 99.17 22016 200.84 16279 96.47 16279 91.00 22101 198.61 16308 95.52 16308 91.73 29083 188.28 29184 757.61 16384 95.03 16384 93.80 29116 188.08 16429 96.25 16429 90.83 29184 190.27 21547 102.14 21601 99.17 29196 190.98 123 Tabla 4.16: Resultados para el caso 4.1.6, último cuarto Fuente: Datos generados por la herramienta DESFASAJE RAMA I 21872 21946 22016 22101 POTENCIA RAMA I 103.19 101.81 102.27 99.27 DESFASAJE RAMA Q 21872 21946 22016 22101 POTENCIA RAMA Q 97.72 98.83 98.58 99.34 DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 24379 98.13 27703 95.55 24481 99.52 29083 93.25 29083 95.03 29116 92.53 29116 95.55 29184 92.39 29184 97.88 29196 92.55 124 Figura 4.17: Gráfica de trayectos para el caso 4.1.6 Fuente: Datos generados por la herramienta 125 Figura 4.18: Gráfica de radiobases para el caso 4.1.6 Fuente: Datos generados por la herramienta 126 4.2. Caso no ideal: radiobases a diferentes distancias Para simular el efecto de recibir las señales provenientes de radiobases que están a diferentes distancias, se modifica la amplitud de la transmisión para obtener pilotos de diferentes potencias en el receptor. Se realizaron pruebas para todos los casos, pero a manera de síntesis se muestra a continuación la más representativa, es decir, para el caso de tener las seis radiobases activas y recibir el máximo de multitrayectos de cada una de ellas. Para realizar esta prueba se configuró el transmisor con los siguientes parámetros: Número de Pilotos: 6 Piloto 1: Amplitud: 1,3V Desfasaje: 512 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 1,3V Desfasaje: 600 Trayecto N° 2: Amplitud: 1,3V Desfasaje: 415 Trayecto N° 3: Amplitud: 1,3V Desfasaje: 745 Piloto 2: Amplitud: 1,8V Desfasaje: 9216 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 1,8V Desfasaje: 9301 Trayecto N° 2: Amplitud: 1,8V Desfasaje: 9173 Trayecto N° 3: Amplitud: 1,8V Desfasaje: 9267 Piloto 3: Amplitud: 1,5V Desfasaje: 4096 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 1,5V Desfasaje: 4100 127 Trayecto N° 2: Amplitud: 1,5V Desfasaje: 4120 Trayecto N° 3: Amplitud: 1,5V Desfasaje: 4000 Piloto 4: Amplitud: 1,9V Desfasaje: 29184 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 1,9V Desfasaje: 29196 Trayecto N° 2: Amplitud: 1,9V Desfasaje: 29116 Trayecto N° 3: Amplitud: 1,9V Desfasaje: 29083 Piloto 5: Amplitud: 1,4V Desfasaje: 22016 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 1,4V Desfasaje: 22101 Trayecto N° 2: Amplitud: 1,4V Desfasaje: 21872 Trayecto N° 3: Amplitud: 1,4V Desfasaje: 21946 Piloto 6: Amplitud: 1,6V Desfasaje: 22016 Número de Multitrayectos: 3 Trayecto N° 1: Amplitud: 1,6V Desfasaje: 22101 Trayecto N° 2: Amplitud: 1,6V Desfasaje: 21872 Trayecto N° 3: Amplitud: 1,6V Desfasaje: 21946 Esto generó como resultado los valores mostrados a continuación en las Tablas 4.17, 4.18 y 4.19, los cuales generaron las gráficas de las figuras 4.19 y 4.20 128 Tabla 4.17: Resultados para el caso 4.2, primer tercio Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 415 512 600 745 2063 4000 65.21 63.15 63.19 63.01 59.84 59.81 415 512 600 745 4000 4096 59.71 60.80 59.56 60.17 63.96 63.70 415 512 600 745 4000 4096 124.92 123.95 122.74 123.17 123.78 123.54 512 4096 494.78 494.97 4096 4100 59.83 59.97 4100 4120 63.78 63.96 4100 4120 123.75 123.90 Tabla 4.18: Resultados para el caso 4.2, segundo tercio Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 4120 9173 9216 9267 9301 59.94 60.58 60.66 61.00 61.70 9173 9216 9267 9301 16279 63.60 63.44 63.69 63.87 57.80 9173 9216 9267 9301 16279 124.18 124.10 124.68 125.57 119.44 9216 16384 498.54 478.93 16279 61.65 16308 58.29 16308 119.44 16308 61.16 16384 59.97 16384 120.64 16384 60.67 16429 58.03 16429 119.40 Tabla 4.19: Resultados para el caso 4.2, último tercio Fuente: Datos generados por la herramienta DESFASAJE RAMA I POTENCIA RAMA I DESFASAJE RAMA Q POTENCIA RAMA Q DESFASAJES COINCIDENTES SUMA DE POTENCIAS DESFASAJES RADIOBASES POTENCIAS RADIOBASES 16429 61.37 21872 62.47 21872 128.19 22016 511.50 21872 65.72 21946 63.13 21946 128.00 21946 64.87 22016 63.34 22016 128.44 22016 65.11 22101 63.61 22101 126.87 22101 63.26 29083 59.34 29083 120.70 29184 486.17 29083 61.37 29116 58.91 29116 120.81 29116 61.90 29184 58.72 29184 122.12 29184 29196 63.40 63.82 29196 58.72 29196 122.54 129 Figura 4.19: Gráfica de trayectos para el caso 4.2 Fuente: Datos generados por la herramienta 130 Figura 4.20: Gráfica de radiobases para el caso 4.2 Fuente: Datos generados por la herramienta 131 4.3. Análisis de resultados y limitaciones del proyecto En primera instancia se aprecia como en el caso ideal de un solo piloto sin multitrayectos ilustrado en la sección 4.1.1.1, la amplitud de transmisión es recibida en cada una de las ramas como potencia, para luego ser sumada en el trayecto y reportada como radiobase. Esto evidencia el buen funcionamiento de la herramienta en cuanto a la correcta detección de los valores transmitidos. Partiendo de este resultado se evalúan los siguientes casos en función de su similitud al caso ideal. En líneas generales, para el caso ideal de radiobases equidistantes se nota que a medida que se incrementan los trayectos transmitidos, los mismos se reciben con mucha más potencia de lo esperado. Tomando el resultado obtenido en la sección 4.1.1.4, donde se evalúa una sola radiobase con el máximo de multitrayectos, se tiene que en cada rama se reciben potencias con valores entre 15,29W y 16,31W. Esto da una potencia promedio de recepción para cada trayecto de 15,82W. Habiendo transmitido 4 trayectos en total, con un valor de amplitud de 2V para cada uno, es de esperarse que se reciba una potencia total de 16W al momento de hacer la detección. Igualmente, en la sección 4.1.6 se transmiten 24 trayectos en total, por lo que en el caso de estudio de un escenario ideal la potencia recibida en cada rama debería ser de 96W, tomando en cuenta la amplitud de 2V al momento de la transmisión. En lugar de eso se tiene que el promedio de todas las detecciones tomando en cuenta ambas ramas es de 97,23W. Al analizar en detalle las causas de estos fenómenos, se tiene que los mismos son ocasionados por dos razones. La primera de ellas es que a pesar de que el código entero cumple la condición de balance de sus elementos, esto no necesariamente sucede en una ventana de correlación de posición aleatoria. Por lo tanto, puede darse el caso de que para algunos trayectos la porción del código que se toma tiene mayor número de unos que de ceros, representando esto un aumento en la potencia promedio de recepción. De igual manera sucede en los casos en que la potencia recibida es menor de la esperada, sólo que la predominancia de elementos en la ventana de correlación en esta situación es del número de ceros. 132 La segunda causa de este fenómeno se le atribuye a la autointerferencia del código, ya que a pesar de que el mismo tiene baja autocorrelación con versiones desplazadas de sí mismo, esto no es necesariamente cierto para el caso de una sumatoria de señales. En este caso los valores de autocorrelación de los códigos se pueden ver afectados en relación a los obtenidos para un único código debido a las contribuciones de cada uno. Otro resultado de interés es el obtenido para la sección 4.2, donde se simula un ambiente en el que las radiobases se encuentran a diferentes distancias del punto de recepción y por ende se detectan con distinta potencia. Se observa que los resultados de ambas ramas tienen todos aproximadamente los mismos valores de potencia, sin importar la amplitud que se haya configurado para cada una de las detecciones en el transmisor, lo cual contradice los resultados esperados para este caso. La sumatoria de los valores de amplitud introducidos para cada radiobase produce un total teórico de potencia de recepción de aproximadamente 60W por cada rama, mientras que la potencia total recibida tiene un promedio de 61,69W. Este aumento es causado por los mismos factores explicados para el caso anterior, es decir, por la autointerferencia y el desbalance del código en la ventana de correlación. Es decir que para cada detección el programa toma la potencia total recibida como la potencia del código, haciendo que para todos los códigos se obtenga un valor promedio cercano entre uno y otro. Con esto se evidencia que a pesar de que el software realiza la detección inequívoca de todos los desfasajes introducidos en la transmisión, es incapaz de discernir entre la potencia total recibida y la potencia individual de cada código. La causa de esta imposibilidad está en la necesidad de implementar un algoritmo de filtrado de la señal, el cual permita separar por completo la señal detectada en una coincidencia, del resto de la sumatoria total de la transmisión[14]. Dicho algoritmo no se encuentra descrito en el estándar IS-95, siendo este entonces propietario de cada fabricante de móviles o escáneres de señales DS-CDMA. Esta viene a ser entonces la limitante de la herramienta. CONCLUSIONES Y RECOMENDACIONES En el presente proyecto de grado se comprobó inicialmente el procedimiento de generación de códigos Walsh, así como los distintos protocolos de prueba de ortogonalidad de los mismos, obteniendo como resultado la matriz descrita en el estándar IS-95, lo cual verifica su validez. Igualmente se comprobó el procedimiento de generación de los códigos de ruido pseudoaleatorio en fase y cuadratura por medio de registros de corrimiento. Se llevaron a cabo los protocolos de prueba que garantizan su pseudoaleatoriedad, tales como la propiedad del balance y la propiedad de la autocorrelación, obteniéndose que los mismos fueron generados correctamente y de acuerdo al estándar. Igualmente se comprobó que el proceso de detección de desfasajes de los códigos pseudoaleatorios en fase y cuadratura para el canal piloto de un sistema DS-CDMA se basa en el empleo de la propiedad de autocorrelación. Esto generó la correcta obtención de dichos desfasajes, los cuales son propios para cada radiobase. En general, la función principal de la herramienta de realizar la detección de la presencia de radiobases de tecnología celular DS-CDMA y su posterior identificación de acuerdo al desfasaje aplicado a su código de enmascaramiento fue alcanzado de manera exitosa. Así mismo, pudo obtenerse una medición de la potencia total de recepción, mas no de la individual de cada desfasaje por carecer de un algoritmo de filtraje de señales digitales. Así mismo, se comprobó también el procedimiento para la determinación de la existencia del fenómeno de polución de pilotos en el punto de estudio. Paralelamente a esto se cumplió también el objetivo de diseñar un algoritmo que unificó los diversos trayectos detectados que provenían de la misma radiobase, sumando sus potencias de recepción. La generación de las señales emitidas por el transmisor se adecúa al estándar IS-95, al haber seguido sus procedimientos al momento de elaborar las rutinas que las producen. Esto hace factible el uso de la herramienta en casos reales de medición de parámetros en ambientes 134 urbanos. Para esto, se hará necesario implementar hardware de detección de señales de radio que incluya componentes de demodulación y antenas que permitan la recepción y tratamiento de señales a la frecuencia de transmisión de la tecnología DS-CDMA. Igualmente, se deberá adecuar el algoritmo de unificación de trayectos al caso real de 512 posibles desfasajes con separación de 64 chips entre ellos, ya que en la herramienta se implementó el caso inverso, tal como fue explicado en el Capítulo 3. Con la intención de expandir las funcionalidades de la herramienta se recomienda el desarrollo e inclusión del algoritmo de filtraje mencionado con anterioridad para lograr la determinación de las potencias individuales de recepción de cada uno de los desfasajes detectados. Así mismo, se recomienda también la inclusión de un módulo de GPS, ya que se hace necesaria la sincronización de la marca de tiempo para la correcta detección de los desfasajes. 135 REFERENCIAS BIBLIOGRÁFICAS [1] Schulze H. y Lüders C., “Theory and Applications of OFDM and CDMA”, John Wiley & Sons Ltd, West Sussex (2005) [2] Yang, S., “CDMA RF System Engineering”, Artech House, Massachusetts (1998) [3] Sklar, B., “Digital Communications: Fundamentals and Applications”, Prentice-Hall, Nueva Jersey (2001) [4] Mandyam G. y Lai J., “Third-Generation CDMA Systems for Enhanced Data Services”, Elsevier Science, Florida (2002) [5] Ipatov, V., “Spread Spectrum and CDMA: Principles and Applications”, John Wiley & Sons Ltd, West Sussex (2005) [6] TIA/EIA-95-B, “Mobile Station-Base Station Compatibility Standard for Dual-Mode Spread Spectrum Systems”, (1998) [7] Byeong Gi, L. y Byoung-Hoon K., “Scrambling Techniques for CDMA Communications”, Kluwer Academic Publishers, Boston (2002) [8] Anderson J. y Svensson A., “Coded Modulation Systems”, Kluwer Academic Publishers, Boston (2002) [9] Rosenberg, A. y Kemp S., “CDMA Capacity and Quality Optimization”, McGrawHill, Nueva York (2004) [10] Walkowski, B., Identifying the Culprits. Disponible en Internet: http://connectedplanetonline.com/wireless/mag/wireless_identifying_culprits/, consultado el 17 de Septiembre de 2010 [11] Sharma, Prateek. 2009. Impact of Pilot Channel Pollution in CDMA Systems. Disponible en Internet: http://www.slideshare.net/thatsprateek/impact-of-pilot-channel-pollution, consultado el 18 de Septiembre de 2010 [12] Proakis, J., “Digital Communications”. McGraw-Hill, Nueva York (1995) 136 [13] Berkeley Varitronics Systems, Dual Channel PN Scanner. Disponible en Internet: http://www.bvsystems.com/Products/CDMA/Condor/Condor.pdf consultado el 18 de Septiembre de 2010 [14] Lenardi, M. y Slock, D., “A Rake Receiver with Intracell Interference Cancellation for a DS-CDMA Synchronous Downlink with Orthogonal Codes”, Vehicular Technology Conference Proceedings, Vol. 1, Mayo 2000, pp. 430-434 137 APÉNDICES 138 APÉNDICE A: Diagrama de bloques de las etapas del sistema 139 Ilustración 1.- Diagrama de bloques del generador de pilotos expandidos por el código Walsh cero y convertidos a formato bipolar 140 Ilustración 2.- Diagrama de bloques del enmascarador cíclico del código PN 141 Ilustración 3.- Diagrama de bloques del case structure interno de selección de multitrayectos 142 Ilustración 4.- Diagrama de bloques del almacenador de coincidencias por cada rama 143 Ilustración 5.- Diagrama de bloques del detector de coincidencias entre las ramas I y Q 144 Ilustración 6.- Diagrama de bloques del detector de polución de pilotos 145 Ilustración 7.- Diagrama de bloques de la rutina de exportación de los datos a hoja de cálculo 146 Ilustración 8.- Diagrama de bloques del proceso de elaboración y exportación de la gráfica de multitrayectos Ilustración 9.- Diagrama de bloques del proceso de elaboración y exportación de la gráfica de radiobases 147 Ilustración 10.- Diagrama de bloques de las opciones del usuario al finalizar la captura
