First-Best Case

En esta sección se entrará en detalle en los bloques del flujograma usados para la implementación del demodulador para un sistema convencional de recepción con modulación jerárquica OFDM.

En la figura 28 se muestra el diseño realizado para un demodulador OFDM con sus respectivos parámetros y configuraciones.

34 Figura 28:Implementación del diagrama de bloques de GNU Radio para el Receptor OFDM.

El bloque “UHD: USRP Source” es utilizado para recibir las muestras que envía el dispositivo USRP (es decir, actuar como el receptor). Algunos de sus parámetros se muestran en la figura 29 y son:

Devices Address -la dirección del dispositivo es una cadena delimitada que se usa para ubicar dispositivos UHD en su sistema. Si se deja en blanco, se utilizará el primer dispositivo UHD encontrado. Utilice la dirección del dispositivo para especificar un dispositivo o una lista de dispositivos.

Sample Rate -la cantidad de muestras por segundo, que es igual al ancho de banda en Hz que deseamos observar. El controlador de dispositivo UHD hará todo lo posible para igualar la frecuencia de muestreo solicitada. Si la tasa solicitada no es posible, el bloque UHD imprimirá un error en tiempo de ejecución.

35 En la figura 30 encontramos el bloque Schmidl & Cox OFDM synchronisation, el cual, depende en su entrada de muestras complejas y la salida es dada por el desplazamiento de frecuencias finas, escalado por la duración del símbolo OFDM

Figura 29:Bloque UHD USRP Source

36 En la figura 31 se encuentra el Bloque Delay el cual tiene como función retrasar la entrada de un cierto número de muestras. Los retardos positivos insertan cero ítems al inicio del flujo. Los retardos negativos descartan los elementos del flujo. Sin embargo, no se puede inicializar este bloque con un retraso negativo. Esto lleva a un problema de causalidad con los búferes cuando se inicializan. Si necesita retrasar negativamente una ruta, entonces ponga el retraso positivo en la otra ruta.

En la figura 32 se observa el bloque Multiply, el cual se encarga de multiplicar todos los flujos de entrada del diagrama.

En la figura 33 se observa el bloque Frecuency Mod el cual es un Bloque modulador de frecuencia. El cual consta de una entrada flotante y una salida de banda base compleja

Figura 33:Bloque Frecuency Mod Figura 31:Bloque Delay

37 En la figura 34 se observa el Bloque Header/Payload Demux el cual está diseñado para demultiplexar paquetes de una transmisión en ráfaga. La aplicación típica para este bloque es el caso cuando está recibiendo paquetes con una longitud que aún no ha sido determinada. Este bloque pasará la sección de cabecera a otros bloques para demodulación. Utilizando la información de la cabecera demodulada, se emitirá la carga útil. El comienzo del encabezado debe ser identificado por una señal de disparo. Además La entrada 0 toma una transmisión continua de muestras (ítems). La entrada 1 es una entrada opcional para la señal de disparo (marcar el comienzo de los paquetes). En este caso, un valor distinto de cero en la entrada 1 identifica el comienzo de un paquete. De lo contrario, se utiliza como desencadenante una etiqueta con la clave especificada en trigger_tag_key (su valor es irrelevante).

Hasta que se detecta una señal de disparo, todas las muestras se dejan caer al suelo. Una vez que se detecta un trigger, se copia un total de elementos header_len a la salida 0. El bloque se detiene hasta que recibe un mensaje en el puerto de mensaje header_data. El mensaje debe ser un diccionario PMT; todos los pares clave/valor se copian como etiquetas en el primer elemento de la carga útil (que se supone es el primer elemento después de la cabecera). El valor correspondiente a la clave especificada en length_tag_key se lee y se toma como la longitud de la carga útil. La carga útil, junto con los datos de cabecera como etiquetas, se copian en la salida 1. Si la demodulación de cabecera falla, la cabecera debe enviar un PMT con el valor pmt::PMT_F. El estado se reinicia y se ignora el encabezado.

38 En la figura 35 se observa el bloque Packet Header Parser el cual, en cierto sentido, es el bloque inverso a packet_headergenerator_bb. La diferencia es que la cabecera analizada no se emite como una secuencia, sino como un diccionario PMT, que se publica en el puerto de mensajes con el identificador “header_data". El diccionario consiste en las etiquetas creadas por el objeto formateador de cabecera. Debería poder utilizar exactamente el mismo objeto de formateo que se utiliza en el lado Tx en el packet_headergenerator_bb. Si sólo se da una longitud de cabecera, este bloque utiliza el formato de cabecera propuesto.

En la figura 36 se encuentra el bloque Constellation Decoder el cual se encarga de decodificar los puntos de una constelación desde un espacio complejo a bits (sin empaquetar) basados en el mapa del objeto de constelación.

El bloque “FFT” de la figura 37 es el asignador de portadora, genera símbolos OFDM (es decir, vectores complejos de longitud FFT). Estas deben convertirse en señales de dominio de tiempo antes de continuar, por lo que se canalizan a un bloque (I) FFT.

Figura 35:Bloque Packet Header Parser

39 En la figura 38 se observa el bloque OFDM Channel Estimation el cual tiene como entrada símbolos OFDM (en el dominio de frecuencia). Se espera que los primeros (o dos) símbolos sean símbolos de sincronización, que se utilizan para estimar la desviación de frecuencia gruesa y las derivaciones iniciales del ecualizador (estos símbolos se eliminan del flujo). Los siguientes n_símbolos_de_datos se pasan sin modificaciones (la ecualización real debe hacerse en otra parte). Salida: Los símbolos de datos, sin los símbolos de sincronización. El primer símbolo de datos atravesado tiene dos etiquetas: ofdm_sync_carr_offset"; (entero), el desplazamiento de frecuencia grueso como número de portadoras, y "ofdm_sync_eq_taps"; (vector complejo). Cualquier etiqueta adjunta a los símbolos de sincronización se adjunta al primer símbolo de datos. Todas las demás etiquetas se propagan como se espera.

Figura 37:Bloque FFT

40 En la figura 39 se encuentra en Bloque OFDM Frame Equalizer el cual realiza la ecualización en una o dos dimensiones en una trama OFDM etiquetada. Esto hace dos cosas: En primer lugar, elimina la desviación del offset. Si se encuentra una etiqueta en el primer elemento con la clave ‘ofdm_sync_carr_offset', se interpreta como el desplazamiento de frecuencia grueso en el número de portadoras. A continuación, realiza la ecualización en una o dos dimensiones en una trama OFDM etiquetada. La ecualización real se realiza mediante un objeto ofdm_frame_equalizer, fuera del bloque. Además, la entrada se caracteriza por ser una serie de símbolos OFDM etiquetados, y su salida es igual que la entrada, pero con ecualización y corrección de frecuencia.

En la figura 40 se observa el bloque OFDM Serializer el cual es un bloque inverso al carrier_allocator_cvc, que produce los símbolos de datos complejos como un flujo etiquetado, descartando los símbolos piloto. Si se dan, se analizan dos etiquetas diferentes: La primera clave (len_tag_key) especifica el número de símbolos OFDM en la trama en la entrada. La segunda clave (packet_len_tag_key) especifica el número de símbolos complejos que se codifican en esta trama. Si se ha dado, esta segunda clave se utiliza en la salida, de lo contrario, se utiliza len_tag_key. Si se dan ambas, la longitud del paquete especifica el número máximo de elementos de salida, y la longitud de la trama especifica el número exacto de elementos de entrada consumidos.Es posible corregir un desplazamiento de portadora en esta función pasando otra etiqueta con dicho desplazamiento.

La entrada son Vectores complejos de longitud fft_len, y su salida escalar complejos, en el mismo orden que los especificados en occupied_carriers.

41 En la figura 41 se observa el Bloque Repack Bits el cual se encarga de Re empacar los bits k del flujo de entrada en bits l del flujo de salida. Aquí no se pierden bits; se permite cualquier valor para k y l (dentro de un rango de [1, 8]). En cada nuevo byte de entrada, comienza a leer en el LSB, y comienza a copiar en el LSB también. Cuando se suministra un nombre de etiqueta, este bloque funciona en flujos etiquetados. En este caso, puede ocurrir que los datos de entrada o de salida se desalineen cuando k * la longitud de entrada no es igual a l * la longitud de salida. En este caso, el parámetro align_output se utiliza para decidir qué paquete de datos alinear.

Figura 40:Bloque OFDM Serializer

42 En la figura 42 se observa el Bloque Stream CRC32 el cual tiene como entrada un flujo de bytes que forman un paquete. El primer byte del paquete tiene una etiqueta con la clave “longitud”; y el valor es el número de bytes del paquete. Salida: Los mismos bytes que los entrantes, pero siguiendo un CRC32 del paquete. La etiqueta se reajusta a la nueva longitud.

En la figura 43 se observa el Bloque Tag Debug el cual se encarga de recoger todas las etiquetas que se le envían en todos los puertos de entrada y las muestra en el stdout de forma forma formateada. El parámetro name se usa para identificar qué sumidero de depuración generó la etiqueta, así que cuando se conecta un bloque a este sumidero de depuración, un nombre apropiado es algo que identifica al bloque de entrada. Este bloque actúa como un sumidero NULL en el sentido de que los elementos del flujo de entrada son ignorados. Está diseñado para poder conectarse a cualquier bloque y ver todas las etiquetas que salen de ese bloque con fines de depuración.La especificación de una clave permitirá que este bloque filtre todas las demás etiquetas y sólo muestre las etiquetas que coincidan con la clave en cuestión. Esto puede ayudar a limpiar el resultado y permitirle concentrarse en una etiqueta en particular de interés.Las etiquetas de la última llamada a esta función de trabajo se almacenan y se pueden recuperar usando la función ‘current_tags'.

Figura 42:Bloque Stream CRC32

43 En la figura 44 se observa el Bloque File Sink el cual se encarga de enviar valores de datos sin procesar en formato binario al archivo especificado. Este archivo se puede leer en cualquier entorno de programación que pueda leer archivos binarios (MATLAB, C, Python, ...). También se puede reproducir en GRC utilizando un bloque de origen de archivo adecuado. El cual se podrá visualizar especificando el nombre del archivo de salida y su ubicación, además Especifica la longitud del vector para el procesamiento de vectores. Las aplicaciones típicas utilizarán el valor predeterminado de 1. El Unbuffered está desactivado ya que si estuviera activo especificaría si la salida se almacena en la memoria intermedi a. Si la salida no tiene buffer, los datos se vaciarán en el archivo cada vez que se llame a la función de trabajo. Esto puede hacer que el diagrama de flujo se ejecute lentamente debido al tiempo requerido para acceder al disco cada vez y ultima característica es que siempre sobre escribe los datos en el archivo de texto para poder leer cada vez que se ejecute el programa el archivo, ya que por estar en constante recepción de datos genera un archivo demasiado pesado.